Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2017

1 participants
62 discussions

ffmpeg.log.20170718
by burek 19 Jul '17

19 Jul '17

[00:00:00 CEST] <furq> http://vpaste.net/PdHkr [00:00:02 CEST] <furq> first video i tried [00:00:31 CEST] <JEEB> kyleogrg: BBB's blog https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-… [00:00:53 CEST] <kyleogrg> ok [00:01:49 CEST] <kyleogrg> when do you except av1 to reach maturity? [00:02:04 CEST] <furq> probably some time next year [00:02:14 CEST] <furq> they're supposedly freezing the bitstream format in Q3 or Q4 of this year [00:02:24 CEST] <kyleogrg> all right [00:02:38 CEST] <kyleogrg> any advantage to using x264 standalone vs within ffmpeg? [00:02:44 CEST] <furq> not that i know of [00:02:48 CEST] <JEEB> not really [00:02:59 CEST] <kyleogrg> thoughts on ripbot264? [00:03:14 CEST] <JEEB> but do keep in mind that bit stream freeze only means that what is "AV1" gets defined [00:03:30 CEST] <furq> yeah it depends what you mean by "maturity" [00:03:33 CEST] <JEEB> in other words, after that point if the encoder doesn't have bugs you should be able to decode your encodes from after that [00:03:43 CEST] <kyleogrg> sure [00:03:43 CEST] <JEEB> on any AV1 decoder [00:03:50 CEST] <furq> if they do freeze the bitstream this year, then one would expect devices with av1 hwdec to show up in 2018 [00:03:55 CEST] <furq> and for places to be serving it by then [00:04:05 CEST] <furq> obviously the encoders will take time to get really good [00:04:16 CEST] <furq> or usably fast if you don't have google's infra [00:04:44 CEST] <kyleogrg> anyone here use ripbot264? [00:05:08 CEST] <furq> there's a million big corps backing it though, and it saves them all a lot of license fees if AV1 succeeds [00:05:14 CEST] <furq> so there should be no shortage of developers [00:05:32 CEST] <kyleogrg> furq: actually that's a really good point. probably with convert a lot of x264 lovers [00:05:39 CEST] <JEEB> sure, it has much bigger chances to succeed than libvpx or x265 [00:06:09 CEST] <furq> the only problem is apple [00:06:10 CEST] <furq> imagine that [00:06:21 CEST] <JEEB> also it was real fun talking with people from GOOG about "why don't you use VBV/HRD in the encoder?" [00:06:34 CEST] <JEEB> "uhh, we just force the client to buffer enough and then the spikes aren't big enough" [00:06:41 CEST] <furq> lol [00:06:52 CEST] <JEEB> tl;dr fuck proper buffer management [00:07:49 CEST] <furq> good job they don't have to deal with bluray players really [00:08:00 CEST] <furq> that statement is true for any value of "they" [00:11:23 CEST] <kyleogrg> what's the best audio codec in your opinion? [00:11:57 CEST] <furq> opus for lossy audio [00:12:25 CEST] <furq> it's not usually worth encoding the audio though [00:12:41 CEST] <furq> unless your source is pcm [00:12:42 CEST] <kyleogrg> furq: you mean like from a lossy youtube download? [00:12:55 CEST] <kyleogrg> yeah [00:13:22 CEST] <kepstin> JEEB: well, I guess that means the libvpx vbv stuff is mostly untested then? :/ [00:16:49 CEST] <kepstin> google is doing segmented media encoding for everything on yt tho, right? any they probably expect the player to buffer multiple segments, so they only really care that the average bitrate within a segment is ok. [00:18:34 CEST] <JEEB> yea [00:25:30 CEST] <kepstin> I suppose vbv controls aren't really super important for internet streaming aside from maybe reducing playback startup time/initial buffering nowadays. [00:26:08 CEST] <c7j8d9> I have a 4k video that direct plays on my tv and another that doesn't so I attempted to encode it the same as the working one to no avail. Any thoughts why the later would not be playing like the first? https://pastebin.com/aDjtgam9 [00:26:13 CEST] <kepstin> it's not like we're encoding for dvd players with <ŒMB of ram any more. [00:35:08 CEST] <Asuran> i guess they just use android now adays [00:35:16 CEST] <Asuran> atleast in tv [01:05:35 CEST] <Asuran> ehm im kinda confused with http://slhck.info/video/2017/02/24/crf-guide.html you can really use in pass 1 crf and pass 2 b:v? [01:06:01 CEST] <Asuran> couldn't you then use like vp9 both with crf? [01:37:29 CEST] <thebombzen> Asuran: 2-pass with CRF doesn't help any more than 1-pass CRF [01:37:47 CEST] <Asuran> thanks [01:40:40 CEST] <LinuxLoader> thebombzen ... what are the most ffmpeg procceses that you are tested on single machine [01:41:05 CEST] <thebombzen> why are you asking me [01:41:12 CEST] <LinuxLoader> because i run out of cpu :( then of GPU :( [01:41:22 CEST] <thebombzen> why are you asking me [01:41:55 CEST] <LinuxLoader> 4xQuadro P5000 and 2xXeon E5-2620 v4 @ 2.10GHz load 100 :) [01:42:16 CEST] <thebombzen> you should not be surprised if your cpu load is 100 percent [01:42:37 CEST] <LinuxLoader> yep :) but i use gpu encoding and decoding [01:43:06 CEST] <thebombzen> "why doesn't it work" is not a question I can answer [02:00:26 CEST] <lindylex> Greeting all I created the following python using mostly ffmpeg for editing media https://github.com/MotionDesignStudio/commandlinemediahelper/blob/master/RE… I added a cross fade affect to the special affects. You can use it like this ./ffmpegHelper.py -e15 vid1.mov vid2.mov 2 out.mp4 [02:24:21 CEST] <Aerroon> has anybody built a video editor on top of ffmpeg? [02:24:33 CEST] <furq> yes [02:25:15 CEST] <Aerroon> sorry i mean a gui video editor [02:25:22 CEST] <furq> yes [02:25:28 CEST] <Aerroon> thanks, then it's worth looking for [02:26:56 CEST] <iive> furq: what is the name of that editor? [02:28:12 CEST] <furq> openshot and shotcut are both built on top of libav* [02:28:39 CEST] <iive> will try them out :D [02:28:44 CEST] <iive> thanks [02:29:01 CEST] <Aerroon> openshot crashed too much for me [05:19:11 CEST] <kyleogrg> Is there a way, even if only in theory, to reduce the file size of a x264 stream without reencoding it? I'm thinking of something like jpegtran for x264. [05:26:48 CEST] <dystopia_> you could stip metadata [05:26:56 CEST] <dystopia_> but that would only save you a few bytes [05:27:10 CEST] <dystopia_> strip* [07:59:32 CEST] <t3v4> Hi all, I need help with public metadata API within ffmpeg. Detailed problem is here https://stackoverflow.com/questions/45050177/adding-metadata-informations-w…. Problem is in write_header function, it produces SIGSEG. Can anyone tell me where I have mistake or to point me where to ask. Thanks! [08:03:42 CEST] <c3r1c3-Win> Is there some place that I can look up what the AVERROR(AV_LOG_ERROR) numbers mean? (and actually all the various libav error codes?) [08:04:30 CEST] <ggggle> http://paste.ubuntu.com/25116964/ [08:04:35 CEST] <ggggle> Original video "Duration: 00:00:21.02",but the output file only "Duration 00:00:00.03". What args I need to add? [08:18:07 CEST] <ggggle> . [08:18:21 CEST] <ggggle> [08:19:00 CEST] Last message repeated 1 time(s). [08:34:03 CEST] <t3v4> Hi all, I need help with public metadata API within ffmpeg. Detailed problem is here https://stackoverflow.com/questions/45050177/adding-metadata-informations-w…. Problem is in write_header function, it produces SIGSEG. Can anyone tell me where I have mistake or to point me where to ask. Thanks! [09:16:59 CEST] <t3v4> . [09:17:00 CEST] Last message repeated 1 time(s). [09:17:12 CEST] Last message repeated 1 time(s). [09:17:12 CEST] <t3v4> Hi all, I need help with public metadata API within ffmpeg. Detailed problem is here https://stackoverflow.com/questions/45050177/adding-metadata-informations-w…. Problem is in write_header function, it produces SIGSEG. Can anyone tell me where I have mistake or to point me where to ask. Thanks! [09:17:14 CEST] <t3v4> . [09:18:00 CEST] Last message repeated 2 time(s). [09:48:57 CEST] <Dazzle982> Hi, I'm trying to make an exact filesize xvid encode on ffmpeg via libxvid. Did pass1 and pass2, set bitrate with the -b:v 1500k parameter, but somehow the end result is much smaller then I gave avg bitrate for. [09:49:46 CEST] <Dazzle982> Am I doing something wrong. Or is it true that libxvid does not really honor the bitrate given to it? [11:18:18 CEST] <flux> when opening an H264 video track from an MPEG4 file the AVStream's codecpar.extradata fills up fine. but when I open a ra H264 stream, it doesn't (I suppose this is natural given the format is AvcDecoderConfigurationRecord from MPEG4). Now I understand I could parse the (beginning) of the H264 stream myself and get the contents, but is there some other way to make FFmpeg provide this data to me? [11:24:55 CEST] <flux> hmm, for example, does the extradata get filled in if I actually read the stream.. ? my code isn't flexible enough to just try it out easily :) [11:28:38 CEST] <LinuxLoader> some one with experience with high load GPU transcoder servers [11:36:34 CEST] <Dazzle982> Hi, I'm trying to make an exact filesize xvid encode on ffmpeg via libxvid. Did pass1 and pass2, set bitrate with the -b:v 1500k parameter, but somehow the end result is much smaller then I gave avg bitrate for. [11:36:47 CEST] <Dazzle982> Am I doing something wrong. Or is it true that libxvid does not really honor the bitrate given to it? [11:39:15 CEST] <Fig1024> there should be a way to set minimum/maximum bitrate [11:40:06 CEST] <Mavrik> Also most encoders won't fake data [11:40:17 CEST] <Mavrik> So if there's not enough content to encode you're not getting bitrate [11:40:45 CEST] <Fig1024> on C++ level you could just add padding [11:41:30 CEST] <Mavrik> Yes, some formats allow adding padding [11:41:32 CEST] <Mavrik> But that's silly [11:42:19 CEST] <Dazzle982> Yea but with a relatively low bitrate as 1500 .. there should always be enough content right? I mean as long as it's not lossless.. there is always more bitrate to assign not? [11:44:45 CEST] <Mavrik> \o/ [11:44:57 CEST] <Mavrik> No idea, libxvid is kinda really old and not used anymore :/ [11:45:44 CEST] <Dazzle982> there is something to say for that .. :P [11:51:40 CEST] <n3wborn> Hi [11:52:11 CEST] <n3wborn> what's the best way to just add a thumbnail to a mp3 ? [11:58:02 CEST] <n3wborn> I find answers on the net but it only explain how to change from flac to mp3 and insert the cover for example. Not just add a thumbnail to an already reencoded file [12:02:07 CEST] <n3wborn> I found the solution :) but thank you, I know you're here for "real" problems [12:02:43 CEST] <Fig1024> you get what you pay for [14:13:03 CEST] <winjer> I'm trying to split up an input file using timings from the blackdetect output. the black detection works great, but the output segments are not the same lengths as I'm specifying, and i really need them to be precise. I'm calling ffmpeg like ffmpeg -i input.mxf -c:v h264_nvenc -vf format=yuv420p -acodec aac -map 0 -g 30 -sc_threshold 0 -force_key_frames [14:13:08 CEST] <winjer> 30.03,35.035,45.045,50.2836,514.314,525.125,782.115,793.059,815.014,825.158,1151.22,1162.03,1423.02,1433.06 -f segment -segment_times 30.03,35.035,45.045,50.2836,514.314,525.125,782.115,793.059,815.014,825.158,1151.22,1162.03,1423.02,1433.06 -segment_time_delta 0.05 -reset_timestamps 1 -y out.part%03d.mp4 [14:13:14 CEST] <winjer> anyone able to point me in the right direction? [14:45:09 CEST] <winjer> looks like ordering of arguments on the command line has some effect [14:45:49 CEST] <klaxa> it has [14:46:07 CEST] <klaxa> ffmpeg [input options] -i <input> [output options] <output> [14:46:31 CEST] <winjer> moving force_key_frames to after segment_times seems to have sorted it? [14:46:42 CEST] Action: winjer tests with a load more files [14:59:48 CEST] <ayum> Hi, I have a question about quick sync performance, I can encoding 8 1080P/30FPS live channels by using the h264_qsv encoder, I think it's very good, but I am plan to encoding maximum 8 1080P/60FPS live channels, is it possible? please give me some idea how to optimize the speed if possible. thanks in advance [15:05:58 CEST] <jkqxz> ayum: Should be achievable on GT4 and maybe GT3; probably not possible on GT2. [15:07:54 CEST] <jkqxz> ayum: The encoder speed is mainly dependent on where the frames come from (preferably they are already in GPU memory) and the rate control mode (CBR or CQP are fastest, anything with lookahead is slower). [15:09:22 CEST] <ayum> the frame is come from capture card, so I think it's in system memory. also, I used 2 memory card, to prevent memory performance bottleneck [15:10:26 CEST] <ayum> when I testing, I usemetrics_monitor to check the GPU usage, I found the RENDER is almost used 100%, but VIDEO only used 60~70%. is this normal? [15:11:23 CEST] <ayum> if I can decrease the RENDER usage, maybe it will faster. how do you think? [15:15:09 CEST] <jkqxz> I think that's normal, though it can vary by options. Encode has to use a lot of render resource (for ME and mode decision); video resource is for the bitstream parts. [15:16:20 CEST] <jkqxz> What chip are you using? [15:18:45 CEST] <ayum> after I changed to use the CBR mode, actually it faster than previous test. I can run 8 1080P/40FPS live channels [15:19:18 CEST] <ayum> skylake i3-6100 + ASUS B150 motherboard [15:20:36 CEST] <ayum> for use quick sync encoding, is i7 faster than i3? I think i7's GPU is more powerful than i3. [15:21:10 CEST] <BtbN> The CPU is not involved with hardware encoding at all [15:21:22 CEST] <BtbN> I think all their GPUs have the same encoder [15:21:28 CEST] <BtbN> within the same generation [15:23:44 CEST] <ayum> I think so, the GPU is same [15:32:02 CEST] <jkqxz> The CPU branding doesn't make any difference. But, that's a GT2 (usually "HD graphics" branding). You probably won't be able to get 8x1080p60 without at least a GT3 ("Iris" branding). [15:39:03 CEST] <jkqxz> The 6100 does have a slightly slower GPU than some of the other desktop models (e.g. 6300 or 6600), but that would only get you another 10%. [15:40:43 CEST] <ayum> I think Xeon E3 v5 is powerful than i3-6100, because it has a Iris graphical card [15:41:49 CEST] <jkqxz> The 15xx SKUs, yes. (12xx SKUs are the same as the desktop Core i parts.) [15:44:34 CEST] <ayum> I just checked some introduction about the Xeon E3 v5 CPU, it can handle up to 15 real-time 1080P/30FPS channels [16:25:19 CEST] <leif> Does anyone know what compiler was used to make the windows builds of ffmpeg here: https://ffmpeg.zeranoe.com/builds/ [16:25:36 CEST] <leif> ? I assume not, but worth asking anyway. [16:26:08 CEST] <leif> (I'm trying to ask so that I can find the correct version of the redistributable VC++ library. [16:27:31 CEST] <kepstin> leif: there's a readme linked from that page which says [16:27:56 CEST] <kepstin> It's built with GCC from MinGW-w64 [16:28:31 CEST] <leif> kepstin: Oh, woops. I thought that was just the ffmpeg readme. Thanks. :) [16:37:12 CEST] <leif> kepstin: Hmm...the readme says they were build with mingw-w64. Doesn't that lack the requirement for the VC++ redistributables? [16:43:03 CEST] <kepstin> yeah, you shouldn't need a VC++ redistributable for that. [16:43:33 CEST] <kepstin> (I think it uses the c++ runtime from gcc, statically linked, and the CRT in windows) [16:50:19 CEST] <leif> Interesting. http://i.imgur.com/QcJ2Oh6.png [16:50:56 CEST] <leif> It 'seems' to want to link to those libs. Maybe gcc has its own C++ runtime that is not included. [16:54:01 CEST] <kepstin> the binary downloads from zeranoe work fine without having to install any other libraries, so that doesn't seem to be the case? [16:54:11 CEST] <kepstin> maybe you need it when linking tho [16:55:37 CEST] <leif> Ya, that would make sense. [16:55:47 CEST] <leif> Because I can absolutely use the executables. [16:56:22 CEST] <leif> But maybe those executables aren't using those DLLs, and are just using staticaly linked builds. [16:56:30 CEST] <leif> Just a guess anyway. I will investigate it more. [16:56:37 CEST] <leif> Thanks again for the help. [17:22:38 CEST] <c7j8d9> I have a 4k 10bit hevc hdr movie. My tv seems to only play x264 4k or VP9 not hevc. Is 10bit hdr possible with H.264 if I convert it myself? [17:28:54 CEST] <iive> c7j8d9: yes, x264 supports 10bit sample encoding, just make sure you have a version that supports it. (it could be built without it). [17:29:46 CEST] <c7j8d9> does chroma sampling have to do with hdr too? 4:2:0 vs 4:4:4? [17:32:09 CEST] <iive> no. chroma sampling means the chroma (color) planes are at smaller resolution (420->1/2*1/2 ; 422->1/2 ; 444 ->1) [17:32:44 CEST] <c7j8d9> thanks iive [17:35:26 CEST] <fberg> hello guys. I have a question about rtsp output: is there any way to set max udp packet length when rtsp is involved (recompiling is also an option, with some hints)? I had success with raw udp and rtp also but I found no way with rtsp. Thank you [17:42:02 CEST] <c7j8d9> is it possible to doctor mediainfo? I have a 4k movie that plays on my tv which the info say hevc but seems that it is an x264 in actuality. [17:43:22 CEST] <iive> c7j8d9: what does ffprobe say about it? [17:43:48 CEST] <c7j8d9> hadn't tried it let me give it a shot. thanks [17:44:08 CEST] <iive> use pastebin site :D [17:44:25 CEST] <iive> if you paste more than 1 line [17:52:03 CEST] <furq> c7j8d9: i would be very surprised if your tv plays x264 hi10p and not hevc main10 [17:52:13 CEST] <furq> hardware support for the former is basically nonexistent [17:52:32 CEST] <furq> s/x264/h264/ [17:55:25 CEST] <c7j8d9> it could be just a 4k x264 8bit thats playing I was hoping to convert the rest of my 4k movies which 2 are 10bit hdr hevc. I haven't tried H.264 10bit yet so it sounds like I would be wasting my time [17:58:49 CEST] <c7j8d9> the movie that works on my tv ffprobe says hevc but I can't get any other hevc to play. I found the same movie who's file size was the same which is an x264 that plays the same so I was thinking maybe the first movie was actually x264. Sorry to be so convoluted. [18:00:26 CEST] <c7j8d9> is it possible my tv doesn't like H.265 but plays x265? [18:00:52 CEST] <kepstin> x265 is an H.265 encoder, that sentence doesn't make sense. [18:01:26 CEST] <c7j8d9> sorry. I thought it meant hardware [18:01:51 CEST] <c7j8d9> can my tv reject hardware encoded hevc as opposed to software encoded? [18:02:25 CEST] <kepstin> c7j8d9: if they're encoded to different profiles, possibly, but it seems unlikely. [18:05:42 CEST] <kerio> if anything i'd expect the opposite to be the case [18:05:54 CEST] <gtt> hello my fellow encoders [18:07:23 CEST] <kyleogrg> Veteran x264 users, please tell me which settings actually matter and which ones you commonly use. For instance, I am usually doing something like this for high-res: -preset veryslow -crf 18 -tune film -pix_fmt yuv420p -profile:v main -level 5.0. I also like to do 10-bit to reduce banding. [18:08:37 CEST] <furq> get rid of the last two options unless you're specifically trying to restrict the output to main(a)5.0 [18:08:49 CEST] <gtt> I have a VOB file of my sister parachuting, cool stuff, but the thing is 390MB and I need to convert it to another format (ideally mp4) while attaining some very decent compression. I already tried `cat vid.VOB | ffmpeg -i - outfile.mp4` and this achieved some decent compression, it brought it down to 290MB which is nice, but I guess more can be done [18:09:26 CEST] <furq> another new entry for my "redundant use of cat" list [18:09:28 CEST] <furq> this one's going in near the top [18:09:36 CEST] <kyleogrg> furq: well, i looked up the highest level which supports my resolution. is that a bad idea? is ffmpeg's default always correct? [18:09:37 CEST] <gtt> for instance I assume the conversion maintained the resolution the same, but aside from downgrading on the resolution, what else can be done? [18:09:55 CEST] <furq> gtt: do you have a build with libx264 [18:10:09 CEST] <furq> i'd expect the default settings for mp4 to compress it better than that [18:10:13 CEST] <furq> it depends a lot on the source though [18:10:21 CEST] <gtt> furq: I don't know mate, how can I test whether it does? [18:10:35 CEST] <gtt> I just installed the default ffmpeg package for archlinux [18:10:45 CEST] <furq> ffmpeg -version | grep -o ...able-libx264 [18:10:46 CEST] <iive> gtt: ffmpeg should be able to read mpeg-ps directly, and .vob is just that. so don't `cat` it [18:11:09 CEST] <gtt> ok [18:11:12 CEST] <furq> or just ffmpeg -codecs | grep x264 [18:11:49 CEST] <furq> kyleogrg: -profile and -level are only useful if you want ffmpeg to restrict the output to a certain level [18:11:49 CEST] <iive> ir -encoders :D [18:11:59 CEST] <furq> otherwise it'll autoselect the correct profile and level [18:12:11 CEST] <gtt> furq: it is compiled with enable-libx264 [18:12:48 CEST] <kyleogrg> furq: aren't there multiple levels which accommodate a given resolution? how can i choose, and how does ffmpeg know the correct one? [18:13:08 CEST] <furq> kyleogrg: you don't choose unless you have a tv or phone or something which only plays a certain level/preset [18:13:46 CEST] <kyleogrg> okay [18:13:53 CEST] <furq> libx264 will automatically select the lowest valid level and preset [18:14:23 CEST] <kyleogrg> is there any advantage to selecting the highest valid level/profile? [18:14:25 CEST] <furq> no [18:14:49 CEST] <furq> by "lowest valid" i mean to accommodate the resolution, settings you've picked etc [18:14:52 CEST] <kyleogrg> sure [18:15:12 CEST] <furq> if you force a lower profile or level then it'll disable certain settings [18:15:32 CEST] <kyleogrg> do you usually use profile and tune presets, or do you customize further? [18:15:47 CEST] <furq> gtt: if this is a vob then i'm guessing it's a dvd that was originally a videocamera [18:15:51 CEST] <furq> so i'm guessing it's noisy and interlaced [18:16:01 CEST] <furq> kyleogrg: i never touch profile or level because i have no devices that need it [18:16:06 CEST] <furq> i always use preset and often use tune [18:16:17 CEST] <furq> and it's very rare i fuck with anything beyond that [18:16:30 CEST] <kyleogrg> furq: oh yeah, i meant preset and tune [18:17:11 CEST] <kyleogrg> i'd like to be more familiar with the under-the-hood settings tho [18:17:21 CEST] <kyleogrg> i guess i just need to start experimenting [18:18:13 CEST] <furq> if you're happy to use -preset veryslow then there's nothing else worth touching really [18:18:40 CEST] <furq> i know there are crazy people out there who are Very Serious about tweaking psy and aq and shit so it's Just Right [18:18:57 CEST] <furq> i always thought that was a waste of time [18:18:59 CEST] <kyleogrg> yeah... diminishing returns i guess [18:19:14 CEST] <furq> preset and tune gets you 99% of the way there [18:19:23 CEST] <kyleogrg> any benefit to using placebo? [18:19:26 CEST] <furq> nope [18:19:28 CEST] <furq> hence the name [18:19:31 CEST] <kyleogrg> i guess the name speaks for itself [18:19:32 CEST] <kyleogrg> yeah [18:19:38 CEST] <furq> i mean it might be marginally more efficient [18:19:43 CEST] <furq> but it turns literally everything up to max [18:19:49 CEST] <kyleogrg> sure, if i have lots of extra time [18:19:51 CEST] <furq> so it takes massively longer than veryslow [18:19:57 CEST] <furq> for basically no benefit [18:20:37 CEST] <kyleogrg> ok, what's a visually lossless crf for UHD video in your opinion? [18:20:55 CEST] <kyleogrg> like 2k to 4k? [18:24:18 CEST] <furq> i normally use 21 for 1080p [18:24:24 CEST] <furq> you could probably go to 22 for 4k [18:24:25 CEST] <Blubberbub> is there a way for a demuxer/AVInputFormat to determine the delay between demuxing and output/playback? [18:25:18 CEST] <kepstin> Blubberbub: maybe start by telling us why you think a demuxer might want that information? [18:27:36 CEST] <kepstin> the answer to the question you asked is of course "no", but if you clarify why you want that maybe we can figure out a way to resolve the problem. [18:28:38 CEST] <Blubberbub> yea, i guessed that its not possible. I wan't to write a demuxer that concatenates files, but decides which file to concat based on the time of day, so to determine which file to load next i would need to know when its going to be played [18:29:44 CEST] <kepstin> Blubberbub: rather than writing a demuxer within ffmpeg, you should be writing an application that uses ffmpeg apis. [18:30:17 CEST] <Blubberbub> yea, but that would mean basically rewriting ffplay... [18:30:22 CEST] <Blubberbub> and i try to avoid that [18:30:27 CEST] <furq> not really [18:30:36 CEST] <furq> it means writing an application which outputs rawvideo that you pipe to ffplay [18:31:06 CEST] <kepstin> Blubberbub: if your input files are concatenatable (e.g. mpeg-ts) you don't even to use ffmpeg apis in your application, it can just do basic file io :/ [18:31:10 CEST] <furq> or failing that you could use something like libmpv [18:31:38 CEST] <Blubberbub> shell-piping is a bad idea, because the buffer-size in the shell-pipe is one more unknown variable, right? [18:32:00 CEST] <Blubberbub> well - i need demux/decode the files before concat as well [18:32:08 CEST] <Blubberbub> and i want to use filters [18:34:28 CEST] <Blubberbub> i only need audio, though... [18:36:39 CEST] <kepstin> unless you really need subsecond accuracy, you shouldn't have an issue with piping stuff, particularly if it's just audio. [18:37:49 CEST] <Blubberbub> i probably could also just ignore the delay introduced by filter & playback buffer. [18:39:47 CEST] <furq> i'm pretty sure there's an fcntl for pipe size on linux now [18:41:50 CEST] <utack> damn, is there a 32bit limited bmp in the chain? "[png @ 0x56537e4c5b40] [IMGUTILS @ 0x7f44ff7a7c60] Picture size 39936x23296 is invalid" [18:43:24 CEST] <utack> seems like yes https://video.stackexchange.com/questions/21000/largest-input-image-size-wh… [18:45:49 CEST] <Blubberbub> the problem i'm running into is basically the missing support for dynamic input files for filter graphs, because a lot of filters depend on EOF. Ideally i want to have an infinite list of inputs generated by a script and each file is individually filtered(volume+silenceremove+...) and then crossfaded and the resulting stream filtered again before outputting. [18:48:08 CEST] <Blubberbub> ^- but that is of course just a very long version of the "it appears i need to write code myself to solve my very specific problem"-complain :D [18:52:20 CEST] <Blubberbub> and i have no good idea on how to really solve the problem, that you can only filter a finite amount of files, which i'd think is useful for more people than just me - but i might be wrong about that [19:18:16 CEST] <kepstin> utack: ffmpeg internally has some limits on the max size (bytes) it will allocate for a single frame [19:18:47 CEST] <kepstin> ah, yeah, that link shows the limits [19:19:28 CEST] Action: kepstin notes that 'int' on 64bit linux is still a 32bit type [19:21:04 CEST] <utack> seems like it [19:22:31 CEST] <__jack__> is that specific to Linux ? it seems that C allows a 64b int, that is not a good idea [19:23:19 CEST] <kepstin> when 64bit x86 abis were being decided back in the day, the linux devs decided to make int 32bit and long 64bit. [19:23:20 CEST] <__jack__> according to wikipedia, C says "int == at least 16 bits", thus you should never store more than 16 bits inside an int [19:24:01 CEST] <kepstin> and so that's how it is, can't be changed now without making everything binary-incompatible [19:24:58 CEST] <leif> Is there any reason that lib avformat-57.dll would not have the symbol av_packet_unref? [19:25:21 CEST] <leif> (I thought, probably incorrectly, that the ABI stayed the same across major versions like that>0 [19:25:23 CEST] <leif> ) * [19:25:37 CEST] <leif> Although perhaps I am missunderstanding the ffmpeg version scheme? [19:25:50 CEST] <kepstin> leif: yeah, it's in libavcodec not libavformat. [19:26:14 CEST] <leif> kepstin: WOW [19:26:16 CEST] <leif> okay [19:26:37 CEST] <leif> The next question....do you have any idea why some copies of libavformat.dylib 'would' have av_packet_unref? [19:26:47 CEST] <leif> (That one could just be me compiling it wrong somehow.) [19:27:32 CEST] <kepstin> leif: no idea, but there are functions in libavformat which call that av_packet_unref, which means that libavformat has to link to libavcodec, and depending on the system that might make the function visible [19:27:59 CEST] <leif> Oh, okay. Actually, that makes a lot of sense. [19:30:41 CEST] <leif> Yup, that was exactly the case. Good catch, thanks. [20:04:49 CEST] <lindylex> HOw do I preserve the audio and have it play in both videos if I have them playing side by side with the following? ffmpeg -i left.mov -i my.mov -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w" -y side.mov [20:06:01 CEST] <klaxa> you mean keep both audio streams and mix them into one? [20:06:18 CEST] <lindylex> Yes [20:06:20 CEST] <klaxa> https://ffmpeg.org/ffmpeg-filters.html#amix [20:14:06 CEST] <kyleogrg> Easiest way to pause, close, open, and resume ffmpeg encoding? [20:16:15 CEST] <relaxed> screen, ctrl-z, and fg [20:18:12 CEST] <kyleogrg> what do you mean? [20:18:39 CEST] <klaxa> if you press ctrl-z in a shell, it usually pauses the process in the foreground [20:18:48 CEST] <klaxa> with fg you can continue it in the foreground [20:19:24 CEST] <kyleogrg> hmm, i'm talking about being able to restart your machine and resume encoding [20:19:47 CEST] <relaxed> nope [20:20:09 CEST] <jkqxz> Run in a VM. [20:20:16 CEST] <kyleogrg> yeah [20:21:06 CEST] <kyleogrg> do you think ffmpeg should have this feature? it seems somewhat basic [20:40:20 CEST] <CounterPillow> that would be incredibly dependant on encoder and container [20:41:24 CEST] <kyleogrg> well, if i put it in a VM and paused the VM, obviously that would work. so is there a way to sandbox one program in windows and pause it? [20:43:15 CEST] <klaxa> if you really need to be able to stop encodes, maybe it would be easiest to split your input by gops and encode one gop after another, then you can stop after each gop and once all are done you can concat them again [20:43:16 CEST] <relaxed> if using a VM works, why not just do that? [20:43:53 CEST] <kyleogrg> relaxed: sure, actually i've been doing that lately with lubuntu. just exploring all the options. [20:44:26 CEST] <kyleogrg> klaxa: yeah, how can you split an input file by gop? [20:45:25 CEST] <kyleogrg> klaxa: also, can i concat x264 sections? [20:45:45 CEST] <klaxa> https://github.com/klaxa/Distributed-encoding/blob/master/server.py#L75 [20:45:52 CEST] <klaxa> this function does exactly that [20:46:01 CEST] <klaxa> it just calls mkvmerge [20:46:14 CEST] <kyleogrg> ah, interesting [20:47:43 CEST] <klaxa> don't pay attention to the poor code quality :P [20:48:08 CEST] <kyleogrg> haha, well i don't even know python [20:48:37 CEST] <kyleogrg> now why split by gop? why not just make 30 second chunks or something like that? [20:48:55 CEST] <CounterPillow> because that's not how video codecs work [20:49:10 CEST] <klaxa> you can do that too, but splitting by gop preserves keyframes [20:49:28 CEST] <klaxa> also you can't actually split at non-keyframes [20:49:32 CEST] <kyleogrg> ahh, yeah, unless i'm actually reencoding those chunks, not stream copying [20:49:36 CEST] <klaxa> basically what CounterPillow said [20:50:32 CEST] <kyleogrg> so i guess i'd segment the input x264/mp4 file to a bunch of ".264" chunks, like myvideo_seg1.264 [20:50:39 CEST] <kyleogrg> then concat [20:51:28 CEST] <klaxa> yeah maybe use a container (i.e. mp4 or mkv) instead of raw h264 [20:51:34 CEST] <klaxa> makes file handling easier [20:52:37 CEST] <kyleogrg> i guess segmenting before encoding won't make much of a practical difference on the output file quality/size? i mean versus encoding the whole file at once? [20:53:04 CEST] <kyleogrg> because the encoder can only look at what's in the segment [20:53:44 CEST] <klaxa> i highly doubt it has a huge impact but i have no data to back that up [20:53:49 CEST] <klaxa> maybe run a test or two [20:53:55 CEST] <kyleogrg> sure [20:57:26 CEST] <c_14> If the input gops you split are the same length as the output gops (in general) there shouldn't be a difference [20:57:34 CEST] <c_14> since a frame can't reference anything outside the gop [20:57:49 CEST] <kyleogrg> yeah. so how would i know that? [20:58:09 CEST] <kyleogrg> i usually just use preset/tune [20:58:17 CEST] <kyleogrg> and crf [21:01:03 CEST] <c_14> I'm not sure what the default gop length is. I think 150? [21:01:44 CEST] <kyleogrg> i guess if i wanted to be picky, i could get the input file's gop from ffmpeg and then set the output settings to the same [21:01:45 CEST] <c_14> But even then it could be marginally larger if the encoder decides to add a keyframe somewhere in the middle due to a scene change that wasn't there in the original and then the cut ends and the next cut starts with a keyframe again [21:03:19 CEST] <kyleogrg> huhhh... is there a way to do a fast-pass gop split? like splitting the input file based on where the x264 wants to put the gops? [21:03:40 CEST] <c_14> don't think so [21:04:06 CEST] <c_14> you could maybe do a first-pass and then manually parse the progress file (though who knows what the format is) [21:05:25 CEST] <kyleogrg> or maybe a way to split the input file based on "scenes"? then at least the x264 encoder is unlikely to suffer from oddly-places cuts, right? [21:09:43 CEST] <c_14> the select filter can select frames at scene changes, but since it can't create the cuts or output timestamps it's not really helpful [21:10:49 CEST] <kyleogrg> i guess it depends on the amount of effort you're willing to put into it. maybe if i did a few steps, or did a lot of output info parsing, i could get the necessary info [21:12:59 CEST] <kyleogrg> supposing i had a text file of all the scene changes, i guess i could make a script that tells ffmpeg to encode each chunk (if it doesn't yet exist). i just need ffmpeg to be able to start at a frame-exact location [21:13:31 CEST] <klaxa> -ss and -t [21:13:33 CEST] <klaxa> are your friend [21:13:40 CEST] <c_14> ffmpeg's -ss is frame-exact in recentish versions of ffmpeg [21:14:05 CEST] <c_14> (on a timestamp level, but not on a framecount level) [21:14:11 CEST] <c_14> So you'll need timestamps not frame numbers [21:14:21 CEST] <kyleogrg> hmm, what's the difference if it's exact both ways? [21:14:25 CEST] <kyleogrg> oh [21:14:32 CEST] <kyleogrg> i just need it to be formatted like a timestamp? [21:14:55 CEST] <c_14> You can't tell ffmpeg to seek to the nth frame, but you can tell it to seek to the frame at the instant XX:YY:ZZ.XYZ or whatever [21:15:00 CEST] <kyleogrg> yeah [21:15:34 CEST] <kyleogrg> ok, now i thought it made a difference whether -ss and -t were before or after -i [21:15:35 CEST] <kyleogrg> true? [21:15:44 CEST] <c_14> not anymore [21:15:49 CEST] <c_14> it's just a speed difference [21:15:58 CEST] <kyleogrg> how so? [21:15:59 CEST] <c_14> (before is faster) [21:16:08 CEST] <kyleogrg> why? [21:16:10 CEST] <c_14> because using -ss before doesn't decode everything up to that point, after does [21:16:22 CEST] <kyleogrg> ah. so why ever use the slower method? [21:16:51 CEST] <c_14> if you have multiple outputs with different seek offsets [21:17:04 CEST] <c_14> There's also mild differences if you're trying to overlay subtitles [21:17:09 CEST] <kyleogrg> ok [21:17:12 CEST] <c_14> (if you don't use -copyts) [21:18:14 CEST] <kyleogrg> i'm kind of paranoid that it can't be exact without decoding [21:18:35 CEST] <klaxa> <klaxa> maybe run a test or two [21:21:16 CEST] <kyleogrg> maybe i will do some test [21:21:47 CEST] <furq> you probably want -f segment -segment times [21:21:56 CEST] <furq> although i don't really know why you want to do this in the first place [21:22:08 CEST] <klaxa> to reboot in the middle of an encode [21:22:19 CEST] <kyleogrg> that's what started my thought process, yes [21:22:47 CEST] <kyleogrg> which led me to think of what's the ideal way to split up an input file for encoding [21:23:12 CEST] <kyleogrg> doesn't -f segment -segment give me gop times? [21:23:30 CEST] <furq> it would if this file was already encoded with x264 [21:23:43 CEST] <furq> that would split by gop in the appropriate places [21:23:56 CEST] <furq> but if it's any other codec then the gops will probably be different than what x264 would select [21:23:57 CEST] <kyleogrg> ok, what about vp9? [21:24:01 CEST] <kyleogrg> yeah [21:24:02 CEST] <furq> shrug [21:24:07 CEST] <furq> idk about modern codecs [21:24:08 CEST] <kyleogrg> makes sense [21:24:11 CEST] <furq> it'll definitely be wrong for mpeg2video [21:24:19 CEST] <furq> which is usually what i'm encoding to x264 [22:15:16 CEST] <dynek> hello [22:15:44 CEST] <dynek> not sure it's worth asking without the full command line but I'm trying to read an h264 stream from a network camera and restream it using hls, but ffmpeg keeps saying: [22:15:55 CEST] <dynek> H.264 bitstream malformed, no startcode found, use the video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v h264_mp4toannexb' option with ffmpeg) [22:16:01 CEST] <dynek> even though I add -bsf:v h264_mp4toannexb [22:16:16 CEST] <dynek> that's ffmpeg 3.2.5-1 [22:30:37 CEST] <dynek> oh well I gave up on va-api that was causing this problem [22:32:21 CEST] <kepstin> kyleogrg: if you just want to encode stuff in smaller granularities so you can reboot part way through, no reason to try to match gop size, you could just split into fairly large chunks, like 5-10 minutes long each [22:33:22 CEST] <kyleogrg> yeah... i thought of that [22:33:46 CEST] <kyleogrg> that is a simpler solution too [22:53:50 CEST] <kepstin> (note that i'd recommend encoding the entire audio track as a separate step, rather than in chunks, because concatenating audio is ... strange) [23:05:47 CEST] <kyleogrg> kepstin: yeah haha, i was going to simply stream copy the audio later or encode the entire track separately [23:17:25 CEST] <jcarpenter2> oi, i'm having a bit of trouble linking against libavcodec - can anybody lend me their eye? https://stackoverflow.com/questions/45177212/linking-with-libavcodec-still-… [23:20:04 CEST] <drv> jcarpenter2: are you including the headers inside extern "C"? [23:20:12 CEST] <atomnuker> jcarpenter2: you still need to link to libavutil and libavformat [23:20:40 CEST] <jcarpenter2> drv: what do you mean? [23:20:51 CEST] <jcarpenter2> atomnuker: added -lavutil -lavformat, no dice [23:21:01 CEST] <jcarpenter2> (same error) [23:23:05 CEST] <drv> extern "C" { #include <libavcodec/avcodec.h> } (with line breaks around the #include) [23:23:49 CEST] <jcarpenter2> drv: thanks, that's the answer [23:24:37 CEST] <kepstin> jcarpenter2: if you don't do that, the compiler assumes they're C++ function names and applies mangling (modifying the function name to include type names), and then they don't match up with the C function names. [23:40:15 CEST] <jcarpenter2> avcodec_find_decoder(AV_CODEC_ID_MP2) is returning null, is that normal? [23:41:26 CEST] <pgorley> jcarpenter2: is the codec registered? [23:41:38 CEST] <JEEB> then that decoder is not registered (you usually want to do av_register_all) [23:43:41 CEST] <jcarpenter2> ah yes, thanks [23:44:31 CEST] <pgorley> vp8_mediacodec always returns "Unsupported or unknown profile" during initialization, but it still tries to decode, resulting a black screen [23:44:38 CEST] <pgorley> any ideas on how to fix this? [23:45:26 CEST] <JEEB> pgorley: hmm that one I haven't actually tried [23:45:46 CEST] <pgorley> looking at the code, it seems that vp8_mediacodec isn't fully implemented [23:45:48 CEST] <JEEB> I've tried that the fallback works with H.264 (10bit) and HEVC [23:46:24 CEST] <pgorley> the call to ff_AMediaCodecProfile_getProfileFromAVCodecContext only returns positive values if using h264 or hevc [23:50:58 CEST] <jkqxz> It would make sense for VP8 to do nothing there, because it doesn't have meaningful profiles. [23:51:05 CEST] <jkqxz> But yeah, ret is clearly -1 in that case... [23:51:55 CEST] <pgorley> so that wouldn't (shouldn't) be the problem i'm having? [23:52:27 CEST] <jkqxz> Don't think so, it's just a warning. [23:53:31 CEST] <jkqxz> Passing the -1 to the following function makes it always return the first profile it finds, which makes sense. [23:54:12 CEST] <pgorley> ah, ffmpeg does eventually print "MediaCodec started successfully, ret = 0" [23:56:46 CEST] <pgorley> i'm guessing the error comes from this line then: D/ACodec: [OMX.MTK.VIDEO.DECODER.VPX] onInputBufferFilled ID 3 w/ time -7301425711502320997 eos 1 mode 1 err -1011 [00:00:00 CEST] --- Wed Jul 19 2017

1 0

ffmpeg-devel.log.20170717
by burek 18 Jul '17

18 Jul '17

[13:07:12 CEST] <J_Darnley> atomnuker: the vc2 encoder does not have a constant quantiser mode, right? [13:09:24 CEST] <J_Darnley> To add that I would need to "remove" the rate control, select the quant I will use, but I still need to calculate how many bytes the bistream will write for every slice, right? [16:17:28 CEST] <J_Darnley> Okay I am almost equally lost in the quantising as I am in the rest of the code. [16:17:53 CEST] <J_Darnley> I can see the encoder counting bits [16:18:10 CEST] <J_Darnley> I can see it using quantiser(s) [16:19:00 CEST] <J_Darnley> but I can't see where they come from [16:20:36 CEST] <J_Darnley> There seems to be tables of them. One for every level and maybe one for each orientation or subband [16:53:55 CEST] <kierank> J_Darnley: comes from ratecontrol I guess [16:58:53 CEST] <atomnuker> J_Darnley: quantization _indices_ range from 0 to 116-ish(check the size of the table) [16:59:01 CEST] <atomnuker> they look up quantizers [16:59:09 CEST] <atomnuker> the quantizers are used to quantize [16:59:32 CEST] <atomnuker> they're fairly large non-linear numbers [16:59:53 CEST] <atomnuker> so to save a few instructions they're pre-generated in a lookup table [17:00:34 CEST] <atomnuker> btw notice the spec says nothing about wavelet depth limit or coefficient intermediates sizes [17:00:45 CEST] <atomnuker> they can be arbitrarily big [17:01:34 CEST] <atomnuker> but for all practical purposes qindices above 90ish are useless with 32 bit wide coeffs and wavelet depth of 5 [17:01:51 CEST] <atomnuker> (the greater the depth the larger the coefficients) [17:02:49 CEST] <atomnuker> rip out the rate control and the bit spreading function and make each slice use a constant one, shouldn't be hard at all [17:05:17 CEST] <J_Darnley> okay thank you [20:42:50 CEST] <J_Darnley> Oh fun! [20:43:18 CEST] <J_Darnley> "Internal error, put_bits buffer too small" [20:49:41 CEST] <J_Darnley> aaaaahhhh! Is that why that memset is there? [20:50:57 CEST] <kierank> yes to zero out the rest of the coeffs [20:51:12 CEST] <J_Darnley> No, this is a different memset [20:51:17 CEST] <kierank> ah [20:51:41 CEST] <J_Darnley> I am using a cache of slice sizes that I think is uninitialised [20:51:51 CEST] <J_Darnley> or might be cleared every frame [20:52:29 CEST] <atomnuker> J_Darnley: no, just increase the slice size in bits [20:52:47 CEST] <atomnuker> you're on a constant quantizer, you'd need to encode twice to get the bit cost [20:53:07 CEST] <atomnuker> have huge amounts of fun figuring out how much to pad each cost in bits [20:54:05 CEST] <J_Darnley> Then what the heck is this stuff I copy-pasted? [20:54:41 CEST] <J_Darnley> ... out of count_hq_slice [20:54:52 CEST] <J_Darnley> Is that not the bit cost? [21:09:04 CEST] <J_Darnley> ugh. removing the use of that cache just changed the problem [21:10:29 CEST] <J_Darnley> oh that might be because I made a different bug by commenting out a line. [21:12:36 CEST] <J_Darnley> ha ha ha [21:12:47 CEST] <J_Darnley> quantiser index 25 looks pretty bad [21:12:57 CEST] <J_Darnley> and the colour is washed out [21:13:09 CEST] <J_Darnley> now didn't I see an option for that? [21:31:58 CEST] <atomnuker> J_Darnley: you might also notice qindices of 1-4 actually take _more_ bits to encode rather than less [21:33:23 CEST] <J_Darnley> I didn't see that yet but now I will look for it [22:06:00 CEST] <iive> atomnuker: do you have some free time to run some tests? [22:06:34 CEST] <atomnuker> in an hour or so [22:06:53 CEST] <iive> great :D [22:12:43 CEST] <durandal_170> atomnuker: will you finish audio denoiser? [22:37:02 CEST] <atomnuker> I need to deal with a lot of things, I'm still not feeling great nor in a great place but if I feel like it I'll finish it [22:39:00 CEST] <iive> you are not well?! [22:39:20 CEST] <atomnuker> first my throat went bad for 3 weeks [22:40:02 CEST] <atomnuker> then just as it started to get well after a course of antibiotics one of my ear tubes got inflamated and it hurt a bit and didn't sound right [22:40:32 CEST] <atomnuker> after treating it with cold water and pills for sore throat the fucker went after my right ear [22:41:19 CEST] <atomnuker> so I had to suffer through another round of ear pain (which only occured just before going to bed) and high frequency muffling [22:42:52 CEST] <atomnuker> and now I think I have a slight tooth ache which is making me paranoid [22:43:22 CEST] <atomnuker> I can't get a fucking break from feeling bad [22:43:40 CEST] <iive> well, at least uk have good and free healthacre [22:43:53 CEST] <iive> but yeh, these are quite bad symptoms [22:43:54 CEST] <atomnuker> they did fuck all [22:44:14 CEST] <atomnuker> no, they're not, so I was told not to bother doing much and that it'll pass [22:44:15 CEST] <iive> you think antibiotics made it worse? [22:44:24 CEST] <atomnuker> no, they made it better, it just spread [22:46:53 CEST] <iive> yeh, it sounds like infection, so antibiotics should handle it well. Just don't forget to take some pro-biotics too, if theya re not already combined. [22:49:52 CEST] <Compnn> atomnuker : i remember reading something about taking ear wax from an ear that didnt have an ear ache to an ear that did ... [22:49:56 CEST] <Compnn> dunno if it will help :D [22:49:58 CEST] <J_Darnley> atomnuker: I now feel a little bad for bothering you with my stupid dirac questions [22:51:06 CEST] <atomnuker> Compnn: while my right ear was inflamated I couldn't get any out, after it went away a few days ago I pulled out quite a lot [22:52:57 CEST] <atomnuker> J_Darnley: bah, its fine, at least I haven't had anything actually serious in a while *knocks on wood* [22:53:23 CEST] <J_Darnley> Well that's something good then [22:59:12 CEST] <iive> ear wax has some anti-microbial properties, so cleaning it too much can actually be bad thing. but that's not the case here [23:00:06 CEST] <iive> it sounds more like infection going into the sinuses and internal ear. and that's why i said it is bad symptoms [23:00:11 CEST] <Compnn> never stick anything into your ear :( [23:00:15 CEST] <Compnn> sinus infection yes :( [00:00:00 CEST] --- Tue Jul 18 2017

1 0

ffmpeg.log.20170717
by burek 18 Jul '17

18 Jul '17

[11:18:34 CEST] <kier[work]> hi all, having an interesting problem: i'm passing "--enable-vaapi --enable-hwaccels" to configure, and it reports that it's going to build said hwaccels, but the resulting ffmpeg executable doesn't seem to include them (ffmpeg -hwaccels doesn't list any) [11:19:17 CEST] <kier[work]> this is on version 3.0. This problem doesn't occur on the latest version, so it's just a legacy issue [11:19:56 CEST] <kier[work]> is there some magic configure flag that I'm missing, or does this just not work in v3.0? [11:32:30 CEST] <Fig1024> I heard there was some change to the way hardware acceleration was handled, I don't think hwaccels is used. But I dunno for sure [11:33:27 CEST] <Fig1024> now hardware encoders have their own codec ID and names, so like nvenc is NVidia h264 [11:34:13 CEST] <kier[work]> ah i'm looking at decoders, forgot to say that earlier [11:35:11 CEST] <kier[work]> afaict encoders have their own codec (e.g. hevc_vaapi) as you say, while decoders use the "hevc" codec with a hwaccel enabled [11:35:58 CEST] <kier[work]> apologies if that sentence didn't make any sense, haven't had enough coffee yet today [11:46:42 CEST] <jkqxz> kier[work]: 3.0 does not support VAAPI decode in the ffmpeg utility, only through libavcodec. [11:48:11 CEST] <kier[work]> jkqxz: ah, thanks [13:51:00 CEST] <kiki`> hi. i have the following task: concat videoA (100frames) and videoB (100frames) blending videoB over VideoA using N (lets say 20) frames -> so effectively at frame 80 videoA starts to crossfade to videoB .. resulting in 180 frames .. im trying for hours now, but its really just a simple crossfade between two channels.. can u help? [13:52:22 CEST] <Mavrik> That sounds like a task for a video editing software, not ffmpeg :/ [13:52:31 CEST] <Mavrik> I don't know of a way that wouldn't be painful as heck [13:54:36 CEST] <furq> i've done this before for the benefit of someone on irc [13:54:39 CEST] <furq> but yeah, it's pretty horrible [13:56:01 CEST] <kiki`> ffmpeg -i videoA -i videoB -complex_filter [0:v]setpts=pts+80[a],[1:v][b],[a][b]blend=blah sth like that the fucj [13:56:10 CEST] <kiki`> it is [13:56:44 CEST] <kiki`> i guess once one understands that cryptic syntax its super powerful [13:57:58 CEST] <Forgon> Why does this command not work? I want to extract pictures from seconds 16:31 to 16:76 out of an mkv videofile. [13:58:23 CEST] <Forgon> ffmpeg -i input.mkv -ss 16:31 -to 16:76 -q:v 'picture\%03.png' [13:59:43 CEST] <furq> what is 16:76 supposed to be [14:00:25 CEST] <furq> if that's supposed to be 16 seconds then you want 16.76 [14:01:14 CEST] <Forgon> Okay thanks [14:01:21 CEST] <furq> also get rid of -q:v [14:17:01 CEST] <Asuran> ehm, is it possible that ffmpeg shows also how many frames are left to encode? [14:28:42 CEST] <DHE> unfortunately not. it's not always known or even accurate without reading the whole input ahead of time just to measure it. [14:29:12 CEST] <DHE> above the progress report is ffmpeg's best guess as to the duration, so you can see how it's going with regards to time [14:35:16 CEST] <JEEB> yea, if you're only dealing with files then I recommend using something like ffms2 that is a library which wraps around FFmpeg's libraries to create an index and use seeking/decoding according to that [15:20:33 CEST] <t3v4> Hi all [15:21:30 CEST] <t3v4> I have problem with metadata API via AVFormatContext. Detailed problem is here: https://stackoverflow.com/questions/45050177/adding-metadata-informations-w… [15:21:38 CEST] <t3v4> Can anyone help me with this? Thanks! [15:31:19 CEST] <DHE> the most glaring issue is that you're not using AVDictionaryEntry properly [15:31:50 CEST] <DHE> oops, sorry my bad. [15:32:09 CEST] <DHE> can you at least indicate what line it crashes on? [15:58:53 CEST] <t3v4> hi [15:59:06 CEST] <durandal_1707> hi [16:01:30 CEST] <DHE> wtf... [16:01:55 CEST] <shincodex> i assume his shit crashes on tag [16:01:59 CEST] <shincodex> tag->key [16:02:05 CEST] <shincodex> probably null ptr [16:02:30 CEST] <shincodex> AVDictionaryEntry *tag = nullptr; [16:02:36 CEST] <shincodex> thats a abomination [16:02:49 CEST] <t3v4> problem is at int status = avformat_write_header(ctx, &ctx->metadata); [16:02:53 CEST] <t3v4> its causing sigseg [16:11:58 CEST] <shincodex> does crash go away when you remove av_dict_set(&ctx->metadata, "TPFL", "testtest", 0); [16:26:58 CEST] <Asuran> DHE, JEEB ok thx [18:24:03 CEST] <Blubberbub> Hello, i've got a question about the design of the filters and filtergraph. Maybe i'm missing something, but it looks to me, that these are not designed to work with streaming applications at all, because: A lot of the filters require an EOF to function properly and will shut down afterwards. You can only feed in a predetermined number of files. (Example: concat list of files, but silenceremove them individually before concat or [18:24:03 CEST] <Blubberbub> acrossfade a list of files or stream of files) Am i right about this or am i missing something? Was this a deliberate design decision? [18:27:07 CEST] <JEEB> Blubberbub: it works for streaming but you might have to re-init the filterchain if you have an input count change [18:27:45 CEST] <JEEB> unless you build a separate filter chain for each stream [18:28:16 CEST] <JEEB> of course there are specific filters where the use case is more limited [18:28:27 CEST] <RealName7890> Why is it that my bitrate is being ignored and the encoding is going over the CBR that i specify for libvpx? [18:28:55 CEST] <RealName7890> ffmpeg -i in.mp4 -an -ss 120 -t 119 -c:v libvpx -bufsize 10k -b:v 180k -y -threads 4 -speed 0 [18:28:55 CEST] <RealName7890> output.webm [18:29:23 CEST] <JEEB> have you set maxrate+bufsize and just fyi libvpx's rate control is known to be bad [18:29:43 CEST] <Blubberbub> so i need to reinit it every time and it does not work out of the box with ffmpeg, but needs a custom application [18:30:15 CEST] <JEEB> Blubberbub: depends on the filters you want to use, but yes [18:30:34 CEST] <Blubberbub> i thought it would be great, if there would be some additional kind of link that supports multiple files after one another separated by a special packet or something like that. [18:31:05 CEST] <Blubberbub> and then have filters that turn this into a "normal" stream - like concat, or crossfade [18:31:17 CEST] <JEEB> I mean even with ffmpeg.c I can do streaming with specific filters. ffmpeg.c is just very static regarding inputs etc [18:31:50 CEST] <Blubberbub> you need to know your input files in advance, though. You cannot really play an infinite amount of files [18:31:53 CEST] <RealName7890> JEEB, it's still going over: ffmpeg -i .\in.mp4 -an -ss 120 -t 119 -c:v libvpx -bufsize 10k -b:v 180k -maxrate 180k -y -threa [18:31:53 CEST] <RealName7890> ds 4 -speed 0 out3.webm [18:32:14 CEST] <JEEB> RealName7890: also is that vp8 or 9? [18:32:23 CEST] <RealName7890> JEEB, vp8 i believe [18:32:35 CEST] <JEEB> and yea, have fun with libvpx \o/ [18:32:49 CEST] <JEEB> #vp8 might be able to help [18:32:57 CEST] <RealName7890> JEEB, should the -bufsize be high or low to have a more accurate bitrate? [18:33:29 CEST] <JEEB> RealName7890: you just have to calculate bits with the buffer size [18:34:03 CEST] <JEEB> as long as you use the bufsize in calculations you should get valid results [18:34:08 CEST] <RealName7890> JEEB, how do i do that? [18:34:33 CEST] <RealName7890> I don't understand what you meant [18:35:31 CEST] <JEEB> google for vbv.pl [18:35:43 CEST] <JEEB> that should have a function that explains you [18:36:16 CEST] <Blubberbub> Thanks for your answers, JEEB. Do you think this "static-ness" for input files is by design or is it considered a "missing feature"? [18:36:49 CEST] <RealName7890> JEEB, I only did: bitrate = (target filesize in kilobits) / (length in seconds) kbps [18:36:53 CEST] <JEEB> duration and size of packet and bufsize+maxrate let you calculate if you are within your vbv or not [18:37:08 CEST] <cableguy> hello, team [18:37:24 CEST] <cableguy> my ffmpeg wont copy subtitle stream/track [18:37:35 CEST] <JEEB> Blubberbub: lavfi should be improved a lot and ideas/patches are generally welcome [18:37:36 CEST] <cableguy> ffmpeg -i "source.VOB" -map 0:v -map 0:a -map 0:s -c copy -fs 10000000 -ss 00:00:00 -t 00:10:00 "split.vob" [18:37:48 CEST] <cableguy> 'Stream map '0:s' matches no streams.' [18:38:31 CEST] <JEEB> then there are no subs according to ffmpeg [18:38:31 CEST] <RealName7890> JEEB, I was trying to do CBR to get the targetted file size. [18:38:33 CEST] <JEEB> c [18:38:42 CEST] <cableguy> but they are [18:38:46 CEST] <cableguy> mediainfo shows them [18:39:17 CEST] <cableguy> Text ID 189 (0xBD)-33 (0x21) [18:39:30 CEST] <cableguy> they exist in the vob and play in any player [18:44:25 CEST] <RealName7890> JEEB, I think the problem was that I had to set minrate and maxrate [18:44:30 CEST] <RealName7890> i was missing minrate [18:50:52 CEST] <gmoryes> Can somebody help? Why I can't see audio-bitrate from webm format? Using this command: ffprobe -analyzeduration 20M -i video.webm? [18:51:30 CEST] <gmoryes> And this I can see in the output [18:51:31 CEST] <gmoryes> Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default) [18:51:59 CEST] <gmoryes> where is bitrate? And yes, there is an audio in video [18:52:57 CEST] <Asuran> idk maybe due vbr [18:53:56 CEST] <Asuran> what about ffmpeg -i file? [18:54:48 CEST] <gmoryes> the same situation [18:54:51 CEST] <gmoryes> Duration: 00:07:56.09, start: 0.000000, bitrate: 640 kb/s Stream #0:0: Video: vp8, yuv420p, 640x360, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default) Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default) [18:55:44 CEST] <gmoryes> Okey, let propose it has a variable bitrate [18:56:54 CEST] <gmoryes> Do anybody know how to know is it variable bitrate or not? [19:02:21 CEST] <JEEB> RealName7890: minrate is generally something you do not set [19:02:21 CEST] <DHE> vorbis is intended as a VBR codec by design [19:06:44 CEST] <iranen> no one should use ogg/vorbis anymore since there are OPUS [19:07:11 CEST] <JEEB> cableguy: then cut a sample of the VOB with dd or so (without any remuxing) that contains a subtitle and then open a ticket for it (just make sure you're using latest FFmpeg) [19:07:23 CEST] <JEEB> that way developers get a sample, too :P [19:08:00 CEST] <furq> cableguy: you might need to bump up analyzeduration/probesize [19:09:12 CEST] <furq> failing that, use something like tcdemux [19:14:56 CEST] <RealName7890> JEEB, that's what it says under constant bitrate and it fixed getting CBR to work, https://trac.ffmpeg.org/wiki/Encode/VP8 [19:17:03 CEST] <JEEB> could be libvpx/VP8 specific [19:17:29 CEST] <JEEB> also always question the wiki as it is not written by developers in general (it wouldn't be the first time it had incorrect data in it) [19:18:40 CEST] <JEEB> in general (f.ex. with libx264) minrate is frowned upon as something that tries to hack the rate control on the libavcodec side [19:19:17 CEST] <JEEB> and with libx264 you'd probably get better results by using a low enough CRF with maxrate+bufsize [19:27:01 CEST] <gmoryes> Does anybody know how to get average VBR from video? [19:27:19 CEST] <gmoryes> or audio [19:28:16 CEST] <JEEB> average over the whole clip is the size of the stream divided by the seconds of content [19:28:57 CEST] <gmoryes> yes, but I need average vbr of video, and I don't know the size of audio stream [19:29:16 CEST] <gmoryes> average vbr of audio stream in video* [19:29:25 CEST] <gmoryes> any ideas? [19:31:53 CEST] <kerio> gmoryes: -map the video alone, mux it with -null [19:31:54 CEST] <kerio> er [19:31:56 CEST] <kerio> with -f null [19:38:17 CEST] <LinuxLoader> hello , did some one have tested 4xGPU quadro P5000 on single server from udp stream transcoding to mpeg-dash [20:04:53 CEST] <cableguy> JEEB, whats a dd [20:05:07 CEST] <furq> https://en.wikipedia.org/wiki/Dd_(Unix) [20:07:51 CEST] <cableguy> anyway i ran ffprobe and it does indeed not see the subtitle stream, it does on other dvd [20:08:09 CEST] <cableguy> but i dont get it,subtitle is in there. [20:08:11 CEST] <furq> did you try increasing analyzeduration and probesize [20:08:14 CEST] <cableguy> and im on windows [20:08:19 CEST] <cableguy> so no ^ [20:08:33 CEST] <furq> what does that have to do with windows [20:08:36 CEST] <JEEB> lol [20:08:50 CEST] <cableguy> i thought its only on linux [20:08:55 CEST] <furq> those are ffmpeg options [20:08:57 CEST] <JEEB> no, its ffprobe/ffmpeg options [20:09:01 CEST] <JEEB> *it's [20:09:05 CEST] <cableguy> so how do you run it [20:10:43 CEST] <cableguy> ok i ran this ffprobe -i "VTS_01_1.VOB" -analyzeduration 2147483647 -probesize 2147483647 i found it on some ticket [20:11:03 CEST] <cableguy> and now it sees the subtitle [20:11:14 CEST] <cableguy> so not sure whats going on [20:11:41 CEST] <furq> those default to 5 million (microseconds/bytes) [20:11:47 CEST] <furq> i.e. 5 seconds, 5MB [20:11:57 CEST] <furq> so the subtitle stream doesn't show up until after that point in the file [20:12:18 CEST] <cableguy> okay so how i make my initial command work [20:12:33 CEST] <cableguy> the ffmpeg -i "source.VOB" -map 0:v -map 0:a -map 0:s -c copy -fs 10000000 -ss 00:00:00 -t 00:10:00 "split.vob" [20:12:34 CEST] <furq> you do the same thing with ffmpeg [20:13:06 CEST] <cableguy> same how [20:16:03 CEST] <cableguy> the -analyzeduration 2147483647 -probesize 2147483647 on ffmpeg does not show subtitle stream [20:16:18 CEST] <cableguy> and if i add it to my original splitting command i get same error [20:16:24 CEST] <cableguy> 'Stream map '0:s' matches no streams. [20:19:49 CEST] <rodorgas> I'm using pad and overlay to merge two rtsp live streams. The output stream is `-f mpegts udp://localhost:1234`, can it be played on VLC? How? I'd rather have a RTP stream, but whenever I try, it says "Only one stream supported in the RTP muxer". Suggestions? [20:20:59 CEST] <cableguy> ok i solved [20:21:17 CEST] <cableguy> apparently you add analyzeduration and probesize on ffmpeg before input -i [20:21:30 CEST] <cableguy> and i changed it to -analyzeduration 2148M -probesize 2148M [20:21:44 CEST] <cableguy> because someone had problem like that https://lists.ffmpeg.org/pipermail/ffmpeg-user/2014-May/021564.html [20:22:03 CEST] <cableguy> and it says sometimes subtitle starts at the middle of the vob [20:22:08 CEST] <cableguy> so probably that was the trouble [20:22:22 CEST] <cableguy> but looks like nobody gives a fuck in this chat,as usual [20:22:25 CEST] <cableguy> take care [20:23:03 CEST] <rodorgas> lol [20:27:48 CEST] <momomo> anyone have any experience with tvheadend? is it possible to view signal strength so one can adjust the satellite dish? [20:44:39 CEST] <Blubberbub> probably a stupid question, but i was not able to google the answer for it, yet: does PTS include the time of day or does it start at 0 when the demuxer/decoder is initialized? [20:47:22 CEST] <JEEB> PTS is just something [20:47:33 CEST] <JEEB> for MPEG-TS for example you can have it somewhere way positive [20:47:44 CEST] <JEEB> while for audio in mp4 the initial samples can have a negative PTS [20:48:21 CEST] <JEEB> (usually negative PTS means "you can throw <amount of samples until zero> out after decoding") [20:48:47 CEST] <Blubberbub> ah ok. Thanks :) [20:52:10 CEST] <JEEB> usually what it means is that it's just a means to synchronize between different things, even if the time base is different between say audio or video tracks [20:56:38 CEST] <Blubberbub> so if i understand correctly the actual double value is identical, but the pts might differ because of different time_base between the streams? [20:57:52 CEST] <JEEB> not necessarily identical but you can then utilize the PTS values to synchronize between streams [20:58:52 CEST] <Blubberbub> ah, true [21:30:04 CEST] Action: kepstin notes that in mpeg-ts, the pts values were designed to be able to hold (slightly more than) 24h before wrapping, so *some* broadcasters may have the current time of day in the pts, wrapping every 24h. [21:30:09 CEST] <kepstin> but you probably won't see that [21:36:26 CEST] <DHE> mpegts is intended to run perpetually. so you can run into the situation where dts is (visually) around 8 billion time units but pts is around 1000 [21:36:34 CEST] <DHE> which is always fun [21:45:43 CEST] <kerio> whats dts instead [21:45:54 CEST] <kerio> sync between different programs? [21:45:58 CEST] <JEEB> decoding time stamp [21:46:06 CEST] <JEEB> as opposed to presentation timestamp [21:46:11 CEST] <kerio> oh [22:31:33 CEST] <Mavrik> Ugh. [22:31:43 CEST] <Mavrik> Just found another PTS/DTS rollover bug in ffmpeg. [22:31:50 CEST] <Mavrik> -_- [22:33:00 CEST] <JEEB> weeeeeee [22:33:13 CEST] <JEEB> I actually thought about adding extra fields to AVPacket/AVFrame [22:33:15 CEST] <JEEB> a la upipe [22:34:08 CEST] <JEEB> upipe has: timestamp, coded_timestamp, unix_time_of_receipt [22:34:18 CEST] <JEEB> I can see why you'd have at least two of those [22:34:28 CEST] <Mavrik> For? :) [22:35:15 CEST] <JEEB> some of the issues currently with the roll-over stuff is because the mpegts demuxer outputs the timestamps with roll-over [22:35:25 CEST] <JEEB> which people defent because they want remuxing to possibly keep timestamps [22:35:27 CEST] <JEEB> *defend [22:35:44 CEST] <JEEB> for which separate timestamp fields would make sense [22:35:51 CEST] <JEEB> "if you want the original coded timestamp, here" [22:36:04 CEST] <JEEB> "if you just want a rising timestamp properly fixed, here" [22:37:37 CEST] <Mavrik> Oh yeah. [22:37:50 CEST] <Mavrik> The people I'm writing this code for certanly want the timestamps to remain the same [22:38:09 CEST] <Mavrik> Including the batshit crazy "We're splicing commercials so PTS/DTS jumps thefuck whatever" type stuff [22:38:18 CEST] <JEEB> :D [22:38:20 CEST] <Mavrik> So there are a few patches around fixing that [22:38:29 CEST] <JEEB> yea, I bet [22:38:38 CEST] <JEEB> makes sense for live input [22:38:41 CEST] <Mavrik> Trying to upstream them as much as possible, but my ugly hacks probably won't be looked upon with grace :P [22:38:51 CEST] <Mavrik> Yeah, broadcast TV must die. [22:39:35 CEST] <Mavrik> Hmm, should I add a .ts sample: https://trac.ffmpeg.org/ticket/6531#ticket ? [22:40:28 CEST] <JEEB> would probably help [22:40:47 CEST] <JEEB> Mavrik: if done correctly it's not a hack, but requirement of the format [22:40:49 CEST] <JEEB> generally speaking [22:41:37 CEST] <Mavrik> I'm not sure what a proper solution for that is though? [22:41:58 CEST] <Mavrik> Checking if DTS difference is over treshold and reset the counters? Since I'm guessing the DTS isn't coming in linearly into muxer in all cases. [22:42:22 CEST] <JEEB> isn't it basically a discontinuity? [22:42:32 CEST] <JEEB> or does everything expect no decoder reset on those? [22:43:39 CEST] <Mavrik> That's the part which I might be a bit fuzzy about - are DTS discontinuities legal in MPEG-TS or do they have to be ordered? [22:44:13 CEST] <JEEB> I do have a 2012 H.222 bible somewhere here, but it might also be written in the DVB/EBU specs as well [22:44:17 CEST] <Mavrik> Meaning, is "fuu, emit PAT/PMT if dts < last_seen_dts" a valid strategy :) [22:44:26 CEST] <Mavrik> Yeah, gonna go dig through my spec books as well [22:48:17 CEST] <c7j8d9> Is there nvenc hw acceleration for vp9 like hevc? [22:48:17 CEST] <JEEB> Mavrik: also as a framework I'm surprised everything else took it well enough :D [22:48:53 CEST] <JEEB> granted, I guess after you decode it the PTS comes out sane enough [22:49:15 CEST] <JEEB> and then you can just re-time the output packet. or you're just remuxing [22:50:25 CEST] <Mavrik> Most of the stuff doesn't really care all that much. [22:50:33 CEST] <Mavrik> I had to do a few fixes in vf_fps [22:51:09 CEST] <Mavrik> And I think two or three other fixes. [22:51:20 CEST] <Mavrik> But it's a rather specific use-case - MPEG-TS -> transcode -> MPEG-TS [22:51:35 CEST] <JEEB> yea [22:51:46 CEST] <JEEB> also I just read the code and noticed that you can't add extra streams? [22:51:53 CEST] <JEEB> in the mpegts muxer [22:52:05 CEST] <JEEB> unless I read it wrong [22:53:02 CEST] <JEEB> so if I will ever have to do broadcast I guess I'll have to either implement that or just look for a "proper" MPEG-TS muxer [22:53:30 CEST] <Mavrik> Yeah, for me that's not an issue yet [22:53:47 CEST] <JEEB> yea, not an issue for me either [22:53:53 CEST] <Mavrik> The input streams are all very stable (they come from content providers and are emitted to IPTV targets) [22:54:03 CEST] <JEEB> that's the usual thing :) [22:54:10 CEST] <Mavrik> Not sure if anyone even uses that capability here. [22:54:20 CEST] <JEEB> at least the inputs do :D [22:54:25 CEST] <Mavrik> The only real panful thing that made me think about switching muxers was trying to emit to DVB-C [22:54:38 CEST] <Mavrik> Aaaand that did not go well at all with ffmpegs muxer [22:54:42 CEST] <JEEB> yea libavformat is gonna fail hard at that [22:54:47 CEST] <JEEB> it's not a "real" MPEG-TS muxer [22:55:03 CEST] <Mavrik> I think they just bought a few Ciscos for that instead of spending a lot of time porting to another TS library [22:55:18 CEST] <Mavrik> Since I wasn't really able to find any good ones that wouldn't cost the same as getting a few encoders [22:55:41 CEST] <Mavrik> (See also: budgeting politics) [22:56:00 CEST] <JEEB> I had a couple of alternatives but I haven't touched either [23:31:56 CEST] <kepstin> c7j8d9: as far as I can tell, the vp8/vp9 support on nvidia cards is decode-only. [23:32:33 CEST] <kyleogrg> Using ffmpeg to pipe 2560x1440 video to x265, with --crf 20, --preset slower, --no-sao, -rskip. This is in Lubuntu in Virtualbox, on Windows 10. Processor is ASUSTek P8H67-M EVO. Thoughts on how to speed up encoding at minimal quality loss? [23:32:40 CEST] <c7j8d9> that's what I am figuring out too...thanks for checking [23:33:27 CEST] <kepstin> kyleogrg: you listed your motherboard, not your processor :) But if you want to speed up encoding... use a faster preset? [23:34:06 CEST] <kyleogrg> oops, processor is Intel Xeon E3 1230 v2 [23:34:19 CEST] <kepstin> kyleogrg: also, consider using x264 instead of x265. [23:34:48 CEST] <kyleogrg> kepstin: sure, i might just try a faster preset. just wondering if there were other tweaks too. i like x265 for the smaller file size [23:35:52 CEST] <kepstin> kyleogrg: in general, the devs have the presets set up to already do the minimum quality change for maximum speed difference between them, so there's no real reason to do manual tweaking unless you want something inbetween [23:36:29 CEST] <kyleogrg> kepstin: ok, i will do some tests, but i wonder how much of a size difference there is between medium and slower [23:36:32 CEST] <kepstin> and unless you're using x265 with a preset that's slower than x264 with 'veryslow', you're probably not actually getting smaller file sizes anyways (for the same quality) [23:37:55 CEST] <kyleogrg> kepstin: i've thought about that. but aren't you supposed to get noticeably smaller videos with x265 over x264? [23:38:37 CEST] <kepstin> kyleogrg: in theory if you use a reference encoder (very very slow) and >HD content, the size of H.265 video will be smaller than H.264 for the same quality [23:38:54 CEST] <kyleogrg> what's a reference encoder? [23:39:29 CEST] <kepstin> in practice, x264 is a really damn good encoder, and all x265 encoders isn't optimized to the same point yet. [23:40:35 CEST] <kyleogrg> i guess it takes time, because it's been several years that i've heard about x265 development [23:40:40 CEST] <kepstin> a "reference encoder" is an encoder built while designing a codec, usually as a way to test all the possible features; generally they aren't optimized for speed but rather to simply encode video at max quality. [23:41:07 CEST] <kyleogrg> hmm, so what are some x265 reference encoders? [23:41:25 CEST] <furq> that's max quality not relative to bitrate [23:42:21 CEST] <kepstin> how old is x264 now anyways? Got to be >10years. [23:42:26 CEST] <furq> at least 13 [23:42:31 CEST] <furq> https://hevc.hhi.fraunhofer.de/trac/hevc/browser [23:42:34 CEST] <furq> this is the hevc reference encoder fwiw [23:42:47 CEST] <furq> i don't recommend using it unless you're that russian website that publishes slightly wonky codec comparisons [23:43:05 CEST] <kepstin> if you're looking for a way to speed up your hevc encodes... using the reference encoder is not it ;) [23:43:16 CEST] <furq> but yeah x264 is much older and actively invited contributions [23:44:06 CEST] <furq> it's really hard to beat even with a new standard [23:44:18 CEST] <kyleogrg> kepstin: yes... this would be even slower. i guess i'll likely have to stick with x264, which is very good. i was just trying to keep up with newer technology. i thought x265 would be fairly mature after several years. [23:44:22 CEST] <furq> last time i saw a comparison, x264 beats x265 at the same speed [23:44:32 CEST] <furq> but obviously x265 has much slower settings you can use [23:44:55 CEST] <JEEB> the real issue is, x265 just doesn't get as much love to actually optimize the coding tools at its disposal. which there are plenty new [23:45:02 CEST] <furq> right [23:45:15 CEST] <JEEB> they can copy stuff from x264, but that only works for features that were in AVC [23:45:23 CEST] <kyleogrg> JEEB: you mean everyone loves x264 too much, basically? [23:45:36 CEST] <furq> x264 is much more highly optimised [23:45:53 CEST] <furq> because it's older and attracted a ton of developers from all over the place [23:45:54 CEST] <JEEB> kyleogrg: it was an actual OSS project handled by nerds and various corporate projects handled by those nerds [23:46:10 CEST] <JEEB> when you get a community around something it tends to get better [23:46:24 CEST] <kyleogrg> JEEB: ok, so x265 development isn't like that? [23:46:38 CEST] <JEEB> x265 tried to do open source, but flopped due to various reasons [23:46:44 CEST] <kyleogrg> ah [23:46:51 CEST] <JEEB> I even tried to contribute at the very beginning :P [23:47:02 CEST] <furq> i can imagine people being less interested anyway [23:47:04 CEST] <JEEB> (I think I even might have a patch in the build system) [23:47:07 CEST] <furq> x264 was pretty revolutionary [23:47:17 CEST] <furq> whereas x265 seems more like an incremental step [23:47:30 CEST] <furq> unless you're doing 4k, which you probably aren't [23:47:30 CEST] <JEEB> that's the hard part of optimizing. there are good tools in HEVC, but a lot of them lead to PSNR-optimized results [23:47:47 CEST] <kyleogrg> i guess i just heard the hype about x265 being, you know, like 60% the size of x264 videos [23:47:51 CEST] <JEEB> kyleogrg: so in the end it was just MCW and a couple of randoms (I think one guy from Oki?) [23:47:58 CEST] <JEEB> kyleogrg: don't mish-mash formats and encoders [23:48:08 CEST] <furq> yeah that's h264 vs h265 [23:48:23 CEST] <JEEB> HEVC as it as a format goes, according to testing done by JCT-VC [23:48:39 CEST] <furq> if you're comparing the reference encoders then 30-50% is probably true [23:48:39 CEST] <JEEB> that you should be able to get ~40% improvement in file size [23:48:52 CEST] <furq> but x264 is much better than the h264 reference encoder [23:49:06 CEST] <furq> x265 is better than the h265 reference encoder, but comparatively less than x264 [23:49:09 CEST] <JEEB> yes, of course it was reference encoders, and I guess they know their shit and it's the theoretical improvement you can get (with X% of error) [23:49:14 CEST] <kyleogrg> hmm, so if i went with the slowest settings on the HEVC (not x265) reference encoder, it would indeed beat x264 in file size? [23:49:25 CEST] <JEEB> ahahaha, HM [23:49:35 CEST] <furq> shrug [23:49:37 CEST] <JEEB> kyleogrg: no it was reference encoder vs reference encoder [23:49:41 CEST] <furq> ^ [23:49:45 CEST] <JEEB> kyleogrg: also you don't want frame per minute speeds [23:49:51 CEST] <JEEB> I encoded clips with HM [23:49:52 CEST] <JEEB> in late 2012 [23:50:09 CEST] <JEEB> you not only have to manually configure the hell out of it, it has no real optimizations in it [23:50:36 CEST] <JEEB> the end theme is that someone has to care for a current-gen format for it to be more viable than previous-gen formats [23:50:50 CEST] <kyleogrg> yeah [23:50:53 CEST] <furq> i expect AV1 has taken the wind out of x265's sails as well [23:50:57 CEST] <JEEB> if the best previous gen encoder is good enough, and the format difference is not as big as with MPEG-4 Part 2 => AVC [23:51:11 CEST] <furq> in terms of developer attention [23:51:19 CEST] <JEEB> I mean, AVC was already wow because of stuff like in-loop deblocking or CABAC [23:51:21 CEST] <kyleogrg> okay, what about vp9? i guess that's mainly youtube's thing? [23:51:30 CEST] <JEEB> kyleogrg: yea it's a one-vendor thing [23:51:38 CEST] <furq> vp9 doesn't have any future [23:51:42 CEST] <JEEB> AOM and AV1 is the thing where they took VP10 and took other people in [23:51:47 CEST] <JEEB> and groups [23:51:55 CEST] <furq> AV1 is more or less the future of vp9 [23:52:12 CEST] <furq> and hopefully the future of all video that isn't on apple devices [23:52:13 CEST] <JEEB> but yea, I hope having more than one cook in the mess will improve things [23:52:14 CEST] <kyleogrg> JEEB: given the choice between HEVC and VP9, which would you say is better? not talking about compatibility [23:52:29 CEST] <JEEB> kyleogrg: HEVC was actually made with a specification [23:52:40 CEST] <JEEB> VP9 should now have a spec, but it definitely wasn't made with one [23:52:41 CEST] <furq> in terms of encoders, x265 is p much universally thought of as better than libvpx-vp9 [23:52:54 CEST] <JEEB> (also I hate the way GOOG did its formats behind closed doors) [23:53:06 CEST] <JEEB> BBB's proprietary VP9 encoder might be better than x265 [23:53:15 CEST] <JEEB> but that's gonna be business-to-business licensed [23:53:22 CEST] <JEEB> so we're not gonna see it [23:53:24 CEST] <furq> right [23:54:29 CEST] <furq> x264 is good enough to tide us over until av1 is mature enough to bother with [23:54:38 CEST] <furq> it's certainly good enough to tide me over anyway [23:54:46 CEST] <kyleogrg> so when i download a youtube video, why is the vp9 file size often larger than the avc/mp4 version (at the same res)? i thought the idea of vp9 was to save bandwidth [23:55:06 CEST] <furq> it's almost always smaller at the same resolution in my experience [23:55:09 CEST] <furq> and it often looks noticeably better [23:55:19 CEST] <Diag> Because vp9 is softer instead of blocky [23:55:21 CEST] <furq> i've not done exhaustive checks though, and youtube is notoriously weird [23:55:50 CEST] <Diag> It's quality just gets bad, it doesn't give you the notorious jpeg compression artifacts [23:56:24 CEST] <JEEB> kyleogrg: you have to keep in mind that 'tube doesn't really encode for quality anyways [23:56:33 CEST] <furq> i only really notice it with pathological cases like strobing, water etc [23:56:43 CEST] <furq> the h264 encode is almost always fine [23:56:50 CEST] <JEEB> and it's not a surprise they would give more rate to the VP9 thing compared to AVC [23:57:02 CEST] <JEEB> after all, HAVE TO SHOW HOW VP9 IS BETTUR [23:57:34 CEST] <kyleogrg> well, i know this isn't really the place, but using youtube-dl at "bestvideo" rarely seems to give me VP9. so i manually told it to download the best VP9, because it might be the same or higher quality even though the bitrate is lower [23:57:52 CEST] <furq> you can check the bitrates with youtube-dl -F [23:57:52 CEST] <JEEB> it really depends on what kind of settings 'tube is using [23:58:12 CEST] <JEEB> I mean, you're expecting them to try and match settings while they could be skewing things however they want [23:58:15 CEST] <furq> in my experience 1080p30 h264 is usually 3.5mbit and vp9 is closer to 2.5 [23:58:22 CEST] <kyleogrg> furq: sure, but i expect VP9 to have lower bitrate at identical quality [23:58:39 CEST] <furq> that is the case in my experience [23:59:07 CEST] <kyleogrg> that's what i imagined too, because i think that's part of yt's motivation, to save bandwidth [23:59:10 CEST] <JEEB> anyways, if nothing else on firefox VP9 is nice because it uses FFmpeg's VP9 decoder which BBB optimized to sell his encoder :D [23:59:23 CEST] <kyleogrg> okay, what's bbb? [23:59:27 CEST] <JEEB> it's a person [23:59:33 CEST] <JEEB> (also a video clip) [00:00:00 CEST] --- Tue Jul 18 2017

1 0

ffmpeg-devel.log.20170716
by burek 17 Jul '17

17 Jul '17

[00:20:36 CEST] <wm4> JEEB: the new API forces refcounting [00:20:50 CEST] <wm4> JEEB: refcounted_frames has been deprecated for this reason [00:21:06 CEST] <wm4> if you give the new APIs non-refcounted stuff, they'll probably copy it [00:24:03 CEST] <iive> what?! [00:29:30 CEST] <JEEB> wm4: yea it was mostly about the flag you could set it [00:29:39 CEST] <JEEB> which doesn't make sense wrt encoders [00:29:43 CEST] <wm4> iive: yes [00:29:47 CEST] <JEEB> since they don't produce refcounted frames [00:29:50 CEST] <JEEB> only packets [00:37:07 CEST] <iive> the new api is not ref-counted? [00:37:15 CEST] <iive> the threaded api? [00:44:30 CEST] <wm4> the new API forces refcounting, and it has nothing to do with threading [00:47:39 CEST] <iive> by threaded i was refereing to the async api, that's kind of most useful with threading [00:47:55 CEST] <iive> but if there is another api that doesn't implement that.... [00:56:45 CEST] <wm4> there's no async API either [00:57:31 CEST] <iive> i thought libav made one and we merged it. [00:58:09 CEST] <atomnuker> no, there are plans to make the new api async but nothing's come of it [00:58:49 CEST] <atomnuker> and that's something I think I remember back when the patches were originally sent to the ml [01:00:08 CEST] <wm4> there's no need for an async API currently [01:00:13 CEST] <wm4> nothing would use it [01:00:30 CEST] <wm4> but the new API could be made async easily [01:09:04 CEST] <cone-481> ffmpeg 03Michael Niedermayer 07master:0ef8f03133a0: avcodec/aacdec_template: Fix undefined integer overflow in apply_tns() [03:43:07 CEST] <cone-481> ffmpeg 03Michael Niedermayer 07master:4de4308d2aa3: avcodec/ffv1dec_template: Fix signed integer overflow [14:29:57 CEST] <cone-900> ffmpeg 03Ashish Singh 07master:615479d51c6a: avfilter: add LIBVMAF filter [14:30:06 CEST] <BBB> woohoo \o/ [14:30:50 CEST] <JEEB> did netflix enable building that lib? [14:30:57 CEST] <JEEB> IIRC that guy was trying to make it buildable as lib [14:40:14 CEST] <durandal_1707> BBB: how is native vmaf supposed to work if its split into several filters? [15:01:26 CEST] <wm4> <cone-900> ffmpeg Ashish Singh master:615479d51c6a: avfilter: add LIBVMAF filter [15:01:29 CEST] <wm4> who pushed this? [15:01:35 CEST] <wm4> apparently the patch review wasn't finished [15:12:11 CEST] <durandal_1707> wm4: by who..? [15:14:24 CEST] <RiCON> BBB, according to the commiter name? [15:22:00 CEST] <wm4> BBB: <Daemon404> wm4, http://fate.ffmpeg.org/?sort=descdate [15:22:09 CEST] <wm4> <Daemon404> fate explodes~ [15:22:28 CEST] <wm4> seems like configure enables this filter by default [15:22:32 CEST] <wm4> what a shit show [15:27:00 CEST] <RiCON> maybe because it's using vmaf_filter_deps instead of libvmaf_filter_deps [15:27:21 CEST] <wm4> BBB: can you push a revert? [15:33:45 CEST] <BBB> wm4: uhm [15:33:49 CEST] <BBB> can you just fix it? [15:33:52 CEST] <BBB> review was definitely fixed [15:33:59 CEST] <BBB> dont push reverts just because [15:34:05 CEST] <nevcairiel> if reviews were ignored, it should probably just go back to the ML [15:34:06 CEST] <wm4> I don't know anything about this patch [15:34:11 CEST] <wm4> but fate says it breaks EVERYTHING [15:34:17 CEST] <BBB> nevcairiel: all reviews were finished and addressed [15:34:24 CEST] <BBB> let me fix the deps [15:34:30 CEST] <BBB> I have to run out though [15:34:32 CEST] <BBB> darn it [15:34:34 CEST] <nevcairiel> BBB: the ML claims otherwise [15:35:28 CEST] <BBB> ... [15:35:31 CEST] <BBB> I have to run [15:35:35 CEST] <BBB> revert it if you have to [15:35:39 CEST] <BBB> I have no time unfortunately [15:35:54 CEST] <BBB> I think you guys could be more constructive, Ive spent a lot of time with the student on getting this in [15:35:56 CEST] <BBB> :( [15:36:13 CEST] <wm4> constructive or not, if it breaks everything, it must be addressed quickly [15:36:21 CEST] <wm4> that's just a fact of life [15:39:19 CEST] <durandal_1707> lol, fact of life [15:40:31 CEST] <durandal_1707> leave it to michaelni [16:15:04 CEST] <kierank> wm4: Nvidia cuda crap is enabled by default even with --disable-everything [16:15:13 CEST] <kierank> That was never fixed [16:15:19 CEST] <wm4> heh [16:15:34 CEST] <wm4> well, configure is bad with this [16:15:42 CEST] <wm4> it's hard to enable things by default in a proper way [16:15:45 CEST] <wm4> honestly, fuck configure [16:16:12 CEST] <RiCON> cuda uses the same enable_weak as other system hwdecs [16:16:55 CEST] <wm4> hwdec autoselection is broken too [16:17:09 CEST] <RiCON> yeah, you have to explicitely disable dxva/d3d11va [16:17:09 CEST] <wm4> I had some "special" experiences with this [16:21:45 CEST] <nevcairiel> the cuda and dxva stuff doesnt really harm anything since it doesnt add link dependencies [16:22:28 CEST] <RiCON> but it could be argued that --disable-everything doesn't actually disable-everything [16:23:00 CEST] <wm4> the hwaccels can pull in the proper decoders [16:34:38 CEST] <RiCON> either way, having a broken git master isn't good [16:49:01 CEST] <wm4> yeah [16:49:15 CEST] <wm4> if nothing happens in an hour or so I'll push a simple revert [16:53:57 CEST] <RiCON> $AUTODETECT_LIBS could be added to --disable-all so there's an easier way to disable auto-detected stuff without doing it explicitely for each one [17:01:04 CEST] <cone-900> ffmpeg 03Michael Niedermayer 07master:ba4beaf6149f: avcodec/apedec: Fix integer overflow [17:12:53 CEST] <cone-900> ffmpeg 03Derek Buitenhuis 07master:a27c412795c2: webmdashenc: Fix memory leak [17:12:54 CEST] <cone-900> ffmpeg 03Matt Oliver 07master:d8f198263975: configure: Fix libvmaf name [17:18:37 CEST] <durandal_1707> wm4: noo, i will pish fix, wait [17:19:38 CEST] <wm4> k [17:22:55 CEST] <durandal_1707> does matt fixes it? [17:24:01 CEST] <nevcairiel> there is probably still other issues in there, like it being enabled by default in the first place [17:35:29 CEST] <durandal_1707> nevcairiel: its not enabled by default here [17:35:46 CEST] <nevcairiel> clearly if that was the case, the error would not have happened [17:40:42 CEST] <RiCON> it was using the wrong filter name [17:41:13 CEST] <nevcairiel> yet if it was disabled, that should not have mattered [17:41:13 CEST] <RiCON> it just wasn't being enabled or disabled either way [17:41:46 CEST] Action: JEEB has learned today that AVSEEK_FLAG_BACKWARD is required for av_seek_frame to work as expected [17:51:20 CEST] <BtbN> It fixed the Travis-Builds at least [17:51:43 CEST] <jamrial> nevcairiel: every module (filters/decoders/muxers/etc) is enabled by default during configure until the dependency checks take place [17:52:07 CEST] <jamrial> in this case, the dependency entry for this filter was broken [17:52:29 CEST] <jamrial> so the fact libvmaf isn't available didn't disable it [17:58:29 CEST] <ashk43712> Hi, sorry for the libvmaf patch. I changed everywhere else (from vmaf to libvmaf) but forgot to change this line: vmaf_filter_deps="libvmaf" . [17:59:05 CEST] <ashk43712> <jamrial> I am not sure how to do that. [17:59:39 CEST] <jamrial> ashk43712: it's already fixed [18:00:14 CEST] <ashk43712> This patch is the one that requires Netflix's vmaf library as an external dependency. [18:00:20 CEST] <ashk43712> thanks a lot. [18:02:38 CEST] <JEEB> ashk43712: did they already make it buildable as a library_ [18:02:39 CEST] <JEEB> ? [18:02:47 CEST] <JEEB> that was the primary issue before I think? [18:03:40 CEST] <ashk43712> yeah, I opened a pull request for the library integration into their code. That was merged a week ago. [18:04:18 CEST] <ashk43712> Currently, I am implementing vmaf metrics (ansnr, adm, motion and vif) inside ffmpeg so that it can have an independent implementation (without any library) of vmaf later. [18:05:39 CEST] <ashk43712> vmaf installation is a three step process after getting Netflix's vmaf repo: [18:05:50 CEST] <ashk43712> make, make lib and make install [18:19:24 CEST] <JEEB> ok, cool [19:01:38 CEST] <thebombzen> Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309] [19:01:49 CEST] <thebombzen> Wow. [19:23:06 CEST] <DHE> in fairness, firefox 2 is way better than firefox 3 was. or firefox 4. or... [19:24:05 CEST] <BtbN> Firefox will soon be a Chrome-Copy anyway [19:37:26 CEST] <durandal_1707> i will apply dolbye if nobody will [19:39:54 CEST] <JEEB> I think it was already once requested here? [19:40:36 CEST] <jamrial> JEEB: he means applying the patchset on the ml [19:40:43 CEST] <JEEB> yes [19:40:51 CEST] <JEEB> I think kierank or so already poked him to push it [19:41:50 CEST] <jamrial> foo86 should be given push access by now. he actively maintains the dts decoder and now dolby_e [19:41:55 CEST] <jamrial> i told him to send his ssh key to michaelni some time ago but i guess he didn't [19:42:03 CEST] <JEEB> yea [19:42:12 CEST] <JEEB> I see no reason not to have him have push access :) [19:42:37 CEST] <durandal_1707> but he wants to be anon [19:47:51 CEST] <jamrial> throwing a public ssh key our way wouldn't change that [19:51:41 CEST] <michaelni> jamrial, i asked him to send a patch to add himself to the MAINTAINERs file over a year ago IIRC, not sure why he didnt [20:03:33 CEST] <wm4> was master fixed yet [20:04:02 CEST] <BtbN> Travis builds fine at least [20:06:24 CEST] <wm4> at least seems to build here too [20:56:18 CEST] <thebombzen> looking at MAINTAINERS is a bit amusing. There's all these names and then just "wm4" who was the only one who choose not to use real name [21:12:42 CEST] <atomnuker> BBB: what's the point of having support for the library if its being ported/ [21:16:46 CEST] <iive> atomnuker: easier to compare both versions? [21:17:13 CEST] <BBB> atomnuker: whats the point of fdkaac or other aac encoders if were workign on our own? :) [21:17:28 CEST] <atomnuker> i guess [21:17:32 CEST] <BBB> atomnuker: thats not meant to be an asshole response btw, sorry if it sounded like one [21:17:40 CEST] <BBB> but I think the reasons are comparable [00:00:00 CEST] --- Mon Jul 17 2017

1 0

ffmpeg.log.20170716
by burek 17 Jul '17

17 Jul '17

[00:01:57 CEST] <klow> its not the the right channel is empty, its just a duplicate of the left exactly [00:02:20 CEST] <klow> so its would sound the exact same as a mono file of half the size, right? [00:04:48 CEST] <klow> ok how about this instead [00:05:20 CEST] <klow> transcode a stereo .opus file to a mono mp3 file (preferably using Left side rather than mixing L+R) [00:05:56 CEST] <klow> basically I am trying to get the highest quality *mp3* file, in mono, from youtube, which has several audio formats, the highest of which is a high-ish bitrate .opus i think [00:06:37 CEST] <c_14> I mean, it's possible [00:08:02 CEST] <c_14> but I don't think going down to $bitrate mono mp3 instead of $bitrate stereo mp3 is going to be that much of a quality difference [00:08:18 CEST] <c_14> "that much" being anything noticeable [00:08:19 CEST] <atomnuker> the encoder still probably detected no difference and used MS coding or intensity stereo [00:09:35 CEST] <klow> ah. OK thanks anyways. what i have is working fine just trying to save iPhone space but no biggy [00:51:24 CEST] <JodaZ> klow, ideally the files are already in M/S mode, you should check [00:52:37 CEST] <JodaZ> M/S means only the difference to a center channel (M) is encoded (as S), so S will be small for "Mono-like" audio and cost barely any size [00:57:40 CEST] <atomnuker> if you're compression lectures just compress with opus at ~28kbps, you'll likely not hear a difference [00:57:48 CEST] <atomnuker> or aac-he at 48kbps [01:18:01 CEST] <thebombzen> is ffaac going to get he-aac? or is there not really much demand for it with opus being a thing now [01:26:35 CEST] <iive> atomnuker: is there a way to get psnr of audio encode while encoding? [01:31:54 CEST] <atomnuker> its what fate does and you should never ever do that [01:32:59 CEST] <atomnuker> optimize for psnr and you'll end up making everything sound worse than low bitrate speex [01:44:13 CEST] <iive> i don't want to optimize [01:44:17 CEST] <iive> just to measure [01:44:50 CEST] <iive> if you have better psyhoacoustic measure... then i'd be happy to use it. [01:47:07 CEST] <atomnuker> there isn't any and with good reason [03:52:00 CEST] <bsuh> is there a way to create HLS segments separately in different invocations of ffmpeg instead of 1 passthrough? [09:08:19 CEST] <the_gamer> can anybody help me out why this does not work? http://pasteall.org/473484 [09:08:47 CEST] <the_gamer> ffmpeg -i "%03d.png" -aspect 16:9 -target pal-dvd -q:v 1 gunung\ kawi\ karte.mpg [09:08:59 CEST] <the_gamer> error: Could find no file with path '%03d.png' and index in the range 0-4 [09:08:59 CEST] <the_gamer> %03d.png: No such file or directory [09:09:10 CEST] <the_gamer> same with %04d.png but the folder is full of them [09:10:47 CEST] <the_gamer> anybody? [09:18:08 CEST] <the_gamer> the slideshow manpage says my syntax is right [09:18:14 CEST] <the_gamer> i don't get it [09:25:54 CEST] <thebombzen> the_gamer: they have to start at 0001 [09:26:12 CEST] <the_gamer> oh that could be it [09:26:28 CEST] <thebombzen> yea. if you have 680-900 you'd probably want to do a batch rename [09:26:43 CEST] <thebombzen> alternatively, you can use: cat *.png | ffmpeg -f image2pipe - [09:26:51 CEST] <thebombzen> er I mean cat *.png | ffmpeg -f image2pipe -i - [09:26:59 CEST] <thebombzen> I believe you can also use png_pipe [09:27:02 CEST] <the_gamer> -start_number does the trick [09:27:06 CEST] <thebombzen> ah okay that works too [09:27:17 CEST] <the_gamer> thanks a lot thebombzen i thought this was needed only when i don't want to use some [10:46:12 CEST] <kerio> where's 0000.png [10:46:19 CEST] <kerio> oh i was scrolled back dammit [12:22:49 CEST] <Fig1024> using FFMPEG C++ API, should avformat_write_header be used for streaming? (no file recording) [12:27:20 CEST] <JEEB> Fig1024: if you look at the docs it says it's the initialization function for output avformat [12:28:26 CEST] <JEEB> so that you can have a lot of stuff before that if you need, and then when you're ready to start writing packets out you start with that one [12:29:29 CEST] <JEEB> although it seems like you might not always need it https://ffmpeg.org/doxygen/trunk/group__lavf__encoding.html#ga18b7b10bb5b94… [12:29:54 CEST] <JEEB> look at the docs of init_output() and write_header() regarding exit codes [12:31:31 CEST] <Fig1024> ok, my issue is that if I use streaming and the server is down or URL entered wrong, first call to avformat_write_header hangs indefinitely. I tried passing -timeout and -stimeout options but it doesn't change anything. I need a graceful way to handle case when connection failed to establish, not hang forever [12:34:21 CEST] <JEEB> I know there are many protocols that have a timeout parameter as an AVOption [12:34:54 CEST] <JEEB> I've only used it for input, not output though [12:36:20 CEST] <Fig1024> avformat_write_header takes AVDictionary options, that's where I tried passing -timeout but it doesn't do anything. Maybe I need to try pass it to different place [12:39:07 CEST] <JEEB> both avformat_init_output and avformat_write_header take in options ("If using this(init_output) function, do not pass the same options to avformat_write_header.") and if the muxer you were trying to use didn't support it, you would get back an avdictionary with the options that weren't supported by it [12:39:35 CEST] <JEEB> so you can actually check if your "-something" went there. which I bet it didn't, because I haven't seen any API options starting with "-" [12:39:51 CEST] <JEEB> the dash is a command line parameter prefix [12:41:06 CEST] <Fig1024> call to avformat_write_header hangs cause it's trying use blocking I/O [12:41:57 CEST] <Fig1024> tho I can check it by having correct URL, then it returns fine [12:42:19 CEST] <JEEB> well you check the protocols you are going to use for if they support a goddamn timeout parameter [12:42:47 CEST] <JEEB> also as I said if you set the options in avformat_init_output it will not yet do the writing [12:42:51 CEST] <JEEB> or opening [12:43:06 CEST] <JEEB> just don't pass the same options to both init and write_header [12:43:23 CEST] <JEEB> so you can check if the options are even valid that you're trying to pass [12:43:31 CEST] Action: JEEB sighs [12:46:34 CEST] <Fig1024> I confirmed that -timeout and -stimeout is not recognized parameter [12:46:58 CEST] <JEEB> no fucking shit [12:47:07 CEST] <JEEB> the one in libavformat/udp.c for example is called "timeout" [12:47:13 CEST] <JEEB> (that is for reading only, though) [12:47:21 CEST] <Fig1024> I'm using rtsp stream [12:48:08 CEST] <JEEB> anyways, I've got my own code to write so please just use common sense and look at the available options in the encoder you'd be using :P [12:49:10 CEST] <Fig1024> it's just difficult to understand why nobody considered the fact that infinitely blocking I/O is a bad idea. There are no obvious functions / parameters to change it. Something like this shouldn't be so hard to find [12:50:05 CEST] <JEEB> I don't disagree [12:51:14 CEST] <Fig1024> I was hoping that I missed something hiding in plain sight [12:51:36 CEST] <Mavrik> Did you check the source of rtsp muxer yet? [12:52:12 CEST] <JEEB> rtspenc.c doesn't have any timeout things, but rtsp.c has both timeout and stimeout [12:52:21 CEST] <Fig1024> I don't have ffmpeg source code, I'm a lowly API user [12:52:38 CEST] <JEEB> yes, because FFmpeg is a closed source app [12:52:40 CEST] <JEEB> har har har [12:53:16 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/rtsp.c#L66 [12:53:30 CEST] <JEEB> anyways, I've wasted enough time with this I have to get some things done :| [12:53:31 CEST] <Fig1024> ffmpeg is too big and complex to take it lightly. I'm not sure I want to commit to digging thru it [12:53:39 CEST] <Mavrik> JEEB, but but sunday! :) [12:53:52 CEST] <JEEB> I promised some code to be delivered "this week" [12:53:53 CEST] <JEEB> :V [12:54:05 CEST] <Mavrik> Fig1024, I don't see how you can make a usable software using ffmpeg API without actually looking into ffmpeg source. [12:54:27 CEST] <JEEB> well I guess you could dump the options etc [12:54:28 CEST] <Mavrik> You'd have your answer by now if you just looked there :/ [12:54:40 CEST] <JEEB> a la ffmpeg.c [12:54:46 CEST] <Fig1024> usually people make good API docs so people can use libs without having to understand internals [12:54:51 CEST] <Mavrik> Anyway, I need to go figure out why ffmpeg craps out of shitty radio streams my clients have. [12:54:59 CEST] <JEEB> but it's just simpler to go straight to the component you're using :P [12:55:32 CEST] <JEEB> Fig1024: those same options are noted in https://www.ffmpeg.org/ffmpeg-all.html#rtsp [12:55:45 CEST] <JEEB> if you want them in "documentation" [13:00:29 CEST] <Fig1024> maybe 'avformat_write_header' is the wrong place to pass these options? I just use 'avformat_alloc_output_context2' to create output, which doesn't take any options parameter [13:01:16 CEST] <JEEB> Fig1024: I have mentioned the OTHER place to set options two or three times, and the doxygen link has that other function RIGHT BENEATH THE WRITE_HEADER ONE [13:01:24 CEST] <JEEB> have you not even read what the flying fuck I've been trying to tell you?! [13:10:38 CEST] <Fig1024> ok I figured it out, -stimeout option is working [13:11:42 CEST] <Fig1024> no thanks to you! j/k [15:02:03 CEST] <goodafternoon> test [15:03:11 CEST] <goodafternoon> Hi guys, I would like to record my screen + audio but I'm totally lost with ffmpeg, could you tell me how to do it ? [15:07:18 CEST] <Fig1024> you could download OBS Studio, it's free [15:18:06 CEST] <goodafternoon> but I guess ffmpeg is lighter. I gonna take a look at OBS Studio anyway, thank for the tip, but if someone still have an answer for me, I would be glad [15:30:25 CEST] <Fig1024> OBS comes with a proper GUI, while FFMpeg is all command lines, so it depends on what you prefer. Command line is good for automating stuff [15:31:16 CEST] <JEEB> also I don't think FFmpeg itself has the screen capture API(s) that came with the latest windows systems [16:06:03 CEST] <JodaZ> yeah, OBS is much better at recording the screen [18:53:45 CEST] <RazorSharpFang> How does ffmpeg have a codec for writing H.264 video? I was of the impression that it was a proprietary codec. [18:54:04 CEST] <JEEB> you're mixing two things [18:54:25 CEST] <JEEB> proprietary usually means that its specifications and similar documents are never released [18:54:43 CEST] <JEEB> (many corporations sell magical formats like that) [18:54:54 CEST] <RazorSharpFang> You're right; I was meaning to talk about patents, or other intellectual property law. [18:55:41 CEST] <JEEB> source code distribution is generally not a problem, and FFmpeg itself doesn't provide any binaries [18:56:03 CEST] <JEEB> if you are using FFmpeg for something you would have to think about whether or not you have to care about possible royalties in your use case [18:57:01 CEST] <JEEB> ISO/IEC 14496-10 aka ITU-T Rec H.264 is an open standard which is why having it implemented (FFmpeg itself only contains a decoder) has not been a problem [18:57:05 CEST] <BtbN> binaries of a h264 encoder are also not a problem [18:57:19 CEST] <BtbN> it's distributing encoded material that costs roayalties [18:57:52 CEST] <JEEB> that depends on the exact format and one would have to consult MPEG-LA's documentation if you are in a legal area where you think you would have to care about patent licenses [18:58:06 CEST] Action: JEEB hasn't kept up with it for a while [18:58:17 CEST] <RazorSharpFang> Aha, so having cutscenes encoded with H.264 will be covered by the patent, not the library/functions for decoding it. [18:58:46 CEST] <JEEB> RazorSharpFang: don't take anyone's words for it, look up MPEG-LA's docs [18:58:54 CEST] <JEEB> if you think that you have to care, that is [18:59:09 CEST] <BtbN> Only talking about h264. for HEVC it's more complex [18:59:12 CEST] <JEEB> many game companies just use the APIs that the OS provides for the video, that way they don't distribute the decoder itself [18:59:16 CEST] <RazorSharpFang> This is purely hypothetical, thought experiment. [18:59:20 CEST] <BtbN> Because there are two patent pools [18:59:24 CEST] <JEEB> there's more :P [18:59:29 CEST] <JEEB> like three or four for HEVC now [18:59:41 CEST] <BtbN> way to ruin a codec [18:59:44 CEST] <JEEB> yup [18:59:49 CEST] <JEEB> no wonder AOM went off nicely [19:00:03 CEST] <JEEB> I mean, I like what they did with the format (HEVC) but the licensing is just "lol" [19:00:31 CEST] <JEEB> RazorSharpFang: the general docs for licensing of H.264/AVC is available from MPEG-LA (which is not MPEG, just for the record) [19:00:36 CEST] <BtbN> you either don't give a damn about licensing it, or you use vp9 [19:00:51 CEST] <JEEB> so you a) decide if you are in a place where the patents matter [19:01:03 CEST] <JEEB> b) if a is true, you check the patent licensing terms from MPEG-LA [19:01:21 CEST] <JEEB> I distinctly remember that distributing decoders had a cap of I think 100k and then you had to start paying [19:01:26 CEST] <JEEB> encoders I'm not sure [19:01:37 CEST] <JEEB> but for encoding you can thank cisco I guess [19:01:45 CEST] <JEEB> they release binaries of a library you can use through libavformat [19:01:49 CEST] <BtbN> openh264 is bad [19:01:51 CEST] <JEEB> it is [19:01:54 CEST] <BtbN> you don't really want to use it [19:02:05 CEST] <BtbN> they should have just distributed x264 [19:02:20 CEST] <JEEB> apparently x264's license wasn't liberal enough for them or something [19:02:37 CEST] <BtbN> gpl? [19:02:43 CEST] <JEEB> yes, they wanted BSD or something [19:03:04 CEST] <thebombzen> well GPL is not liberal [19:03:21 CEST] <thebombzen> people are moving away from it [19:03:40 CEST] <thebombzen> mpv is moving to LGPL with the goal of no GPLed internal code, IIRC [19:03:43 CEST] <BtbN> GPL is not business-friendly, because they have to give stuff back [19:03:51 CEST] <thebombzen> GPL is not anyone-friendly [19:03:53 CEST] <JEEB> thebombzen: mpv's case is because mpv is no longer just an app [19:03:54 CEST] <BtbN> with BSD they can just absorb an entire open source codebase and do as they please [19:04:10 CEST] <thebombzen> well tbh LGPL works fine because it prevents them from eating the codebase [19:04:29 CEST] <thebombzen> but GPL is essentially "you cannot use this if you are a business" [19:04:39 CEST] <RazorSharpFang> Is it really that bad? [19:04:53 CEST] <BtbN> Like MS recently had the exact same security hole as haimdall, because they just copied its code. [19:04:57 CEST] <JEEB> BtbN: http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf [19:04:59 CEST] <thebombzen> well GPL eats code and forces anything to be GPL [19:05:00 CEST] <JEEB> they still have the 100k cap [19:05:03 CEST] <JEEB> just fyi [19:05:10 CEST] <JEEB> since you said that encoder or decoder distro is free [19:05:23 CEST] <thebombzen> anything that links to GPL has to follow a whole bunch of restrictions [19:05:42 CEST] <thebombzen> GPL software is a restrictive license that somewhat ironically limits the freedom of its users so people stop wanting to use GPLed code [19:06:11 CEST] <thebombzen> RazorSharpFang: for comparison, you cannot link to libx264 if you have a cool thing and just want to encode video. Including dynamic linking [19:06:14 CEST] <JEEB> well yes, although most of the moves I've seen have been from GPL to LGPL because suddenly there's a library provided by teh code base :P [19:06:30 CEST] <JEEB> but that just means that the needs of the project have changed [19:06:32 CEST] <thebombzen> Yea, but x264 is a GPLed library [19:06:36 CEST] <thebombzen> that's the notable difference [19:06:45 CEST] <JEEB> you can also pay x264 LLC [19:06:51 CEST] <JEEB> and get a non-GPL license [19:07:04 CEST] <JEEB> which also requires you to post all changes to x264 to x264 LLC [19:07:07 CEST] <BtbN> Qt worked the same way a long time [19:07:12 CEST] <BtbN> Either a GPL'ed library, or you pay [19:07:19 CEST] <BtbN> Which seems like a fair deal to me [19:07:22 CEST] <JEEB> yup [19:07:31 CEST] <JEEB> it all depends on your/project's needs [19:07:43 CEST] <RazorSharpFang> Maybe for professional development, but that might be a significant barrier to individuals. [19:08:10 CEST] <JEEB> RazorSharpFang: there are other alternatives if you don't want to release source code [19:08:17 CEST] <JEEB> libvpx or libaom to note a few [19:08:27 CEST] <JEEB> (that's for lossy video) [19:08:46 CEST] <JEEB> RazorSharpFang: anyways since you said you wanted to do thought experiments http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf [19:08:52 CEST] <JEEB> that's the actual tl;dr [19:09:25 CEST] <JEEB> pages 8-9 [19:09:33 CEST] <RazorSharpFang> How would you rate libvpx's video compression compared to h.264? I've heard people say it's a tad disappointing, but I think they might just have unrealistic standards. [19:10:07 CEST] <JEEB> libvpx is not too great in psychovisual optimizations and rate control [19:10:16 CEST] <JEEB> but if you're making a game you can feed it some more bit rate :P [19:10:24 CEST] <JEEB> and work around its shortcomings [19:10:40 CEST] <JEEB> in other words, you would get similar quality with smaller size with libx264 [19:10:53 CEST] <JEEB> but if H.264 is a no-go [19:10:54 CEST] <RazorSharpFang> Are you suggesting that vpx begins to struggle comparatively when deprived of bitrate? [19:11:01 CEST] <JEEB> yes [19:11:11 CEST] <BtbN> libvpx is not exaxctly a good piece of software [19:11:23 CEST] <JEEB> I hope that with libaom since it's >1 vendor it'll be better [19:11:35 CEST] <JEEB> having just el GOOG doing it wasn't exactly great :) [19:11:59 CEST] <RazorSharpFang> Well, libvpx is probably a big step above Bink video. [19:12:04 CEST] <JEEB> totally [19:12:18 CEST] <JEEB> which is why I said that "just boost the rate usage until it looks good" [19:12:35 CEST] <JEEB> with games you're not trying to compress stuff to minimal limits anyways [19:12:45 CEST] <JEEB> and it seems like VP8/9 are currently considered "no royalties needed" [19:13:10 CEST] <JEEB> and a guy in FFmpeg is working on his proprietary encoder for VP9 which is why he's optimized the FFmpeg decoder for it to high heavens [19:13:25 CEST] <JEEB> (and the FFmpeg decoder is also utilized by Firefox) [19:13:42 CEST] <JEEB> (Chromium said that they are not taking new dependencies in so it didn't get there) [19:13:58 CEST] <JEEB> (even though Chromium already uses FFmpeg for H.264) [19:49:48 CEST] <tdannecy> Is there a way to take an mkv, copy video, mixdown 5.1 audio to stereo, and add it as a second channel? [19:50:26 CEST] <CounterPillow> BtbN: Qt is actually LGPL. [19:55:15 CEST] <c_14> tdannecy: ffmpeg -i mkv -c:v copy -filter_complex asplit[a0][a1] -map [a0] -map [a1] -map 0:v -ac:1 2 out.mkv [19:55:23 CEST] <c_14> you'll probably need to escape all the [] for your shell though [20:01:17 CEST] <BtbN> CounterPillow, that's why I said "for a long time"... [20:01:54 CEST] <CounterPillow> you said "a long time", no "for", and even then that is ambiguous [20:03:11 CEST] <tdannecy> c_14: Hey that worked! Thanks a lot! :) [20:05:18 CEST] <BtbN> <BtbN> Qt worked the same way a long time [20:05:24 CEST] <BtbN> Don't see anything ambigous there [20:05:31 CEST] <BtbN> It's clear that it doesn't anymore. [20:05:53 CEST] <CounterPillow> unambiguous would be "used to work" [20:06:24 CEST] <CounterPillow> omitting the helper verb could stand for "has worked", which would imply it still works that way. [20:06:26 CEST] <BtbN> sorry for not being a native english speaker that is able to use the language to the full extend you are used to -_- [20:06:36 CEST] <BtbN> Not in the mood for this shit right now [20:06:37 CEST] <CounterPillow> I'm not a native English speaker either [20:06:42 CEST] <furq> i am a native english speaker and BtbN is right [20:06:43 CEST] <furq> hth [20:06:52 CEST] <CounterPillow> fuck you furq you backstabbing cunt [20:06:59 CEST] <CounterPillow> :^) [20:07:01 CEST] <furq> rude [20:40:02 CEST] <tdannecy> c_14: So I tried running the command in a directory with multiple .mkv files and I get this error: Filter asplit:output1 has an unconnected output [20:41:50 CEST] <thebombzen> JEEB: is libaom even ready? [20:42:00 CEST] <thebombzen> cause I thought av1 wasn't even frozen yet [20:42:09 CEST] <JEEB> no, av1 is not frozen yet [20:42:55 CEST] <furq> The bitstream format is projected to be frozen in Q3[7] or Q4[8] of 2017. [20:42:59 CEST] <Fenrirthviti> supposedly later this year [20:43:44 CEST] <thebombzen> Does that mean libaom is not useable for me (as a non-developer) [20:43:56 CEST] <furq> there's a frontend for it [20:43:59 CEST] <furq> aomenc/aomdec [20:44:17 CEST] <furq> but the files it produces aren't guaranteed to be decodable in the future [20:44:19 CEST] <thebombzen> I meant "reference implementation" rather than "specifically the library" [20:44:39 CEST] <furq> libaom is the reference implementation [20:44:53 CEST] <thebombzen> okay and also primitive reference CLI binaries [20:44:57 CEST] <furq> right [20:45:17 CEST] <thebombzen> but "the files it produces might not be decodable" is a pretty good reason not to use it from my perspective [20:45:34 CEST] <thebombzen> unless I'm specifically engaging in testing it for efficiency or speed [20:46:04 CEST] <thebombzen> wondering if ffmpeg has avcodec/libaom.c yet [20:55:28 CEST] <tdannecy> c_14: I had a typo and I was going crazy. Sorry. Thanks for your help. [21:39:04 CEST] <AndroUser> I'm trying to make a closed caption transcoder arib b24 <-> cea-708 using ffmpeg, anyone have some document for me start this project? [22:34:24 CEST] <kingsley> May I please have the benefit of your informed thoughts on why a simple filtergraph is failing? [22:34:39 CEST] <kingsley> I'm using version 7:3.2.6-1+b3 on Debian unstable. [22:34:47 CEST] <kingsley> The simple command is... [22:34:58 CEST] <kingsley> $ ffplay -i /tmp/in.mkv -vf histogram /tmp/out.mkv [22:35:14 CEST] <kingsley> ffmpeg's error message is... [22:35:26 CEST] <kingsley> Argument '/tmp/out.mkv' provided as input filename, but '/tmp/in.mkv' was already specified. [22:35:52 CEST] <kingsley> 15 lines of details are at ... [22:35:56 CEST] <kingsley> https://paste.ubuntu.com/25106670/ [22:36:02 CEST] <kingsley> What do you think? [22:47:10 CEST] <furq> uh [22:47:14 CEST] <furq> that works for me [22:49:09 CEST] <furq> oh right, ffplay [22:49:34 CEST] <furq> if you want to play it, get rid of the output filename [22:49:39 CEST] <furq> if you want to save it to a file, use ffmpeg [22:49:50 CEST] <myke> i have a video i'm looping with stream_loop, and a fixed playlist i'm using with the concat muxer. i want the video to end when the concat muxer is done, but -shortest ends it the first time the video plays thru. how can i end the video when the concat muxer is done? [22:49:53 CEST] <furq> if you want to do both, use ffmpeg and the tee muxer and pipe it to a player [22:50:02 CEST] <furq> or just multiple outputs and pipe [23:00:01 CEST] <myke> guess i can just pipe in that part instead of using the concat muxer and it'll end when that pipe closes, ty [23:12:34 CEST] <kingsley> furq, [23:12:40 CEST] Last message repeated 1 time(s). [23:12:40 CEST] <kingsley> brave, [23:12:44 CEST] <kingsley> courageous, and [23:12:46 CEST] <kingsley> BOLD! [23:12:53 CEST] <kingsley> Long live his fame! [23:12:56 CEST] <kingsley> Long live his glory! [23:13:05 CEST] <kingsley> And long may his story be told! [23:13:16 CEST] <kingsley> (Ie: Thank you very much. It worked.) [00:00:00 CEST] --- Mon Jul 17 2017

1 0

ffmpeg-devel.log.20170715
by burek 16 Jul '17

16 Jul '17

[00:01:08 CEST] <Gramner> J_Darnley ported all the other recent x86inc changes from x264 but left that one out, I don't know if there was some issue or objection or whatever [00:01:41 CEST] <nevcairiel> I think he was working up to that one [00:02:05 CEST] <nevcairiel> and wanted to get the others all done first, especially because of the one cpuflag we had that x264 didnt have yet [00:02:39 CEST] <Gramner> ah the aesni one. that has been pushed to x264 [00:03:34 CEST] <BBB> Gramner: fixed [00:04:24 CEST] <BBB> its really just intended as a slightly updated version of https://wiki.videolan.org/X264_asm_intro/, because that was getting seriously old [00:06:03 CEST] <Gramner> yeah, that was very much outdated [00:35:19 CEST] <J_Darnley> Gramner: I don't remember why not. [00:35:59 CEST] <J_Darnley> Perhaps I thought it a little pointless to port them when we didnt even support an assembler that could use them [00:36:43 CEST] <J_Darnley> nevcairiel: ah yes [00:36:48 CEST] <J_Darnley> I think I need to check which ones I pushed [00:48:07 CEST] <JEEB> BBB: cheers for releasing the updated entry <3 [02:06:52 CEST] <BBB> Gramner: First thing I found out about x86inc.asm is that they put vzeroupper after the register pops in the epilog, which I am not sure is legal on Windows x64. <- is that true? [02:07:56 CEST] <Gramner> I saw that comment and I have no idea what he's talking about. vzeroupper zeroes the upper parts of vector registers so it has nothing to do with how you pop registers [02:10:17 CEST] <Gramner> maybe some sort of exception handling stack unrolling stuff that we don't care about? [02:11:28 CEST] <iive> maybe he tries to tell that they should not be zeroed at all? [02:11:45 CEST] <Gramner> windows have some complicated exception handling stack debugging stuff that's way to bothersome to care about in asm [02:12:40 CEST] <Gramner> only the lower xmm parts of caller-saved xmm regs needs to be saved, anything above the first 128 bits are volatile [02:14:22 CEST] <Gramner> callee-saved* [02:15:37 CEST] <jamrial_> vzeroupper is also kinda slow. would be cool to have a way to prevent it being issued (other than adding INIT_XMM before RET) on functions where you know you're clearing the high 128 bits of every register [02:16:11 CEST] <jamrial_> like those that end with HADDD, meaning the last bunch of instructions use xmm and implicitly clear said high bits [02:16:22 CEST] <Gramner> clearing registers through other means than vzeroupper or vzeroall doesn't work. the cpu state still marks them as dirty in that case [02:16:31 CEST] <jamrial_> i see [02:16:46 CEST] <Gramner> avx-512 solves it though. at least on x64 [02:16:50 CEST] <jamrial_> ah well, whatever :p [02:17:18 CEST] <Gramner> since you can freely use regs 16-31 without caring about legacy xmm state (since there are no legacy registers for those) [02:18:15 CEST] <jamrial_> do vzeroupper and vzeroall work on them if issued, though? [02:18:50 CEST] <jamrial_> i guess if there's an EVEX encoding of both they should... [02:19:20 CEST] <Gramner> iirc no [02:19:24 CEST] <atomnuker> at the start they shouldn't, the CPU zeroes them out for you for free apparently [02:19:37 CEST] <atomnuker> (if you issue pxor or something else [02:20:58 CEST] <iive> zeroupper 2 cycles on sandy bridge, strange, it is 4 microops [02:20:59 CEST] <Gramner> vzeroupper is like 4/1 or something. it can be an issue in really short functions I guess, in longer ones it should be hidden by OoOE pretty well [02:21:17 CEST] <Gramner> probably µarch-dependent [02:21:23 CEST] <atomnuker> *at the start [02:21:28 CEST] <atomnuker> (not in general) [02:22:20 CEST] <jamrial_> i think i saw one arch in agner's pdf that mentioned one uop per half of a register. so 16 for vzeroupper and 32 for vzeroall [02:22:54 CEST] <Gramner> vzeroall is super slow iirc. not really sure what the use case of it is [02:23:32 CEST] <iive> jamrial_: on atom generations? [02:23:35 CEST] <Gramner> I can't really thing about what scenario reuires you to zero all regs completely that is common enough to warrant it's own instruction [02:23:49 CEST] <jamrial_> iive: no, looks like bulldozer [02:23:56 CEST] <iive> that's amd [02:24:31 CEST] <iive> you can count on them doing the wrong thing in simd. e.g. maskmov [02:25:01 CEST] <iive> jamrial_: how is it on ryzen? [02:25:03 CEST] <jamrial_> yeah, looks like vzeroupper is fine on intel but slow on amd, whereas vzeroall is slow on everything [02:25:56 CEST] <jamrial_> iive: looks like the same as bulldozer [02:29:49 CEST] <iive> maybe we should separate assembly by cpu family... because there are really major diffrences between amd and intel. [02:31:01 CEST] <atomnuker> not worth it, they're not that dissimilar [02:31:18 CEST] <iive> jamrial_: btw, do you have a bulldozer? [02:31:19 CEST] <atomnuker> besides, then we'd get into the whole "intel-optimized ecosystem" [02:32:20 CEST] <iive> the difference is cycles is quite major. [02:33:05 CEST] <Gramner> bulldozer is the new p4. nobody really cares about it imho [02:33:41 CEST] <iive> what are game consoles running on? [02:34:02 CEST] <atomnuker> iive: they're still fast enough to not drop every single bit of asm code written [02:34:42 CEST] <iive> atomnuker: you understood me wrong. You need a special crafted version for amd to run on optimal speed. [02:34:51 CEST] <Gramner> ps4 and xbone uses jaguar [02:35:41 CEST] <iive> btw, which one was where you make the code run faster, by placing nop between x87 ops? [02:35:44 CEST] <Gramner> crafting special asm implementations for each µarch is not really worth it. way to hard to maintain [02:36:00 CEST] <atomnuker> iive: atom [02:36:19 CEST] <iive> atomnuker: i\m sure it was amd... [02:36:53 CEST] <atomnuker> no, it was atom [02:39:06 CEST] <iive> yes, it is atom [02:39:13 CEST] <iive> appologies to AMD [04:17:17 CEST] <cone-071> ffmpeg 03Michael Niedermayer 07master:d0ba0be35530: fate: add sub-srt-badsyntax test [12:10:22 CEST] <wm4> rcombs: someone thinks you're MIA: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213643.html [12:19:57 CEST] <ubitux> MIA? not sure it's matching the urban dictionary definition here& [12:30:53 CEST] <nevcairiel> AWOL maybe =p [12:31:31 CEST] <durandal_1707> what prediction ffv1 uses? [12:45:13 CEST] <durandal_1707> atomnuker: i think finite state entropy, fse for short, could be base for ffv2 codec [12:45:43 CEST] <durandal_1707> fse is faster than arithmetic coding [12:49:41 CEST] <nevcairiel> what about the ANS thing that av1 now uses? [12:50:13 CEST] <nevcairiel> its supposed to compress as well as arith with a speed of huffmann [12:52:00 CEST] <JEEB> durandal_1707: there are already ffv2 patches - http://akuvian.org/src/x264/ [13:14:21 CEST] <durandal_1707> nevcairiel: fse is ans [13:48:47 CEST] <iive> BtbN: got some free time? [13:50:54 CEST] <BtbN> yeah, just tell me which patch and which tests [14:01:27 CEST] <iive> just a second [14:02:08 CEST] <iive> https://patchwork.ffmpeg.org/patch/4270/ [14:11:06 CEST] <BtbN> All the variations again, or just some specific ones that were changed? [14:13:56 CEST] <durandal_1707> JEEB: how that compares to ffv1? [14:15:25 CEST] <JEEB> no idea [14:15:49 CEST] <JEEB> pengvado might have some answers if he appears out of the mist [14:17:35 CEST] <BtbN> iive, https://bpaste.net/show/e0f70aedcff3 that's with master + patch, otherwise unmodified [14:22:24 CEST] <iive> if this is with the same sample, then i think it is good news :D [14:23:12 CEST] <BtbN> pretty much the exact same commandline [14:24:22 CEST] <iive> yes, it is the same sample, it's in the log. [14:25:10 CEST] <iive> try the defines in the .asm file. just the first 2. [14:30:47 CEST] <BtbN> https://bpaste.net/show/a20324b995c9 CONST_IN_X64_REG_IS_FASTER 0 [14:33:25 CEST] <iive> nice, it is not dramatically faster anymore :) actually almost same speed. [14:34:20 CEST] <BtbN> https://bpaste.net/show/3d753cd86f43 STALL_WRITE_FORWARDING 1 [14:37:49 CEST] <iive> that one is 7 cycles faster. [14:38:37 CEST] <iive> i don't think this is worth it to have a special version just for ryzen. [14:39:19 CEST] <iive> BtbN: may i ask you to do one more test. restore to the defaults and then in the .asm file, find the cmpss instruction. [14:39:49 CEST] <iive> - cmpless xmm0, xmm3 [14:39:49 CEST] <iive> + cmpps xmm0, xmm0, xmm3, 1 [14:42:50 CEST] <jdarnley> BBB: I should get you to plug upipe as another project which uses x86inc [14:43:30 CEST] <BtbN> https://bpaste.net/show/7dc86cc1a053 [14:44:06 CEST] <BBB> whats upipe? [14:44:14 CEST] <BBB> is that your low-latency thing for high-bitrate video? [14:45:06 CEST] <jdarnley> We use it for that yes. [14:45:17 CEST] <jdarnley> https://github.com/cmassiot/upipe/tree/master/x86 [14:48:31 CEST] <mifritscher1> hi [14:50:47 CEST] <durandal_1707> hi [14:54:58 CEST] <iive> BtbN: this one seems slower. [14:58:23 CEST] <iive> BtbN: revert to default and run avx1 version. (cpuflags -avx2) I would guess it is still ~100 cycles faster. just want to be sure. [14:58:40 CEST] <iive> i am probably not going to enable the avx2 version in the final code. [15:03:57 CEST] <BtbN> https://bpaste.net/show/225d6e1113cd [15:05:27 CEST] <iive> wow, it is a lot faster then the v3 version. Nice. [15:07:03 CEST] <iive> it used to be around 1970 c , now it is around 1933 c . [15:07:40 CEST] <iive> well, that's all the benchmarks i can think of. [15:15:01 CEST] <iive> thank you very much :) [15:39:58 CEST] <iive> atomnuker: i won't mind if you run few benchmarks, just to be sure everything is ok. and the cmpless->cmpps thing. [16:56:23 CEST] <atomnuker> durandal_1707: ugh, its ANS based [16:56:32 CEST] <atomnuker> no, the daala one is better [16:56:47 CEST] <atomnuker> it can be SIMDd because its multisymbol [16:57:00 CEST] <atomnuker> and neither are any better in terms of compression [16:57:13 CEST] <atomnuker> they're both extremely close to the entropy limit [16:59:32 CEST] <atomnuker> also ANS encoding can be quite expensive [16:59:59 CEST] <atomnuker> it has to reverse all bits in a second pass in the entire packet [18:06:58 CEST] <durandal_1707> atomnuker: so is there lib of this daala stuff as encoder and decoder? [18:13:54 CEST] <atomnuker> durandal_1707: https://github.com/atomnuker/FFmpeg-FFA1/blob/master/libavcodec/daala_entro… [18:14:01 CEST] <atomnuker> https://github.com/atomnuker/FFmpeg-FFA1/blob/master/libavcodec/daala_entro… [18:14:44 CEST] <atomnuker> encoding and decoding, mostly rewritten ant optimized daala entropy coding functions [18:14:48 CEST] <atomnuker> *and [18:17:08 CEST] <atomnuker> ff_daalaent_encode_generic/ff_daalaent_decode_generic is what's SIMDable and what's going to be called the most [18:17:58 CEST] <atomnuker> its what does adaption on a per-call basis [19:42:40 CEST] <JEEB> huh [19:43:07 CEST] <JEEB> with a mpeg-ts stream I have on hand avformat_find_stream_info actually ends up having memory "still reacahable" according to valgrind [19:43:13 CEST] <JEEB> with an mp4 file it doesn't happen [19:43:36 CEST] <JEEB> I used `valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --trace-children=yes` [19:44:14 CEST] <JEEB> http://up-cat.net/p/a4ba862e [19:44:40 CEST] <JEEB> of course since it's a one-off it's not too bad [19:54:00 CEST] <nevcairiel> The lock manager leaking is kinda normal [19:55:05 CEST] <JEEB> ok [19:57:22 CEST] <wm4> yeah [19:57:30 CEST] <wm4> also the lock manager shouldn't exist [19:57:36 CEST] <wm4> but that's still a far goal [19:57:53 CEST] <nevcairiel> we already have the solution to that, just needs a lot of work :p [19:58:08 CEST] <kierank> Does it protect more than static tables? [19:58:53 CEST] <nevcairiel> no [19:59:15 CEST] <nevcairiel> i believe its not even used if the codec is marked as threadsafe [19:59:22 CEST] <nevcairiel> which might explain why JEEB may not see it with some file [20:00:08 CEST] <JEEB> yea [20:00:17 CEST] <JEEB> the mp4s and mkvs with H.264 and AAC don't get it [20:00:32 CEST] <JEEB> the MPEG-TS with MPEG-2 Video, AAC and H.264 all mixed gets it [20:00:50 CEST] <nevcairiel> its probably mpeg2 then [20:01:08 CEST] <wm4> hm I should propose a patch to deprecate the codec register functions [20:01:15 CEST] <wm4> and call them automatically instead [20:27:00 CEST] <JEEB> oh, so input in lavf has close, but output doesn't? interestingf [20:27:14 CEST] <JEEB> just expected those two to be symmetrical [20:33:13 CEST] <JEEB> oh, right. misread the name of the function. that's why [21:58:09 CEST] <faLUCE> Hello. Which is the correct form for this instruction? 1) av_opt_set(mMuxerContext->priv_data, "mpegts_flags", "pat_pmt_at_frames", 1); OR 2) av_opt_set(mMuxerContext->priv_data, "pat_pmt_at_frames", "1", 0); [22:18:03 CEST] <wm4> I don't think priv_data is a public field, but haven't checked [22:21:39 CEST] <TD-Linux> atomnuker, fwiw ANS can be multisymbol too (rANS) [22:30:46 CEST] <atomnuker> rans's downside gets particularly bad with the huge packet sizes of lossless video [22:35:06 CEST] <JEEB> were refcounted frames limited to decoding? [22:36:49 CEST] <atomnuker> no, pretty sure you can give encoders refcounted frames [22:42:38 CEST] <JEEB> well I'm just having an init() function and I wondered if I wanted to put the av_opt_set_int of refcounted_frames only to a decoder or not [22:43:01 CEST] <JEEB> of course they are usable with encoders as well :) [22:43:12 CEST] <JEEB> although wait, that doesn't make sense [22:43:31 CEST] <JEEB> as in, of course they don't need the flag since encoders don't output AVFrames :P [22:51:13 CEST] <nevcairiel> encoders might potentially store multiple input frames [22:51:21 CEST] <nevcairiel> although not sure if any make use of that with refcounting [22:51:41 CEST] <nevcairiel> the option wouldnt make a difference for them, though [22:52:59 CEST] <JEEB> yeah [22:53:10 CEST] <JEEB> I've been looking at the screen a bit too much recently I guess :P [00:00:00 CEST] --- Sun Jul 16 2017

1 0

ffmpeg.log.20170715
by burek 16 Jul '17

16 Jul '17

[00:00:26 CEST] <Asuran> hmm really? would it make it sound worse or? i usally do that in audacity [00:00:33 CEST] <kazuma_> why does "ffprobe video.mkv > videoinfo.txt" not work? [00:00:56 CEST] <furq> because ffprobe with no options outputs to stderr [00:04:39 CEST] <Asuran> furq, would it for example resample 48khz again and using libopus prevens it? [00:04:53 CEST] <furq> nvm libopus doesn't resample [00:05:03 CEST] <Asuran> doesnt? im sure it does [00:05:14 CEST] <Asuran> you can give opusenc for example 44khz input [00:05:18 CEST] <Asuran> and it will be upsampled [00:05:19 CEST] <furq> right, opusenc does [00:05:26 CEST] <furq> that's part of opus-tools, not libopus [00:05:33 CEST] <Asuran> alright thanks [00:05:36 CEST] <furq> anything using the lib has to resample itself [00:10:13 CEST] <Asuran> thx [00:35:11 CEST] <Asuran> does -ar does not resample if same khz? [00:37:14 CEST] <JEEB> it enables the filter and no idea what it does if input=output, hopefully it is nice enough to do no-op if the input rate matches output rate :P [00:38:25 CEST] <Asuran> should i left it out then and let ffmpeg decide or who it does [00:44:30 CEST] <grublet> JEEB: maybe somebody should test if input=output for -ar with same rate [00:45:06 CEST] <JEEB> it's not closed source so you can just check the docs or the source :) [00:46:29 CEST] <furq> it's a noop [00:46:37 CEST] <furq> you don't need to look at the source, just use -v debug [00:46:51 CEST] <JEEB> :) [00:47:20 CEST] <thebombzen> Although whether or not it autoinserts the filter shouldn't be relevant, because aresample should do nothing for input=output [00:47:43 CEST] <thebombzen> in the same way that -vf scale does nothing if the input and output size and pixel format are the same [00:48:57 CEST] <furq> -af aresample does actually do something though [00:49:29 CEST] <furq> [Parsed_aresample_0 @ 0x80d435ac0] ch:2 chl:stereo fmt:s16 r:44100Hz -> ch:2 chl:stereo fmt:s16 r:44100Hz [00:49:37 CEST] <furq> that's missing with -ar 44100 [00:50:25 CEST] <furq> and ofc by "something" i mean potentially still nothing [00:50:39 CEST] <furq> but -ar doesn't even insert the filter if it's the same as the input [01:08:41 CEST] <Asuran> -af aresample=resampler=soxr:cheby=1:precision=28:dither_method=shibata -ar 48000 so should i use it like this [01:15:37 CEST] <thebombzen> Asuran: try -af aresample=48000:resampler=soxr:cheby=1:precision=28:dither_method=shibata [01:17:24 CEST] <Asuran> thanks [01:17:27 CEST] <Asuran> i use it now [05:28:19 CEST] <created> How do I tell libavcodec not to reorder frames for display order? [05:31:17 CEST] <created> (I want them in coded order, as given to it) [05:50:37 CEST] <created> It's amazing how much useless junk you can configure (or pretend to configure) [05:50:51 CEST] <created> But no option to avoid reorder :/ [06:00:52 CEST] <created> Hooray! [06:01:04 CEST] <created> I think I found a way to bleed the right order out of libavcodec [06:01:56 CEST] <created> If I don't get a picture, I try again with an empty packet and libavcodec splurges out the frame it was saving [06:03:56 CEST] <created> At least.. it works nicely in avc1... mp4 seems to not save the i frames in this case for some reason [06:07:37 CEST] <created> mp4 (aka mp4v) doesn't have b-frames, though, does it? [06:09:33 CEST] <created> Aka mpeg4 or whatever it's called [06:10:15 CEST] <atomnuker> yes it does [06:10:18 CEST] <atomnuker> mpeg2 does [06:10:44 CEST] <atomnuker> and you seem to be doing something very wrong to want to get frames in some other order than present order [06:12:31 CEST] <created> Something unusual, but not wrong [06:13:26 CEST] <created> What's the difference between MPEG2 and MPEG4? [06:14:13 CEST] <created> (I pretty much need to stream an application the frames in decompress order, I have no choice) [06:16:01 CEST] <atomnuker> the correct way is to ref each decoded frame and wait for the frame with the lowest (expected) pkt_dts to appear [06:16:19 CEST] <atomnuker> this obviously wouldn't work with variable frame rate [06:17:08 CEST] <atomnuker> (or maybe it would assuming the dts is always monotonic) [06:17:16 CEST] <created> That means I can't stream frames until I'm done with the entire file, though, no? [06:17:23 CEST] <atomnuker> no [06:17:26 CEST] <created> Unless I misunderstand you [06:17:40 CEST] <created> By 'ref' do you mean save? Else, what's 'ref'? [06:17:49 CEST] <atomnuker> av_frame_ref [06:18:10 CEST] <atomnuker> you do know you unref frames once you're done with them, no? [06:19:01 CEST] <created> No, I don't think that was in the example I copied [06:19:44 CEST] <created> But how do I know when to wait for a frame with lower dts? [06:19:45 CEST] <atomnuker> not sure what you copied from where, but generally once you decode a frame you need to unref it once you're done with it [06:20:40 CEST] <atomnuker> the next sequential dts is going to be the present dts + the delta (of the current dts from the previous dts) [06:21:31 CEST] <atomnuker> what program requires to be fed _decoded_ frames with unchanged _encoded_ order? [06:22:17 CEST] <created> But that still requires waiting for all the b-frames to come [06:23:15 CEST] <atomnuker> no, it requires waiting for the next one to arrive [06:23:27 CEST] <created> Yeah, I mean it requires waiting for additional packets [06:24:24 CEST] <created> Which isn't ideal when I just want to get a frame that was already decompressed and libavcodec is just sitting on it (and my application needs it before it can display the other frames that libavcodec is giving me) [06:24:49 CEST] <atomnuker> why? [06:25:05 CEST] <created> Because it expects frames in decode order, as simple as that [06:25:27 CEST] <created> (my != one I control in any way) [06:25:47 CEST] <atomnuker> whatever you have is completely wrong [06:26:18 CEST] <atomnuker> if libavcodec outputs a b frame early this would probably break the decoder state [06:26:39 CEST] <atomnuker> since the p frames you receive depend on a b frame already popped off the list of references [06:29:39 CEST] <created> Yeah, though it seems to work fine in h264's case (unless something's breaking without me noticing) [06:30:26 CEST] <created> So I guess I'll keep my workaround there and deal with mpeg4 when I get to it [06:30:38 CEST] <created> Thanks for trying to help and putting up with me, atomnuker :p [06:31:49 CEST] <atomnuker> (if you have to deal with vp9 this will break completely because there are invisible frames which you never present) [06:33:31 CEST] <created> Yeah, hopefully I won't need to deal with much else. Maximum, I might try the dts sugestion [06:36:22 CEST] <created> I think I likely won't have to deal with mpeg4s with bframes either [06:55:12 CEST] <created> Oh and re:av_frame_unref [06:55:39 CEST] <created> Going by the documentation of avcodec_decode_video2, it should only be used if refcounted_frames was set [06:55:57 CEST] <created> Otherwise, the frame is valid until the next decode, which is perfect for me [06:57:16 CEST] <created> (As I need to copy/convert it anyway) [06:58:58 CEST] <atomnuker> ugh, a memcpy [07:02:16 CEST] <created> No [07:02:21 CEST] <created> Also.. I wonder if... [07:07:32 CEST] <created> Hooray, it looks like everything I said is invalidated - I can use display order after all [07:07:44 CEST] <created> :P [07:20:37 CEST] <created> (Tunnel vision is a difficult thing to avoid) [07:21:30 CEST] <created> Thanks for the help! [11:38:12 CEST] <cableguy> hey team [11:38:29 CEST] <cableguy> why does my command copy only last audio track in the vob and not all audio tracks? [11:39:00 CEST] <cableguy> ffmpeg -i "file.vob" -c copy -fs 10000000 -ss 00:00:00 -t 00:10:00 "copy.vob" [11:39:29 CEST] <cableguy> e.g. source vob has 2 audio tracks, ffmpeg picks only 2nd audio track [11:39:35 CEST] <cableguy> where does 1st audio track disappear [11:42:40 CEST] <kerio> furq the histeq filter only takes 8 bit inputs ;-; [11:47:32 CEST] <furq> cableguy: -map 0 [11:47:43 CEST] <cableguy> what does that do [11:48:48 CEST] <cableguy> i get 0 byte [11:49:22 CEST] <cableguy> Invalid media type data for output stream #0 [11:49:49 CEST] <furq> -map 0:v -map 0:a [11:50:56 CEST] <furq> or -map 0 -copy_unknown [11:54:00 CEST] <cableguy> -map 0:v -map 0:a works [11:54:07 CEST] <cableguy> the other one gives same error [11:54:58 CEST] <cableguy> wait, its wrong [11:55:03 CEST] <cableguy> it remaps audios order [11:55:20 CEST] <cableguy> the 2nd track (foreign language) becomes 1st track and the 1st track (english) becomes 2nd track [11:55:32 CEST] <cableguy> i dont need that [11:56:38 CEST] <furq> https://ffmpeg.org/ffmpeg.html#Advanced-options [12:04:02 CEST] <cableguy> but its not working [12:04:07 CEST] <cableguy> the -map 0 [12:04:14 CEST] <cableguy> "For example, to map ALL streams from the first input file to output" [12:04:19 CEST] <cableguy> "ffmpeg -i INPUT -map 0 output" [12:04:31 CEST] <cableguy> it gives 'Invalid media type data for output stream #0 [12:10:37 CEST] <cableguy> nevermind,im retarded,the audio tracks are already mixed up in the source [12:10:50 CEST] <cableguy> so yeah furq thanks for -map 0:v -map 0:a [14:46:26 CEST] <mifritscher1> hi [14:47:18 CEST] <mifritscher1> I'm trying to encode. in what cases can AVFormatContext.pb be null (so avio.open() crashes) ? [14:47:49 CEST] <mifritscher1> a av_dump_format says: [14:47:58 CEST] <mifritscher1> Output #0, mpeg, to 'C:\temp\blabb.avi': [14:47:58 CEST] <mifritscher1> Stream #0:0: Unknown: none (mpeg1video) [14:49:05 CEST] <mifritscher1> it seems that a muxer is missing? [15:18:52 CEST] <mifritscher1> hmm, if I give a broken filename to it it returns normally [15:19:03 CEST] <mifritscher1> (albeit with a error message) [15:34:02 CEST] <mifritscher1> got it :-) (Java jni mistake) [19:42:38 CEST] <Asuran> how do i pass x265-params when they already spaced with : but the param itself uses : like -x265-params deblock=1:1 [19:46:19 CEST] <kepstin> Asuran: have you tried escaping it with a '\'? (note that you'll have to quote or escape it so your shell doesn't eat it, too. [19:46:22 CEST] <kepstin> ) [19:49:52 CEST] <Asuran> works thanks [21:56:29 CEST] <faLUCE> Hello. Which is the correct form for this instruction? 1) av_opt_set(mMuxerContext->priv_data, "mpegts_flags", "pat_pmt_at_frames", 1); OR 2) av_opt_set(mMuxerContext->priv_data, "pat_pmt_at_frames", "1", 0); [22:01:28 CEST] <wondiws> Hi, I do "ffmpeg -i yolt.vob -vn acodec copy file.ac3", but this gives me the first soundtrack, which is French dub, how do I get the third? [22:03:24 CEST] <c_14> -map 0:a:2 [22:03:57 CEST] <c_14> or maybe -map 0:m:language:eng (or whatever language code) [22:20:44 CEST] <faLUCE> I'm trying to set some params on the mpegts muxer, but the result is the same of when I don't set them. Here's the CLI, what's wrong? ffmpeg -i sgarbi2.mkv -f mpegts -pat_pmt_at_frames 1 -mpegts_flags resend_headers -an sgarbo.ts [22:21:34 CEST] <faLUCE> sorry: ffmpeg -i sgarbi2.mkv -f mpegts -mpegts_flags pat_pmt_at_frames -mpegts_flags resend_headers -an sgarbo.ts [22:22:17 CEST] <faLUCE> when I inspect the produced mpegts file, with wireshark, I see it's the same (same position of PATs and PMTs) of that without options [22:26:15 CEST] <c_14> you're overwriting the flags [22:26:24 CEST] <c_14> use -mpegts_flags pat_pmt_at_frames+resend_headers [22:26:36 CEST] <JEEB> flags are basically bitmasks [22:26:48 CEST] <JEEB> but yea, -v debug might have also shown you what was happening [22:30:17 CEST] <faLUCE> great c_14 [22:31:22 CEST] <faLUCE> how can I obtain the same result with C code? I tried av_opt_set(mMuxerContext->priv_data, "pat_pmt_at_frames", "1", 0); but it doesn't seem to work [22:33:04 CEST] <c_14> if you're setting 2 flags, the same way [22:34:28 CEST] <faLUCE> c_14: av_opt_set(mMuxerContext->priv_data, "mpegts_flags", "pat_pmt_at_frames+resend_headers", 1); ? [22:35:02 CEST] <c_14> probably [22:50:14 CEST] <faLUCE> now; I'm trying to set pes_payload_size: fmpeg -i sgarbi2.mkv -f mpegts -pes_payload_size 752 -an sgarbo.ts but it doesn't set it.... what could be wrong? [23:52:57 CEST] <klow> Hey, anyone know if its easily possible to losslessly extract the left channel of an mp3 file to a new mp3 (to half the filesize of an mp3 where the Left and Right channels are the same data) [23:53:14 CEST] <klow> I have a load of lectures etc where the audio is same on both sides , in mp3 format , want to reduce size [23:54:06 CEST] <c_14> With ffmpeg, no. In general probably no [23:57:50 CEST] <atomnuker> its not going to reduce the size anyway, the encoder is bound to see nothing in the right and spend as few bits as possible [00:00:00 CEST] --- Sun Jul 16 2017

1 0

ffmpeg-devel.log.20170714
by burek 15 Jul '17

15 Jul '17

[00:49:03 CEST] <kierank> durandal_170: give foo86 commit [00:52:33 CEST] <jamrial> kierank: if you reviewed his dolby_e or dts patchsets, then push them [00:53:36 CEST] <peloverde> durandal_170: Any update on aac960? [02:34:12 CEST] <cone-915> ffmpeg 03Kaustubh Raste 07master:df806605f7b7: avcodec: Add prefetch for mips [02:34:12 CEST] <cone-915> ffmpeg 03Aleksandr Slobodeniuk 07master:390e028c663b: avutil/threadmessage: fix error return in case of av_fifo_alloc failure [04:53:15 CEST] <amey> [ashowinfo_hanning @ 0x328b8e0] n:90 pts:16427 pts_time:2.98022 pos:-1 fmt:fltp channels:1 chlayout:mono rate:5512 nb_samples:2048 checksum:B8DA7FD0 plane_checksums: [ B8DA7FD0 ] [04:53:15 CEST] <amey> Above is description of frame as shown by ashowinfo filter. I want to use samples somewhere else. I am not able to figure out how to get all 2048 float samples out of frames. When I typecast frame->data field to float I only get 64 valid values which is backed by frame->linesize[0] = 256 bytes, thus 256/4 = 64 samples. What is relation between nb_samples and sample format and how to get all 2048 samples out of [04:53:15 CEST] <amey> frame? [05:02:39 CEST] <amey> Or there is possibility of frame itself being corrupt. Saying 2048 samples but only having 64? [05:33:27 CEST] <beauty> how to know ts stream's bitrate? [05:36:46 CEST] <beauty> ?? [05:57:42 CEST] <cone-759> ffmpeg 03Rostislav Pehlivanov 07master:91b27b83939a: opusenc: use float_dsp for non-transient windowing [07:57:38 CEST] <LongChair> jkqxz: i'm back, was wondering if you could gimme a patch file with your latest hwcontext_drm changes, or even better a link to the GH repo / branch where you would have those so that i can update the rockchip decoder :) [10:20:31 CEST] <durandal_1707> should i add long double to swresample as sample format? [10:38:48 CEST] <wm4> would anyone insist on still keeping VDA? [10:39:17 CEST] <wm4> because I'm at a point where I'm fixing videotoolbox, and it would require fixes to VDA code as well, which I'm not going to touch [11:17:43 CEST] <wm4> how do you make "make install" not strip symbols again? [11:21:07 CEST] <nevcairiel> configure with disable-stripping? [11:22:53 CEST] <wm4> sigh [11:22:56 CEST] <nevcairiel> but maybe that doesnt even help [11:22:57 CEST] Action: wm4 rebuilds [11:22:58 CEST] <nevcairiel> who knows [11:23:13 CEST] <wm4> stupid crap [11:23:20 CEST] <wm4> why make life harder for no reasomn [11:23:41 CEST] <nevcairiel> should've adopted the autotools way and offer make install and make install-strip [11:29:22 CEST] <wm4> and of course it'll still be built with optimizations [12:44:51 CEST] <jkqxz> LongChair: <http://ixia.jkqxz.net/~mrt/ffmpeg/drm/0001-lavu-Add-DRM-hwcontext.patch> (rebased again). [12:45:24 CEST] <kierank> durandal_1707: for super audiophile? [12:45:34 CEST] <durandal_1707> peloverde: post patch to ml [12:45:53 CEST] <durandal_1707> kierank: no, for atomnuker [12:47:04 CEST] <LongChair> jkqxz: thanks [12:52:19 CEST] <BtbN> wow, VDPAU is alive [13:17:47 CEST] <philipl> BtbN: They obviously finally hired someone. [13:48:27 CEST] <thebombzen> wm4: I believe --enable-debug=3 disables opt and stripping [14:49:26 CEST] <cone-527> ffmpeg 03Derek Buitenhuis 07master:e10c31f3316a: hdsenc: Remove dead store [15:10:14 CEST] <Compn> anyone tried the libfuzzer-gv yet ? [18:29:04 CEST] <atomnuker> is the last git commit hash defined anywhere? [18:29:13 CEST] <atomnuker> as a macro [18:31:15 CEST] <J_Darnley> perhaps in FFMPEG_VERSION [19:10:09 CEST] <BBB> would people like an updated version of an x86inc.asm tutorial? [19:10:22 CEST] <BBB> the one from x264 is kind of prehistorical [19:11:12 CEST] <kierank> yes [19:11:23 CEST] <kierank> maybe I can allocate some time for J_Darnley to work on this with you BBB [19:11:42 CEST] <kierank> unless you want to do it alone [19:12:14 CEST] <BBB> I already have one :-p [19:12:18 CEST] <BBB> Im considering making it public [19:12:24 CEST] <BBB> (need to clean it up and sanitize it a little) [19:12:39 CEST] <BBB> (basically remove any references to internal materials / symbols etc.) [19:12:50 CEST] <BBB> but Id appreciate some review from you or J_Darnley if you guys have time [19:13:02 CEST] <BBB> Ill probably put it on my blog, but also in the wiki or so [19:13:35 CEST] <BBB> its not intended to teach people how to write assembly, i.e. it assumes you know what assembly is and how it works, it really only teaches the x86inc.asm-specific pieces [19:13:57 CEST] <J_Darnley> Sure. Send me a link privately if you want me to check it out before hand. [19:14:06 CEST] <BBB> cool [19:14:18 CEST] <BBB> hm, in fact [19:14:28 CEST] <BBB> I bet you guys would want to extend it to cover things like floating point etc. [19:14:47 CEST] <BBB> (how does argument passing work across platforms, return values, etc.) [19:15:54 CEST] <J_Darnley> I'm sure others would be more interested in that. I still haven't done any fp in assembly [19:16:00 CEST] <BBB> ok [19:16:23 CEST] <kierank> BBB: my issues is I know how to use x264asm at a basic level (i.e the old x264 tutorial) but I don't understand all the crazy shit you guys do [19:16:35 CEST] <BBB> :D [19:16:47 CEST] <BBB> Im wondering now what crazy shit youre refering to [19:17:03 CEST] <tdjones> I would really appreciate some asm material. They teach it at a very basic level in uni usually, but I can't really follow much of the asm I see on the ML either [19:17:08 CEST] <kierank> for example why and when to use the stack or red zone isn't covered in the old tutorial [19:17:25 CEST] <kierank> floating point as you say [19:19:05 CEST] <BBB> my tutorial covers stack memory [19:19:13 CEST] <BBB> but like I said, no floating point material [19:19:25 CEST] <BBB> tdjones: ok, cool [19:19:28 CEST] <BBB> let me spend some time on this [19:19:39 CEST] <BBB> well just note this down as another beer owed by kierank [19:19:44 CEST] <kierank> ahahaha [19:19:47 CEST] <BBB> Ill get so drunk at VDD this year [19:19:51 CEST] <BBB> yikes [19:19:58 CEST] <atomnuker> yep, the only way to learn asm now is to be taught by someone [19:20:17 CEST] <BBB> atomnuker: what would you want to see in a tutorial? [19:20:20 CEST] <kierank> atomnuker: no the best way to learn asm is to write code [19:20:33 CEST] <atomnuker> actually yes [19:22:04 CEST] <BBB> I currently have x86inc.asm example, then INIT_*, cglobal, DEFINE_ARGS and RET (this is the longest section), then register type templating (mmx/sse/avx), then instruction set templating (sse2/ssse3), then AVX emulation (3-operand instructions), then SWAP, then stack memory [19:23:02 CEST] <kierank> heh, it's almost like wikibooks [19:23:06 CEST] <kierank> than a blog post [19:23:29 CEST] <BBB> its intended to be thorough :-p [19:24:08 CEST] <BBB> the portion that explains cglobal is several pages of text :-o [19:24:20 CEST] <BBB> even though its just one stupid line of text (code) [19:25:34 CEST] <kierank> I wonder if we can add exercised and stuff [19:25:38 CEST] <kierank> so it becomes like a textbook [19:26:48 CEST] <BBB> :D [19:26:49 CEST] <BBB> brb [19:31:06 CEST] <tdjones> Does anybody have recommendations for modern x86 books/resources? I struggle to find any books that cover more than the bare minimum. [19:31:38 CEST] <J_Darnley> Not outside the Intel reference and Agner's timing tables, no. [19:33:01 CEST] <kierank> atomnuker: does av1 use x264asm? [19:33:51 CEST] <atomnuker> yes, though lately there's been a lot of intrinsics too [19:34:00 CEST] <kierank> eugh [19:34:24 CEST] <kierank> intrinsics is to asm as c++ is to c [19:34:33 CEST] <kierank> people think they are saving time but in fact they are making a mess [19:35:08 CEST] <atomnuker> the way av1 deals with simd is a mess [19:35:15 CEST] <atomnuker> no function pointers like we do [19:35:32 CEST] <kierank> we are the exception instead of the rule afaik [19:35:35 CEST] <atomnuker> instead global function pointer variables which you can't seem to chase [19:35:50 CEST] <atomnuker> also they don't template SIMD code [19:35:59 CEST] <kierank> from reverse engineering stuff people just seem to shove their simd whenever they want [19:36:04 CEST] <atomnuker> every file is for a different instruction set, e.g. sse, avx, avx2 [19:36:08 CEST] <kierank> eugh [19:36:11 CEST] <kierank> that is disgusting [19:36:37 CEST] <atomnuker> at least its not doing the x265 thing with a single huge file [19:37:28 CEST] <atomnuker> (they do that with intrinsics too) [19:37:59 CEST] <atomnuker> and then we get blamed for a bloated ffvp9 [20:06:01 CEST] <iive> atomnuker: i wonder if somebody have tried C++ templetes and intrinsics... [20:07:00 CEST] <BBB> atomnuker: ffvp9 isnt bloated [20:07:05 CEST] <BBB> atomnuker: libvpx is much, much bigger [20:07:16 CEST] <BBB> atomnuker: but libvpx got in chrome before limits were imposed, ffvp9 was proposed after [20:07:21 CEST] <BBB> so we got stuck in traffic, basically [20:07:27 CEST] <BBB> unfortunate, but thats life [20:07:30 CEST] <BBB> at least firefox uses ffvp9 [20:09:39 CEST] <TD-Linux> and it's wonderful [20:10:19 CEST] <BBB> :) [20:10:57 CEST] <TD-Linux> we're finally adding 10 bit planes so the high bitdepth path should get some exercise soon too [20:11:27 CEST] <JEEB> najs [20:13:03 CEST] <Gramner> BBB: floating point calling conventions are a huge mess, so the x86inc approach to that is basically "screw that, you're on your own. have fun" [20:13:25 CEST] <BBB> TD-Linux: oh thats super-cool [20:21:59 CEST] <atomnuker> Gramner: its not that bad, just an ifdef to get floats in a register, the unix64 way [20:22:24 CEST] <Gramner> on unix64 it's quite sane [20:22:45 CEST] <atomnuker> yes, someone was thinking [20:23:02 CEST] <atomnuker> "why would someone want to give float arguments and what would they use them for?" [20:23:14 CEST] <atomnuker> SCALING FACTORS! [20:23:40 CEST] <atomnuker> so its just a splat away from done [20:24:24 CEST] <atomnuker> somehow doing extra work just to put them in gprs would be wasteful [20:24:48 CEST] <Gramner> win64 is fun when you can only have 4 args in regs, and floats makes some int registers become unused etc [20:24:49 CEST] <atomnuker> come to think of it, it would be nice to do this for everything [20:25:10 CEST] <atomnuker> so mm regs would mirror gprs [20:26:10 CEST] <atomnuker> though modern CPUs already zero them out for free I think [20:29:43 CEST] <Gramner> it's just that making cglobal accept a mixture of int and fp and just make it do "the right thing" (tm) in all cases on all operating systems is non-trivial and would complicate the cglobal syntax as well (since you'd need to be able to specify a type for each arg) [20:31:40 CEST] <atomnuker> yep [20:32:27 CEST] <nevcairiel> manually handling the fp args for the couple functions you need it in is probably better then making x86inc be evil [20:32:34 CEST] <Gramner> indeed [20:32:41 CEST] <nevcairiel> to make it easier on yourself, just put them last in the arg list [20:55:32 CEST] <iive> while talking about asm arguments [20:56:11 CEST] <iive> if the function is 64 bit and is having int32 arguments, is it supposed to clear the high 32 bits? e.g. moszxifidn ? [20:58:51 CEST] <Gramner> if you need to use the 32-bit argument in a 64-bit operation, e.g. by adding it to a pointer, you need to zero out the upper 32-bit yourself since those bits are undefined by the ABI [21:00:29 CEST] <Gramner> note that any 32-bit operation will implicitly zero the upper 32-bits [21:01:09 CEST] <Gramner> or you can just change the type of that value to ptrdiff_ [21:01:26 CEST] <Gramner> ptrdiff_t* [21:13:43 CEST] <iive> thanks [21:16:20 CEST] <iive> they are counters so it is easy to use them in 32bit mode. [21:17:36 CEST] <Shiz> a/w 25 [21:39:49 CEST] <J_Darnley> :) I see users are starting to wear Moritz down on the user mailing list. [22:25:06 CEST] <BBB> J_Darnley: want to review now? [22:25:36 CEST] <atomnuker> the asm tutorial? [22:27:26 CEST] <durandal_1707> who needs that? [22:31:17 CEST] <BBB> atomnuker: yes [22:34:31 CEST] <atomnuker> post it somewhere [23:01:51 CEST] <BBB> atomnuker: https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-using-x86inc-as… [23:02:21 CEST] <TD-Linux> BBB, nice [23:02:38 CEST] <BBB> hope its useful [23:02:53 CEST] <BBB> Ill copy it to ffmpegs wiki at some point in the future [23:03:20 CEST] <ubitux> now link it in doc/optimization.txt [23:03:34 CEST] <ubitux> (or maintain a text version in that file) [23:04:29 CEST] <BBB> Ill link it :) [23:08:12 CEST] <Gramner> BBB: your "void" sad_16x16_c example is returning a value [23:10:45 CEST] <BBB> fixed [23:11:30 CEST] <Gramner> you could perhaps also mention zmm regs where you mention mm-ymm regs [23:12:36 CEST] <BBB> INIT_ZMM avx512? [23:12:43 CEST] <Gramner> yes [23:13:06 CEST] <atomnuker> BBB: "to xmm0and m1 might" <- lack of space [23:13:11 CEST] <Gramner> things are basically how you'd expect them to be [23:13:33 CEST] <atomnuker> I think this should be on trac as well [23:13:44 CEST] <BBB> fixed [23:13:56 CEST] <BBB> atomnuker: yes, Im intending to move it to the wiki (trac=wiki) [23:14:06 CEST] <Gramner> some behind-the-scenes register renaming is done behind in avx512 code but that might be overkill for a tutorial [23:14:22 CEST] <atomnuker> cool [23:14:49 CEST] <BBB> hopefully also useful for future gsoc students [23:15:57 CEST] <Gramner> something about auto vzeroupper maybe? [23:17:13 CEST] <BBB> oh right, good point [23:17:17 CEST] <BBB> in the RET section [23:17:53 CEST] <atomnuker> also a sentence or two on float argument differences across different platforms? [23:19:08 CEST] <BBB> Gramner: added [23:19:29 CEST] <BBB> atomnuker: right, so thats what Id need help with, because Im just not familiar enough with float to say anything useful about it :-/ [23:19:41 CEST] <BBB> atomnuker: I was thinking of adding that in the wiki version (i.e. telling you to add it :-p) [23:19:52 CEST] <atomnuker> yep, that'll be easier [23:25:26 CEST] <Gramner> qXXXX notation for imm8 shuffle indices is used but not explained [23:26:11 CEST] <atomnuker> (that notation rocks btw) [23:26:57 CEST] <Gramner> yeah, using anything else is so hard to mentally parse [23:28:16 CEST] <BBB> hm, yes, qNNNN [23:28:47 CEST] <Gramner> it's just base4, but base4 happens to be super useful [23:30:38 CEST] <BBB> "; qNNNN is a base4-notation for imm8 arguments [23:30:44 CEST] <BBB> (as documentation int he relevant code segment) [23:30:55 CEST] <iive> i thought it is nasm/yasm construct. [23:31:05 CEST] <iive> sadly, it is not. [23:31:28 CEST] <Gramner> it's way more useful than octal which they do have [23:31:42 CEST] <BBB> should put it on hackernews now :-p [23:32:17 CEST] <iive> aren't there some octal imm in ymm avx2 land? [23:33:11 CEST] <BBB> https://news.ycombinator.com/item?id=14773368 < go vote! :-p [23:35:57 CEST] <Gramner> "On win64, if this number is larger than 6, well be using callee-save xmm registers" unless it's an avx-512 function, in which case the number of volatile registers available is 22 (nit!) [23:36:07 CEST] <Gramner> one of the more useful features of avx-512 on win64, really [23:37:06 CEST] <Gramner> also that is not documented anywhere from microsofts side the last time I looked [23:37:14 CEST] <BBB> ugh :D [23:37:16 CEST] <Gramner> I had to get intel to ask their MS reps [23:37:25 CEST] <Gramner> to confirm calling convention stuff [23:37:38 CEST] <BBB> 6 xmm or 22 zmm caller-save? [23:37:53 CEST] <BBB> or, in other words, 10 callee-save [23:38:02 CEST] <Gramner> applies to any register (with avx-512VL) [23:38:09 CEST] <Gramner> you have xmm16-xmm31 too [23:38:17 CEST] <BBB> !!!!!!!!!!!!!!!!!!!!!!!1111111one [23:38:18 CEST] <Gramner> any register size* [23:38:24 CEST] <BBB> why did I not know that [23:38:25 CEST] <BtbN> I'm still sad Ryzen doesn't have avx-512 [23:38:25 CEST] <BBB> that is insane [23:38:30 CEST] <BBB> when can I use them? [23:38:35 CEST] <BtbN> but probably a bit much to ask, as it doesn't even have real avx2 [23:38:36 CEST] <BBB> I want 32 xmm registers!!!!!!!!!! [23:38:42 CEST] <nevcairiel> BtbN: ryzen doesnt even have real avx2, so yeah [23:38:47 CEST] <Gramner> on any 64-bit systemn. also vzeroupper is not needeed for regs 16-31 [23:38:49 CEST] <nevcairiel> also, snap =p [23:39:00 CEST] <Gramner> so what x86inc does it rename regs so that 16-31 are used first [23:39:13 CEST] <nevcairiel> BBB: just invest into a brand new cpu =p [23:39:19 CEST] <nevcairiel> (no macs) [23:39:32 CEST] <BBB> fixed [23:39:34 CEST] <Gramner> so vzeroupper is basically only used when you need more than 16 regs on avx512 x64 functions [23:39:35 CEST] <BtbN> The new Skylake-SP CPUs are all horrible sadly [23:39:51 CEST] <BtbN> not SP, X [23:40:03 CEST] <atomnuker> they are? [23:40:03 CEST] <BtbN> The Xeons are fine [23:40:09 CEST] <BtbN> They have a massive heat issue [23:40:17 CEST] <nevcairiel> the "horribleness" is largely overrated and overreported [23:40:21 CEST] <nevcairiel> mien runs perfectly fine [23:40:39 CEST] <Gramner> xeons have massive avx downclocking though [23:40:43 CEST] <BtbN> from what I heard, the package is unable to spread the long-term 100% load heat [23:40:52 CEST] <Gramner> up to like halving the clock frequency in some cases [23:40:57 CEST] <atomnuker> from what I've been reading if I had to get a CPU I'd get a ryzen [23:41:15 CEST] <BtbN> yes, Ryzen seems like the way more appealing consumer CPU [23:41:22 CEST] <BtbN> Than anything Intel has right now [23:41:54 CEST] <nevcairiel> I have a 7900X OCed to 4.5GHz and its fine, even in torture testing like Prime95. You do need a proper competent cooler, but shrug. Only in AVX512 I configuerd some downclocking because that does get terribly hot [23:42:17 CEST] <BtbN> It's funny how avx2 on ryzen isn't even that much slower, as it does not clock down at all [23:42:42 CEST] <nevcairiel> The reporting of those "overclocking is impossible due to heat" things is hilarios though, considering you ltierally cannot OC ryzen much at all since it just stops working [23:42:52 CEST] <TD-Linux> I was surprised to see cinebench tied between the new 16 core threadripper and 22 core broadwell-ep [23:42:59 CEST] <TD-Linux> then again I think that benchmark has no AVX2 [23:43:08 CEST] <nevcairiel> cinebench doesnt use avx, indeed [23:43:45 CEST] <Gramner> SKL-X mobos seem to favor ignoring TDP as much as possible over throttling. which does make sense though since you usually don't buy a HEDT system for perf/watt reason [23:44:07 CEST] <TD-Linux> at least they managed to do their avx2 "emulation" in the smart way that doesn't introduce extra latency [23:46:17 CEST] <Gramner> water cooling is sort of mandatory for SKL-X I think, air doesn't cut it [23:46:39 CEST] <nevcairiel> Probably. I have one of those AIO/CLC coolers [23:46:54 CEST] <nevcairiel> but threadripper wont be any different, it comes witha 180W TDP out of the box [23:47:10 CEST] <Gramner> AIO is fine for normal usage. for high-end OC you probably want a custom loop [23:47:19 CEST] <nevcairiel> granted, you likely wont be able to OC it, since like Ryzen it'll likely just not cross 4GHz anyway [23:47:50 CEST] <Gramner> threadripper is spread over a larger surface area due to it being 2 separate dies which might be easier to cool. it's also soldered [23:47:58 CEST] <Gramner> SKL-X uses TIM [23:48:27 CEST] <atomnuker> nevcairiel: what difference does OC make in say, h264 decoding speed? [23:50:53 CEST] <nevcairiel> clock speed scales pretty well (almost linear) with most workloads [23:51:43 CEST] <nevcairiel> so between 4 and 4.5ghz, you could probably assume close to 10% improvement as well [23:52:08 CEST] <nevcairiel> not sure how well h264dec scales with so many cores though, didnt really test that much [23:52:31 CEST] <jamrial> BBB: maybe mention why intrinsics carry a performance penalty [23:52:44 CEST] <BBB> hm& dunno [23:52:46 CEST] <jamrial> otherwise it reads like "it's bad because reasons, use this other thing instead" [23:52:55 CEST] <jamrial> you did mention what inline asm is bad [23:53:12 CEST] <BBB> if people want to use intrinsics, theyll use it [23:53:18 CEST] <BBB> see libvpx/aom [23:53:24 CEST] <jamrial> just say it depends on the compiler not being stupid [23:53:31 CEST] <nevcairiel> could still meantion the reasons why we dont like them [23:53:33 CEST] <nevcairiel> -a [23:53:43 CEST] <nevcairiel> even if it doesnt change peoples minds [23:54:32 CEST] <BBB> jamrial: ok [23:55:20 CEST] <BBB> done [23:56:23 CEST] <Gramner> xmN could need an explanation [23:57:07 CEST] <BBB> good point [23:57:11 CEST] <BBB> not sure where to introduce it though [23:57:22 CEST] <BBB> we may just add that later in the wiki version [23:58:48 CEST] <Gramner> several instances of "mm0, xmm0 or ymm0" should have zmm added [23:59:25 CEST] <iive> does x86asm support zmm ? [23:59:29 CEST] <Gramner> overall a good writeup [23:59:49 CEST] <Gramner> the version in x264 does, I don't think it got commited to ffmpeg yet [00:00:00 CEST] --- Sat Jul 15 2017

1 0

ffmpeg.log.20170714
by burek 15 Jul '17

15 Jul '17

[00:13:29 CEST] <c_14> realnc: try -f data ? [00:22:24 CEST] <realnc> @c_14 "ffmpeg -i tst.ogg -acodec copy -f data tst.vorbis" get me: Output file #0 does not contain any stream [00:22:33 CEST] <c_14> -map 0:a [00:23:20 CEST] <realnc> that worked! [00:23:24 CEST] <realnc> thank you :) [00:23:32 CEST] <c_14> I'm honestly not sure what it produces though [00:23:37 CEST] <c_14> might want to check that it's valid vorbis [00:23:49 CEST] <realnc> hm [00:30:07 CEST] <TD-Linux> indeed, you can basically consider that .vorbis file a ffmpeg-specific format [00:34:55 CEST] <realnc> will need to experiment with this. i'm writing some code using libvorbis to decode raw vorbis packets, and i wanted some quick way to get some example raw vorbis data to get started with. [00:35:47 CEST] <realnc> so, we'll see. in any event, thanks for the help! [02:00:57 CEST] <shodan45> Hi #ffmpeg [02:02:19 CEST] <shodan45> is there a replacement for ffserver yet? I'm just starting to learn ffmpeg & ffserver... then I see that ffserver is "dead" [02:03:48 CEST] <c_14> not really [02:03:53 CEST] <c_14> depends on what you want to do [02:04:18 CEST] <c_14> ffmpeg can output hls which a webserver can serve, you can feed nginx-rtmp for rtmp streams (which can also do hls) [02:04:34 CEST] <c_14> can also output webm and mp4 dash [02:05:03 CEST] <c_14> (which a webserver can again serve) [02:05:46 CEST] <c_14> rtp can work in certain circumstances [02:05:56 CEST] <c_14> only thing missing is something for rtsp I guess [02:11:14 CEST] <shodan45> my goal is to stream a laptop's webcam+mic with h264, using va-api for hw accel encoding, to an html 5 video player [02:11:32 CEST] <shodan45> https://www.virag.si/2012/11/streaming-live-webm-video-with-ffmpeg/ is pretty close to what I want [02:12:06 CEST] <shodan45> I guess I can continue to use ffserver since it's "here" [02:12:40 CEST] <shodan45> then again, if there's a security problem with it, I'm stuck, huh? [02:13:03 CEST] <c_14> Well, there's nobody really maintaining it so [02:15:45 CEST] <shodan45> it seems that you actually tell ffserver what codec, resolution, etc. to use, and that "magically" ffmpeg talks to ffserver...? [02:16:01 CEST] <c_14> yeah [02:16:04 CEST] <c_14> It's rather [02:16:06 CEST] <c_14> uh [02:16:08 CEST] <c_14> complex [02:16:49 CEST] <shodan45> yeah... but it does feel like quite a bit of effort went into making it as simple as possible [02:17:02 CEST] <shodan45> I thought it would be more complex [02:18:18 CEST] <c_14> Well [02:18:22 CEST] <c_14> You're assuming it's going to work [02:19:01 CEST] <shodan45> I was able to sorta get it working by following the instructions in that link [02:19:12 CEST] <shodan45> but my cpu usage was crazy [02:19:57 CEST] <shodan45> and there was a huge delay, and the stream kept stuttering [02:20:43 CEST] <c_14> codec? [02:20:51 CEST] <shodan45> I'm hoping that by using hardware encoding it'll be tolerable [02:21:07 CEST] <c_14> maybe [02:21:23 CEST] <shodan45> vpx and vorbis [02:21:39 CEST] <shodan45> VideoCodec libvpx and AudioCodec vorbis [02:22:05 CEST] <c_14> vpx is slow so [02:22:26 CEST] <shodan45> right, and no (or very few) hw support [02:23:21 CEST] <shodan45> I'd like to get a webcam that has h264 encoding built in, but I'm broke [03:14:55 CEST] <thebombzen> you mean I actually convinced this person not to mess with psy tuning [03:14:56 CEST] <thebombzen> wow [05:23:21 CEST] <fa0> Hello all [05:24:23 CEST] <fa0> I'm trying to change the metadate title in a video http://dpaste.com/1NZQ7PQ lines, 17,23,40 is all I want to change, removing the BlahBlahBlah and adding in something else... [05:24:49 CEST] <fa0> I've been trying a few things I read online, but not having any success... [05:26:19 CEST] <fa0> metadate/metadata title... [05:31:34 CEST] <beauty> hello [05:32:26 CEST] <beauty> how to know ts's bitrate? [12:38:19 CEST] <Fig1024> can ffmpeg work well with videos containing alpha channel? or is it too difficult to deal with [12:44:23 CEST] <durandal_1707> Fig1024: what is your issue? [12:45:34 CEST] <Fig1024> I need to use videos with alpha, ffmpeg fails to open files I have, I'm using DirectShow based solution. But if there was some ffmpeg friendly format, I could convert and drop DirectShow dependency [12:46:31 CEST] <durandal_1707> Fig1024: what ffmpeg -i says? [12:48:28 CEST] <durandal_1707> ffmpeg works fine with alpha, thats why im asking for more info [12:51:12 CEST] <Fig1024> Could not find codec parameters for stream 0 (Video: none (FRWT / 0x54575246), none, 800x600, 23970 kb/s): unknown codec [12:51:12 CEST] <Fig1024> Consider increasing the value for the 'analyzeduration' and 'probesize' options [12:51:12 CEST] <Fig1024> Input #0, avi, from 'D:\ProgramData\eStudio\DContent\Monitor Frame\monitor4.avi [12:52:24 CEST] <Fig1024> it's using custom DirectShow codec now. But I could convert if I knew what is the best format and try it out [12:53:23 CEST] <durandal_1707> Fig1024: that codec is not supported [12:53:41 CEST] <Fig1024> ok, so which codecs should be used for videos with alpha [12:54:02 CEST] <furq> is that lossless [12:54:16 CEST] <durandal_1707> try utvideo, magicyuv for lossless [12:54:27 CEST] <furq> ffv1 does alpha as well but there's no dshow codec [12:54:51 CEST] <furq> durandal_1707: is there a magicyuv decoder now [12:54:53 CEST] <Fig1024> what about flv [12:55:02 CEST] <furq> oh hey so there is [12:55:03 CEST] <furq> nice [12:55:18 CEST] <furq> flv isn't a codec [12:55:52 CEST] <Fig1024> designer can export flv files with alpha, what if I want to open them with ffmpeg [12:59:03 CEST] <durandal_1707> Fig1024: depends what codec is in [13:02:20 CEST] <Fig1024> is there such a thing as PNG video? a sequence of PNG frames in avi container? [13:03:44 CEST] <furq> no [13:04:24 CEST] <furq> if you want a lossless codec that does rgba in avi and works with windows shit, use ut video [13:09:51 CEST] <Fig1024> I don't need it to work with windows shit, I'm using ffmpeg for video decoding inside custom OpenGL application. I want to remove all existing dependencies on DirectShow [13:11:03 CEST] <Fig1024> anyway, I'll try those codecs you recommended [13:11:13 CEST] <furq> well if you need something that "designer" can export [13:11:41 CEST] <Fig1024> I can make a conversion app that will decode using DirectShow and encode using FFMPEG [13:11:51 CEST] <furq> ut video is probably a good choice anyway [13:12:03 CEST] <furq> it compresses fairly well and decodes very quickly [13:12:23 CEST] <furq> ffv1 will compress a lot better but be slower to encode and decode [13:12:54 CEST] <Fig1024> yea I need fast decoding [13:55:59 CEST] <Tatsh> trying to use my webcam [13:56:00 CEST] <Tatsh> just test [13:56:02 CEST] <Tatsh> ffplay -vcodec h264 -f v4l2 -i /dev/video1 [13:56:08 CEST] <Tatsh> [h264 @ 0x7fbdac011340] Error splitting the input into NAL units. [13:56:15 CEST] <Tatsh> [h264 @ 0x7fbdac011340] No start code is found. [13:56:27 CEST] <Tatsh> [video4linux2,v4l2 @ 0x203b540] Compressed: h264 : H.264 : 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240 640x360 800x448 800x600 864x480 960x720 1024x576 1280x720 1600x896 1920x1080 [14:00:15 CEST] <Tatsh> i think it has to do with power available on the USB bus [14:00:19 CEST] <Tatsh> i hate that about this camera :/ [14:43:55 CEST] <kiloreux_> Have the "veryfast" preset removed from ffmpeg 3.3.2 ? Whenever i try to use it, I get "File for preset 'veryfast' not found" . [14:56:05 CEST] <tdr> mine doesn't have it, but i may have just not build a part that would have included it [15:19:29 CEST] <furq> are you using -vpre or something [15:19:34 CEST] <furq> that was deprecated ages ago [15:47:15 CEST] <Asuran> can x264 be cpu limited and if reached produce errors while encoding? [15:54:28 CEST] <JEEB> not during encoding, if x264 cannot run fast enough it will just be your bottleneck. thus usually where you start getting errors is *before* [15:54:50 CEST] <JEEB> for example depending on how your application works either buffered data will be dropped (leading to decoding artifacts) [15:55:22 CEST] <JEEB> or things will be decoded, but thrown away before feeding to the encoder (leading to a period of no frames from the encoder) [15:55:47 CEST] <JEEB> x264 itself is very simple. frame in - frame out of the encoder [15:57:48 CEST] <Asuran> thank you [15:58:20 CEST] <shincodex> Well [15:58:32 CEST] <shincodex> libvlc_media_player_play is returning zero and errmsg is null what the hell can I do. [15:58:50 CEST] <shincodex> other than throw the filth layer on libav out [15:59:01 CEST] <BtbN> Ask the vlc people? [15:59:15 CEST] <shincodex> That was a given before I said anything [16:00:05 CEST] <shincodex> worst part is its 64 bit DllImport [16:00:09 CEST] <shincodex> and all the signatures look right. [16:03:13 CEST] <c7j8d9> Hello. I have a 4k hevc video that plays great on my tv and a bunch that don't play at all. all hevc in a mkv. Is there a tool to see the settings of the working file to encode the rest to match? [16:04:04 CEST] <Asuran> c7j8d9, its not related to youre question, but what settings you set at -x265-params for it? im asking because i cant find much help about it [16:05:10 CEST] <c7j8d9> I did not encode it [16:05:24 CEST] <c7j8d9> https://usercontent.irccloud-cdn.com/file/Lftgf4zK/Screen%20Shot%202017-07-… [16:05:47 CEST] <c7j8d9> Deadpool works on my vizio but BvS does not [16:10:08 CEST] <Asuran> c7j8d9, try ffmpeg -i <file> [16:10:25 CEST] <Mavrik> mediainfo usually gives a bit more info [16:10:38 CEST] <Asuran> Mavrik, i just googled it for him xD trying to help hehe [16:11:49 CEST] <furq> maybe dts vs ac3 audio [16:13:15 CEST] <c7j8d9> thanks...Mavrik is mediainfo from mediaarea.net? [16:13:36 CEST] <Mavrik> yp [16:13:40 CEST] <Mavrik> I usually grab it from homebrew [16:14:39 CEST] <devinheitmueller> Worth noting that mediainfo is available on various Linux distributions without having to build from source. On Ubuntu for example, just apt-get install mediainfo". [16:14:49 CEST] Action: devinheitmueller doesnt know what OS c7j8d9 is running though. [16:15:31 CEST] <c7j8d9> I'm an outsider here I think so I won't mention the window I look through [16:16:10 CEST] <devinheitmueller> c7j8d9: Never fear. We have no animosity towards Windows users. [16:16:24 CEST] <devinheitmueller> Well, perahps Im only speaking for myself. Many people here may not like Windows. [16:16:25 CEST] <c7j8d9> How did you guess? [16:16:50 CEST] <c7j8d9> You don't have to like my OS but I am not a bad person [16:17:13 CEST] <pgorley> c7j8d9: i respect your choice of os, even if it's the wrong choice :) [16:18:06 CEST] <furq> that screenshot is of mediainfo [16:18:11 CEST] <furq> presumably via mpc [16:18:23 CEST] <dl2s4> be modern and type "apt install foo" [16:18:27 CEST] <c7j8d9> yeah. the mediacodec from mpc [16:18:43 CEST] <furq> there's no difference between using that and using mediainfo itself [16:18:52 CEST] <furq> other than the invocation [16:19:19 CEST] <furq> but yeah you probably want to pastebin the full text [16:19:24 CEST] <c7j8d9> so how do I translate the info from deadpool to encode BvS and other movies? [16:20:09 CEST] <furq> the video streams look the same to me [16:20:59 CEST] <c7j8d9> so maybe just my tv doesn't play video that it can't play the audio for? [16:21:14 CEST] <furq> that's pretty norma [16:21:15 CEST] <furq> l [16:21:49 CEST] <furq> pastebin the full mediainfo output [16:21:56 CEST] <c7j8d9> well at least that's less time consuming to try out first...thanks [16:26:39 CEST] <c7j8d9> furq: https://pastebin.com/cyctj4W0 [16:33:10 CEST] <furq> is that the full mediainfo output for the second file [16:33:13 CEST] <furq> those stream sizes don't add up [16:34:21 CEST] <c7j8d9> yes [16:35:11 CEST] <c7j8d9> I really just want to figure out why deadpool works but it doesn't seem to give much info [16:37:05 CEST] <c7j8d9> the audio looks the same on both [17:02:10 CEST] <relaxed> c7j8d9: the second video is Main@L5.1@Main, maybe your tv can't decode that profile [17:04:25 CEST] <relaxed> encode some small hevc samples with different profiles to see what your tv can/can't play [17:05:02 CEST] <c7j8d9> thanks relaxed. [17:07:34 CEST] <relaxed> https://trac.ffmpeg.org/wiki/Encode/H.265 [17:10:39 CEST] <c7j8d9> here's the info from ffmpeg -i https://pastebin.com/Fqi6WbrA [17:13:11 CEST] <relaxed> it might be level 5.1 that's causing it, try lowering it [17:18:47 CEST] <furq> i'd have thought they'd both be main(a)5.1 if they're both 4k [17:19:20 CEST] <relaxed> you may be right, the only other difference is frame rate [17:19:22 CEST] <furq> Stream #0:2(eng): Audio: truehd, 48000 Hz, 7.1, s32 (24 bit) [17:19:43 CEST] <furq> i knew that mediainfo didn't add up [17:20:07 CEST] <relaxed> hmm, I thought they were both AC-3 [17:20:14 CEST] <furq> c7j8d9: ffmpeg -i foo.mkv -c copy -map 0:0 -map 0:3 bar.mkv [17:22:12 CEST] <c7j8d9> foo being the working video? [17:22:42 CEST] <furq> the broken video [17:23:23 CEST] <c7j8d9> and bar being a new file or the working file? [17:23:52 CEST] <kepstin> c7j8d9: this command is to remove all but one of the audio tracks from the broken file, hopeuflly leaving one that your tv supports [17:24:02 CEST] <kepstin> c7j8d9: to from the broken file to a new file. [17:24:10 CEST] <kepstin> so from* [17:24:18 CEST] <c7j8d9> got it [17:24:20 CEST] <c7j8d9> thanks [17:25:14 CEST] <furq> i assume you want the english audio track and not the italian one [17:25:24 CEST] <c7j8d9> yes [17:31:17 CEST] <c7j8d9> so presumably my tv is not capable of choosing the right audio and it won't play because of the true hd? [17:31:43 CEST] <furq> a lot of devices will just bail out at the first sign of an unknown codec [17:32:03 CEST] <furq> even if there are playable ones of the same type [17:32:17 CEST] <furq> that's the most likely problem anyway [17:33:04 CEST] <c7j8d9> great news. at least i can try that faster than reencoding a 4k file [17:33:48 CEST] <furq> by all accounts the film isn't good enough for that kind of effort [17:34:41 CEST] <c7j8d9> i would beg to differ but that's probably a discussion for another channel [17:36:50 CEST] <c7j8d9> it does look like all my other 4k movies have multiple audios that include true hd and ac-3 [17:37:04 CEST] <c7j8d9> thanks for your help furq and kepstin [17:37:21 CEST] <c7j8d9> and relaxed [19:13:58 CEST] <xen> hi everyone. i'm trying to encode h264 videos to hevc with hevc_nvenc. is it possible to achieve the same visual quality on a GTX 1070 (or on any GPU in general) as with CPU encoding? if so. what parameters do i need to juggle if my only constraint is that the output file size cannot be greater than the source's [19:18:54 CEST] <kepstin> xen: the nvenc hardware encoders are good as far as hardware encoders, but they're not gonna be able to match a cpu encoder at close to the same bitrate. [19:19:11 CEST] <kepstin> (assuming you're running a cpu encoder with fairly slow settings) [19:19:27 CEST] <xen> yes i do. almost 6 hours to encode one vid on veryslow [19:19:50 CEST] <xen> on GPU, it's around 10 minutes, but the quality is ... meh [19:20:12 CEST] <kepstin> only reason to use a hardware encoder, imo, if you're busy using the cpu for something else and need to encode video at the same time. [19:20:24 CEST] <kepstin> or if the cpu is otherwise horribly underpowered. [19:20:35 CEST] <xen> gen4 corei5, so the latter applies [19:21:03 CEST] <kepstin> haswell desktop i5 is probably fairly reasonable as far as it goes. [19:21:08 CEST] <DHE> xen: that's the tradeoff unfortunately. hardware encoders are technically inferior, but are offloaded from the CPU and very fast. [19:21:57 CEST] <xen> :\ [19:22:07 CEST] <xen> i see, thank you [19:22:22 CEST] <xen> it's time to look for some powerfull servers then [19:22:32 CEST] <xen> -l [19:25:45 CEST] <DHE> you want realtime encoding of hevc? [19:26:39 CEST] <xen> no, i just want to get the job done faster than on CPU, so i could do other things with my workstation. also, i aim for the same quality of output [19:27:25 CEST] <furq> you should be able to get the same quality [19:27:28 CEST] <furq> just not at the same bitrate [19:27:56 CEST] <xen> bitrate does not matter if the output will be as large as the source [19:28:25 CEST] <furq> what's the source [19:28:39 CEST] <xen> or maybe it does a little [ i'm not much of a video guy ] [19:28:55 CEST] <xen> one sec [19:29:11 CEST] <xen> title : Hi10 1080p h.264 [19:29:17 CEST] <xen> BPS : 4192605 [19:29:35 CEST] <xen> if that's the right line [19:30:31 CEST] <furq> you probably won't be able to beat competently-encoded x264 with nvenc [19:30:38 CEST] <xen> the root my problem is that i need to play these videos on consumer devices which only encode up to hevc main10. h264 high10 is not implemented, so i can not force them to play [19:30:47 CEST] <furq> oh [19:31:06 CEST] <xen> *decode*, sorr [19:31:10 CEST] <xen> long day :\ [19:31:10 CEST] <furq> right [19:39:28 CEST] <kepstin> xen: bitrate * length = filesize, so the only way to keep the same filesize while increasing bitrate would be to cut the video length :) [19:39:54 CEST] <xen> did not think that trough... :D [19:40:25 CEST] <xen> say.. if i double the bitrate than, i will get the same quality with double the file size? [19:40:48 CEST] <kepstin> xen: hard to say without knowing more about how your source video was encoded. [19:41:00 CEST] <kepstin> you'll just have to "try and see", really :/ [19:41:44 CEST] <furq> you could also use a faster x265 preset [19:42:16 CEST] <xen> wouldn't that decrease quality? [19:42:36 CEST] <furq> it depends what crf you use [19:44:07 CEST] <kepstin> it'll either decrease quality or increase file size relative to a slower preset, depending on other settings. [19:44:31 CEST] <xen> too many variables [19:44:43 CEST] <xen> took me hours to get my bearings on the basic parameters [19:45:21 CEST] <xen> i'll try to experiment then [19:45:22 CEST] <xen> thank you [19:45:56 CEST] <kepstin> assuming you're using -crf on either x264 or x265, switching to a faster preset should result in similar (not identical) quality while increasing file size. [19:46:00 CEST] <kepstin> in general [19:47:10 CEST] <xen> you mean with hevc_nvenc ? [19:47:32 CEST] <Asuran> x265 [19:47:43 CEST] <xen> ah, ok [19:59:46 CEST] <xen> is it possible, that with crf=0, there are no visible quality loss? [19:59:57 CEST] <xen> i've made a test run, output size is about half [20:25:47 CEST] <Asuran> xen, i read crf 0 is somewhat lossless but i doubt its true lossless [20:26:39 CEST] <JEEB> depends on teh encoder and bit depth [20:26:48 CEST] <JEEB> x264 and 8bit per plane is lossless at crf=0 [20:27:16 CEST] <JEEB> x264 and >8bit per plane is not lossless (you should use qp=0) [20:27:20 CEST] <JEEB> x265... NFI [20:27:47 CEST] <JEEB> and of course it is lossless compared to what you are feeding the *encoder* [20:28:16 CEST] <JEEB> so if you have RGB input, and you convert that to YCbCr 4:2:0 before feeding it to the encoder, that is of course not the same as the RGB. [20:28:46 CEST] <JEEB> (x264 at least does support GBRP input so you *can* do lossless RGB with it if you really want to) [20:37:54 CEST] <xen> i c [20:38:43 CEST] <xen> well, i can not see any differences right now by eyeballing it, so for starters, this will be good [20:40:31 CEST] <xen> these videos do not have much detail though, also, are 1920x1080 in resolution and my future target is 4k [20:43:26 CEST] <Asuran> xen and what commands you used for encoding? [20:44:11 CEST] <xen> i've deleted every finetuning i had before: -c:v hevc_nvenc -pix_fmt yuv420p -profile:v main10 -preset slow -x265-params crf=0 -c:a copy [20:44:38 CEST] <JEEB> hevc_nvenc will not do anything with x265-params [20:44:48 CEST] <JEEB> x265-params is a specific thing for... libx265 [20:45:08 CEST] <JEEB> preset... I'm not sure, you have to find out if that encoder even has that [20:45:43 CEST] <xen> oh my [20:46:13 CEST] <JEEB> so it's higly likely that neither of those does anything :P [20:46:17 CEST] <xen> preset might exist, ffmpeg did list it for me [20:46:19 CEST] <xen> oh wow [20:46:39 CEST] <JEEB> there was a way to output the options for a specific encoder [20:46:45 CEST] <JEEB> but I can't remember it out of my head [20:46:50 CEST] <JEEB> because I usually just look at the source code [20:46:58 CEST] <xen> i would kill for a well written wiki page about it [20:47:23 CEST] <Asuran> people dont seem to share their knowledge [20:47:46 CEST] <xen> i could not aggree more [20:47:53 CEST] <JEEB> generally for general options https://www.ffmpeg.org/ffmpeg-all.html should list everything that's actually documented within the source code [20:47:55 CEST] <xen> days of googling did not get me anywhere [20:48:02 CEST] <Asuran> i can help you wait a second [20:48:30 CEST] <JEEB> ok, seems like it's `-h encoder=hevc_nvenc` [20:48:37 CEST] <JEEB> if you want help about that encoder specifically [20:48:46 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#Generic-options [20:48:58 CEST] <JEEB> (searched with ctrl+F for `-h`) [20:49:43 CEST] <xen> this is where the slow preset came from [20:50:15 CEST] <Asuran> https://github.com/HandBrake/HandBrake/issues/634 [20:50:37 CEST] <Asuran> more i couldn't find [20:50:42 CEST] <JEEB> "preset" is generally listed under different encoders [20:51:04 CEST] <JEEB> I mean, after preset files which are something completely different to using something available in the external libraries [20:52:27 CEST] <xen> this github thread seems interesting [20:53:15 CEST] <xen> thank you guys, i'll switch to RTFM mode [21:35:21 CEST] <shincodex> there is no fucking manual for ffmpeg [21:35:25 CEST] <shincodex> "its the code" [21:35:28 CEST] <shincodex> and the "suffering" [21:35:30 CEST] <shincodex> HEHEHEHE [21:36:28 CEST] <JEEB> and you get to keep both pieces [21:37:10 CEST] <kepstin> half the time, i'm answering questions in here with the help of 'git grep', yeah :/ [21:37:21 CEST] <shincodex> thankfully [21:37:41 CEST] <shincodex> you have git grep [21:41:05 CEST] <Blubberbub> I'm trying to get the filtering_audio.c-Example working, but the resulting sound is mostly gibberish. I did a cmp of the output to the output generated by ffmpeg and it has some extra bytes, which makes the s16le-data unaligned. Has anyone experienced that problem or can confirm it? [21:41:33 CEST] <pgorley> hi, is AVCodecContext->gop_size used when encoding VP8? [21:41:52 CEST] Action: kepstin opens up his git grep [21:42:24 CEST] <kepstin> pgorley: yes [21:42:33 CEST] <pgorley> kepstin: thanks [21:42:39 CEST] <kepstin> that's the same as the -g option in ffmpeg cli, yeah [21:45:23 CEST] <pgorley> debugging a problem in my app, the video freezes after a while, but only for vp8, and i'm pretty new to vp8 [21:53:01 CEST] <meekohi> Hey kind of stumped... when I `./configure --enable-gpl --enable-libx264 --enable-avresample --enable-libvpx` it shows png as one of the encoders, but after build I do `./ffmpeg -encoders` and it doesn't show up? [21:53:12 CEST] <meekohi> I've got libpng and libpng-devel, seems like it should be included... [21:53:34 CEST] <JEEB> the avcodec png encoder is its own thing, doesn't use libpng [21:53:39 CEST] <meekohi> (and when I try to use it in practice I get "Unknown encoder 'png'" [21:53:53 CEST] <iive> all external encoders have "lib"- prefix [21:54:02 CEST] <iive> codecs actually. [21:54:20 CEST] <meekohi> Ah fair enough so libpng isn't a factor. Still seems like png encoder should be included? [21:54:41 CEST] <c_14> meekohi: do you have zlib installed? [21:54:45 CEST] <c_14> or zlib-devel [21:55:01 CEST] <JEEB> although if configure script lists the 'png' encoder then you should have it :P [21:55:10 CEST] <meekohi> Yup (Package zlib-1.2.8-7.18.amzn1.x86_64 already installed and latest version) [21:55:15 CEST] <JEEB> (--enable-zlib is a good way to make sure it's there in FFmpeg) [21:55:29 CEST] <JEEB> (as in, the png encoder, as it depends on zlib) [21:55:38 CEST] <kepstin> yeah, if it shows in the configure output when building ffmpeg but not when you run ffmpeg, then you're not running the ffmpeg that you just built. [21:56:13 CEST] <c_14> or your build environment is somehow corrupted [21:56:21 CEST] <meekohi> Hmm seems pretty straight forward I'm running it right out of the build directory... [21:56:26 CEST] <meekohi> Any ideas on env things I could double check? [21:56:49 CEST] <c_14> ldd ffmpeg and check for libz.so ? [21:56:55 CEST] <c_14> (if it's linked dynamically anyway) [21:56:59 CEST] <meekohi> (will also retry with --enable-zlib but takes a while to build) [21:58:43 CEST] <iive> also, make sure you do run the ffmpeg you bult, not a system installed one. [21:58:53 CEST] <iive> or older installation [21:59:40 CEST] <meekohi> Hrm don't see zlib in `lld ffmpeg`. Rebuilding now will quadruple check I'm looking at the right one [22:00:19 CEST] <JEEB> `which ffmpeg` is generally useful to known which ffmpeg binary you're calling :P [22:01:00 CEST] <meekohi> I'm doing `./ffmpeg` to be sure (in fairness the system should be the same since I built it with same config) [22:04:33 CEST] <meekohi> ugh fuck me... "make: *** No rule to make target `libavcodec/x86/simple_idct.c', needed by `libavcodec/x86/simple_idct.o'. Stop." [22:05:04 CEST] <iive> make distclean [22:05:11 CEST] <meekohi> yup [22:05:23 CEST] <iive> the file has been removed, but the dependency has stayed [22:05:36 CEST] <iive> you might do rm *.d in there too. [22:05:49 CEST] <iive> i mean, instead. [22:06:17 CEST] <meekohi> I'll just wipe and get a new repo [22:07:06 CEST] <iive> distclean is more than enough. [22:07:27 CEST] Action: meekohi trusts no one. [22:10:35 CEST] <arpu> Application provided duration: -292 / timestamp: 77322 is out of range for mov/mp4 format [22:10:42 CEST] <arpu> any idea how i can fix this? [22:11:04 CEST] <arpu> input stream is from rtmp server [22:13:14 CEST] <arpu> kepstin, ? for one line? [22:13:38 CEST] <kepstin> well, the "complete console output" will be more than one line... [22:14:28 CEST] <kepstin> and will include things about codecs, etc. that assist in diagnosing issues. [22:15:18 CEST] <arpu> ok [22:17:52 CEST] <meekohi> (random -- is there a flag to skip compiling all the docs? takes forever...) [22:18:29 CEST] <meekohi> and, fresh build fixed the problem... sigh... should have tried that first. Thanks all! [23:41:00 CEST] <Asuran> JEEB, does ffmpeg really default use libsoxr? [23:41:10 CEST] <JEEB> what [23:41:28 CEST] <Asuran> libsoxr, the resampler [23:41:40 CEST] <JEEB> never built with that library, the resamplers in FFmpeg itself use swresample, which is a part of FFmpeg [23:41:42 CEST] <Asuran> from doc i knew there a native and that if enabled [23:41:53 CEST] <Asuran> how is the quality of it? [23:42:17 CEST] <JEEB> good enough, and there's specific options for those who want extra precision [23:42:23 CEST] <furq> you can use the sox resampler if you build with libsoxr [23:42:27 CEST] <furq> but the native resampler is fine [23:42:47 CEST] <furq> and sox isn't the default either way, you need to explicitly enable it [23:49:20 CEST] <Asuran> okay thanks i will try [23:49:57 CEST] <furq> just use swresample, it's fine [23:53:06 CEST] <Asuran> thats too easy [23:58:52 CEST] <Asuran> -af aresample=resampler=soxr:cheby=1:precision 28 -ar 48000 <- is it ok to set ar because i use opus and it should do it automatic? [23:59:57 CEST] <furq> don't resample at all if you're using opus, let libopus do it for you [00:00:00 CEST] --- Sat Jul 15 2017

1 0

ffmpeg-devel.log.20170713
by burek 14 Jul '17

14 Jul '17

[01:21:44 CEST] <kierank> J_Darnley: atomnuker: I would guess it's best doing the interpolation on stack [01:21:48 CEST] <kierank> or in a scratch buffer [01:23:10 CEST] <J_Darnley> Yay! Just what it needs. More buffers and pointers to buffers. [01:24:36 CEST] <kierank> J_Darnley: i'm not sure if there's a better way [01:24:44 CEST] <kierank> we can have this discussion now if you want [01:25:05 CEST] <J_Darnley> Nah. Tomorrow. [01:25:46 CEST] <kierank> J_Darnley: do you know if the extrapolation (not interpolation technically) stuff is in the spec? [01:26:02 CEST] <J_Darnley> I don't recall seeing it [01:26:31 CEST] <J_Darnley> But wasn't the low latency thing added later as some sort of extension? [01:26:46 CEST] <kierank> that's orthogonal I think to the issue [01:27:07 CEST] <kierank> i believe dirac has always had the property that you could do a transform on the entire plane or per slice and you'd get the same result [01:27:15 CEST] <kierank> as a result of the extrapolation parameters they chose [01:27:24 CEST] <kierank> but maybe a discussion for #dirac [03:05:34 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07master:a82468514048: avcodec/ivi: Use av_image_check_size2() [05:34:00 CEST] <atomnuker> durandal_1707: seems like enabling the cached bitstream reader in flac.h segfaults [05:34:43 CEST] <atomnuker> made 2 tests, utvideo went from 43x realtime to 53x realtime, vorbis went from 483x to 487x [05:35:20 CEST] <atomnuker> gonna test on an arm now [05:51:40 CEST] <atomnuker> *now == after I wake up because it takes that long to do a fresh compile [11:50:33 CEST] <wm4> jkqxz: do you have a git repo with your drm hwcontext changes? [13:22:47 CEST] <durandal_1707> can somebody push dolby e? [13:58:05 CEST] <wm4> did something with h264 hwaccel regress recently? if I enable threads, sw_pix_fmt is set to -1 [13:58:11 CEST] <wm4> in get_format [14:05:41 CEST] <cone-814> ffmpeg 03Ricardo Constantino 07master:0bf857a13fd5: configure: use pkg-config for libgme, if available [14:28:05 CEST] <RiCON> wm4: thanks [14:34:50 CEST] <cone-814> ffmpeg 03Kieran O'Leary 07master:264f6c6f9537: movenc: Add 'keywords' metadata [14:56:03 CEST] <jdarnley> Gah! Where is this rubbish data coming from? [14:56:36 CEST] <jdarnley> I think it obviously comes from an overread because the slice extends byond the edge of the frame [14:57:00 CEST] <jdarnley> But why isn't it in the picture from master? [15:42:38 CEST] <jdarnley> WTF is this this? Why is this encoding odd sized slices? [15:49:21 CEST] <jdarnley> That can't be right. You can't put 33 lines into a 32 pixel tall slice. [16:36:29 CEST] <jdarnley> I'm sure you people will love this... [16:36:32 CEST] <jdarnley> "Slice subbands can change dimension by 1 from one slice to another" [16:37:26 CEST] <jdarnley> WTF am I supposed to do then? Fudge my slices because they are supposed to change size? [16:40:56 CEST] <kierank> shouldn't matter afaik [16:41:56 CEST] <jdarnley> But if am supposed to output the same data I need to code "random" slice sizes [16:42:20 CEST] <jdarnley> rather than uniform [16:42:30 CEST] <kierank> the same data as what? [16:42:38 CEST] <jdarnley> What it does now [16:42:49 CEST] <kierank> why do you say that [16:42:54 CEST] <kierank> at the moment it uses fixed slice sizes [16:43:11 CEST] <jdarnley> NO IT DOES NOT! THEY CLEARLY CHANGE SIZES! [16:43:11 CEST] <kierank> and after it uses fixed slice sizes with edge extension [16:43:21 CEST] <kierank> jdarnley: then it's a bug [16:43:37 CEST] <kierank> atomnuker: are you aware of this? [16:44:13 CEST] <kierank> jdarnley: so with "nice" slice sizes like 32x8 it changes slice size? [16:44:31 CEST] <kierank> slice dimension to be more precise [16:44:36 CEST] <jdarnley> If you try to encode a not mod-8 height yes [16:44:37 CEST] <nevcairiel> poor jdarnley, driven to insanity after a few days of vc2 [16:44:48 CEST] <jdarnley> Or a not mod-32 width [16:44:59 CEST] <jdarnley> A few days? [16:45:04 CEST] <jdarnley> This nearly 2 weeks in [16:45:44 CEST] <jdarnley> Or a week? I forgot when I started [16:48:57 CEST] <kierank> jdarnley: well yeah, don't encode weird heights [16:49:31 CEST] <kierank> use 1920x1080, those numbers are niceish [16:49:54 CEST] <jdarnley> 720p is a weird height? [16:50:05 CEST] <kierank> 720p ain't mod 32 [16:50:09 CEST] <kierank> 1280 isn't i mean [16:50:32 CEST] <jdarnley> I know you want to use 32x8 does that mean I should ignore obvious corruption with 32x32? [16:51:01 CEST] Action: jdarnley goes to print widths too [16:52:18 CEST] <kierank> no please fix 32x32 [17:54:26 CEST] <atomnuker> jdarnley: that's completely normal too [17:55:05 CEST] <atomnuker> the amount of coefficients varies depending on which slice is being encoded/decoded [17:55:55 CEST] <jdarnley> This format sucks! [17:56:21 CEST] <jdarnley> How can that be posible? How can they call that a slice? [18:00:56 CEST] <jdarnley> Fudging it is then! [18:01:09 CEST] <JEEB> :D [18:06:18 CEST] <atomnuker> jdarnley: just copy the code from the decoder to determine how many coefficients to encode [18:07:04 CEST] <atomnuker> and ask for more than the slice size amount of pixels to encode [18:07:19 CEST] <jdarnley> The encoder in master probably gets it right but I will check [18:08:03 CEST] <atomnuker> it does get it right, it'll encode crazy dimensions and pixel formats [18:08:22 CEST] <atomnuker> yes, it even supports full range and ycocg [18:08:28 CEST] <jdarnley> Yeah, so I just need to fudge my slices like it does [18:08:49 CEST] <atomnuker> its not a fudge [19:20:09 CEST] <wm4> ok so not only did master regress with hwaccel + threads>1, also videotoolbox never worked properly with threads>1... [19:27:32 CEST] <wm4> I suspect it's because AVHWAccel.end_frame for videotoolbox mutates the AVFrame (the reference and data pointer, not just the "contents") [19:27:58 CEST] <wm4> and then those changes don't get propagated to some other worker threads which might need them [19:28:11 CEST] <wm4> but I'm not really sure if that makes sense at all [19:34:32 CEST] <wm4> wait that doesn't even make sense, first because it doesn't make sense, and second because you never pass surfaces to videotoolbox (it manages them on its own) [19:35:48 CEST] <wm4> another possibility would be that ffmpeg tries to output an allocated but uninitialized frame (but it decodes fine with software decoding) [19:39:58 CEST] <jdarnley> I hate specs. I hate whitepapers. They all speak about decoders as if streams appear out of thin air with the wave of a wand. [19:40:23 CEST] <wm4> can't you just buy expensive reference stream samples? [19:41:07 CEST] Action: jdarnley shrugs [19:44:00 CEST] <durandal_1707> kierank: buy it, you sleep on moneys [19:44:11 CEST] <kierank> buy what [19:44:15 CEST] <kierank> i can't buy imaginary files [20:19:35 CEST] <atomnuker> jdarnley: that's why encoders exist [20:20:11 CEST] <BBB> :D [20:20:22 CEST] <jdarnley> Yeah. That's the magic wand. You wave them about and streams come out. [20:20:38 CEST] <jdarnley> Nobody knows how they work. [20:21:01 CEST] <jdarnley> Voldemort killed 1 of the 2 people who knew and the other retired. [20:21:30 CEST] <atomnuker> be thankful encoders are not specified [20:21:37 CEST] <atomnuker> be very thankful they're not [20:22:47 CEST] <jdarnley> Yeah. We'll just create them like wands. Make thousands and try them out one at a time until we find one that works. [20:25:18 CEST] <tdjones> Is there a widely preferred benchmarking tool when submitting perfomance-related changes to the ML, or is anything that is accurate acceptable? [20:25:49 CEST] <jdarnley> If the code is supposed to run a for fixed duration everytime: timer.h [20:26:05 CEST] <ubitux> what are you trying to bench? [20:26:49 CEST] <ubitux> if it's ASM SIMD, you can use the START/STOP_TIMER from timer.h as suggested by jdarnley, or you could use checkasm --benchmark if you have checkasm FATE tests for your functions [20:27:19 CEST] <ubitux> otherwise... you have ffmpeg -benchmark(_all) [20:27:25 CEST] <tdjones> These are C changes in the vorbis encoder, not asm. [20:27:45 CEST] <ubitux> try ffmpeg -benchmark -i ... -f null - [20:28:17 CEST] <ubitux> -benchmark_all is more helpful i suppose [20:28:37 CEST] <jdarnley> In that case I would suggest run time recording (like -benchmark or /usr/bin/time) and an average. [20:29:25 CEST] <tdjones> I've been running under callgrind and just referencing instruction references, but I'll do that. Thanks! [20:30:03 CEST] <atomnuker> better use perf [20:30:25 CEST] <atomnuker> if you need function level overhead measurements, otherwise -benchmark [20:42:41 CEST] <BBB> <jdarnley> Voldemort killed 1 of the 2 people who knew and the other retired. <<< ??? :D [20:43:46 CEST] <BBB> Im pretty sure theres more than 2 people in the world knowing how to write encoders? [20:54:16 CEST] <cone-884> ffmpeg 03Rostislav Pehlivanov 07master:035c755b4ef3: opusenc: use float_dsp for transient mdcts [21:04:51 CEST] <iive> you can benchmark C functions with START/STOP_TIMER, not just asm [21:12:02 CEST] <atomnuker> durandal_1707: on an rpi 1 for utvideo: before - 60.860s, after - 71.420s [21:12:37 CEST] <atomnuker> I think changing the cache size wouldn't result in a performance regression [21:13:06 CEST] <durandal_1707> atomnuker: so that means one need to enable this only on x64 [21:13:38 CEST] <atomnuker> yes, so just put it under the have_fast_64 bit define rather than its own [21:13:50 CEST] <durandal_1707> BBB: i just wrote one it was easy peasy [21:13:51 CEST] <atomnuker> I failed to measure a regression on 64 bit systems with it [21:26:11 CEST] <iive> durandal_1707: you might get better speed if you do aligned read on arm. [22:03:50 CEST] <alphabitcity> Is there a creation timestamp stored on RTP packets? If so, is it possible to access that timestamp from filter_frame (e.g. on the AVFrame obj)? Thanks! [22:10:38 CEST] <alphabitcity> Or, put another way, is it possible to get a frame's capture time in a custom filter? [22:13:24 CEST] <jamrial> durandal_1707: can you look at the vf_limiter patch? [22:14:07 CEST] <durandal_1707> jamrial: i dont have x86, do you have? [22:14:18 CEST] <jamrial> yes [22:14:42 CEST] <durandal_1707> so just push it if it works [22:15:18 CEST] <jamrial> give me a command line example to test it, since there's no fate test [22:15:33 CEST] <jamrial> using testsrc or whatever [22:24:04 CEST] <durandal_1707> -vf limiter=50:110 [23:32:48 CEST] <cone-884> ffmpeg 03James Almer 07master:823cc7e25f97: checkasm: add a g722dsp test [23:32:49 CEST] <cone-884> ffmpeg 03James Almer 07master:6f205a42d76a: checkasm: add hybrid_analysis_ileave and hybrid_synthesis_deint tests to aacpsdsp [23:32:50 CEST] <cone-884> ffmpeg 03James Almer 07master:5688fd77b57f: x86/vf_limiter: make limiter functions work on x86_32 [00:00:00 CEST] --- Fri Jul 14 2017

1 0

ffmpeg.log.20170713
by burek 14 Jul '17

14 Jul '17

[00:01:07 CEST] <BtbN> I don't think it's possible [00:01:17 CEST] <alphabitcity> Is there a "crop if bigger otherwise scale" filter? I want to use ffmpeg to resize videos to 1280x720, but if the video is larger, I want it to crop and use the center, and if it's smaller, stretch it [00:01:53 CEST] <kepstin> alphabitcity: you can build it yourself by using scale & crop filters with math expressions rather than static values [00:03:18 CEST] <kepstin> BtbN: hmm, I guess you're right. I dunno how flexible the frame reordering is in h264. [00:03:39 CEST] <BtbN> I don't think B frames can exist with _only_ forward references [00:03:54 CEST] <alphabitcity> kepstin: thanks! i'm failing at googling this .. can you point me in the right direction? what should i search for to learn more about math expressions w/ filters? [00:04:01 CEST] <BtbN> Your usual gop is something like IPB...BP [00:04:14 CEST] <nicolas17> Threads: B means bidirectional, there's only one direction if it's the first frame... what would the reference frames be? [00:04:34 CEST] <BtbN> the I frame after it, but like you set, it needs forward and backward references [00:04:38 CEST] <BtbN> *said [00:05:17 CEST] <kepstin> right, a typical gop is often like IBBPBBPBBP or something in pts order, which is saved as IPBBPBBPBB in dts order (so the forward reference is available before the B frame is decoded) [00:05:29 CEST] <nicolas17> if B frames were that flexible, maybe you could reverse a video without reencoding :P [00:07:30 CEST] <kepstin> alphabitcity: read the docs for the scale filter https://www.ffmpeg.org/ffmpeg-filters.html#scale-1 and crop filter (same page), they list the parameters that take expressions and the available variables you can use. Some examples there too. [00:07:51 CEST] <kepstin> alphabitcity: full expression syntax info is at https://www.ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation [00:07:58 CEST] <alphabitcity> kepstin: tyvm [00:09:04 CEST] <jkqxz> The forward/backwardness in referencing is entirely specified by the stream. You can make references to any frames you like, they don't need to have any particular POC order. [00:09:32 CEST] <nicolas17> jkqxz: can a P frame only reference a 'previous' frame? [00:09:35 CEST] <nicolas17> and if so how is 'previous' defined? [00:09:45 CEST] <jkqxz> And the frames needn't even be unique. You can send an I frame and then a B frame with lower POC which refers to the I frame for all references. [00:09:56 CEST] <jkqxz> No, a P frame can reference any other frames it likes. [00:10:01 CEST] <jkqxz> (One or more.) [00:10:04 CEST] <kepstin> alphabitcity: the basic construction i'd recommend is have a scale filter first which resizes larger if the video is small, then a crop that takes the center bit (and implicitly does nothing on a video already the right size) [00:10:16 CEST] <nicolas17> jkqxz: with that flexibility, what's the difference between P and B? [00:10:46 CEST] <kepstin> nicolas17: number of other frames that can be referenced, I guess? P is max 1, B is more. [00:11:04 CEST] <nicolas17> ah, jkqxz said "one or more" and confused me :) [00:11:09 CEST] <jkqxz> B frames can use bidirection prediction, with two input frames for a given macroblock (selecting any two frames from the available references). P frames can only use one frame for the reference for a single macroblock, but it can again be any of the available frames. [00:11:14 CEST] <alphabitcity> kepstin: that sounds right, ty. the semi-tricky part there is implementing the conditional logic for scale .. but doesn't seem to bad. thanks again [00:11:28 CEST] <nicolas17> oh it's per MB [00:12:01 CEST] <kepstin> and h264 of course lets you mix different types of macroblocks in the same frame, too [00:12:09 CEST] <jkqxz> Yes. The B vs. P only influences the set of prediction modes you are allowed to pick, and how the reference picture lists work by default. The second of those can be completely overridden replacing the lists with anything you like. [00:13:20 CEST] <nicolas17> so in theory could you reverse a video without fully decoding and reencoding? if you have an I and a P based on it, make it PI where the P depends on the I in the future :P [00:13:21 CEST] <jkqxz> So a P frame can reference up to 16 frames which were previously encoded (but may be in the future in presentation order), but only one in each macroblock. [00:13:47 CEST] <jkqxz> A B frame can do the same thing, but has additional modes to reference any two of the 16 frames. [00:14:45 CEST] <jkqxz> Yes, except the amount of reordering is limited. You can't make 100 frames each referring to the following one in presentation order, because that would need to buffer 100 frames which isn't allowed by the level limits. [00:15:00 CEST] <nicolas17> oh sure, it would turn into a pretty horrible output file [00:15:21 CEST] <kepstin> so in theory it could be done, if the video is closed gop and the gop size is 16 frames or less, I guess? [00:15:36 CEST] <jkqxz> If your GOP is short enough, then yes you can reverse a video like that. [00:16:32 CEST] <jkqxz> Limit is probably more than 16 if you have unreferenced frames, but it deepends on your GOP structure. For IPPPP... only, then yes. [00:17:29 CEST] <nicolas17> reversing a video even with full reencoding is more annoying than it should be [00:17:41 CEST] <jkqxz> Though note that your first frame must be an I frame, not an IDR frame (since you're not allowed to define frames which follow an IDR frame in encode order but get presented before it). [00:18:41 CEST] <nicolas17> it could be done one GOP at a time (from the last one), but I haven't seen tools that can do that, all guides I saw decode the entire video into images on disk and then encode it back [00:20:22 CEST] <kepstin> reversing a video like that doesn't really fit into how ffmpeg is built, either; it could be done in ffmpeg.c i guess, or some pseudo-format [00:20:34 CEST] <nicolas17> yeah it would need a separate tool [01:37:50 CEST] <_Vi> How do I refer to another video's width and height in "scale" filter? [01:38:12 CEST] <_Vi> I want two input video to be scaled to the same size. [02:42:11 CEST] <c_14> _Vi: You write a script [02:42:31 CEST] <_Vi> c_14, So no inline way? [02:42:38 CEST] <c_14> nope [02:42:43 CEST] <_Vi> OK. [02:44:01 CEST] <kazuma_> use media info to script it _vi [02:44:38 CEST] <c_14> ffprobe might be easier, that can output json/csv etc [02:45:16 CEST] <_Vi> Actually already hardcoded fixed width and height, so no need anymore. [03:49:23 CEST] <kerio> does ffvhuff fit in flv [03:49:28 CEST] <kerio> for the purpose of rtmp [04:39:39 CEST] <kepstin> _Vi: if you're running both videos through ffmpeg, look at the 'scale2ref' filter [05:41:00 CEST] <kerio> how do i rtmp a gray16 video D: [05:47:06 CEST] <furq> you don't [05:57:59 CEST] <kerio> furq pls gibe lossless gray16 on rtmp [06:22:50 CEST] <thebombzen> Alright, I just enabled my Skylake's GPU in the bios. With FFmpeg do I have to do something fancy to use it as an hwaccel (like -vf hwupload) cause I'm not sure how to use it [06:32:45 CEST] <atomnuker> -hwaccel vaapi -vaapi_device /dev/dri/renderD128 before input to decode [06:33:36 CEST] <thebombzen> atomnuker: does it matter that I have /dev/dri/renderD128 and /dev/dri/renderD129? [06:33:45 CEST] <atomnuker> probably not [06:34:00 CEST] <thebombzen> do I need -codec:v h264_vaapi or similar? [06:34:25 CEST] <atomnuker> no [06:34:34 CEST] <atomnuker> to decode anyway [06:34:38 CEST] <thebombzen> I've discovered in my experiences that using -hwaccel cuvid does not use cuvid decoding, but using -codec:v h264_cuvid before -i does [06:35:02 CEST] <atomnuker> cuvid sucks and its not a hwaccel, vaapi os [06:35:11 CEST] <atomnuker> *is [06:35:40 CEST] <atomnuker> h264_vaapi is only needed to encode, and that's when you need -vf hwupload [06:36:57 CEST] <thebombzen> atomnuker: do I also need -vaapi_device? [06:37:33 CEST] <atomnuker> only if you use wayland I think [06:37:54 CEST] <thebombzen> also, cuvid is printed out by ffmpeg -hwaccels, so what do you mean when you say it's not an hwaccel [06:40:47 CEST] <atomnuker> fucked if I know, it requires nonfree nvidia cancer [06:43:59 CEST] <thebombzen> atomnuker: I'm decoding at about 150 fps with my Skylake's gpu and about 400 with my Skylake cpu using ffh264's software decoder [06:44:03 CEST] <thebombzen> is this expected? [06:44:19 CEST] <thebombzen> this is 1920x1080 H.264 video with a very high bitrate [06:51:38 CEST] <furq> i would have expected that [06:53:27 CEST] <atomnuker> yep, that's normal [06:54:23 CEST] <thebombzen> is vaapi's hwdec useless for Skylakes without QSV? [06:54:33 CEST] <thebombzen> should I just expect to use ffh264 + vaapi's encoder without QSV? [06:55:22 CEST] <thebombzen> interestingly, I tried it again on a 10-bit HEVC file with a lower bitrate (17M as opposed to like 100M) and they decoded about the same [06:55:41 CEST] <thebombzen> not sure if it's because ffmpeg fellback to ffhevc or if the lower bitrate made all the difference on my Skylage GPU [06:59:37 CEST] <thebombzen> Hm, I'm trying vaapi hardware encoding, and I'm getting a weird error: [06:59:40 CEST] <thebombzen> [h264_vaapi @ 0x5559980db960] Failed to end picture encode issue: 6 (invalid VASurfaceID). [06:59:44 CEST] <thebombzen> http://sprunge.us/RRbH [07:00:56 CEST] <thebombzen> I'm not sure what I'm doing wrong here :P [07:02:15 CEST] <thebombzen> setting the bitrate to something sane (-b:v 2000k), setting -qp, and using a real muxer rather than -f null, none of these did anything [07:12:23 CEST] <atomnuker> you still need -hwaccel vaapi [07:15:31 CEST] <ffpure> guys, does anyone know why colorkey filter is not working for me? I'm trying to do this: [07:15:33 CEST] <ffpure> ffmpeg -i green_rabbit.jpg -vf colorkey=0x2fc145:0.4:0.2 -y green_rabbit_fixed.jpg [07:15:51 CEST] <ffpure> but it won't remove the green areas [07:16:20 CEST] <ffpure> this is the image: https://il6.picdn.net/shutterstock/videos/3548021/thumb/1.jpg [07:17:06 CEST] <ffpure> if i do an overlay, it works [07:18:04 CEST] <thebombzen> ffpure: most likely it's an alpha channel thing. try writing it to a PNG and see what happens [07:18:44 CEST] <ffpure> yeah, i thought so too. same thing... [07:19:21 CEST] <ffpure> do we have a filter to make the jpg an alpha channel BEFORE the colorkey filter? [07:23:56 CEST] <thebombzen> ffpure: try using -vf format=yuva444p,colorkey=blah [07:25:36 CEST] <ffpure> no change. same with ffplay: [07:25:38 CEST] <ffpure> ffplay green_rabbit.jpg -vf "format=yuva444p,colorkey=0x2fc145:0.4:0.2" [07:29:15 CEST] <durandal_1707> ffpure: you need overlay [07:30:26 CEST] <ffpure> but i don't have two videos. I just want the green colors to become transparent, so that i can put the output file as an overlay later [07:31:44 CEST] <durandal_1707> ffplay doesnt display transparent colors [07:32:32 CEST] <ffpure> yeah but at least it should show black... [07:32:46 CEST] <ffpure> right now it does not change green pixels at all [07:33:42 CEST] <furq> that command works for me [07:34:45 CEST] <ffpure> furq: which one? [07:34:52 CEST] <furq> ffmpeg -i 1.jpg -vf colorkey=0x2fc145:0.4:0.2 1.png [07:34:56 CEST] <furq> http://i.imgur.com/LwKSsfF.png [07:35:23 CEST] <ffpure> wow! [07:36:11 CEST] <thebombzen> furq: imagine that [07:37:35 CEST] <ffpure> furq: you are right, but now try to play it: ffplay 1.png [07:37:50 CEST] <furq> 06:31:44 (@durandal_1707) ffplay doesnt display transparent colors [07:38:13 CEST] <furq> you shouldn't base any knowledge off what ffplay does [07:38:31 CEST] <furq> it's intentionally very basic [07:38:35 CEST] <ffpure> but how does it know those colors were green? haha [07:38:53 CEST] <ffpure> 1.png has them transparent [07:38:56 CEST] <furq> colorkey probably isn't changing the colours of those pixels [07:38:59 CEST] <furq> it's just setting the alpha channel [07:39:08 CEST] <ffpure> hmmm i see... [07:39:26 CEST] <furq> it should still work fine with overlay [07:40:07 CEST] <ffpure> ok that's good for me because i'm not using ffplay... I just didn't check them with another app... [07:40:11 CEST] <ffpure> thanks guys! [07:55:41 CEST] <thebombzen> furq: you stealing my advice kudos? :) [09:11:04 CEST] <kerio> hm, is nginx my best bet for a rtmp server nowadays? [09:13:31 CEST] <furq> yes [09:18:14 CEST] <kerio> but i dont wanna :> [09:18:15 CEST] <kerio> :< [09:18:39 CEST] <kerio> is ffserver actually that bad [09:24:10 CEST] <_Vi> kepstin, Thanks. Expected that this mode is just some special parameter of scale, like "scale=in[b]_w" or "b_w" or "in_b_w", not a separate filter. [09:34:41 CEST] <thebombzen> kerio: ffserver is deprecated [09:34:47 CEST] <thebombzen> so yea, you should use nginx [09:39:41 CEST] <furq> kerio: ffserver is an unusable piece of shit [09:39:51 CEST] <furq> and it has been for years [10:34:44 CEST] <kerio> ayy it takes like 20 hours to build ffmpeg on pi0 [10:37:10 CEST] <furq> of course it does [10:37:13 CEST] <furq> what did you expect [10:37:24 CEST] <furq> this is why god gave us cross compilers [10:46:30 CEST] <kerio> fuck it i'll gstreamer [10:57:49 CEST] <furq> "six weeks to get a doctor's appointment to get my ear syringed? fuck it, i'll just cut my leg off" [10:57:58 CEST] <furq> that's you. that is an impersonation of you [10:59:13 CEST] <kerio> ye i gave up on gstreamer [11:01:09 CEST] <furq> cross compiling is easy and fun [11:01:26 CEST] <kerio> ayyy [11:39:00 CEST] <thebombzen> durandal_1707: do you read DOA? or is that a different durandal who commented on the DOA thread? [11:50:41 CEST] <durandal_1707> thebombzen: what is doa? [12:31:49 CEST] <thebombzen> durandal_1707: Dumbing of Age. http://0x0.st/GO0.png [12:33:31 CEST] <durandal_1707> thebombzen: he stole my identity, i will report that to higher authorities [12:36:27 CEST] <furq> lol [12:36:32 CEST] <furq> i always knew durandal_1707 was a big doctor who fan [12:38:19 CEST] <thebombzen> what does the 1707 even mean? I assume this is durandal from Marathon but where does 1707 come from [12:38:52 CEST] <furq> http://durandaljs.com/get-started.html [12:39:58 CEST] <thebombzen> ah, I see [12:39:59 CEST] <thebombzen> https://vignette2.wikia.nocookie.net/marathongame/images/c/c7/Durandal_Logo… [13:36:25 CEST] <Asuran> hi, im using: ffmpeg -i %1 -c:v libx265 -preset:v slow -crf 19 -x265-params rd=6:psy-rd=0.01:psy-rdoq=0.41 -c:a libopus -b:a 96k -vbr on -packet_loss 0 -compression_level 10 -application audio "%~n1".mkv - my question is: how can i better achieve to disable psycho visual options? -tune psnr didnt really worked, just file blown up [14:18:11 CEST] <Fig1024> what are psycho visual options? [14:34:55 CEST] <thebombzen> Fig1024: human-vision-specific visual optimizations [14:35:41 CEST] <thebombzen> human eyes don't see everything objectively. We see minor differences in lightness better than differences in color. We see differences in lightness better in very dim areas than very bright areas [14:36:54 CEST] <Fig1024> and there are options to tune that behavior? [14:36:58 CEST] <thebombzen> Asuran: x265's psy tunings are messed up [14:37:02 CEST] <thebombzen> the AQ is bad [14:37:30 CEST] <Asuran> i try to achieve original result [14:37:33 CEST] <Asuran> nothing more [14:37:33 CEST] <thebombzen> Asuran: consider using x264 if you want to disable psy optimizations [14:37:39 CEST] <Asuran> so i dont want it better then it was [14:37:45 CEST] <thebombzen> also, you probably don't want to disable psy optmizations [14:37:46 CEST] <Fig1024> what about VP9 [14:38:03 CEST] <thebombzen> Asuran: unless you know why you want to turn them off, you probably don't want to turn them off. [14:38:07 CEST] <thebombzen> What are you actually trying to do. [14:38:07 CEST] <Asuran> well i tried vp9 too but idk cant find documention about psy rd options and such there [14:38:17 CEST] <Asuran> reencode stuff [14:38:23 CEST] <thebombzen> Be more specific [14:38:31 CEST] <Asuran> h264 and other to h265 [14:38:33 CEST] <thebombzen> What do you want to accomplish? Why do you need to re-encode? [14:38:38 CEST] <Asuran> and achievbe 95% similarity [14:38:48 CEST] <thebombzen> Why do you need H.265? What is 95% similarity? [14:38:54 CEST] <thebombzen> Why can't you use the existing H.264 stream? [14:39:00 CEST] <Asuran> 95% quality of the original [14:39:18 CEST] <Asuran> h265 does more savings on space [14:39:23 CEST] <Asuran> so i can set crf higher [14:39:26 CEST] <Asuran> and get better result [14:39:35 CEST] <thebombzen> Higher CRF is lower quality. [14:39:42 CEST] <thebombzen> What are you actually trying to accomplish? Because "I need an H.265 stream that is 95% quality of the original" is not a goal. [14:39:58 CEST] <thebombzen> You're trying to do something - but why do you need H.265? [14:40:19 CEST] <Asuran> i mean higher in terms of quality [14:40:32 CEST] <thebombzen> Higher CRF produces lower quality videos. [14:41:58 CEST] <Fig1024> I guess he wants to reduce file size while keeping almost same quality [14:42:35 CEST] <thebombzen> Asuran: because if you're just trying to re-encode the video at a lower bitrate, you don't want to disable psy tuning. [14:43:22 CEST] <thebombzen> What videos are you trying to recompress? What's the current bitrate? What do you want to get it to? [14:43:49 CEST] <Fig1024> you should contact Pied Piper, I heard they have excellent compression algorithm [14:44:52 CEST] <thebombzen> Fig1024: completely unrelated. [14:53:29 CEST] <Asuran> idc the bitrate tbh i use crf [14:53:54 CEST] <Asuran> Fig1024, do you got vp9 expierence? [14:55:33 CEST] <thebombzen> Asuran: what videos are you trying to recompress? What are the dimensions? What is the bitrate? [14:55:39 CEST] <Fig1024> not practical, but on user level, it seems like you can achieve better compression with higher quality if encoding time isn't an issue [14:56:21 CEST] <thebombzen> Asuran: I ask because HEVC and VP9 are not worth it for smaller videos [14:57:13 CEST] <Asuran> thebombzen, is there even an alternative for them? [14:57:26 CEST] <thebombzen> Yes. Like H.264, for example. [14:57:50 CEST] <Asuran> well but as i said hecv is more effiecent then h264 so i can set due that alone crf higher [14:57:51 CEST] <thebombzen> HEVC's advantage over H.264 primarily occurs at larger resolutions. At smaller resolutions it's generally not worth it to use HEVC. [14:58:17 CEST] <thebombzen> Same with VP9 over VP8. They're worth it for 4k content and the like but for small videos it's not worth it. [14:58:29 CEST] <thebombzen> Which is why I'm asking you, how big are the videos you're trying to recompress, and what is their bitrate? [14:58:44 CEST] <Asuran> different [14:58:58 CEST] <thebombzen> Approximately is good enough [14:58:59 CEST] <Asuran> my only problem is understand psy-rd and rdoq [14:59:03 CEST] <thebombzen> Asuran: don't touch that. [14:59:05 CEST] <Asuran> how they actually work out together [14:59:16 CEST] <Asuran> but i touched it and it seemed to helped a lot [14:59:27 CEST] <thebombzen> Don't touch those settings unless you know what they do and why. The defaults are fairly sensible. [14:59:37 CEST] <colde> Yeah, i dont think that is your only problem, right now your problem is not cooperating with people who are helping you [14:59:41 CEST] <thebombzen> If you changed them and it "helped" it's because you got lucky. [14:59:46 CEST] <Asuran> the defaults make it blurry except you maybe use source (raw video) [15:00:16 CEST] <thebombzen> Asuran: you don't know that those are making it blurry. You could have just set the quality too low, for all I know. [15:00:35 CEST] <Asuran> crf 19 [15:00:45 CEST] <Asuran> and yea thats why i want to disable them [15:00:54 CEST] <Asuran> to preserve the original as much as possible [15:01:12 CEST] <thebombzen> I'm telling you, don't change them unless you know why you want to. [15:01:13 CEST] <Asuran> or reduce them as much as it is good for picture quality [15:01:27 CEST] <thebombzen> I'm also telling you, turning off psy tuning does not help picture quality. [15:01:45 CEST] <Asuran> but it does already, it looks less blurry [15:01:47 CEST] <Asuran> more sharp [15:01:51 CEST] <Asuran> more than the original [15:01:54 CEST] <Fig1024> Youtube uses VP9 even for small videos [15:02:04 CEST] <thebombzen> Fig1024: that's because it batch processes them. [15:02:10 CEST] <Asuran> they use vp9? i thought they use h264 only [15:02:22 CEST] <thebombzen> Fig1024: they dont' have a human decide what's there and what's not. Easier and simpler to have uniform settings for them. [15:02:50 CEST] <thebombzen> Asuran: and I'm asking you again, what are the dimenions of the videos are you trying to re-encode, and what is their bitrate? [15:03:00 CEST] <Asuran> different on each video [15:03:07 CEST] <thebombzen> Approximately [15:03:13 CEST] <Asuran> from full hd to sd [15:03:28 CEST] <thebombzen> What is Full HD. Is that 1080p or 720p? [15:03:37 CEST] <Asuran> 1080p [15:03:53 CEST] <Asuran> 720p is hd ready if i dont get the brandings on televisions in past wrong [15:04:06 CEST] <thebombzen> it's just marketing [15:04:11 CEST] <Asuran> i know [15:04:21 CEST] <thebombzen> for the 1080p videos what bitrates do they have typically? [15:04:34 CEST] <thebombzen> Also, to answer your earlier question, try this: [15:04:35 CEST] <Fig1024> most TV people still use 1080i. I hate dealing with interlaced video [15:05:00 CEST] <Asuran> Fig1024, is interlaced even useful? isnt it just good for fps 30 and less? [15:05:34 CEST] <thebombzen> Asuran: try this: ffmpeg -i input.mkv -c:v libx264 -preset:v veryslow -crf:v 18 -c:a libopus -b:a 96k output.mkv [15:05:37 CEST] <Fig1024> it was made due to old bandwidth limitations. There's no reason to keep using it, but so many people have old hardware [15:05:46 CEST] <Asuran> i did, didnt helped much [15:05:53 CEST] <thebombzen> Well then you're SOL [15:06:06 CEST] <thebombzen> And did you try veryslow? or did you try slow? [15:06:09 CEST] <thebombzen> Veryslow is much better. [15:06:13 CEST] <Asuran> it was jsut bit better cuz veryslow changes psy-rd or such a bit too [15:06:17 CEST] <Asuran> i use slow [15:06:20 CEST] <thebombzen> Veryslow does not change psy-rd [15:06:34 CEST] <thebombzen> and notice, I typed libx264. Not libx265 [15:06:34 CEST] <Asuran> it changes something, idk, its maybe rd [15:06:40 CEST] <thebombzen> did you try libx264? [15:06:45 CEST] <Asuran> nope [15:07:02 CEST] <Asuran> is libx265 still that behind? [15:07:29 CEST] <thebombzen> so when you said "I did try that" you lied [15:07:34 CEST] <thebombzen> Don't dot hat [15:07:37 CEST] <thebombzen> Just don't [15:07:44 CEST] <Asuran> i didnt lied, i assumed its h265 [15:07:50 CEST] <thebombzen> I literally typed libx264 [15:08:32 CEST] <Asuran> i just focused on the value that matters, and they were indentical, like the ones i posted, so i assumed they not much change [15:08:38 CEST] <Asuran> so no, i didnt lied [15:08:46 CEST] <thebombzen> So you didn't read, okay [15:08:47 CEST] <Asuran> i just didnt read it with full care [15:08:56 CEST] <thebombzen> try this: ffmpeg -i input.mkv -c:v libx264 -preset:v veryslow -crf:v 18 -c:a libopus -b:a 96k output.mkv [15:08:56 CEST] <Asuran> cuz i thought its almost same [15:09:13 CEST] <Asuran> and i assumed this due i posted my batchline before this conversation [15:09:25 CEST] <Asuran> and the 96k opus part looked identical like the rest [15:09:40 CEST] <thebombzen> well, keep in mind, I already said that HEVC is not worth it for you. [15:09:51 CEST] <thebombzen> x265 is not mature enough to bother with HEVC. [15:09:58 CEST] <Asuran> okay [15:10:11 CEST] <thebombzen> because the advantage of HEVC over H.264 is primarily at higher resolutions (>1080p) [15:10:17 CEST] <thebombzen> (like 1440p+) [15:10:38 CEST] <Asuran> vp9 is bad documented, or i couldnt find the right one on their homepage, i would give it a try but i need to adjust that psycho visual optimizations [15:10:48 CEST] <thebombzen> NO, you don't [15:11:01 CEST] <thebombzen> You shouldn't change those settings unless you don't know why you want to change them. [15:11:12 CEST] <thebombzen> unless you know* why you want to change them [15:11:23 CEST] <thebombzen> Have you tried the command I suggested yet [15:12:16 CEST] <Asuran> no, if i use h264 i dont even need to reencode them [15:12:21 CEST] <Asuran> no use, then i can let them be [15:13:10 CEST] <Asuran> i will try it myself out i will try and fail learn the psy-rd stuff [15:13:28 CEST] <Asuran> psy-rd 2.0 and psy-rdoq 15.0 seem to be almost what i want [15:13:58 CEST] <Asuran> i wish i would understand why they behave like this in this range but well i figure it maybe out [15:14:05 CEST] <thebombzen> Asuran: Not necessarily, because x264 could re-encode them with a lower bitrate than they were encoded before. [15:14:14 CEST] <Asuran> but without gurantee im right about it [15:14:19 CEST] <Asuran> (the interpration i mean) [15:14:41 CEST] <thebombzen> x264 is a very efficient encoder, so it's worth a try to re-encode H.264 to H.264 if you're encoding it with x264 [15:15:08 CEST] <thebombzen> Often times you can re-encode it at a much smaller size with minimal quality loss if you re-encode it with libx264 [15:15:10 CEST] <Asuran> hmm [15:15:30 CEST] <Asuran> so the point is libx265 is inmature [15:15:41 CEST] <Asuran> and even h264 would give better result with lesser file [15:15:43 CEST] <Asuran> ? [15:16:04 CEST] <Fig1024> why not just test it for yourself [15:16:16 CEST] <Asuran> i believe him Fig1024 no need [15:16:24 CEST] <thebombzen> Yes, there is a need. [15:16:28 CEST] <thebombzen> You should try the command I suggested. [15:16:45 CEST] <Asuran> thebombzen, if you didnt lied to me, i already know due what you said [15:17:02 CEST] <Asuran> so i should stick h264 or give vp9 a try is my conclusion [15:17:12 CEST] <thebombzen> First of all, I said, "it's worth a try" because"often times" it works [15:17:27 CEST] <thebombzen> I didn't say it was guaranteed to improve anything in your case [15:17:39 CEST] <Asuran> ye i understand why [15:17:43 CEST] <Asuran> it same codec [15:17:44 CEST] <thebombzen> I said that it's worth trying [15:18:00 CEST] <Asuran> i cant expect 50% file saving, except if the first encode was high bitrate [15:18:09 CEST] <Asuran> and they just avoided with it much encoding time [15:18:29 CEST] <thebombzen> You can't expect 50% with H.264 -> HEVC either unless you're allowing yourself to kill the quality. [15:18:41 CEST] <thebombzen> Even the people who are marketing HEVC don't claim that it's that good. [15:37:30 CEST] <CounterPillow> I've heard this is the channel for masochists [15:38:01 CEST] <flux> thebombzen, hmm, the 50% is an often repeated number, though :) [15:38:49 CEST] <thebombzen> flux: at UHD and up, yea [15:38:58 CEST] <thebombzen> not relevant here [15:39:19 CEST] <thebombzen> nobody is saying it's that much better for dvd-quality movies [15:39:31 CEST] <flux> thebombzen, cool, that's nice to know [15:39:40 CEST] <thebombzen> in practice it's not really 50% [15:39:52 CEST] <thebombzen> but the 50% number that's marketed is for very large frames [15:40:11 CEST] <thebombzen> x264 is still very competitive at smaller sizes and slower presets [15:42:28 CEST] <JEEB> the %-wise HEVC claims are theoretical based on various tests with the reference encoder. and yes, most likely there's a difference between the such theoretical capabilities between resolutions. that said, we're dealing with actual implementations [15:42:35 CEST] <JEEB> like, actual production implementations [15:42:55 CEST] <JEEB> and fighting against x264 is hard :P [15:43:05 CEST] <JEEB> since x264 had a lot of love put into it during its life time [15:43:21 CEST] <JEEB> while x265 for example is a single-company effort with almost zero outside contributions [15:51:38 CEST] <thebombzen> #x264savesfansubbing [16:37:33 CEST] <iive> JEEB: I think BBB also had a chart or presentation that supported the 50% claim. [16:37:58 CEST] <JEEB> the claims themselves are not incorrect, the reality is just different due to actual real encoders [16:38:41 CEST] <flux> is the 50% theoretical gain comparison to the h264 practical or theoretical encoders? [16:38:53 CEST] <JEEB> it's the theoretical capability of a similar encoder to a similar encoder ("similar" as in usually "reference encoder") under specific similar parameters [16:39:03 CEST] <JEEB> flux: the encoder does actually exist but is the reference one usually [16:39:11 CEST] <JEEB> so JM for AVC and HM for HEVC for example [16:39:23 CEST] <iive> the presentation I speak about was empirical. it compared a number of encodes, including vp9 [16:40:22 CEST] <JEEB> anyways, whatever the specific graph actually meant, I will not do guesswork. I do know what the ISO/IEC numbers more or less based on [16:41:09 CEST] <JEEB> just like the case of "libvpx is not /that/ much slower! (if you're only doing single threaded encoding)", things can be true under specific circuimstances [16:41:45 CEST] <iive> but I do agree that x264 is perfectly polished encoder, and no h265 comes close to it. [16:43:27 CEST] <dino82> Hey all o/ Trying to get ffmpeg to run in windows server core 2016. Noticing there are problems with running it at all, reference: https://emby.media/community/index.php?/topic/46254-windows-server-2016-cor… [16:43:50 CEST] <kerio> does the image2 muxer overwrite the old image atomically, in update mode? [16:44:13 CEST] <dino82> I get zero output from running ffmpeg.exe [16:47:03 CEST] <c_14> kerio: if you add -atomic_writing [16:50:03 CEST] <iive> dino82: if you don't get any imput, then there might be something even before ffmpeg itself starts. check the admin logs and try running ffmpeg in compatibility mode. [16:50:31 CEST] <kerio> c_14: ty [16:50:35 CEST] <iive> dino82: i haven't used windows for a very long time... so i'm not sure what tool you can check for missing libraries. [16:51:32 CEST] <iive> also, antivirus might block execution and etc... [16:53:04 CEST] <dino82> It's a barebones server install, no AV or windows defender [16:55:38 CEST] <dino82> In the security logs I see a "A new process has been created..." log every time I run it. Nothing else appears. I'd much rather run this in linux :[ [16:56:30 CEST] <c_14> can you tell if the process is crashing? [16:56:38 CEST] <c_14> does windows have some sort of strace replacement? [16:56:59 CEST] <iive> sysinternals do a good job of tracing processes [16:57:30 CEST] <iive> microsoft aquired them long ago and they are now available from ms site [16:57:43 CEST] <dino82> I am limited to what I can do in Powershell, this is a headless box with no GUI [16:58:12 CEST] <dino82> I'll check to see if there's a stack tracer built-in [16:58:17 CEST] <iive> windows can run on such a thing?! [16:58:40 CEST] <dino82> yeah Windows server core is like the 'alpine linux' of Windows [16:59:07 CEST] <iive> no, i mean, windows running withoug GUI [16:59:39 CEST] <dino82> Oh, yeah. It's all powershell/cmd.exe [17:00:12 CEST] <dino82> In fact I'm running it inside of a docker container for portability [17:00:38 CEST] <iive> hum? containers can now run windows? [17:01:08 CEST] <dino82> yep, Windows-only containers, so you can't run ubuntu on a container unless you involve some virtualbox trickery [17:17:40 CEST] <Dovid> hi. I am using ffmpeg to watch a stream using m3u8 where it seems sending the files in chunks of a few seconds). I have found on my simple box that when ever it goes to get a new chunk the CPU jumps from 2% to 20-20% for a moment then comes down. I assume this is when it's grabbing the last chunk. What is the reason for the CPU spike and is there any way to get around it? [17:19:23 CEST] <kepstin> Dovid: ffmpeg isn't really a player, how are you using it to watch a stream? [17:20:19 CEST] <kepstin> if you're using ffmpeg to transcode, spiky cpu behaviour like that is probably expected, since it'll grab a chunk, encode that as fast as possible, then grab the next chunk. [17:48:18 CEST] <DHE> kepstin: almost. unless it's changed recently, I find ffmpeg just streams data over HTTP as it goes and forces TCP and the HTTP server to buffer [17:48:34 CEST] <DHE> rather than downloading a whole file as quickly as possible and running it from RAM [17:49:07 CEST] <kepstin> DHE: but with segmented media, it has to do separate http requests per segment; does this temporarily block it or slow it down? [17:49:39 CEST] <DHE> kepstin: the HTTP setup might slow it down, but unless SSL handshaking was involved I wouldn't expect a CPU usage spike [17:49:53 CEST] <DHE> even then client-side SSL is pretty light on CPU [17:50:31 CEST] <DHE> HLS treats it mostly like a tcp stream source with HTTP headers involved periodically [17:50:34 CEST] <kepstin> well, we have no idea what Dovid is actually doing, so speculating it... :/ [17:50:40 CEST] <DHE> true [17:51:17 CEST] <Dovid> kepstien: The url is https. I am using it on a phone system to play an audio stream [17:51:54 CEST] <kepstin> https on a phone with a non-reused ssl connection could cause cpu spikes for rsa :/ [17:51:58 CEST] <Dovid> kepstien:I have logging enabled. the spikes happen exactly when it goes o get the next chunk [17:52:30 CEST] <alphabitcity> Hi, I'm trying to use ffmpeg to change input video size to 720p. If the input is smaller, I want it to scale, and if it's larger, I want it to crop. I'm using `-vf scale=max(iw\,1280):max(ih\,720),crop=1280:720`, which seems to work fine on an image, but I'm getting an "Error initializing filter 'scale'" when the input is an RTSP video: https://gist.github.com/maxstoller/825787bd3757b03766b0f360e565dc97 [17:52:42 CEST] <Dovid> kepstien: well the phone does not do it. in my case ffmpeg gets it and passes it to mplayer. so the https is prob what is causing the spike or is it something else? [17:52:45 CEST] <alphabitcity> Is it possible it doesn't know the iw/ih for the first frame? [17:53:42 CEST] <kepstin> Dovid: ouch, you're using ffmpeg to read the hls stream then passing to mplayer over a pipe? That's a bit weird. Why can't you just use a player that can read hls directly and avoid the extra step? [17:54:26 CEST] <kepstin> Dovid: also make sure your ffmpeg command isn't doing any transcoding. CPU spikes could also happen if there's some buffering going on in the pipe, I guess. [17:54:39 CEST] <Dovid> kepstin: If I spent the time on it probably. regardless the jump is from ffmpeg so I want to adress the CPU spike. [17:55:48 CEST] <kepstin> alphabitcity: we need to see the ffmpeg command you're running, but it looks like a syntax error in your command line from this line in the output: [AVFilterGraph @ 0x31eb040] Error initializing filter 'scale' with args 'max(iw:flags=bicubic' [17:55:58 CEST] <kepstin> alphabitcity: might be a command line string escaping issue. [17:56:58 CEST] <alphabitcity> kepstin: the introduction of the scale/crop filter broke it. `-vf scale=max(iw\,1280):max(ih\,720),crop=1280:720,my` [17:57:23 CEST] <adhawkins> Is there any way to use ffprobe to report the maximum bitrate of a file? Currently it's just reporting 'N/A'. [17:57:27 CEST] <kepstin> alphabitcity: please pastebin the complete ffmpeg command, copy/pasted exactly from the command line where you ran it. [17:58:36 CEST] <kepstin> adhawkins: "maximum" is tricky to define, over what timescale? I think the maximum field that ffmpeg reports is just some metadata from the file container, if the container stores such info (and the encoder set it) [17:58:56 CEST] <adhawkins> Over the whole file. Ideally read the entire file and report what the maximum bitrate is that it sees. [18:00:46 CEST] <DexterF> hi [18:01:15 CEST] <alphabitcity> kepstin: here's the full cmd https://gist.githubusercontent.com/maxstoller/3c50475df3207937f8231a06fa4fa… [18:01:19 CEST] <DexterF> wanted to rotate a cell vid (shot with a Google Pixel) and get this: https://pastebin.com/3pT5MHPK [18:01:45 CEST] <kepstin> adhawkins: "maximum bitrate over the whole file" makes no sense, "over the whole file" is just average bitrate [18:02:01 CEST] <adhawkins> Ok, perhaps 'peak' bitrate is the term I mean? [18:02:02 CEST] <DexterF> so mainly [aac @ 0xcdfee0] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. <-- adding the strict option is simply ignored [18:02:36 CEST] <kepstin> DexterF: upgrade to ffmpeg 3.0 or later [18:02:50 CEST] <adhawkins> So it reads (say) a second worth of video, works out how much data that was, and calculates a bitrate from that. then does the same with the next second. Whichever one comes out as hte highest value is the peak bitrate. [18:03:15 CEST] <kepstin> adhawkins: you'd have to calculate it yourself (you can use ffprobe to get the info) by getting the size in bits of each frame, deciding what time period you want to average over (e.g. 1s), and doing the calculation. [18:03:28 CEST] <adhawkins> Yeah, that's what I feared :) [18:03:48 CEST] <kepstin> and you'd probably want to do a rolling average, not by segment, although it's probably close enough in most cases i guess. [18:04:13 CEST] <adhawkins> Just thought that there being a 'max bitrate' field in the results, there was some way of getting this filled in. [18:06:10 CEST] <DexterF> kepstin, yay, thanks [18:06:48 CEST] <kepstin> adhawkins: encode the file with vbv max bitrate limits and save in a format that preserves the values used as metadata? :) [18:07:39 CEST] <adhawkins> This is on files that could come from anywhere, so that's not an option sadly. [18:11:01 CEST] <kepstin> at least you don't have to decode the files, just demux them, so it should be reasonably quick to calculate [18:14:22 CEST] <RationalCoding> Hello. I am trying to merge an indefinite stream of webm files (they are being generated from a live stream), and output an RTMP stream. Is this possible with the -concat option? How do I specify which codecs are being used, and which ones I want? Any clues to how this might be done would be very helpful. Thanks. [18:23:26 CEST] <Fenrirthviti> Pretty sure concat is a static list and can't be used dynamically [18:33:41 CEST] <RationalCoding> Ah, that's what I was afraid of. Well thanks anyways, it seems I'll have to write my own transcoder for this strange case. Regards. [18:42:26 CEST] <alphabitcity> I'm using ffmpeg to scale/crop a live RTSP stream. According to top, ffmpeg is taking about 50% of an 8 vCPU machine (a "high" CPU machine on Google Cloud) for 1 stream. Is that expected? Any way to optimize? Thanks! [18:45:53 CEST] <c_14> probably reencoding to H.264 [18:46:11 CEST] <c_14> you can make it use less if you don't mind dropping quality or upping bitrate [18:46:32 CEST] <JEEB> right, I've gotten so used to people meaning optimize as "use more CPU" [18:46:42 CEST] <JEEB> :) [18:46:56 CEST] <JEEB> (esp. when people mention core counts) [18:48:03 CEST] <alphabitcity> c_14: i was under the impression that if you're scaling/cropping you have to re-encode. we also have a custom filter that's adding a watermark [18:48:19 CEST] <alphabitcity> c_14: here's our full cmd: https://gist.githubusercontent.com/maxstoller/3c50475df3207937f8231a06fa4fa… [18:48:47 CEST] <c_14> alphabitcity: you do have to reencode [18:50:02 CEST] <c_14> but you can use a faster preset if you want to use less cpu (-preset fast/veryfast/ultrafast) [18:50:20 CEST] <alphabitcity> c_14: ok, i will give that a shot. thank you [18:58:53 CEST] <Dovid> kepstin: I just checked and it's http NOT https. The URL is: http://radio.sa-media.com:1935/shoutcast/_definst_/radiostation.stream/chun… [19:02:48 CEST] <Asuran> thebombzen, what you think about netflix claims about hevc tuning (x265)? [19:18:34 CEST] <DHE> Dovid: oh, it's a live audio channel. so what you're seeing it ffmpeg processing the ~10 second burst of data in an instant, and then waiting 10 seconds for the next burst. [19:19:38 CEST] <Dovid> DHE: Correct. That is what I meant by "chunks" [19:20:43 CEST] <kepstin> Dovid: expected behaviour, yep. To fix it, use a player that can open hls directly, rather than ffmpeg in the middle with a pipe. [19:21:07 CEST] <DHE> which is odd because I'd expect a phone to play it okay. [19:21:09 CEST] <kepstin> You could try playing around with the -re input option to slow ffmpeg down, but it'll probably cause a desync from the live stream over time. [19:21:35 CEST] <Dovid> kepstin: Why does the CPU spike there? Is it just the process of the get to the server? [19:21:59 CEST] <Dovid> kepstin: Pardon my ignorance. what is HLS? [19:22:03 CEST] <kepstin> Dovid: nah, it's just a result of ffmpeg being a batch tool and the size of the pipe buffer between it and the player. [19:22:28 CEST] <kepstin> HLS is the name of the segmented media streaming format you're trying to play (with the m3u8 playlist) [19:22:52 CEST] <Dovid> btw when I say phone I mean a SIP phone. [19:23:27 CEST] <Dovid> kepstin: I dont know streaming well. This is what I am feeding to the PBX: [19:23:34 CEST] <Dovid> . /usr/bin/ffmpeg -report -i http://radio.sa-media.com:1935/shoutcast/radiostation.stream/playlist.m3u8 -vn -c:a libmp3lame -b:a 320k -joint_stereo 0 -y -f mp3 pipe:1 |/usr/local/bin/madplay -Q -o raw:- -1 -R 8000 -a -10 - [19:23:52 CEST] <Dovid> madplay can not play aac [19:24:13 CEST] <Dovid> unless I can get ffmpeg to output raw but i would still then have the CPU issue [19:24:18 CEST] <kepstin> Dovid: ffmpeg sits around waiting for the next segment to be available, then once it is it'll download and transcode it quickly, storing the result in the pipe buffer, which the next application will read at its leisure [19:24:59 CEST] <Dovid> kepstin: So I would need to have ffmpeg slow down the download and transcode since it tries to do the entire segman at once [19:25:19 CEST] <kepstin> Dovid: why bother? it should be working fine as it is... [19:25:41 CEST] <Dovid> kepstin: Its working except for the spike every 10 seconds [19:25:57 CEST] <kepstin> Dovid: I have no idea why you're using madplay in there tho, ffmpeg should be able to output the raw format you need for the pbx directly. [19:26:17 CEST] <Dovid> kepstin: So I can send you a few shekels to help me out? [19:26:22 CEST] <kepstin> Dovid: sure, but why is a cpu spike every 10s a problem? [19:27:19 CEST] <Dovid> kepstin: Because I am pulling multiple streams. It's a system where people can call in and listen to church sermons so if we have say 5 churches on there 9/10 seconds the CPU is idle but for 1/10 the CPU load from 5 streams kills the box [19:28:06 CEST] <kepstin> Dovid: well, first thing first is that you should drop the extra transcode to mp3 you're doing and have the audio only be decoded by ffmpeg [19:28:11 CEST] <kepstin> should save a chunk of cpu [19:28:42 CEST] <Dovid> so the PBX needs 8khz mono as you can see in the output from madplay. how would I modify the ffmpeg part to do that? [19:28:44 CEST] <kepstin> and second, fix your thread priorities so the pbx software is high or even soft realtime, then it shouldn't matter that the ffmpegs are bursting cpu. [19:29:14 CEST] <kepstin> 16bit signed 8khz mono? [19:29:14 CEST] <Dovid> can you explain " fix your thread priorities". r u talking about nice? [19:29:28 CEST] <kepstin> Dovid: check with the pbx software provider about that [19:29:46 CEST] Action: kepstin knows that when started as root, freeswitch does thread priorities correct by default [19:30:08 CEST] <Dovid> kepstin: I am using asterisk :( [19:30:31 CEST] <Dovid> so I need to modify: /usr/bin/ffmpeg -report -i http://radio.sa-media.com:1935/shoutcast/radiostation.stream/playlist.m3u8 -vn -c:a libmp3lame -b:a 320k -joint_stereo 0 -y -f mp3 pipe:1 [19:30:46 CEST] <Dovid> so that it will send it out as raw 9khz mono. correct? [19:31:29 CEST] <relaxed> maybe something like, .... -vn -c:a pcm_s8 -ac 1 - [19:31:39 CEST] <kepstin> Dovid: anyways, "ffmpeg -i <streamurl> -vn -ar 8K -ac 1 -f s16le -" should do that. [19:31:49 CEST] <Dovid> let me try. one mometn [19:32:05 CEST] <kepstin> but check whether 16 bit is correct, if you need 8bit it'll be different [19:32:21 CEST] <relaxed> -f s8 [19:33:06 CEST] <kepstin> that'll drop the cpu load a fair bit simply by avoiding the extra encode step, which might be enough. [19:33:09 CEST] <Dovid> so for 16 bit "ffmpeg -i <streamurl> -vn -ar 8K -ac 1 -f s16le -" and for 8 but "ffmpeg -i <streamurl> -vn -ar 8K -ac 1 -f s8 -" [19:34:11 CEST] <relaxed> it would help if you knew what the pbx called for [19:34:29 CEST] <kepstin> if that existing madplay command works, s16le is probably correct [19:34:55 CEST] <kepstin> note that the madplay command is also reducing gain by 10dB, if you want to do the same in ffmpeg, add "-af volume=-10dB" [19:35:51 CEST] <Dovid> kepstin: Wow. not using madplay helps a lot!. Thank you. Your fav charity is? [19:36:16 CEST] <kepstin> well, what helped a lot was not encoding mp3 audio :/ [19:36:25 CEST] <kepstin> encoders are cpu intensive :) [19:37:27 CEST] <Asuran> thebombzen, i tried now libx264 [19:38:10 CEST] <Asuran> thebombzen, just 10% bigger size hmm [19:38:40 CEST] <Dovid> kepstin: Your favorite charity is? [19:39:45 CEST] <relaxed> Dovid: maybe ffmpeg? http://ffmpeg.org/donations.html [19:40:53 CEST] <kepstin> Dovid: also EFF and archive.org are up there for me :) [19:41:23 CEST] <Dovid> bah. seems like the wife has my cc. one sec [19:46:43 CEST] <Dovid> kepstin: and they dont take amex. Just made a donation to both ffmpeg and FFmpeg - OPW (Outreach Program for Women) [19:47:54 CEST] <DexterF> how come that after not doing more than: -vf "transpose=2" the output video is half in size? (The original was shot with a mobile phone in wrong orientation) [19:48:22 CEST] <furq> DexterF: because it'll use the default x264 settings [19:48:32 CEST] <kepstin> DexterF: in order to apply the transpose filter, the video is being re-encoded, and the newer settings are probably smaller than what the phone uses [19:48:37 CEST] <furq> or the default settings for whatever encoder is default for the container you used [19:48:41 CEST] <furq> which is probably mp4 and x264 [19:49:02 CEST] <kepstin> assuming it's using x264, that's a way better encoder than the phone's hardware encoder, so the quality loss is probably minimal, too. [19:49:06 CEST] <furq> also you might be able to fix that losslessly [19:49:34 CEST] <kepstin> hmm, by adding metadata, yeah. Not all players will respect it, but it might be good enough? [19:49:38 CEST] <furq> mp4 has widely-supported rotation metadata for this exact scenario [19:49:45 CEST] Action: DexterF checks source [19:49:51 CEST] <furq> it might be as simple as just removing that from your source file [19:50:07 CEST] <DexterF> well, mpv and smplayer played it in proper orientation, but youtube borked [19:50:07 CEST] <furq> but if it was actually encoded the wrong way up, you can try adding it [19:50:21 CEST] <furq> oh right [19:50:26 CEST] <furq> yeah that sounds bad then [19:50:48 CEST] <furq> check with ffprobe anyway [19:51:42 CEST] <DexterF> Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, smpte170m), 1920x1080, 32998 kb/s, SAR 1:1 DAR 16:9, 60.02 fps, 60 tbr, 90k tbn, 180k tbc (default) [19:52:31 CEST] <DexterF> shot at whatever a Google Pixel considers default, I didn't touch any settings [19:53:25 CEST] <DexterF> audio is Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 96 kb/s (default) [19:54:28 CEST] <DexterF> re-encoded I have Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 1920x1080 [SAR 1:1 DAR 16:9], 16204 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default) [19:54:53 CEST] <furq> it should namedrop the rotation flag in there [19:54:57 CEST] <furq> if not then try adding -show_format [19:55:48 CEST] <DexterF> "displaymatrix: rotation of -90.00 degrees" . so the video stream lost half its bandwidth. what is tbr, tbn, tbc, btw? [19:58:09 CEST] <DexterF> https://pastebin.com/CTkYhmFs <- with show_format [19:58:25 CEST] <DHE> timebase info for the stream in various ways [19:58:30 CEST] <DHE> tbc is the codec's timebase for example [20:25:31 CEST] <Asuran> kepstin, you use h264 because x265 isnt good enough today? [20:25:55 CEST] <Asuran> it seems due that people wait for av1 or im wrong? [20:26:07 CEST] <Asuran> thebombzen, ffmpeg -i %1 -c:v libx264 -preset:v placebo -crf 19 -tune film -c:a libopus -b:a 96k -vbr on -packet_loss 0 -compression_level 10 -application audio "%~n1".mkv is now i use [20:31:09 CEST] <kepstin> I use x264 because it's a really good encoder and I'm mostly dealing with sub-4k content where hevc encoders aren't really worth the speed loss. [20:31:50 CEST] <kepstin> although if you're willing to use the 'placebo' option in x264 (which isn't guaranteed to actually be more efficient than 'veryslow'...), x265 might be ok for you? [20:33:11 CEST] <Asuran> kepstin, what you mean ok for me? i would love to use it, but i cant get it done [20:33:23 CEST] <Asuran> kepstin, its not bad yea, im almost impressed [20:37:13 CEST] <Asuran> kepstin, forget it, i now understood [20:37:19 CEST] <Asuran> kepstin, no, in x265 its very slow [20:37:23 CEST] <Asuran> i get less then 1 fps [20:37:28 CEST] <Asuran> around 0.7 fps [20:37:30 CEST] <Asuran> or lesser [20:39:26 CEST] <Asuran> i cant go beyond slow even with that i risk at full hd slow frames [20:40:02 CEST] <Asuran> but since i cant get it working it doesnt matter, no one shares the settings tbh so idk what to set and try and fail doesnt work well [20:40:07 CEST] <Asuran> atleast with me [21:12:30 CEST] <lindylex> Does ffmpeg know the values of the video dimension and duration? This is what i am trying to code. https://pastebin.com/dLQBPAEe I want to get the values dynamically. I am trying to avoid the python programmatic way. If needed I will. [21:14:08 CEST] <Dovid> when using -report for ffmpeg can I change the file name? [21:20:09 CEST] <kepstin> lindylex: some filters have variables available for certain things like video dimensions etc. (for example, scale crop and overlay do). But ffmpeg filters don't have any way to know the video duration - because other filters can change the duration in unpredictable ways, or the video source might not have the info, or other reasons. [21:20:53 CEST] <kepstin> lindylex: you'd probably be best off programatically generating the filters string for this case. [21:22:56 CEST] <lindylex> kepstin: That is what I remember from yesterday kepstin. Yesterday the W and H were the values of the main video I used for the base height and width. I thought that their were built in way that ffmpeg always stored this information. [21:26:42 CEST] <furq> they're only exposed to certain filters [21:27:12 CEST] <furq> and also only to filters that take an input, which doesn't include sources [21:31:19 CEST] <lindylex> Thanks so much for the explanation. [21:55:39 CEST] <ioan> I'm trying to stream from an IP camera to youtube without sound and I always get the error "Cannot select sample rate for the link between filters Parsed_anullsrc_0 and out.anullsrc: Invalid argument" from ffmpeg. With sound works fine, but I can't figure out how to do it without sound [21:56:04 CEST] <ioan> here is the everything: https://pastebin.com/A2zj3n2V [21:58:15 CEST] <ChocolateArmpits> ioan, did you try setting sample rate for the anullsrc ? [21:59:44 CEST] <BtbN> Pretty sure youtube wants you to send aac audio [22:00:02 CEST] <BtbN> and 712kbps for audio is super exzessive [22:00:12 CEST] <nicolas17> ...lol [22:00:26 CEST] <ChocolateArmpits> youtube can deal with with mp3, or at least did a year ago [22:00:45 CEST] <BtbN> I also don't think using qscale is a good idea, if x264 even cares about it [22:01:04 CEST] <nicolas17> isn't ~1Mbps enough for uncompressed PCM? [22:01:20 CEST] <nicolas17> to put that 712kbps compression bitrate in perspective... [22:01:44 CEST] <ioan> :-) so what should I change? how should my parameter list look like? [22:09:11 CEST] <ioan> I guess this works the best: https://pastebin.com/1NcdtD5A but with sound. I tried -an to remove the sound from source, but youtube (I think) needs sound. So I tried "-f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100" and "-map 0:a -map 1:v" but then I get that error: "Cannot select sample rate for the link between filters Parsed_anullsrc_0 and out.anullsrc: Invalid argument" [22:11:14 CEST] <ChocolateArmpits> ioan, did you try adding -re before the null audio input ? [22:14:09 CEST] <kepstin> ChocolateArmpits: there's no null audio input there, so that wouldn't do anything useful. The timing will be synced by the muxing code so no problem with that. [22:14:55 CEST] <kepstin> er, wait, no, i misread that [22:15:05 CEST] <ioan> ChocolateArmpits, like this: https://pastebin.com/v52mFgun [22:15:07 CEST] <ioan> ? [22:15:56 CEST] <kepstin> ioan: don't use -re on an input that's already realtime like an rtsp camera, that'll cause problems [22:16:26 CEST] <kepstin> and i'd recommend not using -re on the other input here either, it might cause the camera to drop frames, and the audio will be synced fine by the muxer anyways [22:16:54 CEST] <Vaska> Hello - I've noticed that quite a few options (with ffplay specifically) aren't available using the windows build binary. -fps and -video_size for example result in "Option video_size not found." [22:17:36 CEST] <kepstin> Vaska: you need to provide more context about the command you're trying to run and where the options are being placed. Those options are mostly applied to specific input or output drivers. [22:19:02 CEST] <Vaska> kepstin: ah, sorry, I'm playing a video stream and was hoping I could resize the video playback "ffplay.exe -video_size 320x240 http://192.168.1.22/videofeed" [22:19:47 CEST] <kepstin> Vaska: yeah, the -video_size option only applies to some types of inputs like webcams where you can request a specific size of frame for the camera to return, it doesn't apply to things like http streams. [22:20:30 CEST] <kepstin> Vaska: you can use "-vf scale=320:240" in this case to downscale the video before displaying it [22:20:41 CEST] <kepstin> or you could just resize the window, I suppose... [22:21:12 CEST] <ioan> kepstin, dropped the -re. Any idea on the error I'm getting? "[Parsed_anullsrc_0 @ 0225a7a0] Cannot select sample rate for the link between filters Parsed_anullsrc_0 and out.anullsrc=channel_layout=stereo:sample_rate=44100: Invalid argument" if I drop the arguments for anullsrc I get: "Cannot select sample rate for the link between filters Parsed_anullsrc_0 and out.anullsrc: Invalid argument" [22:22:18 CEST] <Vaska> kepstin: ok got it, the -vf scale=320:240 option works perfect, I'm kicking myself for not trying that since I'm familiar with it from mplayer's syntax, thanks for the help [22:23:08 CEST] <kepstin> ioan: i dunno, that's really strange. Have you tried putting the anullsrc in a -filter_complex string rather than using it as an input? [22:23:59 CEST] <ioan> I did not, I have to read about that because I don't know what it means :-) [22:24:34 CEST] <kepstin> that said, using "-f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100" works perfectly fine as an input for me [22:25:04 CEST] <kepstin> can you please pastebin the full and complete output from running the command? [22:25:53 CEST] <kepstin> (well, remove your stream key if it's in the output of course) [22:27:25 CEST] Action: kepstin notes that anullsrc defaults to stereo 44.1kHz, so the options should be doing nothing [22:28:16 CEST] <kepstin> the command you pasted is obviously not what you're actually running, because it's full of newlines - double check that the command you're really running doesn't have any syntax or escaping issues [22:28:17 CEST] <ioan> https://pastebin.com/qgmEbFFp [22:29:11 CEST] <kepstin> and, uh, before doing anything else, get yourself an ffmpeg from within the past couple years maybe? [22:29:58 CEST] <kepstin> this could very well just be a bug that was fixed in modern ffmpeg. [22:30:06 CEST] <ioan> fair point. when I searched for ffmpeg windows binary, I got to this one. Let me do that first, just realized the date too [22:30:28 CEST] <kepstin> for windows, grab one from https://ffmpeg.zeranoe.com/builds/ [22:32:50 CEST] <Asuran> kepstin, is ffmpeg suitable for image conversion? [22:32:57 CEST] <Asuran> like jpg [22:33:21 CEST] <kepstin> Asuran: it can do it, but I'd recommend other tools which are more image-oriented [22:33:26 CEST] <ioan> that's what I'm using and it shows -version as "ffmpeg version N-50911-g9efcfbe built on Mar 13 2013 21:26:48 with gcc 4.7.2 (GCC)" [22:33:27 CEST] <Vaska> Asuran: ImageMagick is probably better suited for image manipulation [22:33:28 CEST] <Asuran> ok thx [22:34:47 CEST] <kepstin> ioan: you're not running the correct ffmpeg binary then - do you have another old one in your path, maybe? [22:35:14 CEST] <ioan> probably, I'll have to dig a little [22:35:27 CEST] <kepstin> the git commit 9efcfbed9dd64679145f5f39d9a812dfeea97172 that the one you're running is built from is in fact from 2013. [22:35:41 CEST] <kepstin> it's definitely not the zeranoe build you just downloaded [22:36:23 CEST] <Vaska> ioan: if you have ImageMagick installed it also comes with a copy of ffmpeg.exe that optionally gets added to your path statement [22:36:47 CEST] <ioan> YES, just found it. It is the one from ImageMagick [22:37:16 CEST] <Vaska> ioan: while you're updating you could update your ImageMagick binary too ;) [22:38:37 CEST] <ioan> Vaska, that would take more work, some of the software I developed for the company depends of imagemagick and I can't just change the version without checking first. But I'm sure my software doesn't use ffmpeg, so I can just rename that file [22:42:47 CEST] <ioan> YAY! success, it was the version I was using... I can't believe I didn't' see the date from the beginning. Thanks ChocolateArmpits, kepstin, Vaska! [22:46:05 CEST] <ioan> Anyone konws if a Raspberry Pi is powerful enough to run ffmpeg 24/4 without setting the house on fire? [22:46:14 CEST] <ioan> 24/7 [22:47:10 CEST] <alphabitcity> Is there any way to get the capture time of a frame from an AVFrame object? [22:50:44 CEST] <kepstin> ioan: I think that a raspberry pi is not powerful enough, and has sufficient thermal throttling applied, that it should not normally be a cause of fires. Do make sure you're using a decently quality power supply tho, those are sometimes nasty. [22:51:48 CEST] <kepstin> alphabitcity: depends what the frame came from. I think (most of?) the webcam and screen capture input devices just use the time of frame capture as the pts... [22:52:36 CEST] <ioan> I'll have to try with a Pi and see what happens... if not, maybe EC2 T2.nano would do the trick [22:52:37 CEST] <alphabitcity> kepstin: hm, i was under the impression that the pts would be some relative number and not an absolute timestamp [22:53:51 CEST] <kepstin> alphabitcity: it typically is, but some of the frame grabbers put real time in there because it's simpler. [22:54:25 CEST] <alphabitcity> kepstin: i'll check .. that would be great. in that case, pts would be the capture time? [22:54:55 CEST] <kepstin> alphabitcity: yeah, it'll be in the same format as av_gettime() returns in that case. [22:55:12 CEST] <kepstin> I dunno how much i'd rely on this tho - it's an implementation detail of a few input drivers. [22:55:47 CEST] <alphabitcity> is there a better way? our workflow is webrtc > rtp > ffmpeg [22:56:09 CEST] <kepstin> oh, yeah, that won't work on rtp. [22:57:14 CEST] <kepstin> what would "capture time" even mean on a frame received over rtp anyways? [22:58:03 CEST] <alphabitcity> kepstin: yea, sorry, that terminology is a lil bit confusing. we're using a custom filter to stamp a timestamp on each frame of a video with ffmpeg. ideally we want that timestamp to be the time the frame was captured in the user's browser (again, webrtc ingest) or as close to it [22:58:32 CEST] <alphabitcity> kepstin: right now we're just stamping the wall clock, but it's about ~300ms behind the actual capture time (not precisely measured but somewhere in that range) [22:59:35 CEST] <alphabitcity> kepstin: the dream is each AVFrame having some sort of source timestamp attached to it that we could use [22:59:37 CEST] <kepstin> alphabitcity: yeah, there's no way to really know the real time that a frame on the remote side was captured from the receiving side. You could *maybe* estimate it from the delay that rtcp computes, but I don't think that's exposed anywhere in ffmpeg's api [23:00:00 CEST] <alphabitcity> kepstin: makes sense, thank you. [23:01:23 CEST] <kepstin> if possible, you could try sending (out of band) info from the client about what its local clock was when it captured the first frame, maybe. [23:01:35 CEST] <oerg866> Hi, I have a question about the 3GP file format [23:01:50 CEST] <kepstin> but if the client's on wifi, then the delay will be changing constantly anyways... :) [23:02:04 CEST] <alphabitcity> kepstin: right. hoping to keep it in band, but not sure it's possible [23:02:18 CEST] <oerg866> as far as I understand it there's some way of telling the player which orientation to play the content in, like phones use... if I for example film upside down on my phone, the Windows 10 movie player plays it correctly, while it is upside down in MPC-HC [23:02:34 CEST] <oerg866> can i change that information with ffmpeg and if yes, how? [23:03:05 CEST] <alphabitcity> kepstin: our current solution is only ~300ms off, which is not terrible .. perhaps we can squeeze more precision out of it. we're using -vf myfilter .. where myfilter takes the wallclock and stamps the timestamp on. are there any flags that you could suggest we try that might cause frames to hit the filter earlier? [23:04:36 CEST] <ioan> thanks for helping. See you all later! [23:06:18 CEST] <kepstin> oerg866: yeah, you should be able to set it with the -metadata option. e.g. "ffmpeg -i orig.3gp -c copy -metadata s:v:0 rotate=90 output.3gp" [23:06:31 CEST] <kepstin> oerg866: replace 90 with 0, 90, 180, 270 [23:06:53 CEST] <kepstin> er, "-metadata:s:v:0 rotate=90" i made a typo [23:08:10 CEST] <oerg866> ahhh cheers [23:08:13 CEST] <oerg866> :) [23:10:20 CEST] <kepstin> oerg866: note that this should work on mp4 as well, I'm not sure about other formats. [23:32:43 CEST] <realnc> hello! got a quick question: how do I rip the raw vorbis audio from an ogg vorbis file? [23:33:04 CEST] <realnc> this doesn't work: ffmpeg -i file.ogg -acodec copy file.vorbis [23:37:02 CEST] <drv> I don't think there is any such thing as a raw Vorbis format - it is always encapsulated in some kind of container [23:41:34 CEST] <realnc> there is no raw vorbis "format". there is raw vorbis. mime type is "audio/vorbis". I'm trying to somehow produce a file with raw vorbis in it. [00:00:00 CEST] --- Fri Jul 14 2017

1 0

ffmpeg-devel.log.20170712
by burek 13 Jul '17

13 Jul '17

[11:27:18 CEST] <durandal_1707> \o/ [11:27:46 CEST] <durandal_1707> my magicyuv basic encoder is working [12:19:21 CEST] <VP9-in-MP4> Just some quick Feedback, I'm not staying for a response: I was trying to merge a video-only file & an audio-only file & I got this error msg... [12:19:47 CEST] <VP9-in-MP4> [mp4 @ 0000000002621400] VP9 in MP4 support is experimental, add '-strict -2' if you want to use it. [12:20:04 CEST] <VP9-in-MP4> Could not write header for output file #0 (incorrect codec parameters ?): Experimental feature [12:20:34 CEST] <VP9-in-MP4> ...I tried the "-strict -2" thing, but the file didn't play in VLC, it had the fourcc of vp09 instead of vp90, then I tried to force the fourcc & that didn't help either (not change), then I found that going back to the origianl command (no "-strict -2" & no "-vtag") & simply changing the output file extention to .webm made the command/conversion work without problems. [12:20:50 CEST] <VP9-in-MP4> I'd like to suggest this error msg suggest that: change the file extension to webm (or any other extension that supports vp9 video, something like: VP9 in MP4 support is experimental, add '-strict -2' if you want to use it...did you mean to use the .webm extension instead? [12:21:26 CEST] <nevcairiel> update to latest git master, vp9 in mp4 support was only standardized recently and encoding updated as appropriate [12:22:33 CEST] <VP9-in-MP4> but the thing is, I wasn't even really trying for "vp9 in mp4", I just wanted to merge the files, I don't care which container it's in, I only care if it plays in VLC, if the container/extension is mp4 or webm doesn't bother me [12:22:54 CEST] <BtbN> you must have told it to put vp9 into mp4 though [12:23:04 CEST] <BtbN> So it gave the apropiate message [12:23:04 CEST] <nevcairiel> then use webm, its vp9 support is far more widespread [12:23:09 CEST] <VP9-in-MP4> the error assumes that I knew I was trying to get vp9 in mp4, I was just defaulting the extension to mp4, I had no idea that wasn't normal [12:23:48 CEST] <BtbN> If you tell it to create an mp4 file, it will assume that mp4 is what you want. Can't really telepathically guess what you really want [12:23:49 CEST] <nevcairiel> (also, vp09 seem to be the appropriate tag for vp9 in mp4) [12:23:51 CEST] <VP9-in-MP4> nevcairiel: I didn't know that before...I didn't even know the source file was vp9 or that webm did support it or that mp4 didn't support it...I was simply trying to "merge files"... [12:24:05 CEST] <nevcairiel> well we cant fix you not knowing things [12:24:24 CEST] <nevcairiel> if you want blind operation, you should probably use some GUI tool that hides these details from you [12:24:29 CEST] <VP9-in-MP4> no, but the error msg could help guide users, couldn't it? [12:24:39 CEST] <BtbN> There are a million things the user might want [12:24:51 CEST] <BtbN> There is no way to put all of them in there [12:25:27 CEST] <BtbN> The user might also want h264 instead, but how would ffmpeg know? [12:26:19 CEST] <VP9-in-MP4> BtbN: "Can't really telepathically guess what you really want"...actually, it could: it would be helpful if ffmpeg would see the video format & audio format & suggest the best output format based on those...it should suggest webm if my formats are most appropriate for that [12:26:53 CEST] <BtbN> Why not suggest the most apropiate codecs for the requested container instead? [12:27:07 CEST] <VP9-in-MP4> that would be a good option too [12:27:15 CEST] <BtbN> But how would you know which one the user wants? [12:27:22 CEST] <BtbN> Or even something entirely else? [12:27:29 CEST] <VP9-in-MP4> I mean having a mode where ffmpeg could suggest 1 or the other [12:27:42 CEST] <BtbN> and what with the other possiblities? [12:27:52 CEST] <BtbN> Right now ffmpeg assumes the user knows what he/she is requesting. [12:27:53 CEST] <VP9-in-MP4> it could use a command like param like --auto-container or --auto-codec [12:28:02 CEST] <BtbN> So if mp4 is requested, it will to its best to deliver mp4 [12:28:07 CEST] <BtbN> *do [12:28:19 CEST] <BtbN> If you do not specify a codec, it will default to container defaults already. [12:28:43 CEST] <BtbN> which is not neccesarily a good choice in all cases [12:29:33 CEST] <VP9-in-MP4> I'm sorry I'm not a video expert & don't know all the possible combinations of codecs & formats, I'm not an ffmpeg dev (although I am a dev & not a noob with computers)...so I didn't know vp9 wasn't normal in mp4, now I know...I just came here to suggest a slight alteration to that one error msg... [12:30:04 CEST] <BtbN> It's not as easy as you think [12:30:20 CEST] <BtbN> Those auto-suggestions would be wrong more often than right, and then make things worse [12:30:21 CEST] <VP9-in-MP4> also, I wasn't specifying any audio or video codec, I was using -c copy to copy the input, so, then it would be nice if it would also copy the best container from the inputs [12:30:27 CEST] <BtbN> so it's better to not suggest anything [12:30:37 CEST] <BtbN> if you speficy -c you specify a codec [12:30:47 CEST] <BtbN> copy is just a special case that does not transcode at all and keeps the input codec [12:31:07 CEST] <BtbN> if you omit -c entirely, ffmpeg will transcode to container defaults [12:31:11 CEST] <VP9-in-MP4> I prefer not transcoding most of the time [12:31:23 CEST] <BtbN> yeah, then -c copy is fine [12:33:22 CEST] <VP9-in-MP4> maybe my suggestion could be for ffprobe instead? maybe ffprobe could suggest the possible (or best) extensions/containers for the codecs it finds in the file? ffprobe is already an info-only program... [12:36:37 CEST] <BtbN> Usually every container is just fine [12:43:45 CEST] <VP9-in-MP4> BtbN: "So if mp4 is requested, it will to its best to deliver mp4"...I don't think there is, but: is there a way to not "request" any container & let ffmpeg choose? I'm pretty sure if I leave off the output file extension, that won't help. I only "requested" mp4, cuz that's the extension I typed, I didn't know I should've typed webm... [12:44:15 CEST] <BtbN> I don't think there is. [12:44:31 CEST] <BtbN> If it can't deduct the format from the extension, it will complain to you to specify a format explicitly [12:45:03 CEST] <VP9-in-MP4> OK, then, that's my suggestion...have /someway/ to tell ffmpeg to help me choose, like maybe a command line option, or simple using the file extension .auto or something [12:46:07 CEST] <VP9-in-MP4> I know ffmpeg might not be able to help or guess in all cases, but some cases are semi-easy...like webm & maybe mp4...those containers have "normal" codecs that go in them, even if they might overlap in codec support [12:50:19 CEST] <VP9-in-MP4> I normally use -c copy, so ffmpeg should always have 2 codecs (audio & video) it knows about, so between those 2, it should have a really good idea of the "default" or "best" container/extension it should use... [13:00:53 CEST] <BtbN> it really doesn't [13:01:32 CEST] <BtbN> Usually you pick the container based on your needs [13:03:20 CEST] <VP9-in-MP4> anyway, thx for the responses, I never stay in IRC very long...(leaving soon)... [13:19:34 CEST] <VP9-in-MP4> ya know what I just thought of?...in addition to the -c copy option, ffmpeg needs some option like --copy or --preserve-all, so it would read the input & preserve the codecs AND container from the input, even if you specify the wrong output file extension. It already KNOWS the input codec AND container, so it already knows what to suggest (or use) for output, if you could tell it --preserve-all [13:21:11 CEST] <J_Darnley> An interesting idea but isn't the output file openend/created first? [13:21:32 CEST] <JEEB> also we do trust our users to actually know what they want [13:22:12 CEST] <nevcairiel> creating a file with a format not matching the file extensions is just stupid. If you want the files to remain the same, I would expect you to be smart enough to actually pick the same extension [13:22:34 CEST] <nevcairiel> well he left anyway [13:54:30 CEST] Action: JEEB starts digging into stuff to get it upstreamed [14:26:46 CEST] <durandal_1707> JEEB: what stuff? [14:31:04 CEST] <JEEB> Yet Another Subtitle Format and its ISOBMFF mapping [14:31:18 CEST] <JEEB> I will also have to verify that it was done according to spec and not according a Random Vendor's Requirements :) [14:59:35 CEST] <J_Darnley> How does anyone make any progress writing something new? I keep seeing things I already wrote are wrong. [14:59:54 CEST] <BBB> just keep going [15:00:20 CEST] <BBB> during my PhD, I learned the term verbal diarrhea, which means just write stuff [15:00:33 CEST] <BBB> so the idea is to not get bogged down in self-questioning or doubt, but just keep going [15:00:44 CEST] <BBB> and when youre finished, itll obviously be wrong, and thats when you start fixing it [15:00:48 CEST] <BBB> until its correct [15:00:56 CEST] <JEEB> yea [15:01:00 CEST] <JEEB> that way you have *something* [15:01:01 CEST] <BBB> for code, this can be a linear process, since theres only so many variables and states and calculations [15:01:06 CEST] <BBB> so you just get the first one right [15:01:09 CEST] <BBB> and then the second [15:01:19 CEST] <BBB> and after N iterations, you are guaranteed that all N states are right [15:01:23 CEST] <BBB> and then the function is finished [15:01:33 CEST] <BBB> (or algorithm, or research, or ...) [15:01:39 CEST] <JEEB> has anyone here looked into 14496-30? [15:02:16 CEST] Action: J_Darnley already misses his constrained DSP assembly work. [15:02:39 CEST] <BBB> assembly is the best example of this, yes [15:09:03 CEST] <wm4> <J_Darnley> How does anyone make any progress writing something new? I keep seeing things I already wrote are wrong. <- there are enough scapegoats, just complain about them and then ignore the problems, then add new ones instead [15:09:28 CEST] <wm4> pretty high chance you'll be "right" anyway [15:11:46 CEST] <BBB> lol [15:19:33 CEST] Action: JEEB is trying to understand what exactly 14496-30's timing stuff menas [15:26:03 CEST] <durandal_1707> J_Darnley: whats wrong? [15:37:55 CEST] <JEEB> why the fuck couldn't people just have their shit within samples :| [15:38:02 CEST] <JEEB> instead we have samples with XML samples within [15:38:09 CEST] <JEEB> with duplicated timing information etc [15:38:21 CEST] <JEEB> all this shit makes me very fucking sad [15:40:37 CEST] <iive> JEEB: let me use a quote "just complain about them and then ignore the problems, then add new ones instead" [15:42:47 CEST] <JEEB> for related laughter [15:42:48 CEST] <JEEB> https://github.com/Dash-Industry-Forum/dash.js/issues/640 [15:44:18 CEST] <JEEB> so, ok. if I consider the samples within a fragment a solved problem (I'm not just yet 100% sure of that), I will also have to have fun with the timestamps within the samples (because those are TTML documents which also contain timing) [15:44:29 CEST] <JEEB> now excuse me while I go get some whiskey [15:54:41 CEST] <J_Darnley> atomnuker: about the order of these orientations/subbands... [15:55:13 CEST] <J_Darnley> Are they 0=top-left, 1=top-right, 2=bottom-left, 3=bottom-right? [15:55:27 CEST] <wm4> reaching balmer peak quickly, huh? [15:58:24 CEST] <J_Darnley> wm4: I do not understand that [15:59:22 CEST] <wm4> what? [15:59:37 CEST] <wm4> https://xkcd.com/323/ [15:59:50 CEST] <J_Darnley> ah [16:03:27 CEST] <durandal_1707> so what to do with golomb and cached reader? [16:04:13 CEST] <nevcairiel> i dont suppose you can make it so that if the define is set before golomb is included, it'll also use cached then? [16:04:20 CEST] <nevcairiel> i guess golomb uses the evil macros? [16:08:32 CEST] <durandal_1707> it can be set with define, but i think its fragile [16:21:06 CEST] <J_Darnley> Yay! A colourful messy picture this time [16:32:25 CEST] <iive> J_Darnley: you should save this code and turn it into music visualization :D usually you could never think of such effects on purpose :D [16:33:18 CEST] <J_Darnley> Sounds good but I have no idea how you would have audio change what it does. [16:33:46 CEST] <J_Darnley> I guess you could run the encoder-decoder as a filter on some other vis source. [16:34:37 CEST] <J_Darnley> Besides I already have a stalled audio vis project. [16:37:15 CEST] <iive> :) [16:39:03 CEST] <iive> you can draw a line that is result of frequency aplitudes, encode and decode the image, and draw new one over the result. [16:39:11 CEST] <iive> amplitures... [17:19:06 CEST] <BBB> ubitux: have you ever seen tsan complain that atomic_int has a race condition? any idea what that could mean? [17:19:36 CEST] <BBB> it literally just says that an atomic_store write and atomic_load read are concurrently reading and writing into the same variable - which appears to be the whole point of atomic types, right? [17:19:44 CEST] <BBB> is my tsan just cmpletely b0rk3d? [17:20:01 CEST] <ubitux> doesn't ring a bell [17:20:09 CEST] <ubitux> i remember valgrind doesn't support them at all [17:20:24 CEST] <ubitux> helgrind* [17:20:52 CEST] <atomnuker> J_Darnley: I think, there are plenty of comments and the spec to tell you the order of LL, LH, HL and HH [17:20:57 CEST] <ubitux> for tsan, maybe that's just because the lock has a too permissive mode? [17:22:39 CEST] <BBB> Im just using the default load/store operations [17:22:40 CEST] <BBB> no explicit [17:22:53 CEST] <BBB> is that a bug? [17:23:29 CEST] <ubitux> are you using the C atomics? [17:24:44 CEST] <ubitux> anyway, maybe try to use explicit + the stricter order constraint [17:25:12 CEST] <BBB> C atomics, yes [17:25:15 CEST] <BBB> let me try explicit, tnx [17:29:47 CEST] <BBB> this is all so complicated [17:29:54 CEST] <BBB> not the threading, thats easy [17:29:57 CEST] <BBB> but the atomic types [17:30:28 CEST] <ubitux> yeah [17:42:25 CEST] <JEEB> ubitux: I remember you being the subtitle masochist. let's say I'm making a new subtitle encoder+muxer and I need a test, so I need an input file. which FATE sample would you recommend or how else would you handle it? :D [17:45:18 CEST] <ubitux> JEEB: text subtitles? [17:45:21 CEST] <JEEB> yea [17:45:30 CEST] <JEEB> although in theory there can be embedded images but let's not go there [17:45:45 CEST] <ubitux> i'd say copy subrip and vtt encoders [17:46:10 CEST] <JEEB> yea, this stuff I'm reviewing/rewriting here is based on the webvtt encoder as far as I can tell [17:46:17 CEST] <ubitux> fate-sub-webvttenc: CMD = fmtstdout webvtt -i $(TARGET_SAMPLES)/sub/SubRip_capability_tester.srt [17:46:23 CEST] <JEEB> cool [17:46:34 CEST] <ubitux> that sample is covering enough features [17:46:42 CEST] <JEEB> will put that in my notes [17:47:05 CEST] Action: JEEB is working on upstreaming some stuff part by part [17:47:30 CEST] <JEEB> first the basic support for encoding it, then movenc support [17:47:34 CEST] <BBB> even then it still complains :-/ [17:47:37 CEST] <BBB> bah [17:47:39 CEST] <BBB> stupid tsan [17:47:41 CEST] <JEEB> the movenc part will be a PITA [17:47:46 CEST] <BBB> Im going to assume its lying as usual [17:47:51 CEST] <JEEB> because of the specification being stupid [17:48:01 CEST] <ubitux> BBB: can i try? [17:48:27 CEST] <BBB> not yet :( sorry [17:50:36 CEST] <ubitux> covered by fate, we are using atomics in vp8, and builtin such as pthread_frame or lavu/buffer [17:50:48 CEST] <ubitux> and tsan doesn't complain on those afaik [17:53:17 CEST] <J_Darnley> Holy Shit! Have I done this correctly? [17:53:22 CEST] <J_Darnley> I don't believe it! [17:57:48 CEST] <J_Darnley> kierank: can you fetch the dirac2 branch from my Gitlab repo and test the encoder, please. [17:58:18 CEST] Action: J_Darnley goes afk for a bit [18:00:47 CEST] <ubitux> do we already have some infrastructure for timed data stream? [18:00:55 CEST] <ubitux> typically in mov/mp4 [18:02:15 CEST] <kierank> Ok [18:07:01 CEST] <JEEB> ubitux: I think we had support for MOV timed text, however that was transferred? [18:07:18 CEST] <JEEB> the whole ISOBMFF part of this subtitle format makes me cry so I hvaen't really looked into it yet, though... [18:13:24 CEST] <J_Darnley> Ah there's a problem. The default slice size doesn't work right with 420 [18:28:34 CEST] <JEEB> was there an avutil thing that took in the language metadata and output an RFC4646 thing? [18:29:37 CEST] <JEEB> or do we just generally trust that the metadata is sane [18:30:57 CEST] <JEEB> ok, seems like we trust [18:31:04 CEST] <JEEB> at least my older code does [18:36:06 CEST] <peloverde> durandal_1707: What do you think of the new SBR turnoff for 960? aac_isobmff_960.m4a works fine for me now [18:37:36 CEST] <durandal_1707> peloverde: ok [18:39:05 CEST] <kierank> J_Darnley: i only care about 4:2:2 10-bit [18:39:15 CEST] <kierank> so 420 you don't need to worry about [18:42:44 CEST] <peloverde> durandal_1707: I think there are some merge conflicts about MDCT scale, but otherwise it's good to go [18:49:26 CEST] <rcombs> JEEB: wait are you looking at VTT in BMFF [18:49:34 CEST] <rcombs> if so, my condolences [18:49:51 CEST] <rcombs> I looked into that, declared it unworkable, and yelled at the person who asked me to add it [18:50:55 CEST] <rcombs> we ended up deciding to use .vtt text segments in some cases and ASS in others [18:52:40 CEST] <wm4> lol [18:57:30 CEST] <wm4> kierank: what is black? [18:57:37 CEST] <wm4> in yuv... 16/16/128? [18:57:40 CEST] <kierank> wm4: 16 [18:57:41 CEST] <kierank> duh [18:57:53 CEST] <kierank> the full range neckbears are wrong [18:57:57 CEST] <kierank> neckbeards [18:58:09 CEST] <wm4> well I want to add a function to libavutil which fills an image with black [18:58:33 CEST] <wm4> so I guess it depends not only on AVPixelFormat but also AVColorRange [18:59:11 CEST] <kierank> makes sense to have a function like that [18:59:40 CEST] <kierank> if you use picture buffer pools you can have avcodec have packet loss and show uninitialised data which could be porn from another instance using the pool [18:59:41 CEST] <wm4> I'm also trying to avoid needing to have full handling of colors there, but black seems to be simple [19:00:06 CEST] <wm4> yes, seems specifically useful for initialization [19:00:18 CEST] <kepstin> seems like this duplicates some of the lavf drawutils code? [19:01:04 CEST] <kepstin> although that can do a lot of stuff other than fill a frame with black :) [19:01:23 CEST] <wm4> I've looked at the drawutils code, but it seems pretty bad, and doesn't even handle all pixfmts [19:14:37 CEST] <kierank> wm4: you expected good stuff from libavfilter [19:14:38 CEST] <kierank> lol [19:15:38 CEST] <atomnuker> it satisfies all but the most autistic needs [19:17:02 CEST] <wm4> and simple needs [19:17:59 CEST] <atomnuker> simple is a subset of complex [19:43:44 CEST] <rcombs> neckbears sound great [19:44:14 CEST] <durandal_1707> headbears better [19:44:54 CEST] <rcombs> kierank: did I tell you about the macOS bug where decoding failures or incorrect sizes would give you uninitialized surfaces _from other processes_ [19:45:08 CEST] <rcombs> like, you could see random bits of the Dock in the green mess [19:45:13 CEST] <kierank> not a surprise [19:45:34 CEST] <rcombs> apparently they weren't zeroing the buffers in the kernel when allocating hardware-decode surfaces [19:45:48 CEST] <rcombs> they did fix that [19:46:17 CEST] <rcombs> it was really easy to do, too: make a 2x2px H.264 stream, and put it in an MP4 with the stream resolution set to 1920x1080 [19:46:38 CEST] <rcombs> it'd allocate+display 1920x1080 surfaces and decode into the top-left corner [19:46:58 CEST] <rcombs> worked on websites, too, so you could read random bits of vmem in javascript [19:51:50 CEST] <kierank> lol [19:54:54 CEST] <wm4> apple and multimedia [19:57:12 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07master:c28f648b19dd: avcodec/mjpegdec: Clip DC also on the negative side. [19:57:13 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07master:341f01290c23: avcodec/magicyuv: Check that vlc len is not too large [20:26:33 CEST] <J_Darnley> Is there a "correct" way to generate an interlaced video stream with any of the source filters? [20:27:39 CEST] <atomnuker> vf interlace [20:28:17 CEST] <atomnuker> set the field order on the command line to make the encoder run in interlaced mode [20:33:33 CEST] <J_Darnley> thank you [21:14:16 CEST] <J_Darnley> atomnuker: thanks for the help you've provided [21:14:48 CEST] <atomnuker> do levels != 4 work? [21:14:59 CEST] <atomnuker> what speed gains did you get? [21:15:21 CEST] <J_Darnley> I haven't tested speed yet [21:15:28 CEST] <atomnuker> (you'll also have to make slice sizes different than the default work, crappy fpga decoders support 32x8 only AFAIK) [21:15:44 CEST] <JEEB> wow [21:15:46 CEST] <J_Darnley> Nice [21:15:58 CEST] <atomnuker> and then they only support 3 level LeGall (5,3) wavelets [21:16:15 CEST] <kierank> atomnuker: we might use 32x8 [21:16:25 CEST] <atomnuker> you probably should [21:16:49 CEST] <kierank> we'll probably buffer 16 or 32 lines or whatever (omg muh latency the hardware people cry) [21:17:25 CEST] <atomnuker> 4 levels seems to be the best the format can do, 5 levels and the coefficients get too large and you get overflows and also the image quality suffers [21:18:11 CEST] <J_Darnley> Okay, I won't test 5 for now [21:19:17 CEST] <J_Darnley> I do need to see how the encoder is supposed to do a slice height of 8 and wavelet depth of 4 [21:19:36 CEST] <tdjones> This is a 1000hz sin wave that has gone through the vorbis encoder with all short frames: https://0x0.st/GLw.jpg. It is spreading out the energy quite a bit and is only noticeable with pure tones or very resonant sources (stringed instruments). It's my understanding that this is likely something wrong with how the residue being encoded, or is it likely simpler? [21:19:56 CEST] <atomnuker> tdjones: that's normal [21:20:59 CEST] Action: J_Darnley curses automatic line wrapping in Vim [21:21:30 CEST] <J_Darnley> Stop that! That isn't correct bash syntax anymore! [21:26:26 CEST] <tdjones> atomnuker: this is longer frames as a reference: https://0x0.st/GLI.jpg [21:27:28 CEST] <tdjones> It is pretty significant when listening to it. I wouldn't expect to lose that much clarity by using smaller transforms [21:33:28 CEST] <atomnuker> is that with transients? [21:33:31 CEST] <atomnuker> on short blocks? [21:33:35 CEST] <atomnuker> that's completely normal [21:33:48 CEST] <atomnuker> with smaller blocks you get larger spectral leakage [21:34:03 CEST] <atomnuker> you trade off frequency precision for temporal precision [21:34:54 CEST] <atomnuker> (the uncertainty principle in action) [21:35:18 CEST] <tdjones> Yeah, I knew there would be some leakage, but didn't expect it to be that much. That's why I wanted to ask someone on here before I wasted time trying to fix a nonexistant problem [21:39:18 CEST] <atomnuker> here's how well opus deals with it: https://pars.ee/temp/opus_sine_10khz_20ms.jpg vs https://pars.ee/temp/opus_sine_10khz_2.5ms.jpg [21:40:00 CEST] <atomnuker> this is at 510kbps, the max bitrate [21:42:18 CEST] <tdjones> I see, thank you atomnuker [21:53:24 CEST] <atomnuker> tdjones: can you get me samples of a 10khz sine wave encoded with 64 sample frames and 8192 sample frames? [21:56:45 CEST] <atomnuker> curious to see how those ridiculously huge frames would help tonal stuff [22:00:27 CEST] <tdjones> atomnuker: Let me see if I can, I think the residue and floor setups only work with their specific frame lengths [22:04:04 CEST] <tdjones> It's not doable right this moment, I have to modify the how the floor and residues are partitioned so that they span the entire frame length rather than just the first 1024 samples [22:04:52 CEST] <atomnuker> ok, fair enough [22:05:53 CEST] <tdjones> I think I'm almost able to post this to ML, this madness with how codebooks are selected is the next change so that other lengths can be chosen [22:09:46 CEST] <durandal_1707> can someone post on doom9 that magicyuv encoder is going to ffmpeg? [22:11:04 CEST] <tdjones> I'm trying to parse the output of make fate a little better. With normal transient detection, should I expect the stddev from the input wav to increase? I'm getting an output of |654.71 - 296| >= 30 with a PSNR of 40.01. Is this a sign of something wrong in the encoder, or should I expect it? This difference doesn't seem that significant and isn't noticeable when listening [22:11:44 CEST] <atomnuker> tdjones: is that with all short frames? [22:12:59 CEST] <tdjones> No, it is with the frame length changing by itself [22:13:50 CEST] <tdjones> All short is: "stddev: 6367.74 PSNR: 20.25" [22:15:49 CEST] <tdjones> I'm not sure how to get those values if the test passes or else I could get the all long values too [22:16:56 CEST] <atomnuker> oh deviation [22:17:33 CEST] <atomnuker> yep, this looks fine, its lower [22:18:17 CEST] <tdjones> I'm sure I could make it pass if I made transient detection a little more strict [22:23:30 CEST] <atomnuker> don't bother [22:23:37 CEST] <atomnuker> if it sounds fine its right [22:24:20 CEST] <atomnuker> euclidian distance is not something anyone should be optimizing for [22:26:10 CEST] <kierank> J_Darnley: you are meant to duplicate pixels I think [22:26:15 CEST] <kierank> But atomnuker would know more [22:29:58 CEST] <durandal_1707> so nobody did benchmarks with new bitstreamer, im really very disapointed [22:30:40 CEST] <J_Darnley> Hm. I saw that the transform is clearly separated but I wasn't so sure about the rest [22:31:13 CEST] <atomnuker> durandal_1707: fine, I'll do some tonight [22:31:23 CEST] <atomnuker> (for real this time) [22:32:37 CEST] <durandal_1707> atomnuker: but you need to install computer first [22:40:28 CEST] <durandal_1707> atomnuker: also whats up with audio denoiser? [23:10:01 CEST] <atomnuker> I have a second less powerful laptop until I figure out kde or gnome [23:12:48 CEST] <J_Darnley> Rats. 9_7 crashes and 5_3 is corrupt [23:13:46 CEST] <atomnuker> keep in mind those need to overread into the next slice IIRC [23:14:35 CEST] <J_Darnley> Ah [23:14:44 CEST] <J_Darnley> I might have to revert a change I made [23:15:59 CEST] <J_Darnley> Yes. I obliterated something which causes an abort in a free [23:42:43 CEST] <kierank> atomnuker: no, they need interpolation at edges I believe [23:42:54 CEST] <kierank> In single slice mode [23:43:05 CEST] <kierank> In full transform it's overread [23:43:15 CEST] <kierank> The paper proves they are equivalent [23:45:04 CEST] <atomnuker> ok [00:00:00 CEST] --- Thu Jul 13 2017

1 0

ffmpeg.log.20170712
by burek 13 Jul '17

13 Jul '17

[00:13:52 CEST] <OldBrick> kepstin: Thanks for the suggestions. I also replaced the variables with constants for now. Result is the same, it runs fine from command line, but not when run with systemd-run timer. Oddly, I had to move the -t time option to the output side. [00:14:41 CEST] <OldBrick> kepstin: the command now is ffmpeg -probesize 10M -analyzeduration 20M -c:v mpeg2video -i udp://@:5000?timeout=1500000 -t 00:01:00 -c:v copy -c:a copy /home/av/bobdisk/rec1test.m pg & [01:48:57 CEST] <rajkosto> hello i am using C api how do i demux h264 raw elementary stream [01:49:12 CEST] <rajkosto> i need to group NALs by what frame they belong to [08:56:57 CEST] <kimmer> Hi all. I would like to capture a livestream on youtube, but i cant figure out how ;) I'm on a windows mashine, and I have the ffmpeg and the youtube-dl, but I can seem to figure out how ffmpeg works this is the stream that i would like to grab. https://www.youtube.com/watch?v=Y0Ng2odBiio or [08:58:59 CEST] <kimmer> I tried to use a shortner for the link, but does the link change if there is a courruption in the stream? Its a bicycle team that goes from northern Europe to Paris in their aid to support childdren with cancer - I have a family member riding and it came to me that it could be nice to have a record of the stream [09:21:54 CEST] <kazuma_> kimmer https://trac.ffmpeg.org/wiki/Capture/Desktop [09:22:11 CEST] <kazuma_> but you would be better off waiting for the stream to finnishe and just download it [09:22:27 CEST] <kazuma_> there are also gui tools like obs than make screen capture easy [09:24:40 CEST] <kerio> is there a facility in the ffmpeg cli to start/stop recording based on a signal of some sorts? [09:24:52 CEST] <kerio> maybe a literal signal [09:25:18 CEST] <kazuma_> end of stream or input file = it ends [09:25:30 CEST] <kazuma_> you can do ctrl + c to force quit it [09:25:42 CEST] <kazuma_> also [09:25:47 CEST] <kerio> what about starting tho [09:25:58 CEST] <kazuma_> you can hit the pause button on your keyboard to pause whatever it's prosessing [09:26:05 CEST] <kazuma_> and hit return/enter to resume [09:26:29 CEST] <kerio> this is for recording from a couple of webcams tho [09:28:09 CEST] <furq> iirc sigstop and sigcont works [09:28:18 CEST] <furq> although if it's a network source it might just end up timing out if you do that [09:31:24 CEST] <kimmer> kazuma_ I know of the screen capture tools outthere, but - I cant find the recorded streams on the channel, and thats why i wanted to capture it live.... I'' fool around with it, and get the program to learn :) Indeed a nice tool yu have created. [09:32:39 CEST] <furq> kimmer: what's wrong with just youtube-dl [09:33:04 CEST] <furq> also afaik youtube should give the channel owner the option to archive the stream once they're done broadcasting [09:33:29 CEST] <furq> i think it happens by default [09:34:17 CEST] <kimmer> it gave me an error that ffmpeg wasent installed or something, and then I just wanted to grab the stream with ffmpeg... [09:36:24 CEST] <kimmer> furq Well. Thise people have been cycleing for the past 5 days, and only sporatic streams are on youtube.. they are going down throu germany and France to Paris, but I guess that if they hit an aerea with no signal, the stream will stop, and the recording will stop aswell, and when signal reapear, the stream will pickup again. [09:36:39 CEST] <kerio> no this is v4l2 [09:37:01 CEST] <furq> you probably just want to figure out why youtube-dl can't find ffmpeg [09:37:21 CEST] <kerio> in a situations where the framerates are not stable but the timestamps do matter D: [09:37:27 CEST] <kerio> *situation [09:38:06 CEST] <kimmer> when I add up the hours they have been on the cycle, the hours dont add up, not even a 1/3'rd are on the channels archive....... I'll do that furq - I'll figure out why it dident picked up ffmpeg.. I'm currently on a windows mashine, is that an issue? [09:38:22 CEST] <furq> shouldn't be [09:38:57 CEST] <kimmer> mkai. thanks, I'll have a go with it - have a nice day [09:45:14 CEST] <kimmer> ah, ofcourse - ffmpeg needs to be in the same directory as the youtube-dl . I git it to work now - tkankyou fellas, much apreciated [11:41:43 CEST] <kerio> yo real quick [11:41:54 CEST] <kerio> can i stream ffvhuff in mpegts [11:46:02 CEST] <JEEB> kerio: no, but I bet you can do it in NUT or something else you can stream [11:46:28 CEST] <JEEB> (NUT is what some people use between ffmpeg and ffmpeg to stream data with A+V) [11:46:36 CEST] <JEEB> (usually raw audio/video) [12:19:17 CEST] <VP9-in-MP4> Just some quick Feedback, I'm not staying for a response: I was trying to merge a video-only file & an audio-only file & I got this error msg... [12:19:42 CEST] <VP9-in-MP4> [mp4 @ 0000000002621400] VP9 in MP4 support is experimental, add '-strict -2' if you want to use it. [12:19:57 CEST] <VP9-in-MP4> Could not write header for output file #0 (incorrect codec parameters ?): Experimental feature [12:20:29 CEST] <VP9-in-MP4> ...I tried the "-strict -2" thing, but the file didn't play in VLC, it had the fourcc of vp09 instead of vp90, then I tried to force the fourcc & that didn't help either (not change), then I found that going back to the origianl command (no "-strict -2" & no "-vtag") & simply changing the output file extention to .webm made the command/conversion work without problems. [12:20:45 CEST] <VP9-in-MP4> I'd like to suggest this error msg suggest that: change the file extension to webm (or any other extension that supports vp9 video, something like: VP9 in MP4 support is experimental, add '-strict -2' if you want to use it...did you mean to use the .webm extension instead? [12:55:20 CEST] <VP9-in-MP4> dang, this channel is dead, only people joining & leaving...at least I got responses to my report in #ffmpeg-devel [12:56:43 CEST] <JEEB> VP9-in-MP4: people are not always at the keyboard :) [12:57:33 CEST] <VP9-in-MP4> yes, I understand, but still only joins/leaves in this channel since I got here...I understand people aren't always here to respond... [12:57:47 CEST] <JEEB> well you had only been for ~30min so not even long tbqh [12:58:13 CEST] <JEEB> also yea, we generally expect people to understand what they want as the command line parameters are what you want [12:58:19 CEST] <squ> you want vp9 in mp4? [12:58:23 CEST] <VP9-in-MP4> 30 mins is about as long as I ever stay in IRC...I was only here to report that error msg I got... [12:58:38 CEST] <JEEB> and yea, depending on your FFmpeg version the VP9 in mp4 muxing is either out of date or not [12:58:45 CEST] <JEEB> I think it might have become non-experimental lately [12:59:22 CEST] <VP9-in-MP4> squ: no, that's the error msg I got, I already solved the problem by just using the output file extension .webm -- I wasn't /trying/ to do vp9 in mp4, it's just what ffmpeg thought I wanted by me specifying .mp4 as the output file extension [12:59:42 CEST] <squ> so, no problem [12:59:45 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=5ff31babfccd16cdee6575ae01… [13:00:03 CEST] <JEEB> VP9-in-MP4: well you told FFmpeg you wanted mp4 :D [13:00:15 CEST] <JEEB> so it told you "hold up a moment that's experimental" [13:00:23 CEST] <JEEB> I do agree that the message should at least have the human-readable value [13:00:25 CEST] <JEEB> instead of -2 [13:00:37 CEST] <JEEB> "-strict experimental" is the human-readable option [13:00:54 CEST] <VP9-in-MP4> JEEB: yes, I told it I wanted mp4, only cuz that's the default file extension I type, I had no idea my input file was vp9 & I had no idea that vp9 in mp4 was non-standard... [13:01:14 CEST] <JEEB> well it is standard now so you would have not gotten the error in the latest version [13:01:17 CEST] <JEEB> see the commit I linked [13:01:21 CEST] <squ> VP9 in MP4 support is quite readable [13:02:03 CEST] <VP9-in-MP4> that's why I'm suggesting that that error msg should say something like this: VP9 in MP4 support is experimental, add '-strict -2' if you want to use it...did you mean to use the .webm extension instead? [13:02:06 CEST] <squ> who invents such standards, vp9 not going to play on apple devices anyway [13:02:28 CEST] <JEEB> you can specify mappings and register them at the mpeg-4 ra [13:02:44 CEST] <JEEB> and at least netflix and a few other places have already started testing it [13:02:56 CEST] <JEEB> because CENC is defined for ISOBMFF (aka "mp4" [13:03:21 CEST] <squ> how netflix videos are received? [13:03:24 CEST] <JEEB> VP9-in-MP4: but that is not what you might want. we put more trust in the user actually requesting what he thinks he needs [13:03:32 CEST] <JEEB> squ: MPEG-DASH over the interwebs [13:03:37 CEST] <JEEB> which is ISOBMFF fragments [13:03:42 CEST] <squ> so, chrome? [13:03:46 CEST] <JEEB> or firefox [13:03:52 CEST] <JEEB> or mobile clients [13:03:58 CEST] <squ> android & chrome [13:04:06 CEST] <squ> nice standard :) [13:04:17 CEST] <JEEB> well, at least it's a standard [13:04:22 CEST] <JEEB> guess what is isn't [13:04:23 CEST] <VP9-in-MP4> but what if the user isn't a video expert & doesn't know what the need? all I needed was "these 2 files merged", I did specify -c copy, cuz I didn't want transcoding, but I had no idea which file extension was best for my inputs [13:04:24 CEST] <JEEB> *isn't [13:04:38 CEST] <JEEB> VP9-in-MP4: then you learn, young grasshopper [13:04:44 CEST] <VP9-in-MP4> yes, I did learn [13:04:47 CEST] <squ> how is that a standard if it is all Google [13:05:03 CEST] <JEEB> uhh [13:05:11 CEST] <JEEB> mozilla also wanted VP9 in ISOBMFF [13:05:29 CEST] <JEEB> I'm at work so I can't do the full research on who did work on it [13:05:32 CEST] <squ> why? and what is isobmff [13:05:38 CEST] <VP9-in-MP4> but that error msg suggesting -strict -2 sent me down the wrong path: it was suggesting I force an experimental thing, instead of simply using webm which is fully supported [13:05:44 CEST] <JEEB> ISOBMFF is the official name for what you usually call mp4 [13:05:55 CEST] <squ> JEEB: sorry to disturb, I was just in kind of a shock to about vp9 in mp4 [13:06:07 CEST] <JEEB> ISO Base Media File Format [13:06:07 CEST] <ritsuka> ISOBMFF is mp4 without the useless features no one uses anyway [13:06:27 CEST] <JEEB> well it's the latest version of the spec since it has moved in the range [13:06:37 CEST] <JEEB> I think it was part 1 at first, now part 12 (and 15 for AVC/HEVC mappings) [13:07:06 CEST] <JEEB> squ: and it's squarely because a lot of other things aren't specified in Matroska. Including Matroska itself. that's a WIP thing done under the EU [13:07:17 CEST] <JEEB> after Matroska becomes specified then WebM can also be specified [13:07:19 CEST] <JEEB> as a spec [13:07:35 CEST] <VP9-in-MP4> all these codecs & containers give me a headache...all I know is: VLC can play it...VLC can play any format. I think everyone should just design/pick the best audio & video codec/format/container & all use it [13:08:00 CEST] <JEEB> also VLC at this point is old [13:08:08 CEST] <JEEB> I mean the latest release of it [13:08:16 CEST] <VP9-in-MP4> it's old? what's new then? ohh [13:08:20 CEST] <squ> VP9-in-MP4: it turns out VLC with Google invent the standards [13:08:25 CEST] <VP9-in-MP4> yeah VLC releases are kinda slow [13:08:37 CEST] <JEEB> I've mostly used master for the past few years [13:08:43 CEST] <JEEB> done my own builds if I needed it [13:09:00 CEST] <JEEB> so a lot of the newer stuff just won't be in the stable releases of VLC until 3.0 is out [13:09:13 CEST] <JEEB> (which has been "soon (TM)" for the past two VDDs at least ;)) [13:09:16 CEST] <squ> how had vp9 passed into mp4 I don't get it [13:09:26 CEST] <VP9-in-MP4> oh u use master branch of VLC? (or ffmpeg?) [13:09:29 CEST] <JEEB> both [13:10:02 CEST] <JEEB> for FFmpeg you can use fate.ffmpeg.org as a monitor if the current master is OK to update to [13:10:14 CEST] <JEEB> windows/linux, or ARM/MIPS/x86_64 [13:10:19 CEST] <squ> google says we want vp9 in mp4 (don't ask why?), okey let's make it standard lol [13:10:20 CEST] <JEEB> a lot of stuff gets tested [13:10:40 CEST] <VP9-in-MP4> I don't compile any of my own software, setting up that kind of build env is too much of a hassle...(don't get me wrong, I'm not a computer noob, but I just don't "compile" things) [13:10:58 CEST] <JEEB> squ: I dunno why you're so against it. multiple vendors including el GOOG want it. and it's properly specified. what's not to like [13:11:04 CEST] <JEEB> same as DTS specifies DTS in ISOBMFF [13:11:09 CEST] <JEEB> or Dolby with its formats [13:11:40 CEST] <JEEB> http://mp4ra.org/ [13:11:44 CEST] <squ> I thought vp9 will be dead when hevc is out and have decoder/encoder implemented in hardware [13:12:07 CEST] <JEEB> well VP9 came out after HEVC and HEVC's main issues are in licensing [13:12:17 CEST] <JEEB> it got real fucked by corps [13:12:36 CEST] <squ> hevc goes into various hardware now [13:12:41 CEST] <JEEB> so does VP9 [13:12:46 CEST] <squ> not sure about that [13:12:48 CEST] <JEEB> my TV can do 10bit VP9 :P [13:12:55 CEST] <squ> I see [13:13:16 CEST] <JEEB> so due to the licensing shenanigans VP9, and then AV1 which was based on the VP10 with other groups joining, are getting traction [13:13:21 CEST] <ritsuka> my 30¬ dvb-t decoder can decode hevc [13:13:41 CEST] <ritsuka> it seems hevc is already everywhere [13:13:52 CEST] <JEEB> it's used, yes. but people are actively looking at alternatives [13:14:13 CEST] <JEEB> also it's generally not used for its gains as far as I can see :/ other than 10bit decoding being a thing that most HW decoders support [13:14:17 CEST] <squ> ritsuka: yep, and one day, surprise, vp9 in mp4 becomes standard (by Google) no one to argue agaisnt that? [13:14:37 CEST] <JEEB> (Ž4@) [13:14:39 CEST] <ritsuka> it's "standard" as in "there is a specification for it" [13:14:49 CEST] <JEEB> yes, and it's registered on mp4reg [13:14:53 CEST] <JEEB> http://mp4ra.org/ [13:14:57 CEST] <ritsuka> so you won't have two different companies making two different ways to store it in mp4 [13:15:10 CEST] <JEEB> until it's on mp4ra your just hacking around, basically [13:15:34 CEST] <JEEB> anyways, I've wasted enough time here :P [13:19:27 CEST] <VP9-in-MP4> ya know what I just thought of?...in addition to the -c copy option, ffmpeg needs some option like --copy or --preserve-all, so it would read the input & preserve the codecs AND container from the input, even if you specify the wrong output file extension. It already KNOWS the input codec AND container, so it already knows what to suggest (or use) for output, if you could tell it --preserve-all [13:22:03 CEST] <adhawkins> kepstin: Sorry, only just seen this. I didn't think I was trying to use more than one output? [14:06:30 CEST] <Fig1024> when using FFMPEG C++ API, encoded data is moved using AVPacket, how are they allocated? is there an internal memory pool or is it all dynamically allocated on the heap? [16:30:15 CEST] <danieeel> how to avoid the delay after printing the setup? i want to do some benchmarks and this ruins it [16:36:04 CEST] <kepstin> adhawkins: the command you gave in the paste had multiple output filenames in the command... [16:37:15 CEST] <kepstin> danieeel: what delay exactly are you referring to? ffmpeg should be going as fast as it can normally... [16:37:43 CEST] <danieeel> it shows the pipeline setup for a sec, then it starts the coding [16:38:31 CEST] <danieeel> or can i have a print of small statistics (fps) after each frame? [16:38:43 CEST] <kepstin> danieeel: it starts encoding immediately, maybe just the status line isn't shown immediately? [16:39:08 CEST] <kepstin> danieeel: note that current ffmpeg builds when using x264 behave a bit strangely, because x264 buffers a large number of frames internally [16:39:24 CEST] <danieeel> i am doing v210 to prores (on x86 and arm) [16:42:01 CEST] <kepstin> maybe pastebin your ffmpeg output with a marker where you're seeing this "delay" so I can give more accurate feedback? [16:42:31 CEST] <Asuran> guys, how can i list all options x265 does have supported in ffmpeg? [16:42:44 CEST] <Asuran> even with -x265-params i cant set profile for example [16:44:31 CEST] <kepstin> Asuran: you can use most of the options from https://x265.readthedocs.io/en/default/cli.html in the -x265-params (aside from some which are specific to the x265 cli, stull like input/output file options) [16:45:13 CEST] <Asuran> profile wont be recognized [16:45:30 CEST] <Asuran> psy-rd etc. does being recognized [16:46:32 CEST] <Asuran> kepstin, it an one liner: ffmpeg -i %1 -c:v libx265 -preset:v slow -crf 19 -x265-params profile=main10 -c:a libopus -b:a 96k -vbr on -packet_loss 0 -compression_level 10 -application audio "%~n1".mkv [16:46:38 CEST] <kepstin> Asuran: ok, if you look at https://x265.readthedocs.io/en/default/cli.html#profile-level-tier you'll see that the --profile option is listed as "CLI ONLY", which means it cannot be used in the options string. [16:46:48 CEST] <Asuran> thanks kepstin [16:47:03 CEST] <Asuran> so it means i need to get x265 standalone? [16:47:08 CEST] <kepstin> Asuran: I think you can use the "-profile" ffmpeg option to set it, let me confirm [16:47:23 CEST] <Asuran> not supported in trac wiki mentioned [16:47:50 CEST] <kepstin> yeah, looks like it's not implemented. patch welcome, I guess? :/ [16:47:58 CEST] <furq> i wouldn't necessarily trust the wiki [16:48:03 CEST] <furq> but it's not in -h encoder=libx265 [16:49:04 CEST] <kepstin> looks like it wouldn't be that hard to add, tbh., just a new string avoption and some code to call x265_param_apply_profile() at the end of setup, handle errors. [16:55:48 CEST] <danieeel> kepstin: https://pastebin.com/1ppCEuzb [16:56:21 CEST] <danieeel> the :33 is when i run the command but that progresses to :34 when encoding starts [16:59:05 CEST] <kepstin> danieeel: looks like that's a slow spot when it's trying to probe the format of the input file. What's the command you're running? You might be able to speed it up by manually giving input file format options. [16:59:52 CEST] <kepstin> weird that it's using image2 for what appears to be a raw video file [17:00:01 CEST] <danieeel> kepstin: ffmpeg -benchmark -framerate 1 -s 4096x2160 -r 60 -vcodec v210 -i /dev/shm/yuv422.raw -color_primaries bt709 -color_trc bt709 -colorspace bt709 -c:v prores -profile:v 2 /dev/shm/prores.mov [17:00:55 CEST] <danieeel> there is no v210 pixel format.. (which i used for 8bit yuv422 with rawvideo) [17:02:45 CEST] <kepstin> danieeel: but there is a dedicated v210 demuxer, give "ffmpeg -benchmark -video_size 4096x2160 -framerate 60 -f v210 -i inputfile.raw ..." a try [17:06:02 CEST] <danieeel> Unknown input format: 'v210' [17:06:18 CEST] <kepstin> oh, ffmpeg 2.8 lol [17:06:22 CEST] <kepstin> get a newer ffmpeg? [17:07:16 CEST] <danieeel> i can have a look into that... better from sources, right? [17:08:10 CEST] <kepstin> danieeel: for a quick test, grabbing the static binaries from the download page should be fine [17:13:53 CEST] <danieeel> this is nvidia x2 box with ubuntu.. i am a gentoo guy so i have no clue how to get the binaries here, lol :) will do with sources [17:14:12 CEST] <adhawkins> kepstin: Not that I can see...or am I missing something? [17:14:28 CEST] <adhawkins> The only '-f' is right at the end. [17:15:01 CEST] <adhawkins> converter.exe -y -threads 8 -i bbb_sunflower_2160p_30fps_normal.mp4 -crf 1 -maxrate 10000k -bufsize 20000k -vcodec libx264 -pix_fmt yuv420p -me_method hex -vf "fps=24" -fpre "presets\\cabletime.ffpreset" -acodec ac3 -ac 2 -ar 48000 -ab 160k -shortest -f mpegts -metadata "service_provider=Cabletime V2.0" bbb30-24.m2t-shortest -f mpegts bbb30-24.m2t -report [17:15:03 CEST] <kepstin> adhawkins: your paste has expired so i can't reference it now... [17:15:10 CEST] <kepstin> but you have two output filenames there [17:15:13 CEST] <adhawkins> Ah, there is a '-f mpegts' with no filename in the middle... [17:15:20 CEST] <adhawkins> Just pasted in the command. [17:15:22 CEST] <kepstin> "bbb30-24.m2t-shortest" and "bbb30-24.m2t" [17:15:41 CEST] <adhawkins> Ok, wasn't aware of that...let me double check. [17:16:04 CEST] <kepstin> adhawkins: it looks like a copy/paste error, tbh [17:16:25 CEST] <adhawkins> That command line is actually being generated by some code, so that code is probably at fault. [17:17:31 CEST] <adhawkins> Ah yes, copy and paste issue in the code. Let me try it again and see if it works without that duplication. [17:18:37 CEST] <adhawkins> Is there somewhere I can do a paste that won't expire? [17:19:54 CEST] <adhawkins> Will use gist. [17:19:59 CEST] <adhawkins> Ok, just tried again. Result here: [17:20:00 CEST] <adhawkins> https://gist.github.com/adhawkins/1cda47731a78133d664c209ef4b27e6a [17:20:09 CEST] <adhawkins> Basically the same issue. Good spot though kepstin, thanks. [17:20:10 CEST] <kerio> do you guys know if mpv can crop to an exact height [17:20:11 CEST] <kerio> or something [17:20:54 CEST] <kepstin> kerio: are you trying to crop a video with subsampled chroma to an odd height (or at an odd offset)? that's not gonna work... [17:21:03 CEST] <adhawkins> The error on the console is '[error]: malloc of size 52486144 failed' [17:21:06 CEST] <kerio> no i have a v4l2 device that outputs 640x512 [17:21:09 CEST] <kerio> and i want to show 640x480 [17:23:09 CEST] <kepstin> adhawkins: you aren't using a 32bit ffmpeg or something silly like that? [17:23:31 CEST] <kepstin> adhawkins: x264 *eats* ram, particularly at 4k, so you really need a 64bit ffmpeg [17:23:48 CEST] <adhawkins> Ah, I *am* using 32 bit... [17:23:57 CEST] <adhawkins> Let me try with a 64 bit version. [17:24:59 CEST] <adhawkins> kepstin: Genius, 64 bit version has got further at least. Thanks *so* much for the help, I'd never have thought of that. [17:25:10 CEST] <adhawkins> Given how small the allocation was that was failing, I assumed it was something else. [17:25:36 CEST] <kepstin> well, when most of the meory space is full, even a small allocation can fail [17:26:02 CEST] <adhawkins> Yep, but given that the error was occurring right at the start of the process, I didn't really connect the two. [17:28:19 CEST] <kepstin> kerio: mpv can do that, yeah. as for how - this really isn't the place? iirc it's documented in the man page... [17:28:23 CEST] <kerio> ok apparently i need a panscan of 3/19 [17:28:24 CEST] <kerio> :| [17:28:56 CEST] <kepstin> kerio: just use the crop filter [17:29:11 CEST] <kepstin> syntax is almost the same as ffmpeg's [17:30:59 CEST] <furq> you know mpv has an irc channel, right [17:31:08 CEST] <furq> not a very good one, but still [17:31:36 CEST] <danieeel> kepstin: it works now! [17:31:37 CEST] <kerio> i love you as well furq <3 [17:36:22 CEST] <danieeel> kepstin: the multithreading is done on a frame to frame basis, or will we see benefit when encoding just 1 frame? [17:40:38 CEST] <kepstin> danieeel: I don't know about how prores multithreading works, sorry. [17:41:33 CEST] <adhawkins> kepstin: Yep, successfully converted. Thanks so much for your help. [17:41:44 CEST] <danieeel> so it is not on system level, but each codec implements it in own way? [17:43:15 CEST] <kepstin> danieeel: yeah, since there's so much variation in how the codecs actually work, the multithreading has to be implemented mostly in the codec itself. Some of the internal codecs use a slice or frame threading framework that ffmpeg provides, external ones like x264 implement threading completely on their own. [17:48:59 CEST] <solrize> git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg [17:49:02 CEST] <solrize> -> [17:49:03 CEST] <solrize> fatal: unable to access 'https://git.ffmpeg.org/ffmpeg.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none [17:49:15 CEST] <solrize> hmm, this is with a just-installed debian 9 system [17:50:29 CEST] <solrize> oh lol, it's a startcom certificate [17:50:33 CEST] <solrize> please fix that, guys!!! [18:03:36 CEST] <iive> solrize: my browser says ssl is verified by Gandi [18:04:50 CEST] <solrize> Certificate chain [18:04:50 CEST] <solrize> 0 s:/C=SE/ST=Skane/L=Lund/O=Reimar D\xC3\xB6ffinger/CN=ffmpeg.org [18:04:50 CEST] <solrize> i:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class 2 IV Server CA [18:05:06 CEST] <solrize> that's from openssl s_client -showcerts -connect git.ffmpeg.org:443 [18:05:12 CEST] <furq> yeah it's startcom [18:05:17 CEST] <furq> this has been reported before [18:05:26 CEST] <furq> the excuse then was that certs from before october 21st were still trusted [18:05:30 CEST] <solrize> also get that on https://git.ffmpeg.org/ [18:05:36 CEST] <BtbN> Use git.videolan.org [18:05:37 CEST] <furq> but google and mozilla are blacklisting those soon [18:05:47 CEST] <solrize> google already did [18:05:54 CEST] <BtbN> works fine in Chrome for me. [18:06:06 CEST] <furq> they're being blacklisted in chrome 61 [18:06:11 CEST] <furq> unless that's already out [18:06:13 CEST] <solrize> ic [18:06:17 CEST] <iive> i do get different cert from git.ffmpeg and git.videolan [18:06:21 CEST] <BtbN> 59 is stable [18:06:27 CEST] <iive> i thought that the first is redirect to the latter [18:06:30 CEST] <furq> https://threatpost.com/google-to-fully-distrust-wosignstartcom-ssl-certs-in… [18:06:33 CEST] <solrize> i think you're right, it was announced but isn't out yet. what's videolan? [18:06:49 CEST] <iive> vlc website [18:07:05 CEST] <furq> http://git.videolan.org/?p=ffmpeg.git;a=summary [18:07:11 CEST] <furq> or you could just use the github mirror [18:07:18 CEST] <solrize> ok thanks [19:35:54 CEST] <Asuran> by any chance, is there maybe some kind of preset db for x265/x264 [19:43:15 CEST] <kepstin> Asuran: what do you mean? both of those codecs have built-in presets, you should pretty much just use the slowest preset that's fast enough for your use case. [19:43:37 CEST] <Asuran> x265 no still no look doc it seems like they didnt done some really [19:43:47 CEST] <Asuran> i heard x264 had film for example [19:45:08 CEST] <c_14> you mean tunes? [19:46:01 CEST] <kepstin> yeah, that's documented https://x265.readthedocs.io/en/default/presets.html for x265, and probably best to see the x264 cli --help (or --fullhelp) output for that encoder. [19:50:21 CEST] <Asuran> i doubt this works well its different much inside i believe [19:50:24 CEST] <Asuran> anyways thanks [20:19:16 CEST] <Asuran> c_14, kepstin is it maybe possible to force x265 show in output which commands (all) where passed? [20:28:22 CEST] <DHE> Asuran: it doesn't quite work that way with the API. Though you may be able to find the saved encoder parameters in the output file. "strings filename.mp4 | grep x265" might turn something up for example [20:33:07 CEST] <leif> Does anyone know how the command line `ffmpeg` tool is able to jump to the correct packet when encoding? Looking at `ffmpeg.c` the only av_seek_frame I see is for looping streams. [20:33:42 CEST] <kepstin> Asuran: i seem to recall that x265 does include a pretty detailed list of all the parameters its using in the log. doesn't map directly to the command line options, but still. [20:34:11 CEST] <leif> I ask because it looks like it just calls av_read_frame repeatedly, but when I run it with, say the `trim` filter, it is able to seek to the correct frame pretty quickly. [20:34:32 CEST] <kepstin> leif: ffmpeg.c (by default) seeks to the nearest seekpoint prior to the desired time, then demuxes+decodes, discarding the result, until it reaches the exact time wanted. [20:34:42 CEST] <leif> (Faster than I would assume it would take to just call av_read_frame, add it to the filtergraph, and repeat. [20:34:46 CEST] <kepstin> if you use the -ss input option [20:35:19 CEST] <kepstin> if you use the trim filter, then it just decodes from the start, and the trim filter discards frames... [20:35:32 CEST] <leif> kepstin: I see. [20:36:10 CEST] <leif> kepstin: thanks. That's what the code looked like. But I was amazed that the command: [20:36:41 CEST] <leif> `ffmpeg -i demo.mp4 -filter_complex '[0:v]trim=start=50=end=60[fv]' -map '[fv]' out.mp4 [20:37:09 CEST] <leif> appeared to 'jump' to the point where it could write out quickly. [20:37:20 CEST] <leif> Anyway, thanks. [20:37:26 CEST] <kepstin> only trimming 50 seconds off the start? Yeah, decoding 50s worth of frames and discarding them would barely be noticable [20:37:36 CEST] <kepstin> on a modern desktop pc anyways [20:37:40 CEST] <nicolas17> encoding is the slow thing :) [20:38:17 CEST] <leif> kepstin: Ah, okay, that makes sense. [20:38:36 CEST] <leif> Which probably means I'm doing something wrong with my code. Thanks. :) [20:39:08 CEST] <leif> (Namely, it takes much longer to get to the point where it does the encoding, but once it gets there it goes just about as fast.) [20:39:31 CEST] <kepstin> leif: but yeah, "ffmpeg -ss 50 -i demo.mp4 -t 10 -map 0:v out.mp4" would be faster in general, since it will seek into the file and start decoding from there. [20:40:02 CEST] <kepstin> it'll be noticable once you start grabbing chunks a couple hours into a long video :) [20:40:09 CEST] <leif> kepstin: Yup, that absolutely makes sense. [20:40:40 CEST] <leif> (Unfortunately, doing the equivalent of -ss wouldn't work in my case, as I am trying to make a preview feature for my video editor.) [20:40:57 CEST] <leif> err...language/editor hybrid...thing... [20:41:31 CEST] <leif> But ya, thanks. That helps a lot. :D [20:41:49 CEST] <kepstin> why not? there shouldn't be any problem seeking all over a video file while it's open in an editor. It's basically necessary for an NLE to be reasonably efficient [20:42:53 CEST] <leif> In principle ya, although I am currently compiling down to the filtergraph, and I would like to be able to seek to that output. [20:43:46 CEST] <leif> Right now, I have the horrible solution of rendering a low-res output from the filtergraph, and seeking with that. But I will probably need to abandon the filtergraph. [20:43:49 CEST] <kepstin> yeah, you can't seek in the output of a filter graph, but if you know enough and it doesn't have any stateful filters, you can seek the files :/ [20:43:57 CEST] <kepstin> seek the input files [20:44:42 CEST] <leif> That is very true. [20:45:06 CEST] <leif> By just taking the inverse (so to speak) of the filtergraph....that's a good idea. [20:45:23 CEST] <leif> And I think I can do that. (I am not using any stateful filters at the moment.) [20:45:49 CEST] <lindylex> How can I overlay two videos and keep the audio from both playing? ffmpeg -i m.mov -i o.mp4 -filter_complex "overlay=x=40:y=40:eof_action=pass" -y my.mov [20:47:35 CEST] <relaxed> -map 0 -map 1 -map -1:a would omit o.mp4's audio [20:48:17 CEST] <relaxed> I guess only -map -1:a would work [20:48:35 CEST] <lindylex> How do I keep both videos audio? I would like to not omit. [20:49:01 CEST] <kepstin> lindylex: you'd have to use an audio filter to mix the audio from both videos together [20:49:35 CEST] <relaxed> oh, I misunderstood :/ [20:49:47 CEST] <lindylex> What does that look like? The process I am not aware. [20:50:54 CEST] <kepstin> lindylex: -filter_complex '[0:v][1:v]overlay=x=40:y=40:eof_action=pass; [0:a][1:a]amix' [20:50:55 CEST] <lindylex> I have two videos. I will overlay o.mp4 on top of m.mov. I would like the audio for both to play. I can do the overlay but only the audio from m.mov plays. [20:50:55 CEST] <kepstin> should do it [20:51:09 CEST] <lindylex> Ok thanks let me try. [20:52:30 CEST] <lindylex> Thanks it worked perfectly. [20:58:13 CEST] <lindylex> kepstin: [0:v] means the first video that is m.mov in my command? ::: >>> ffmpeg -i m.mov -i o.mp4 -filter_complex "[0:v][1:v]overlay=x=40:y=40:eof_action=pass; [0:a][1:a]amix" -c:v libx264 -preset slow -crf 0 -preset ultrafast -an -y my.mov [20:59:07 CEST] <lindylex> kepstin: [0:a] means the audio from video m.mov. Is this correct? [20:59:14 CEST] <kepstin> lindylex: yes, the first number is the file index, and the part after the : is the stream selector; here 'v' and 'a' mean "default video" and "default audio", but you can use stream numbers instead. [21:00:11 CEST] <lindylex> I think I am begging to understand what this means. One sec I will read about the amix in the docs. [21:05:36 CEST] <lindylex> kepstin interesting if I had three video overlayed and wanted to hear all three audio I would have to specify inputs=3 And it might look like this? -filter_complex '[0:v][1:v]overlay=x=40:y=40:eof_action=pass; [0:a][1:a][2:a]amix=inputs=3' [21:07:02 CEST] <kepstin> lindylex: well, you'd have to use another overlay filter to add the video on top, but that's what the amix would look like yes [21:07:55 CEST] <lindylex> Thanks for explaining. I have a better comprehension now. [22:20:59 CEST] <Purebe> Hello, it seems that it's possible to generate a url in libavformat, is it possible to convert something like this command into a libavformat scheme url? "ffplay -f dshow -video_size 1280x720 -pixel_format uyvy422 -rtbufsize 702000 -framerate 59.94 -i video="Decklink Video Capture"" [22:21:14 CEST] <Purebe> (I may have some fundamental misunderstandings here, but trying to figure it out, any advice would be appreciated) [22:27:21 CEST] <Purebe> Maybe a better question to ask would be if "dshow" is a lbavformat scheme/protocol, or if it falls under a different scheme/protocol? [22:28:38 CEST] <durandal_1707> no no and no [22:29:56 CEST] <Purebe> Ok, thanks, at least I know that is a deadend now [22:31:25 CEST] <Purebe> Is dshow a libavdevice? Or how would you check to see if it is? [22:32:14 CEST] <JEEB> ffmpeg -devices [22:32:15 CEST] <JEEB> IIRC? [22:32:38 CEST] <Purebe> Ah, that makes sense [23:43:14 CEST] <Threads> is it possible to turn the first few frames into B frames ? [23:43:18 CEST] <Threads> if so how [23:45:49 CEST] <BtbN> no [23:46:13 CEST] <BtbN> always starts at an I frame [23:59:32 CEST] <kepstin> well, in theory the first few frames in pts order could be encoded in b frames in e.g. h264, i think? (obviously the first frame in dts order will still be an i frame) [00:00:00 CEST] --- Thu Jul 13 2017

1 0

ffmpeg-devel.log.20170711
by burek 12 Jul '17

12 Jul '17

[00:28:09 CEST] <michaelni> durandal_1707, if you want distinct vlc for 0 occuring symbos they can be set to the lowest probability (1). If the vlc doesnt matter as they do not occur, then anything could be use das their lengt and bits [00:52:42 CEST] <cone-641> ffmpeg 03Rostislav Pehlivanov 07master:ba67c2349c15: opus_celt: move postfilter taps table to the shared opustab.c file [00:52:42 CEST] <cone-641> ffmpeg 03Rostislav Pehlivanov 07master:03d8fbc09cdb: opustab: comment ff_celt_tf_select [00:52:42 CEST] <cone-641> ffmpeg 03Rostislav Pehlivanov 07master:8041b2420f11: opusenc: don't set avctx->cutoff [00:52:42 CEST] <cone-641> ffmpeg 03Rostislav Pehlivanov 07master:e7d977b44619: opus_rc: fix encoder desyncs on very low bitrates [00:53:10 CEST] <atomnuker> this took nearly 30 seconds to push, something's up with the server [00:54:54 CEST] <iive> the videolan one? [00:55:07 CEST] <atomnuker> yep [00:56:04 CEST] <nevcairiel> even pulling is slow for me these days, been that way for a couple months now [08:50:28 CEST] <cone-176> ffmpeg 03Muhammad Faiz 07master:0780ad9c688c: avcodec/rdft: remove sintable [10:06:29 CEST] <scriptso> I was wondering if anyone would be able to help me understand these to Snippets... By no means do I hold or claim that I personally wrote the entirety of these scipts but bs but I did write the majority of one of them at least... You can tell by how ugly it is | ffstreaming screen script https://pastebin.com/URLcbBgn, ffstreamit https://pastebin.com/6mBVYK6u| [10:08:59 CEST] <scriptso> The idea here is that I want to be able to cast from a a boom 2 machine to a Windows machine... I did not use that client script on the Windows machine.... yeah..., for some reason I thought VLC would handle it?? I have gone over ffmpeg entire Docs but what I'm confused on is on the client side for Windows, exactly how do I go about setting the right settings?? I am very very new to ffmpeg [10:32:07 CEST] <scriptso> WOWOWOWWW! not all at the same time! [10:32:08 CEST] <scriptso> lol [10:35:10 CEST] <wm4> scriptso: wrong channel [10:35:27 CEST] <scriptso> ..... oh no imsosorry [10:35:28 CEST] <scriptso> wait [10:35:35 CEST] <scriptso> ohh durp [10:35:38 CEST] <scriptso> im sorry [10:36:34 CEST] <scriptso> this is for.... the actual dev cycle of the application? [10:36:42 CEST] <scriptso> im such a noob [13:05:48 CEST] <J_Darnley> kierank, atomnuker: I might have just had an epiphany [13:06:21 CEST] <J_Darnley> I think I see the deinterleave in encode_subband [13:10:51 CEST] <J_Darnley> Yes, in the original the subbands are read out of the whole plane transform with an offset from the start of the subband based on the slice position [13:14:19 CEST] <J_Darnley> Now comes the tricky part of re-engineering all that. [13:16:03 CEST] <kierank> good! [14:52:14 CEST] <J_Darnley> I hate these structures. Too much is precalculated or hidden away in them. [14:52:26 CEST] <J_Darnley> Subbands are based on the whole plane transform [14:52:41 CEST] <J_Darnley> the dimensions are too large [14:53:02 CEST] <J_Darnley> there are at 3 strides in use [14:53:07 CEST] <J_Darnley> *at least [14:54:22 CEST] <BBB> its usually for performance reasons [14:54:33 CEST] <BBB> so sadly, yes, readability and understandibility goes down as performance goes up [14:59:55 CEST] <J_Darnley> Do I really have to rewrite the quantisation as well? [15:02:12 CEST] <J_Darnley> Is there no part of this encoder that isn't tightly coupled to every other part? [15:03:01 CEST] <J_Darnley> The dwt is about the least coupled thing but even that takes a struct pointer [15:10:59 CEST] <J_Darnley> As a concete example: why does a SubBand need its own stride field. It is a "constant". It is the same as the Plane coefficient stride so just use that! [15:30:54 CEST] <J_Darnley> God fucking dammit! I can't abort a git stash pop [15:50:20 CEST] <BBB> now now now [15:52:47 CEST] <J_Darnley> Yeah, I shouldn't swear in public channels [15:53:58 CEST] <uau> what do you mean by "aborting" it? [15:54:13 CEST] <J_Darnley> Like marge --abort [15:54:19 CEST] <J_Darnley> cherry-pick --abort [15:54:22 CEST] <J_Darnley> rebase --abort [15:54:47 CEST] <iive> J_Darnley: don't worry, it's perfectly normal :) [16:05:44 CEST] <J_Darnley> atomnuker: In dirac are the chroma slices with yuv420p (or any other subsampling) smaller than the luma slices? [16:06:50 CEST] <atomnuker> yes [17:24:37 CEST] <kierank> J_Darnley: make: *** No rule to make target `libavcodec/x86/simple_idct.c', needed by `libavcodec/x86/simple_idct.o'. Stop. [17:24:40 CEST] <kierank> why do i get that [17:24:49 CEST] <nevcairiel> make clean [17:24:54 CEST] <kierank> I did [17:25:08 CEST] <kierank> let's try again [17:25:14 CEST] <nevcairiel> you get that because simple_idct.c doesnt exist anymore, its now simple_idct.asm =p [17:25:31 CEST] <nevcairiel> (at worst, make distclean) [17:45:48 CEST] <ubitux> kierank: rm libavcodec/x86/simple_idct.d [17:45:58 CEST] <kierank> builds after a make clean [17:45:58 CEST] <kierank> thanks [18:17:20 CEST] <durandal_1707> peloverde: i still get artifacts with that hunk applied [18:17:44 CEST] <peloverde> which stream? [18:18:20 CEST] <durandal_1707> aac_isobmff_i60.m4a [18:27:18 CEST] <cone-029> ffmpeg 03wm4 07master:02d248d5828d: videotoolbox: fix crash when decoding interlaced video with new API [18:27:57 CEST] <durandal_1707> golomb uses special bitreader, it have own header, how to convert it to optional cached variant? [18:50:13 CEST] <peloverde> durandal_1707: I hear it, probably another windowing issue, let me take a closer look [18:50:28 CEST] <tdjones> I'm getting this odd reverb with the vorbis encoder on short frames. I set the encoder to use all transient frames to exaggerate it: https://0x0.st/GSo.ogg . It's not evident to me why this would occur [18:54:02 CEST] <atomnuker> tdjones: seems its only on the left channel [18:57:08 CEST] <tdjones> atomnuker: I didn't even notice that, it's what I get for using crappy headphones [18:57:16 CEST] <tdjones> atomnuker: Thank you [19:24:54 CEST] <peloverde> durandal_1707: This should work better https://github.com/aconverse/FFmpeg/commits/aac960 [19:25:40 CEST] <peloverde> I wasn't turning off the default SBR parameters properly [21:03:40 CEST] <durandal_1707> some devs had serious lobotomy [21:26:19 CEST] <amey> Hello all developers. I am using ffmpeg API to build an audio fingerprinting system for GSoC. In first phase it requires pre-processing. I have used ffmpeg filters to resample the audio. It is running fine with some video but it is dumping some error with others. I think the problem is with some file format or codec. Apart from that also if you find any mistakes tell me. [21:26:19 CEST] <amey> Link to project repository: https://github.com/Amey-Jain/audiofingerprinting [21:26:19 CEST] <amey> Error output: https://pastebin.com/sBVz4ZXR [21:56:47 CEST] <J_Darnley> What value should an encoder return when the supplied options are wrong? AVERROR(EINVAL)? [21:57:08 CEST] <nevcairiel> EINVAL for configuration error, yes [21:57:25 CEST] <J_Darnley> I thought so. [21:57:34 CEST] <nevcairiel> AVERROR_INVALIDDATA for bitstream errors, although perhaps not applicable to encoders [21:57:48 CEST] <nevcairiel> (those two often get mixed up) [21:57:59 CEST] <J_Darnley> nah, this would be command line options for ffmpeg [21:59:23 CEST] <jamrial> J_Darnley: for invalid option instead of invalid argument for a valid option, there seems to be AVERROR_OPTION_NOT_FOUND [21:59:54 CEST] <nevcairiel> that would appear to only be needed in AVOption code [22:00:05 CEST] <wm4> (does anything really try to make sense out of these error codes) [22:00:19 CEST] <nevcairiel> they get converted to strings for CLI output sometimes [22:00:36 CEST] <wm4> yes, which is even more wronger and awkward [22:00:39 CEST] <nevcairiel> but sticking to some sense of convention is always a good thing [22:01:00 CEST] <nevcairiel> I just print their numeric values in my logs and then always wonder wtf this one is [22:01:25 CEST] <wm4> yeah, and I start trying to look up raw errno values on various platforms/OSes [22:01:33 CEST] <wm4> (on Linux they can be CPU dependent) [22:01:45 CEST] <J_Darnley> Does anyone really need anything more than a boolean? [22:01:49 CEST] <wm4> I always found it crazy that ffmpeg "wraps" errnos [22:02:28 CEST] <wm4> and that it tries to handle platforms that use negative errnos, which AFAIK don't really exist [22:02:29 CEST] <jamrial> INVALIDDATA, PATCHWELCOME and EOF are used everywhere and they are not wrapped errno values [22:02:53 CEST] <J_Darnley> No but then those are Invented Here codes [22:02:59 CEST] <jamrial> the others are much less common, like BUG, UNKNOWN and $moduletype_NOT_FOUND [22:04:10 CEST] <wm4> supposedly negative errnos can happen on BeOS? [22:04:24 CEST] <wm4> 8fa36ae09dddb1b639b4df5d505c0dbcf4e916e4 [22:04:44 CEST] <wm4> also calling "-ESOMETHING" over "AVERROR(ESOMETHING)" ugly [22:16:20 CEST] <rcombs> the worst thing is when people return -1 from a function that is expected to return an AVERROR [22:16:33 CEST] <rcombs> (-1 is AVERROR(EACCES)) [22:38:05 CEST] <cone-119> ffmpeg 03Rostislav Pehlivanov 07master:aef5f9ab05c3: mdct15: remove redundant scale argument to imdct_half [22:38:05 CEST] <cone-119> ffmpeg 03Rostislav Pehlivanov 07master:594cd1f38a7b: opus_celt: normalize using mdct scale [00:00:00 CEST] --- Wed Jul 12 2017

1 0

ffmpeg.log.20170711
by burek 12 Jul '17

12 Jul '17

[00:10:31 CEST] <kerio> furq: tgt is great yo [00:10:59 CEST] <furq> this is some kind of elaborate prank right [00:11:06 CEST] <kerio> it's top gear with money [00:11:07 CEST] <kerio> what's not to dislike [00:11:18 CEST] <kerio> :^) [00:11:22 CEST] <furq> 23:11:06 ( kerio) it's top gear with money [00:11:25 CEST] <furq> this is what's not to dislike [00:11:36 CEST] <furq> except with only one negative [00:47:40 CEST] <FurretUber> Hi, yesterday I have asked help regarding encoding video with 10-bit depth with libx264. It was told me I should build libx264 with 10-bit support enabled. I built it and tried to encode with it. Trying to use libx264rgb, it segfaults (I was warned it could have problems) [00:48:40 CEST] <FurretUber> Using libx264, I can make the videos with 10-bit, but then colors are lost even with -qp 0, as the color space of the resulting video is YUV [00:49:26 CEST] <FurretUber> Is it possible to make the color space of the output don't lose colors? [00:49:37 CEST] <FurretUber> If the input is RGB [01:14:43 CEST] <thebombzen> FurretUber: if you use yuv444p10le, there won't really be any loss [01:15:28 CEST] <thebombzen> it won't be bit-exact but it's not like yuv420p(10le)? which has chroma subsampling [01:16:32 CEST] <thebombzen> You shouldn't have any color loss issues with yuv444p10le [01:17:05 CEST] <thebombzen> Alternatively, ffv1 supports lossless rgb, but it's too slow for realtime [01:30:31 CEST] <iive> huffyuv is usually fast enough for real time. not sur if it supports 10bit [01:35:49 CEST] <FurretUber> From what I have tested, both ffv1 and huffyuv produces files significantly bigger, comparing to libx264 with -qp 0 [01:40:39 CEST] <The_8472> h.264 has an RGB 4:4:4 profile, but idk if x264 supports it [01:44:58 CEST] <The_8472> FurretUber, also, there's dirac which supports lossless compression and YCgCo which can be interconverted with RGB losslessly [01:49:40 CEST] <lmat> I see -c:v mentioned several times in examples (in man ffmpeg-all;), but what does it mean? [01:52:18 CEST] <lmat> found it! -c = -codec! [01:52:31 CEST] <lmat> (in the man page, it's -c[:... so searching wasn't helpful :-( [01:52:55 CEST] <kepstin> x264 does rgb 4:4:4 just fine in 8-bit, I guess it's only the 10bit that has issues? :/ [02:04:04 CEST] <FurretUber> With 8-bit, libx264rgb can be used correctly, with 10-bit libx264rgb segfaults [02:07:26 CEST] <FurretUber> With the command "ffmpeg -ss 00:00 -i lossless.avi -vframes 1 saida.bmp", will the bmp image be lossless? I'm thinking the problem may be somewhere else [02:07:50 CEST] <thebombzen> FurretUber: You should not care about the filesize of realtime encoding. [02:07:58 CEST] <thebombzen> If you are not encoding in realtime, just use ffv1 [02:08:34 CEST] <thebombzen> I'm not sure why you're insisting on using 10-bit encoding though [02:09:07 CEST] <thebombzen> also, yes, bmp images are lossless, but they're also uncompressed and you should avoid them [02:09:17 CEST] <FurretUber> It is just to test [02:09:22 CEST] <thebombzen> you also don't need -ss 00:00, which just means "seek to 0" [02:09:33 CEST] <FurretUber> I will extract the single frame [02:09:33 CEST] <thebombzen> which is silly, because that's where it starts. [02:09:48 CEST] <FurretUber> Produce a video with libx264, as I am doing [02:09:51 CEST] <thebombzen> FurretUber: what are you actually trying to do? [02:10:08 CEST] <FurretUber> And then I will extract the image from the video [02:10:20 CEST] <thebombzen> What are you actually trying to do though? [02:19:54 CEST] <FurretUber> I'm trying so badly to use libx264 because of the size of the resulting videos [02:20:15 CEST] <FurretUber> One minute with ffv1 has 625 MB [02:21:39 CEST] <FurretUber> One minute, under the same conditions, with libx264 using -qp 0 and yuv444p10le has 19 MB [02:22:20 CEST] <FurretUber> And I would like to ensure the libx264 with -qp 0 and yuv444p10le is lossless [02:27:01 CEST] <The_8472> is your input 10bit? [02:28:32 CEST] <The_8472> qp0 + yuv444p (i.e. 8bit) should already be lossless for 8bit inputs except for the yuv conversion. "With 8-bit, libx264rgb can be used correctly" ... so you could just use that [02:54:29 CEST] <iive> h264 lossless mode is using motion compensation, and this saves a lot of bits [03:01:48 CEST] <thebombzen> FurretUber: I said this before, upping to 10-bit doesn't give you an advantage for lossless content [03:01:59 CEST] <FurretUber> From what I have tested with still images, ffmpeg produces the video losslessly, so it is working correctly. However, the players I have installed are having problems. With ffplay, the quality loss is enormous (is there a option I should set?). With vlc, the resolution of the video is being changed, which causes quality loss. With kdenlive, setting the profile matching the video, it shows it losslessly. [03:02:35 CEST] <FurretUber> The good news is that ffmpeg works. The bad news is that, apparently, the players don't show the video correctly [03:04:55 CEST] <thebombzen> "with ffplay, the quality loss is enormous" wut [03:05:25 CEST] <thebombzen> FurretUber: either way, there's no advantage gained by upping 8-bit content to 10-bit before losslessly encoding. [03:06:05 CEST] <thebombzen> Upping 8 to 10 can be more efficient because it allows more room for low-bit quantization error [03:06:12 CEST] <thebombzen> but lossless content has no quantization error [03:23:39 CEST] <FurretUber> About ffplay, I don't understand why this happened. For example: there is a red bar on the image, with the color, in RGB, 255,0,0. Around it is white with RGB 255,255,255. It changes from one pixel to another with the original content, but with ffplay it appears with a transition: 255,0,0 then 233,11,9 then 232,9,8 then 188,28,25 then 255,226,232 [03:24:49 CEST] <FurretUber> Using compare (from ImageMagick), between 80% and 90% of that specific frame was changed [03:38:31 CEST] <PixelPerfect> c_14 curl didn't redirect me for whatever reason [04:10:27 CEST] <thebombzen> FurretUber: have you considered uploading an image to a screenshot [04:10:36 CEST] <thebombzen> rather than desribing RGB values in english text [04:10:58 CEST] <FurretUber> Yes, I have. However, aren't those services lossy? [04:11:14 CEST] <thebombzen> I don't even know what to say to that [04:12:04 CEST] <thebombzen> Image hosting sites support PNGs [04:15:55 CEST] <hiru> I'm using the -map option to import subs from an input source but the output source loses sub styling. why is this happening? [04:16:29 CEST] <FurretUber> Here they are. Source: https://i.imgur.com/qR2giJO.png , encoded with ffmpeg: https://i.imgur.com/X9VrFMv.png , ffplay https://i.imgur.com/35fxOVb.png , original and ffplay side by side https://i.imgur.com/j1FDkug.png [04:17:42 CEST] <thebombzen> I fail to see how "the quality loss is enormous" [04:18:02 CEST] <FurretUber> compare, from ImageMagick [04:19:36 CEST] <FurretUber> Should ffmpeg and ffplay show this difference? [04:22:05 CEST] <FurretUber> Using a command like " compare saida_original.bmp qR2giJO.png -highlight-color Green -lowlight-color Black compare_imgur.bmp " should make the different parts be green and the non-different parts black [04:22:31 CEST] <FurretUber> Comparing the original to the ffplay I have got this: https://i.imgur.com/X7hRDq5.png [04:22:52 CEST] <klaxa> hiru: it shouldn't lose styling, does it maybe just lose the font? [04:23:13 CEST] <hiru> it looks like it loses styling only if I convert the output file in webm [04:23:25 CEST] <hiru> if I copy the file using mkv it just uses same font style [04:23:26 CEST] <klaxa> webm has no styling subtitles afaik [04:24:35 CEST] <hiru> if I try to extract the .ass file and burn it via -vf it loses style too [04:24:56 CEST] <klaxa> huh [04:25:14 CEST] <klaxa> can you pass the .mkv as the subfile and try that? [04:25:37 CEST] <hiru> if I try that the -vf just fails saying there is no such file or directory [04:26:04 CEST] <hiru> in the past I solved the issue using cd and moving into the file path and using a filename without a folder structure [04:26:23 CEST] <hiru> but I can't to that since the source file comes from a samba path [04:26:42 CEST] <hiru> *do [04:27:11 CEST] <thebombzen> FurretUber: the number of pixels that are not bit-exact identical to the original is not a metric on quality difference [04:28:43 CEST] <hiru> the source path is something like this "\\PC\path\to\media\[TAG]File_Name\[TAG]File_Name_-_04_-_Title,_Title,_Title,_[TAG_Author_Name]_[207A3C74].mkv" [04:29:09 CEST] <hiru> maybe I have to escape special characters? dunno [04:32:05 CEST] <hiru> "All characters enclosed between '' are included literally in the parsed string". what does it mean? [04:33:35 CEST] <hiru> oh... maybe I found the problem [04:33:53 CEST] <hiru> ffmpeg removed all the \ from the file path [04:35:47 CEST] <hiru> it worked :O [04:36:04 CEST] <hiru> using \ before every other \ solved the issue [04:36:27 CEST] <hiru> I mean, escaping all the \ in the file path [04:37:32 CEST] <FurretUber> thebombzen: true. The way I wrote the compare command, even one value of RGB color in a pixel will be flagged as difference (example: 255,0,0 is different than 254,0,0). [04:39:05 CEST] <FurretUber> But the difference is noticeable, the ffplay "output" is visually lossy [04:39:45 CEST] <klaxa> hiru: welcome to escaping hell :P [04:40:07 CEST] <hiru> fortunately I only have to escape when using -vf [04:42:29 CEST] <hiru> ffmepg says "not usable fontconfig" but I have a fonts folder in the ffmpeg folder [04:42:35 CEST] <hiru> (using windows) [05:19:48 CEST] <FurretUber> I discovered why ffplay video is problematic. ffplay is not using yuv444p10le, it is converting the video to yuv420p. [06:31:40 CEST] <kepstin> FurretUber: probably a limitation of the sdl video renderer it uses, yeah. If you want a reference, mpv has a good renderer. [06:32:44 CEST] <Fig1024> just curious, what is the practical application of recording yuv444p10le? who actually needs that? [06:33:42 CEST] <atomnuker> low resolution recordings off of emulators [06:34:01 CEST] <atomnuker> you need to preserve chroma since subsampling at such resolution and source material is hell [06:34:22 CEST] <Fig1024> ok, but why 10 bit [06:34:31 CEST] <FurretUber> I have used mplayer with video driver gl, and it opened correctly [06:34:45 CEST] <atomnuker> to preserve gradients [06:35:24 CEST] <atomnuker> you're also converting from rgb which has a larger colorspace so 10 bits helps preserve colors too [06:35:49 CEST] <Fig1024> why not just record strait rgb 8 bit then [06:35:58 CEST] <atomnuker> doesn't compress well [06:36:09 CEST] <atomnuker> few formats support it [06:36:58 CEST] <Fig1024> I imagine 10 bit video is not popular either, since it wrecks havoc on pixel byte alignment [06:37:37 CEST] <kepstin> x264 can do rgb reasonably well, but player support is eh; although most players that can handle 4:4:4 10bit can probably do rgb. [06:38:15 CEST] <kepstin> Fig1024: when decoded it's stored as 16 bits per component, with padding. Alignment isn't really an issue. [06:38:29 CEST] <atomnuker> Fig1024: not really, its not packed [06:39:42 CEST] <Fig1024> so FFMPEG handles 10 bit video as 16 bit? [06:41:48 CEST] <atomnuker> everything does [06:42:22 CEST] <Fig1024> I'm actually interested in best way to record high quality video from computer desktop (like 3d game) which can be used for editing and conversion to high compression format. Should I look into 10 bit [06:43:09 CEST] <Fig1024> I checked DeckLink 4K Extreme capture/playback device and their 10 bit format used really weird pixel layout, here's no padding [06:43:35 CEST] <atomnuker> they use v210 [06:43:49 CEST] <kepstin> Fig1024: depends a lot on what you're trying to do. If you have lots of disk bandwidth, a fast lossless codec that can store the original rgb would be best. [06:43:57 CEST] <atomnuker> which has 2 bits of padding per uyvy chunk [06:44:48 CEST] <Fig1024> I'm curious what professional video editors prefer as source format for editing [06:46:49 CEST] <furq> well professional video editors aren't using rgb [06:47:56 CEST] <kerio> are 10 bits per channel enough to edit videos [06:48:05 CEST] <Fig1024> but in case source material comes from computer desktop capture, like 3d game [06:48:18 CEST] <furq> yeah that's rgb [06:48:31 CEST] <furq> that's my point, it's not really a good comparison [06:48:36 CEST] <Fig1024> so convert rgb to 10 bit YUV and record that way? [06:48:47 CEST] <furq> maybe [06:49:00 CEST] <kerio> if it's possible, store the source material losslessl [06:49:01 CEST] <furq> it's probably going to end up as 8-bit yuv anyway [06:49:03 CEST] <kerio> losslessly [06:49:08 CEST] <kerio> but it's probably not possible [06:49:17 CEST] <Fig1024> is there a name for this lossless format [06:49:30 CEST] <furq> if you want rgb support then ffv1 is a good choice [06:49:39 CEST] <furq> there are tons of lossless codecs though [06:49:44 CEST] <furq> it really depends what you need from it [06:49:46 CEST] <kerio> ffv1 is slow as ballz tho [06:49:49 CEST] <furq> it's not that slow [06:50:05 CEST] <furq> it is obviously much slower than ffvhuff, but that's because it's actually compressing the video [06:50:27 CEST] <Fig1024> is that part of ffmpeg [06:50:36 CEST] <furq> yes [06:51:06 CEST] <kerio> ffvhuff is a beautiful huffman encoder who don't need no interframe compression [06:51:25 CEST] <kerio> Fig1024: i'd save with ffvhuff which is pretty much free [06:51:32 CEST] <furq> Fig1024: http://vpaste.net/cScvh [06:51:41 CEST] <kerio> and then if possible compress with ffv1 or lossless libx264rgb [06:51:44 CEST] <furq> those are all the lossless video codecs supported by my ffmpeg [06:51:53 CEST] <kepstin> if you're doing something like an external capture card on a fast computer, you could even consider libx264rgb as a temp file format. [06:52:17 CEST] <kerio> ah yes i was assuming the recording pc was also responsible for generating the content [06:52:22 CEST] <kepstin> benefit over something like ffv1 is ... well, you'd have to test it [06:52:24 CEST] <kerio> if it's separate you can libx264rgb or ffv1 [06:52:31 CEST] <furq> ut video, ffvhuff and huffyuv are all very fast [06:52:42 CEST] <furq> ffv1 and x264rgb are slower but compress better [06:52:48 CEST] <kerio> isn't huffyuv just a slightly older version of ffvhuff [06:52:56 CEST] <furq> ffvhuff isn't really supported outside of ffmpeg [06:53:04 CEST] <furq> if you need premiere or whatever then ffvhuff is no good afaik [06:53:07 CEST] <furq> same with ffv1 sadly [06:53:25 CEST] <furq> ut is apparently a good choice if you need widespread support [06:54:19 CEST] <furq> Fig1024: it also depends on what you plan to do with these videos [06:54:34 CEST] <furq> there's no point using rgb or yuv444p10le for your intermediate format if they're going to end up on youtube [06:55:18 CEST] <furq> that's just a waste of space unless you're doing fancy video editing stuff that needs dynamic range headroom [06:55:29 CEST] <Fenrirthviti> furq: but the thousands of youtube guides that say to use RGB! [06:55:34 CEST] <furq> lol [06:55:42 CEST] <furq> that's true. no blog post about video has ever been wrong yet [06:55:44 CEST] <Fenrirthviti> Who will tell them!? [06:55:53 CEST] <furq> especially when ffmpeg is involved [06:56:06 CEST] <Fenrirthviti> "I upload utvideo directly to youtube because it's better quality that way." [06:56:07 CEST] <kerio> just upload your raw rgb video to youtube directly :-D [06:56:14 CEST] <Fenrirthviti> bam! [06:56:17 CEST] <furq> there's no reason not to do that other than bandwidth tbh [06:56:21 CEST] <furq> if i had 1G fibre then i would totally do that [06:56:23 CEST] <kerio> Fenrirthviti: youtube gon reencode [06:56:32 CEST] <Fenrirthviti> I'm well aware. [06:56:50 CEST] <Fenrirthviti> Just quoting some OBS users I've run into in the past :P [06:57:43 CEST] <Fenrirthviti> But recording to utvideo and uploading straight to youtube with no post is kinda stupid. [06:57:47 CEST] <kepstin> youtube is gonna re-encode... but they've gone over and re-done encodes of videos in new codecs in the past, and might again in the future. [06:58:12 CEST] <kepstin> so putting up the best quality you have bw for might eventually help out future generations? :/ [06:59:01 CEST] <furq> i don't know if they keep the source video if it's 400GB v410 [06:59:10 CEST] <furq> i can't say i've tried though [06:59:21 CEST] <Fenrirthviti> it is google, who knows [06:59:26 CEST] <furq> but it's one less step of generation loss [06:59:28 CEST] <Fenrirthviti> They do all sorts of strange shit. [06:59:33 CEST] <furq> so if you have the bandwidth then you might as well do that anyway [07:01:34 CEST] <Fig1024> how come all 3d graphics uses RGB instead of YUV? isn't YUV better in every way [07:02:36 CEST] <kepstin> monitors render rgb directly, so using rgb for the full path means fewer conversions needed. [07:04:20 CEST] <Fig1024> except now recording video is pretty common so there's double conversion. And if there's any video embedded in 3d output it's 4x conversion [07:04:22 CEST] <kepstin> yuv mostly exists because it can improve compression, since detail tends to be in the Y plane, the U/V can be subsampled, etc. [07:05:15 CEST] <Fig1024> having luma component actually makes a lot of 3d engine functions easier, since it's all about lighting and color blending [07:07:31 CEST] <kepstin> most operations will involve all the components anyways, and if you're working in rgb the calculations are nice because they're generally identical on all three components, so easy to compute in gpus. YUV you need to treat the Y separately from the UV typically. [07:08:54 CEST] <kepstin> (then you get fun semi-planar pixel formats like NV12 which are designed to be nicer for gpu/vector stuff) [07:11:35 CEST] <Fig1024> anyway, if I need pretty good high quality format for video editing, without going overboard with fancy stuff, I can just use h264 with I-frame only, right [07:12:10 CEST] <kepstin> unless you really need the ability to cut out individual frames without re-encoding, I frame only is kind of silly. [07:12:21 CEST] <kepstin> Just use a smallish gop so you get fast seeking. [07:15:07 CEST] <Fig1024> ok [09:21:22 CEST] <Raigin> Hay guys, I'm trying to setup a "stream controller" type box. Basically I have box that listens to a UDP Port and takes whatever is streamed to it and converts it to the appropriate formats and streams it to two more devices upstream. Right now I can only stream one thing to it so I have one box that runs a script and streams video based on a schedule and then I stop that script whenever we [09:21:22 CEST] <Raigin> need to "Go Live" from another box. I'm wondering if this can be done automatically because the way I'm stopping the script doesn't work all the time and causes all sorts of issues. [09:22:09 CEST] <Raigin> Anyone got any ideas of how to accomplish this just w/ the listener? Like if it detects packets from IP1 to drop all packets from IP2? [09:54:28 CEST] <kerio> what's ffmpeg-10bit [09:57:42 CEST] <kerio> also is it possible to pick a v4l2 device by serial or some other way [09:57:49 CEST] <kerio> instead of having to pick the correct video* device [10:20:14 CEST] <kerio> is there a way to add timestamps to rawvideo? [10:20:17 CEST] <kerio> as in [10:20:23 CEST] <kerio> i have the output from a program [10:20:31 CEST] <kerio> in raw video form [10:21:38 CEST] <kerio> the framerate is not necessarily stable [10:36:52 CEST] <scriptso> I was wondering if anyone would be able to help me understand these to Snippets... By no means do I hold or claim that I personally wrote the entirety of these scipts but bs but I did write the majority of one of them at least... You can tell by how ugly it is | ffstreaming screen script https://pastebin.com/URLcbBgn, ffstreamit https://pastebin.com/6mBVYK6u| [10:37:02 CEST] <scriptso> The idea here is that I want to be able to cast from a a boom 2 machine to a Windows machine... I did not use that client script on the Windows machine.... yeah..., for some reason I thought VLC would handle it?? I have gone over ffmpeg entire Docs but what I'm confused on is on the client side for Windows, exactly how do I go about setting the right settings?? I am very very new to ffmpeg [11:37:25 CEST] <jimgray> I would like to combine a set of images.jpg and an audio.mp3 to test.mp4. But the images diffs in resolution. The command I use is: [11:37:40 CEST] <jimgray> ffmpeg -framerate 29/201 -pattern_type glob -i '*.jpg' -i audio.mp3 -c:v libx264 -c:a copy -r 30 -pix_fmt yuv420p -shortest test.mp4 [11:38:15 CEST] <jimgray> But some images look ugly, losing original resolution. [11:38:23 CEST] <faLUCE> hello, does zerolatency have no B-frames? [11:40:02 CEST] <furq> faLUCE: http://vpaste.net/txsG2 [11:45:17 CEST] <faLUCE> thanks furq [12:08:39 CEST] <kerio> yo can mpv play two video tracks at the same time [12:09:40 CEST] <jer_> Hey guys, does anyone know of a way to remove the audio priming 'noise' when concating two mp4 files with aac audio? Between each file is a short audioglitch. [12:20:16 CEST] <BtbN> re-encode and use the concat filter [12:26:04 CEST] <jer_> re-encoding isnt really an option here im affraid. We are working with automated processes concatting thousands of videos in a short ammount of time, and re-encoding them all will increase our time/cost tremendously. I found a suggestion forcing the libfaac encoder would do the trick, but still need to test that. Any other tips are more than appreciated [12:26:53 CEST] <squ> re-encode just audio [12:29:36 CEST] <BtbN> if you're not re-encoding, forcing an encoder is pointless [12:29:39 CEST] <BtbN> also, faac is bad [12:30:08 CEST] <BtbN> And I don't think it's possible to avoid this without re-encoding. [12:30:27 CEST] <BtbN> The segments don't match, so the gap in audio becomes audible [12:31:17 CEST] <BtbN> You might be lucky if you trim off the last second of each segment, or even less [12:39:07 CEST] <jer_> hmm, quite right indeed :P Reencoding just audio could be the solution here. Time for some thourough testing. Thanks! [12:40:00 CEST] <BtbN> that'll be hard to do [12:40:20 CEST] <BtbN> if you use the concat filter, which is neccesary to fix this, everything has to be re-encoded [12:40:44 CEST] <BtbN> could split the files, re-encode the audio, and merge them again [14:08:27 CEST] <Nacht> Anyone know why this isnt working? I get a clip, but I'm not seeing any subs burned in: [14:08:27 CEST] <Nacht> ffmpeg -i movie.mp4 -i sub.ass -filter_complex "[0:v][1:s]overlay[v]" -map "[v]" -map 0:a -c:a copy out.mp4 [14:14:43 CEST] <Nacht> im using a filter_complex cause I want to burn in multiple subtitles at different heights/colors [14:28:46 CEST] <kepstin> Nacht: to burn in subs, you should use the 'subtitles' filter [14:30:17 CEST] <Nacht> Ah I see, the overlay only works if its a track in a VOD ? [14:31:49 CEST] <Nacht> Hmmm. I can't really set the heights of the subtitles with the subtitles filter [14:35:00 CEST] <BtbN> heights? [14:35:04 CEST] <BtbN> Do you mean fontsize? oO [14:38:28 CEST] <DHE> I'm surprised the overlay filter didn't just barf on startup for specifying a non-video input [14:57:46 CEST] <Nacht> I tried a few translation services and thought it would be handy having 3 diff language subtitles burned into the video at different heights so you see all languages at the same time. [14:58:06 CEST] <Nacht> Ill just add them as sub tracks and leave it at that [15:12:42 CEST] <BtbN> well, you could do that [15:12:53 CEST] <BtbN> but I'm not sure if 3 diffrent subtitles burned in is a good idea [15:14:56 CEST] <sgermain> Hi, I'm having a strange issue with ffmpeg and I'm not quite sure how to debug it. I'm using it to transcode audio from a live MPEG2 stream and, sometimes, the process just freezes. No error, no indication of what happened, it just freezes. Now, I have my suspicions that the source of the video might be at fault here but I need a way to ignore those errors and keep encoding [15:15:45 CEST] <sgermain> I did try to set -err_detect to ignore errors, but it doesn't seem to do anything [15:16:27 CEST] <sgermain> The source of the video is H264+AC3, sent by a Zenverge zn200 [15:51:05 CEST] <danieeel> anybody to help me out how to use ffmpeg to encapsulate a bitstream with metadata? (e.g. to supply raw frames, codec info, colorspae tags... and produce a .mov file) [16:12:24 CEST] <pgorley> hi, ffmpeg's configure is outputting "GNU assembler not found, install/update gas-preprocessor" even though gas-preprocessor.pl is in my PATH, what switch do i use to tell ffmpeg where the perl script is located? [16:13:26 CEST] <pgorley> ./configure --as=gas-preprocessor.pl doesn't print errors, but shouldn't that switch be used to specify the actual assembler (and not just the preprocessor)? [16:15:06 CEST] <iive> pgorley: this looks like the wrong program. [16:15:26 CEST] <iive> that switch is for the actual assembler [16:16:28 CEST] <iive> pgorley: are you compiling in msvc? [16:17:23 CEST] <pgorley> iive: no, on ubuntu, compiling for android [16:17:31 CEST] <iive> i'm wrong, the configure does check for gas-preprocessor.pl . [16:19:16 CEST] <pgorley> hence my confusion :/ [16:20:21 CEST] <iive> yeh... [16:20:33 CEST] <iive> no idea, somebody else around here should know. [16:21:11 CEST] <iive> you do have working `gas` as in gnu assembler [16:21:18 CEST] <pgorley> it checks for gas-preprocessor.pl in $as [16:21:24 CEST] <pgorley> yes, i have gas installed [16:21:42 CEST] <pfirsich> I am trying to convert the pixel format when piping out raw video, but it doesn't seem to work properly: https://pastebin.com/LdHPypyV [16:22:09 CEST] <pfirsich> I think I don't understand something fundamental [16:23:50 CEST] <furq> pfirsich: -pix_fmt, not -pixel_format [16:24:11 CEST] <pfirsich> damn. It said that was deprecated and I assumed it was just a replacement for clarification [16:26:53 CEST] <pfirsich> furq, that works. Thank you. But it says: "Option -pix_fmt is deprecated, use -pixel_format." [16:27:10 CEST] <furq> -pix_fmt is an ffmpeg output option [16:27:11 CEST] <pfirsich> and on that site: https://ffmpeg.org/ffmpeg.html it says nothing about deprecation. Is that error maybe not intentional? And if it is, it is most definitely confusing [16:27:16 CEST] <furq> presumably ffplay still takes -pixel_format [16:27:36 CEST] <furq> -pixel_format is an input option for some ffmpeg formats [16:27:52 CEST] <furq> it's not confusing at all and also i am lying [16:28:39 CEST] <pfirsich> you are right. it is a simple replacement for ffplay. [16:29:14 CEST] <pfirsich> so passing -pix_fmt for ffmpeg and -pixel_format for ffplay works too. [16:29:48 CEST] <pfirsich> I assume it is not a goal to have a unified interface? [16:29:59 CEST] <furq> -pixel_format is an input option for both [16:30:07 CEST] <pfirsich> ah, I see [16:30:17 CEST] <pfirsich> now I understand, thank you [16:30:18 CEST] <furq> if it's confusing then you can just use -vf format=rgb24 in ffmpeg [16:30:24 CEST] <furq> -pix_fmt is just an alias for that [16:31:37 CEST] <pfirsich> thanks a lot furq [16:32:16 CEST] <sgermain> Is there an advanced debugging mode for ffmpeg? Trying to figure out why my transcode freezes periodically [16:37:50 CEST] <pgorley> sgermain: configure using --enable-debug=[some high number], run ffmpeg with loglevel=debug (or trace, but it's noisy) and use gdb [16:39:49 CEST] <sgermain> Would that show errors coming from the source? Like I said earlier, I think that Zenverge encoder is sending out garbage that causes ffmpeg to freeze [16:40:32 CEST] <JEEB> yes, just debug log level should show various input demuxing/decoding errors [16:40:47 CEST] <sgermain> Cool! Thanks [16:40:52 CEST] <sgermain> I'll try that [16:40:52 CEST] <JEEB> (no need for re-building just for the logging part unless you somehow built without the logging enabled) [16:41:11 CEST] <sgermain> It's the default Ubuntu build [16:41:19 CEST] <pgorley> loggin's enabled [16:41:33 CEST] <sgermain> Excellent [16:41:41 CEST] <sgermain> Thanks guys! [16:53:23 CEST] <adhawkins> Hi all. Trying to convert a 4k video file using ffmpeg to change the frame rate to 24fps for a particular playout device. The conversion is failing. Log is here: [16:53:24 CEST] <adhawkins> http://paste.debian.net/975911/ [16:53:30 CEST] <adhawkins> Anyone suggest what I'm doing wrong? [17:00:57 CEST] <Nacht> Anyone got experiance with Chinese subtitles ? The characters look good in Notepad++ with UTF-8 encoding, but when I inject them in the MP4 I get nothing but squares [17:02:36 CEST] <sfan5> does it work in a different container? which media player are you using to verify? [17:02:44 CEST] <Nacht> VLC [17:03:06 CEST] <BtbN> Your player is probably lacking a font for them [17:03:23 CEST] <Nacht> Ah, thought I was getting nuts. Hadn't considered the player. Ill check that. Cheres [17:03:26 CEST] <Nacht> *Cheers [17:03:47 CEST] <BtbN> or something messed up the encoding [17:25:45 CEST] <carstoge> Hey guys, after a lengthy two-pass vp9 encode on a 2-hour h264 encoded video, I've noticed a dramatic loss in quality in the output, it's not watchable anymore. I used stock settings, like described in the wiki article 'VP9/Encode'. Any tips? [17:28:13 CEST] <carstoge> I've fiddled a bit with the options to get a more speedy encode with better visual quality output, but to no avail. [17:28:40 CEST] <carstoge> The file size is amazingly small, I can deal with it being bigger. [17:38:06 CEST] <furq> the stock settings are 200kbps [17:38:10 CEST] <furq> so it's no wonder it looks shit [17:38:26 CEST] <pgorley> so i found out the problem with my gas-preprocessor, we were downloading the html page instead of the perl script, whoops [17:38:40 CEST] <carstoge> furq: What bitrate do you recommend? [17:38:56 CEST] <furq> https://trac.ffmpeg.org/wiki/Encode/VP9#constantq [17:39:01 CEST] <furq> that's recommended [17:39:04 CEST] <carstoge> Thank you. [17:39:14 CEST] <furq> encode a short sample and pick a crf that suits you [17:39:29 CEST] <furq> https://trac.ffmpeg.org/wiki/Encode/VP9#speed [17:39:34 CEST] <furq> and read that if you want it to be faster [17:40:46 CEST] <carstoge> But can I use VBR, just with a higher targeted bitrate? [17:41:56 CEST] <kepstin> adhawkins: dunno if it's related, but you have to repeat the output options (codec, bitrate, etc.) for each output - your second output on that is using mpeg2video & mp2 audio since nothing's set. [17:42:08 CEST] <kepstin> but i don't know if that's the issue - does it work if you only use one output? [17:59:09 CEST] <lmat> ffmpeg -y -ss 0:20 -i dlittle7.avi -itsoffset 0:4.5 -i dlittle7-stalbans_b_mono.wav -map 1:0 -map 0:0 -c:v copy -c:a aac dlittle7-mixed.mp4 [17:59:20 CEST] <lmat> I'm taking audio from one file and putting it with the video of another file. [17:59:32 CEST] <lmat> My desire here is to make the audio only start 4.5 seconds into the vide. [18:00:02 CEST] <lmat> It's not working, though...The result seems to be that the first 4.5 seconds of the video is being truncated, and the audio is starting at the beginning. [18:00:29 CEST] <lmat> Basically, I *could* add 4.5 seconds of silence to the audio, but I would rather do this in ffmpeg. What am I doing incorrectly? [18:18:59 CEST] <Knorrie> I'm trying to concat a few MP4 files. http://paste.debian.net/plainh/b5a52d66 For some reason, it keeps exiting with "files: Operation not permitted", whatever I try. I have no idea what would not be permitted, it's just a text file with a few lines [18:43:50 CEST] <lmat> Very strange: ffmpeg -y -itsoffset 1:7 -i dlittle7.avi dlittle7-mixed.mp4 [18:44:15 CEST] <lmat> I would expect this command to delay the video and audio by one minute, seven seconds. What actually happens is ... strange. [18:45:06 CEST] <lmat> The audio starts right away, but the video is frozen on the first frame. About ten seconds in, the video goes very fast and catches up with the audio, then everything plays in sync. [18:45:15 CEST] <lmat> is -itsoffset experimental or something? [18:45:36 CEST] <lmat> Also, when I use ffplay to play the video, it starts at 67 seconds. [19:33:14 CEST] <kepstin> lmat: having the audio and video start at different times in files is ... problematic. [19:33:38 CEST] <kepstin> most players sync to audio, so they'll start the video at the point where the audio starts [19:34:15 CEST] <kepstin> so yeah, you'll probably have to add some silence to the start of the audio track (this is something you *can* do with ffmpeg, using a filter; requires re-encoding [19:34:17 CEST] <kepstin> ) [19:34:59 CEST] <kepstin> https://ffmpeg.org/ffmpeg-filters.html#adelay can do it, for example [19:38:41 CEST] <hiru> I was having a look at audio filters but how can I use decimal values? the command just fails if I try to do that https://stackoverflow.com/a/29222419 [19:41:52 CEST] <hiru> oh. I had to use a value in seconds converting minutes in seconds. nevermind [19:42:57 CEST] <agentsim> got a configure issue with I'm stumped on. I need to build a pretty minimal build of avformat/codec/util supporting only audio files and images (for embedded artwork) [19:43:19 CEST] <agentsim> it seems to work, but I cannot read PNG formatted embedded art [19:43:49 CEST] <agentsim> I've included png and apng whenever it is an option in muxers, demuxers, encoders, decoders, etc... but still no luck [19:43:55 CEST] <agentsim> any ideas what I might be missing? [19:44:13 CEST] <c_14> probably something id3 or mp3 or something? [19:45:15 CEST] <agentsim> my test file is an ALAC encoded M4A file, if i replace the artwork with a jpeg it can find it just fine [19:45:28 CEST] <agentsim> so I doubt it is id3/mp3 related [19:45:56 CEST] <c_14> what do you have enabled? output of ./configure ? (on a pastebin site) [19:55:04 CEST] <agentsim> https://pastebin.com/YFAuAynF [20:02:31 CEST] <c_14> you need zlib [20:03:14 CEST] <c_14> for png [20:03:24 CEST] <c_14> which you can notice since png isn't in the list of enabled decoders [20:04:05 CEST] <c_14> (I do wish configure would error out for tried to enable but couldn't for auto-detected things) [20:09:49 CEST] <BtbN> c_14, it does? [20:10:33 CEST] <c_14> not for the auto-detected things [20:10:36 CEST] <c_14> like sdl, zlib etc [20:10:41 CEST] <BtbN> yes, even for those [20:10:47 CEST] <c_14> it does? [20:10:49 CEST] <c_14> since when? [20:11:58 CEST] <BtbN> a while [20:12:06 CEST] <BtbN> No idea if it made it to a release yet [20:12:23 CEST] <agentsim> c_14: thanks, I'll give that a go [20:12:44 CEST] <c_14> BtbN: zlib is check_lib and check_lib doesn't use die? only require_ uses die [20:13:17 CEST] <BtbN> There is special logic to check for things that are user-request enabled but not enabled at the end of configure [20:13:31 CEST] <BtbN> And at least for --enable-sdl2, it works for me. [20:13:41 CEST] <BtbN> ERROR: sdl2 requested but not found [20:14:14 CEST] <BtbN> line 6531 in configure [20:15:10 CEST] <lmat> kepstin: Thanks! [20:18:13 CEST] <c_14> BtbN: then it might just be in the --enable-decoder that doesn't fail anymore [20:18:25 CEST] <BtbN> no [20:19:27 CEST] <c_14> Well he had --enable-decoder=png and it wasn't enabled and didn't fail (though I guess I don't know what version he's building) [20:22:54 CEST] <c_14> --enable-encoder=libx265 neither enables libx265 nor fails on my system [20:23:11 CEST] <agentsim> I'm building 3.3.2 tag [20:28:12 CEST] <lmat> kepstin: hmm, I'm a little clueless; how do I use adelay? (I should probably be asking: "how do I use filters?".) [20:28:23 CEST] <lmat> I have ffmpeg -y -ss 0:20 -i dlittle7.avi -adelay 14.5 -i dlittle7-stalbans_b_mono.wav -map 1:0 -map 0:0 -c:v copy -c:a... but that doesn't work [20:30:29 CEST] <kepstin> lmat: start by reading the filters overview at the top of the page I linked. Here you can use "-af adelay=14500" to add 14.5 seconds of delay to a mono audio track. Note that "-af" is an output option, so it goes after all the input files and before the output file. [20:30:54 CEST] <lmat> kepstin: is -filter adelay... different than -af adelay... ? [20:31:24 CEST] <kepstin> lmat: "-af" is an alias for "-filter:a" [20:32:16 CEST] <lmat> kepstin: awesome. [20:32:47 CEST] <lmat> Ah, it matches up perfectly. [20:33:41 CEST] <lmat> well...maybe 100 more milliseconds... [20:35:35 CEST] <agentsim> c_14: thanks, that did the trick :) [20:43:43 CEST] <c_14> BtbN: ./configure --disable-all --enable-ffmpeg --enable-avformat --enable-avcodec --enable-parser=png --enable-demuxer=apng --enable-decoder=png --enable-filters --enable-protocol=file --enable-decoder=apng --enable-demuxer=image2 --enable-demuxer=image2pipe --enable-demuxer=image_png_pipe --disable-zlib <- minimal example that doesn't fail and also doesn't enable the png decoder. Checked on master as of [20:43:45 CEST] <c_14> 02d248 [20:51:15 CEST] <lmat> kepstin: My command: ffmpeg -y -ss 0:20 -i dlittle7.avi -i dlittle7-stalbans_b_mono.wav -map 1:0 -map 0:0 -c:v copy -c:a aac -filter:a adelay=4100 -vf fade:in:0:30 -t 223 dlittle7-mixed.mp4 [20:51:32 CEST] <lmat> I would like to fade in (vide -vf toward the end), but I am -c:v copy. These are not compatible. [20:51:42 CEST] <lmat> I'm happy to get rid of copy, but I don't know with what to replace it. [20:52:12 CEST] <kepstin> with the name of the codec that you would like to use to re-encode the video. In this case, probably x264 [20:52:21 CEST] <kepstin> er, 'libx264' [20:53:02 CEST] <lmat> okay [20:53:47 CEST] <lmat> kepstin: I think I should have known that... [20:54:15 CEST] <lmat> Oh, I just realized that all my cores are busy with this operation and my cpu is running at > 4.5 ghz :-o [20:54:41 CEST] <lmat> yes, worked perfectly! [20:57:53 CEST] <lindylex> How do I set the overlayed video width and height to 100? This is what I tried ffmpeg -i m.mov -i o.mov -filter_complex 'overlay=x=440:y=400,overlay_w=100:overlay_h=100' -y my.mov [20:58:02 CEST] <lindylex> It does not work. [20:58:56 CEST] <lmat> lindylex: Which video are you wanting to overlay onto which? [20:59:32 CEST] <lindylex> o.mov will be the overlay video. I need to resize it to 100 x 100. [21:00:39 CEST] <lindylex> I think I could specify from reading the docs. This is what it says "overlay_w, w [21:00:39 CEST] <lindylex> overlay_h, h [21:00:39 CEST] <lindylex> The overlay input width and height. [21:00:39 CEST] <lindylex> " [21:00:41 CEST] <lmat> lindylex: ',' is used to add more filters. Perhaps change ',' to ':' ? [21:01:03 CEST] <lmat> lindylex: (I'm totally newb) [21:03:25 CEST] <lindylex> nevermind overlay_h and overlay_w store the width and height of the overlayed video. It is not for setting. I need to resize before I overlay. [22:26:40 CEST] <OldBrick> Hi All. I'm having a bit of trouble with ffmpeg. I'm using a small script to launch it and record a video stream. It works great from the command line, but fails when used from a timer. Linux box, and the error always is "could not find codec parameters". Anyone have some thoughts? [22:36:10 CEST] <JodaZ> OldBrick, you have to explicitly set the input codec now whereas before ffmpeg could propably guess it from the file extension [22:39:08 CEST] <OldBrick> I think I do, the whole command is "ffmpeg -t $RECORDTIME -i udp://@:5000?timeout=1500000 -c:v mpeg2video -pass 1 /home/av/bobdisk/$FILENAME &" [22:41:36 CEST] <JodaZ> so what is the input format? [22:41:48 CEST] <JodaZ> it has to come before the -i in the command [22:43:30 CEST] <OldBrick> Hmm. I don't want to transcode, just stream to disk. So the -c:v mpeg2video should go before -i. I'll try that. Wonder why it works from the bash prompt then. [22:50:49 CEST] <JodaZ> OldBrick, looking at it, it might be the extension on the output file missing too [22:50:52 CEST] <JodaZ> not sure [23:29:08 CEST] <kepstin> OldBrick: what exactly are your trying to do with that command? THere's some options there that don't really make sense... [23:30:25 CEST] <kepstin> OldBrick: first, what is $RECORDTIME - what's an example value, what's the intent of its use? [23:32:19 CEST] <kepstin> OldBrick: right now you're transcoding to mpeg2, you might want to consider using '-c:v copy' if you're just saving to disk. Also the '-pass' option only makes sense if you're going to do a 2-pass encode, which you can't do with a live source. Just remove that option. [23:33:30 CEST] <kepstin> I'm not sure what you mean by "when used from a timer" [23:35:40 CEST] <puppy431> Hello, under windows, is it possible to encode audio directly from a CD (-i Track0n.cda) ? [23:45:21 CEST] <OldBrick> JodaZ, kepstin, there was a lot of playing around to try to make it work, so not all are doing anything. I'm trying to record video from an hdhomerun tv tuner to a file. $RECORDTIME is set to 1 minute for test. [23:45:39 CEST] <OldBrick> The timer is just a systemd timer. [23:46:14 CEST] <kepstin> puppy431: maybe with a custom build that includes libcdio it could work, but e.g. the zeranoe builds don't have that. [23:47:26 CEST] <puppy431> kepstin, is it possible under linux, then? [23:48:05 CEST] <kepstin> puppy431: yes [23:49:09 CEST] <puppy431> and can you 'rip' all tracks at once? [23:49:21 CEST] Action: kepstin notes that libcdio isn't known as a particularly reliable cd ripper, so it's probably still better to use other tools like cdparanoia to rip cds before encoding. [23:49:55 CEST] Action: puppy431 thanks kepstin ;) [23:50:16 CEST] <kepstin> puppy431: you could rip all tracks at once - as a single long audio file, yes. [00:00:00 CEST] --- Wed Jul 12 2017

1 0

ffmpeg-devel.log.20170710
by burek 11 Jul '17

11 Jul '17

[00:08:44 CEST] <nevcairiel> kierank: it automatically unrefs the old buffer if this case happens, ie. basically you dont have to think you it, because its refcounted. [00:09:07 CEST] <kierank> I realise that now after reading buffer.c [00:09:36 CEST] <nevcairiel> thats what one might expect to happen as well, why would av_buffer_realloc require any other actions to be taken depending on what the buffer was before [00:50:49 CEST] <BBB> michaelni: Im not sure how that currently works w.r.t. frame threading? [00:51:14 CEST] <BBB> michaelni: I dont think were asking you to actually fix mpeg4-frame-mt (theres no issues anyway), more to figure out which fields to sync so the memcpy is unneeded [00:51:46 CEST] <BBB> the way I would do that is to copy all fields and remove them until frame-mt+fate breaks or tsan stops complaining [00:52:34 CEST] <BBB> michaelni: but I agree that it is likely boring :-/ [00:52:47 CEST] <BBB> michaelni: the rest of the tsan fixing was quite boring also [00:53:42 CEST] <durandal_1707> you must be superstar when everything is boring [01:04:20 CEST] <kierank> hmmm why my patch not appear [01:36:07 CEST] <jamrial> kierank: you could do the same with hevc close captions. the code there is more or less a copy paste of the h264 implementation [01:36:15 CEST] <kierank> I have no samples of those [01:36:20 CEST] <kierank> otherwise I could [01:36:22 CEST] <kierank> same with mpeg-2 field [01:36:40 CEST] <kierank> also like BBB i don't care about hevc :) [01:38:03 CEST] <JEEB> yea, I haven't seen any HEVC closed captions either :D [01:39:44 CEST] <JEEB> kierank: btw I guess pengvado's vbv.py is the best VBV/HRD verifier that there is in OSS? I was thinking of writing something if that was the case. [01:40:01 CEST] <kierank> yes afaik [01:40:06 CEST] <JEEB> k [01:40:15 CEST] <kierank> vbv.pl I think [01:40:19 CEST] <kierank> if only it was python :) [01:40:22 CEST] <JEEB> ugh, yes :) [01:40:32 CEST] <JEEB> the thing I was writing had a code name like that :P [01:40:49 CEST] <JEEB> although I think I'd have to go further for anything like UDP stream validation etc [01:40:57 CEST] <kierank> I think penvagdo's thing doesn't do the hrd weirdness [01:41:00 CEST] <JEEB> yea [01:41:02 CEST] <JEEB> it's very simple [01:41:22 CEST] <kierank> udp stream validation is a bit meh to be honest [01:41:26 CEST] <kierank> all the numbers are made up [01:41:30 CEST] <kierank> imo [01:41:38 CEST] <JEEB> well so far that's how it looks :P [01:42:06 CEST] <kierank> for me what matters is dts < pcr [01:48:46 CEST] <JEEB> but yea, I'm mostly interested because I'm getting kind of tired of some people telling me that my rate control is off according to something VeryExpensive (which most likely doesn't even read my HRD data if it says so). what I have atm utilizes something as simple as packets and the duration of them which is complete bullshit but does give me some values. for actual real stuff I'd have to do the [01:48:52 CEST] <JEEB> parsing of NAL units myself etc. [01:49:46 CEST] <kierank> JEEB: what analyser is this? [01:49:56 CEST] <kierank> pm me if need be [01:50:15 CEST] <JEEB> I haven't had the chance to see which it is [01:50:18 CEST] <kierank> lol [01:53:27 CEST] <JEEB> anyways, tomorrow^Wtoday's a new day so off to hit the sack for me o/ [01:54:28 CEST] <BBB> kierank: I can be made to care about hevc [01:55:05 CEST] <BBB> kierank: but my general opinion is that because the IP holders have been such enormous &^*%%#$@ about squeezing money out of it before its anything at all, Im not going to be any different [01:56:15 CEST] <BBB> durandal_1707: dont you find tsan-like bugs (or ub-like bugs, which tend to be similar) kinda boring? simd is fun, on the other hand [02:25:19 CEST] <cone-265> ffmpeg 03Wan-Teh Chang 07master:2f84f40d451c: avformat/avio: Remove no-op code in url_find_protocol(). [12:17:13 CEST] <cone-729> ffmpeg 03Paul B Mahol 07master:fa3fd7f5a003: avcodec/magicyuv: make RLE table reading match reference [12:17:14 CEST] <cone-729> ffmpeg 03Paul B Mahol 07master:0281d5ece640: avcodec/magicyuv: add 12 bit formats [13:10:50 CEST] <J_Darnley> atomnuker: if you are around I want to ask you more questions about vc2enc [13:11:46 CEST] <J_Darnley> I'll start with: where does the encoder move data out of the whole plane transform into slices. [13:12:14 CEST] <J_Darnley> I think that's where I need to look for more changes to make [13:25:50 CEST] <kierank> wm4: are you sure changing the src context is ok? [13:25:50 CEST] <kierank> 6:54 PM <"BBB> kierank: this isnt so much a convention but a necessity, because the previous thread expects the contents not to change under its feet while the current frame is decoding concurrently with the next frame [13:26:04 CEST] <wm4> kierank: no, but your patch changes it anyway? [13:26:18 CEST] <kierank> via the bufref mechanism which should be thread safe [13:26:27 CEST] <wm4> or did I read the patch wrongly [13:26:31 CEST] <wm4> let me check again [13:27:12 CEST] <wm4> + av_buffer_unref(&h1->sei.a53_caption.buf_ref); [13:27:16 CEST] <wm4> h1 is from src [13:27:48 CEST] <wm4> the AVBufferRef* itself is not thread-safe - it's just a normal, non-atomic pointer [13:28:10 CEST] <wm4> av_buffer_unref(x) is a helper for freeing the AVBufferRef and doing *x=NULL [13:28:44 CEST] <kierank> then I don't know how else to do it [13:29:02 CEST] <wm4> chances are, you don't actually want to clear the h1->sei.a53_caption.buf_ref? [13:29:06 CEST] <BBB> I dont think we should change anything in src that can change actual non-reference-count values [13:29:26 CEST] <BBB> what does the source do depending on buf_ref being NULL or not? [13:29:32 CEST] <kierank> wm4: iirc if you don't it reappears in a future thread [13:29:36 CEST] <kierank> because of context reuse perhaps [13:30:24 CEST] <kierank> BBB: if a frame is output it uses the data then unrefs, if no frame is output it needs to pass the buf_ref to the next field [13:30:32 CEST] <wm4> well the worker thread itself should probably clear it when a new frame is being decoded or so [13:30:51 CEST] <BBB> its an obvious race condition [13:30:53 CEST] <BBB> IMO [13:31:11 CEST] <BBB> imagine that thread 1 and 2 happen entirely serially [13:31:14 CEST] <BBB> (that can happen) [13:32:12 CEST] <kierank> serial is good, no? [13:32:52 CEST] <kierank> parallel is bad [13:33:03 CEST] <kierank> or maybe i misunderstand [13:36:48 CEST] <kierank> init_context might be the place to do it [13:40:54 CEST] <kierank> actually no i have to do it this way i think [13:41:10 CEST] Action: J_Darnley goes afk [14:01:15 CEST] Action: J_Darnley is back [14:02:02 CEST] <BBB> serial means one starts after the other finishes [14:02:07 CEST] <BBB> it means no parallelism/multithreading [14:04:10 CEST] <iive> can we get the captions before sending the field bitstream to a worker thread? [14:10:06 CEST] Action: kierank not sure what to do [14:12:38 CEST] <BBB> kierank: have a sample you can share? :) [14:21:33 CEST] <wm4> I mean the basic idea of that patch is probably right, just changing the src context is probably not great [14:23:46 CEST] <kierank> I can get rid of the unref but I get double free on exit [14:33:29 CEST] <J_Darnley> I hate this vc2 crap. Never ending nesting of pointers, buffers, strcutures. [14:35:24 CEST] <wm4> kierank: wut [14:45:42 CEST] <J_Darnley> kierank: Do you know why vc2enc allocates a buffer for the dwt of twice as many values as I thought necesary? [14:45:54 CEST] <kierank> 10-bit? [14:46:17 CEST] <J_Darnley> It already has a sizeof if that's what you mean [15:59:41 CEST] <wm4> nevcairiel: fine if I push that dxva2 patch I just sent to libav to ffmpeg master? [16:00:39 CEST] <nevcairiel> should be fine [16:04:39 CEST] <cone-729> ffmpeg 03wm4 07master:c64da19bbc1d: dxva: DXVA2_ModeHEVC_VLD_Main10 does not support Main [17:02:16 CEST] <atomnuker> J_Darnley: it looks up the start address of each slice, no copying involved [17:02:29 CEST] <atomnuker> it allocates 2x because of precision reasons IIRC [17:03:22 CEST] <J_Darnley> Okay, not copying... [17:04:15 CEST] <J_Darnley> I guess: where does it get the DC or LL coeffs for one slice out of the whole? [17:04:38 CEST] <J_Darnley> I can't see the deinterleave(?) for each slice [18:13:00 CEST] <atomnuker> J_Darnley: look at encode_subband [18:14:55 CEST] <J_Darnley> noted [18:23:00 CEST] <J_Darnley> Dammit. I can never remember the order of operations with a cast. [18:23:43 CEST] <J_Darnley> Is "(uint16_t*)a + b" the same as "((uint16_t)a*) + b" [18:26:22 CEST] <J_Darnley> Yes. There it is. Higher precedence [18:29:53 CEST] <iive> i had no idea the latter is valid C [18:30:40 CEST] <J_Darnley> It (probably) isn't I made a horrible typo [18:30:51 CEST] <peloverde> durandal_1707: Any chance we'll see the AAC-LC 960 patch hit the list soon? [18:31:23 CEST] <atomnuker> I always go for ((uint16_t *)a) + b [18:32:37 CEST] <iive> btw, I think i had some fun lately with (float*)y[i] lately :D [18:32:37 CEST] <durandal_1707> peloverde: dunno, its incomplete [18:33:24 CEST] <peloverde> It seems pretty complete for LC (just have it turn off SBR). What's still missing? [18:33:28 CEST] <J_Darnley> Now there's another I'd have to lookup [18:46:08 CEST] <kierank> wm4: how much do you know about ac3 in hdmi? [18:46:15 CEST] <kierank> is it just spdif mapping? [18:47:05 CEST] <JEEB> seems like it? just with more bandwidth. although I haven't dealt with the HW side [18:47:14 CEST] <JEEB> a lot of stuff seems to use the same APIs [18:47:29 CEST] <wm4> yes, just put it into a spdif frame [18:47:38 CEST] <wm4> which I think is defined by IEC 61937? [18:47:45 CEST] <wm4> and libavformat/spdifenc implements it [18:47:52 CEST] <wm4> (extremely awkward API, but works) [18:49:11 CEST] <nevcairiel> 61937 is correct, it just extended the formats supported for HDMI, but same packing as SPDIF [18:52:37 CEST] <nevcairiel> and i use spdifenc as well, works fine [18:52:57 CEST] <nevcairiel> its a bit tedious since i dont want it to write to a file, but shrug [18:53:07 CEST] <kierank> there's no special signalling to signal compressed data? [18:53:10 CEST] <kierank> or is that ignored in practice? [18:53:35 CEST] <nevcairiel> there is, whatever audio api you use would have to implement that [18:53:39 CEST] <wm4> there is signaling, but often enough it's indeed ignored or briken [18:53:46 CEST] <wm4> broken even [18:53:50 CEST] <JEEB> them headers, right? [18:53:57 CEST] <nevcairiel> for HD formats it seems to work [18:54:11 CEST] <kierank> JEEB: there's also sometimes a flag that goes with the headers [18:54:19 CEST] <kierank> but in aes3 (pro spdif) it doesn't seem to matter if they are there [18:54:20 CEST] <nevcairiel> for the spdif-comptible formats .. you can claim its ac3 and send dts and it still works [18:54:25 CEST] <kierank> ok [18:54:29 CEST] <JEEB> hah [18:56:03 CEST] <wm4> on some OSX you sometimes have to send ac3 data as floats (doing the proper int->float conversion) to get passthrough [18:56:11 CEST] <wm4> broken shitty consumer garbage [18:56:41 CEST] <nevcairiel> osx is generally terrible, they only implemented int audio as an addon later [18:56:48 CEST] <nevcairiel> and then called it a feature [18:57:38 CEST] Action: J_Darnley goes afk [18:58:05 CEST] <wm4> I should try whether passthrough of "HD" formats is possible yet, somehow [19:04:29 CEST] <peloverde> Is the info that used to be in config.log kept around somewhere? [19:07:07 CEST] <JEEB> it's in a subdirectory now [19:09:03 CEST] <peloverde> JEEB: thanks [19:34:03 CEST] <peloverde> durandal_1707: This hunk should conceal up the HE-AAC artifacts https://pastebin.com/de2HxZWt [21:03:27 CEST] <cone-729> ffmpeg 03Derek Buitenhuis 07master:5ca063799c16: rtspdec: Fix return error [21:11:17 CEST] <kierank> BBB: had any time to look at my sample? [21:11:28 CEST] <BBB> not that quickly yet, sorry :( [21:11:31 CEST] <BBB> hopefully later this week [21:11:35 CEST] <kierank> still not sure how to fix it without modifying source thread [21:11:36 CEST] <kierank> ok [21:11:45 CEST] <kierank> might send end user a temporary fix of setting threads=1 [21:14:30 CEST] <BBB> does the source thread know anything in advance about passing the data to the second thread? [21:14:49 CEST] <BBB> who adds the side data to the avframe? thread 1 or 2? [21:15:11 CEST] <BBB> (first or second in order of field decoding in terms of incoming data, no in terms of field order) [21:15:21 CEST] <BBB> s/no/not/ [21:31:01 CEST] <kierank> field 2 [21:31:15 CEST] <kierank> i.e the thread that actually outputs an AVFrame [21:49:26 CEST] <J_Darnley> atomnuker: what? encode_subband appears to encode in a linear manner. [21:49:35 CEST] <J_Darnley> for y; for x; coeff[x] ... [21:51:28 CEST] <J_Darnley> 1000gg [21:52:21 CEST] <J_Darnley> whoops, wrong keyboard [21:54:12 CEST] Action: J_Darnley curses how he got roped into looking after a cat and a rabbit [22:03:26 CEST] <Compn> just put them in same room and then you'll only have to deal with the cat [22:53:01 CEST] <durandal_1707> michaelni: do you know how to modify mjpeg bits generation so it creates lengths for 0 probable symbols? [00:00:00 CEST] --- Tue Jul 11 2017

1 0

ffmpeg.log.20170710
by burek 11 Jul '17

11 Jul '17

[00:00:26 CEST] <Ingersol> i reading documentaztion [00:00:34 CEST] <Ingersol> but even last examples uses old version [00:00:44 CEST] <Ingersol> so its why i asking about _right_ example [00:20:08 CEST] <Ingersol> some examples uses fread some uses av_read_frame() [00:20:29 CEST] <Ingersol> both of them uses codecpar structure so i think they all uses latest ffmpeg [00:42:49 CEST] <thebombzen> CoJaBo: you'll run into issues with Generation Loss [00:45:52 CEST] <nicolas17> Ingersol: you can just give ffmpeg a filename/URL and let it read from the file [00:46:59 CEST] <nicolas17> Ingersol: you give avformat a filename, then read packets from it with av_read_frame, then send those packets to avcodec, then read decoded frames from avcodec [01:01:24 CEST] <Ingersol> so av_read_frame is the right way? thanx [01:01:40 CEST] <CoJaBo> thebombzen: Most of the files have been reencoded 18+ times already. One more can't hurt that much :P [01:01:52 CEST] <JEEB> isn't that visible in the demuxing example under docs? [01:01:57 CEST] <JEEB> @ av_read_frame [01:02:35 CEST] <JEEB> I'd be surprised if a demuxing example would be using fread :) [01:02:45 CEST] <JEEB> you can create your own custom AVIO wrapper though [01:03:23 CEST] <JEEB> like this IStream thing I created for windows, which defines the read and seek callbacks https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper… [01:03:37 CEST] <JEEB> (and then you can register them into your AVIOContext [01:03:39 CEST] <thebombzen> CoJaBo: at crf 50? yes it can, unless you want to look at something that is not a smudge [01:04:17 CEST] <nicolas17> JEEB: is stuff like directory listing for wildcards in image2 also abstracted into avio? [01:04:56 CEST] <JEEB> no idea, to be honest [01:05:27 CEST] <nicolas17> -pattern_type glob -f image2 -i "custom:foo/bar/*.jpg" [01:06:26 CEST] <JEEB> I know that the thing is a custom thing on top of something but not sure if it's AVIO [01:06:38 CEST] <CoJaBo> thebombzen: I'm trying to figure out a sane way to guess at a reasonable CRF; 50 is fine for files that look like barf smeared on a tan background, which is something like half of all the files I need to convert.. The decent ones, still trying to fine-tune it, but looks like I can get away with 40 for mid quality and 31 for the better ones. [01:06:40 CEST] <JEEB> AVIO is the basic I/O framework, though [01:06:54 CEST] <nicolas17> damn ffmpeg compiles fast [01:07:02 CEST] <nicolas17> I'm used to large C++ codebases x_x [01:07:17 CEST] <thebombzen> CoJaBo: why do you care about files that look like barf smeared on a tan background? why are you doing this? [01:09:05 CEST] <CoJaBo> thebombzen: It's user-uploaded content; I'd just rm -rf *, but the reason I'm being tasked to do this in the first place is exactly because the barf-iest files are the popular ones. [01:09:19 CEST] <nicolas17> o_o [01:11:40 CEST] <CoJaBo> nicolas17: Fun Fact: It is possible to encode HD 1080p, and even 4K video, as MPEG-1. [01:11:53 CEST] <CoJaBo> I did not know that before today. [01:12:02 CEST] <nicolas17> sure why not [01:12:09 CEST] <nicolas17> you just need a ton of bitrate to get decent quality [01:12:14 CEST] <nicolas17> compared to more modern codecs [01:15:18 CEST] <CoJaBo> nicolas17: But you don't! Incidentally, that happens to be why they all look like vomit slowly dispersing across the surface of a placid lake. [01:15:49 CEST] <nicolas17> that doesn't sound like decent quality [01:16:42 CEST] <CoJaBo> And yet, 28,687 downloads in the past month. [01:17:28 CEST] <CoJaBo> If nothing else, users will be waiting substantially less time for their doses of dissappointment. [01:38:58 CEST] <CoJaBo> nicolas17: (and about half of the files *aren't* completely hopeless, but I still need to reencode those to support the new web player) [03:17:30 CEST] <kusfedora> this might be off topic but is it normal for ffmpeg conversion from mkv to mp4 to nail my processor this hard? all i want to do is add a few youtube videos to a laptop for the baby to watch on a flight >_> https://i.imgur.com/ds9OVuu.png [03:18:21 CEST] <kusfedora> I am on 3.1.9 btw [03:19:18 CEST] <furq> yes [03:19:42 CEST] <furq> although i don't see why you'd need to convert video for a laptop [03:19:50 CEST] <c_14> If it's h264 add -c:v copy? [03:19:56 CEST] <kusfedora> aah I meant iPad sorry [03:20:02 CEST] <furq> right [03:20:07 CEST] <furq> then yeah you can probably just copy the video stream [03:20:26 CEST] <c_14> (and if the audio is aac or mp3 copy that too) [03:20:29 CEST] <furq> ^ [03:20:47 CEST] <kusfedora> ah is that a different command than ffmpeg source.mkv destination.mp4? [03:21:04 CEST] <furq> ffmpeg -i foo.mkv -c copy dest.mp4 [03:24:39 CEST] <kusfedora> furq I get Could not find tag for codec opus in stream #1, codec not currently supported in container [03:24:48 CEST] <furq> -c:v copy then [03:26:00 CEST] <kusfedora> thank you speed is 13x! [03:26:19 CEST] <kusfedora> as opposed to .8x :D [04:42:58 CEST] <nicolas17> okay, I found a fundamental difference between my code and ffmpeg.c + examples/muxing.c [04:43:52 CEST] <nicolas17> I'm setting parameters on st->codecpar, then creating a codec context and copying the parameters to it with avcodec_parameters_to_context(codecCtx, st->codecpar) [04:44:35 CEST] <nicolas17> the examples set parameters on the codec context, then copy the parameters to the stream with avcodec_parameters_from_context(st->codecpar, codecCtx) [04:54:29 CEST] <nicolas17> what's more! [04:54:38 CEST] <nicolas17> the examples set parameters on the codec context, *open it*, then copy the parameters to the stream with avcodec_parameters_from_context(st->codecpar, codecCtx) [06:04:57 CEST] <Trundler> howdy, getting ERROR: x265 not found using pkg-config when i'm trying to configure [06:05:52 CEST] <Trundler> I was reading through some mailing lists and forum posts about this issue where ffmpeg is throwing "ffmpeg: error while loading shared libraries: libx265.so.95: cannot open shared object file: No such file or directory [06:05:52 CEST] <Trundler> " [06:06:44 CEST] <Trundler> installing ffmpeg through the package manager gives you libx265.so.116 and libx265.so.102 but not .95 as required [06:07:03 CEST] <Trundler> i tried manually compiling x265-95 with no luck [07:06:55 CEST] <Trundler> i fixed it [07:23:53 CEST] <lilibox> hi, please, how to convert PAL DV input file to h264 with fixing interlace? pretty thank you [07:24:53 CEST] <furq> that's a pretty open-ended question [07:25:18 CEST] <furq> the most basic answer would be ffmpeg -i foo.dv -vf yadif=1 bar.mp4 [07:26:53 CEST] <lilibox> furq thank you for auick reply, so, such switches like -c:v libx264 i do not need use? extension .mp4 at end of line will cause ffmpeg will use correct codec etc? [07:27:16 CEST] <furq> right [07:27:27 CEST] <nicolas17> huh really? [07:27:28 CEST] <furq> mp4 defaults to h264 and aac [07:27:59 CEST] <furq> http://vpaste.net/GQfrn [07:28:17 CEST] <nicolas17> that's good, I thought mp4 defaulted to mpeg4 part 2 video [07:28:35 CEST] <furq> i think it'll fall back to that if you don't have an h264 encoder [07:28:46 CEST] <furq> a few other containers do default to mpeg4 [07:28:59 CEST] <lilibox> ok, thank you, and second question is far different [07:31:31 CEST] <lilibox> I have got sequention of .dpx files (usualy 10 or 12bits) and some .wav and i need merge them to prores which should be broadcasted in TV, usualy EU regions, do i need make special color correction (LUT), frame rate etc? again, does exist any recommended settings? [08:33:16 CEST] <nicolas17> I can't believe it, I finally got it [08:33:33 CEST] <nicolas17> my program is producing an .mp4 that is bitwise identical to what ffmpeg.c produces :O [08:34:27 CEST] <furq> what was the problem [08:34:57 CEST] <nicolas17> oh a ton of things, but it's like I finally fixed them all [08:35:03 CEST] <nicolas17> one was [08:35:30 CEST] <nicolas17> <nicolas17> I'm setting parameters on st->codecpar, then creating a codec context and copying the parameters to it with avcodec_parameters_to_context(codecCtx, st->codecpar) [08:35:32 CEST] <nicolas17> <nicolas17> the examples set parameters on the codec context, open it, then copy the parameters to the stream with avcodec_parameters_from_context(st->codecpar, codecCtx) [08:36:55 CEST] <nicolas17> I'm sure that affected a bunch of defaults that come from the codec context and I wasn't copying to the stream codecpar [08:37:37 CEST] <nicolas17> for the extradata format, I was missing this snippet: [08:37:40 CEST] <nicolas17> if (outputFormatContext->oformat->flags & AVFMT_GLOBALHEADER) outCodecCtx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER; [08:38:24 CEST] <nicolas17> and by the way, if I set AV_CODEC_FLAG_GLOBAL_HEADER like that but I kept the wrong way to handle codecpar, the output file wasn't even playable [08:39:09 CEST] <nicolas17> I think it's because the encoder stopped putting that info on the stream, but the muxer didn't know it had to put it in the headers :P [08:43:04 CEST] <nicolas17> the only remaining detail is that I need to set st->codec->time_base (despite it being deprecated), otherwise the bitrate ends up slightly different and ffprobe's guessed average fps is 30.30 instead of 30 [08:52:00 CEST] <lilibox> furq could you help me also with my second question please? [08:52:25 CEST] <furq> i've never touched dpx, prores or done any broadcast stuff [08:52:51 CEST] <nicolas17> I had never heard of dpx [08:53:44 CEST] <lilibox> https://en.wikipedia.org/wiki/Digital_Picture_Exchange [08:54:01 CEST] <furq> i assume it needs to be 25p or 50i, and you can look at the colorspace or zscale filters for colour correction [08:55:20 CEST] <furq> if your dpx is yuv422p10le then i guess you don't need to do anything [08:55:35 CEST] <furq> but it's not something i've ever looked into [08:56:28 CEST] <furq> oh nvm it's rgb only [08:56:37 CEST] <furq> !filter zscale @lilibox [08:56:37 CEST] <nfobot> lilibox: http://ffmpeg.org/ffmpeg-filters.html#zscale [08:56:44 CEST] <furq> you probably want to take a look at that [08:57:33 CEST] <lilibox> nfobot: ok, thanks [10:36:45 CEST] <break_da_funk_> hi! is ffmpeg support full g729 codec? [10:38:10 CEST] <furq> it has a decoder but not an encoder [10:38:38 CEST] <break_da_funk_> the codec is now free [10:38:52 CEST] <break_da_funk_> is ffmpeg team going to develop encoder ? [10:43:21 CEST] <thebombzen> break_da_funk_: probably not [10:44:37 CEST] <thebombzen> Not sure there's much reason to use G.729 over Opus nowadays [10:45:22 CEST] <break_da_funk_> many devices uses g729 [10:45:41 CEST] <break_da_funk_> anyway is there any "place" where I can put an request? [10:46:03 CEST] <break_da_funk_> request for new feature (g729 encode) in ffmpeg? [10:47:52 CEST] <thebombzen> you can put one on the trac, but it'll probably be ignored tbh [10:48:06 CEST] <break_da_funk_> thank You for the answer [10:48:07 CEST] <thebombzen> the trac isn't used much, even for defects, so wishes probably won't be looked at [10:48:57 CEST] <thebombzen> You can ask on the mailing list if you want a more complete answer than "probably not tbh" [10:49:05 CEST] <thebombzen> about any sort of plans I mean [11:01:30 CEST] <faLUCE> Hello. If I use "fastdecode" for h264, does it override zerolatency ? [11:01:55 CEST] <JEEB> no, also I'm pretty sure the fastsdecode mode no longer does things with a lot of formats [11:01:59 CEST] <JEEB> oh wait, encoder setting [11:02:05 CEST] <JEEB> both are tunes right? [11:02:09 CEST] <JEEB> if so, yes [11:02:13 CEST] <JEEB> you can only have one tune set [11:02:13 CEST] <faLUCE> JEEB: yes, encoder [11:02:22 CEST] <faLUCE> I see, thanks [11:02:37 CEST] <JEEB> fastdecode's parameters are rather simple, though [11:02:42 CEST] <JEEB> stuff like CABAC=>CAVLC [11:03:02 CEST] <JEEB> setting the baseline profile should provide you with quite similar stuff [11:03:09 CEST] <JEEB> since baseline profile requires CAVLC [11:03:17 CEST] <faLUCE> I see [11:03:17 CEST] <furq> you can have multiple tunes set with the x264 cli [11:03:23 CEST] <furq> just not multiple psy tunes [11:03:23 CEST] <JEEB> hmm [11:03:29 CEST] <JEEB> then I remembered incorrectly [11:03:30 CEST] <JEEB> :D [11:03:40 CEST] <JEEB> and if the cli can do it then the libx264 API can do it as well [11:03:51 CEST] <faLUCE> furq: so I can set both fastdecode and zerolatency at the same time? [11:04:16 CEST] <furq> yeah but there's no point [11:04:27 CEST] <faLUCE> furq: why? [11:04:29 CEST] <furq> preset ultrafast enables all the options in tune fastdecode [11:04:43 CEST] <faLUCE> ok, I see [11:05:01 CEST] <furq> you can do -tune fastdecode,zerolatency in the x264 cli [11:05:02 CEST] <furq> not sure about ffmpeg [11:05:16 CEST] <furq> but yeah if you're using ultrafast then you don't need to [11:05:32 CEST] <furq> and it seems like you might as well be using it in this scenario [11:05:57 CEST] <faLUCE> furq: yes, I use ultrafast :-) [11:09:24 CEST] <kerio> just go audio only at thay point, man [11:09:31 CEST] <kerio> that [11:20:21 CEST] <thebombzen> JEEB: you can use -tune:v fastdecode and -tune:v zerolatency [11:20:26 CEST] <thebombzen> they don't override each other, afaik [11:20:51 CEST] <thebombzen> those two are exceptions to the "single" tune rule b/c they're not psy tunings [11:21:19 CEST] <thebombzen> although ultrafast *shudders* [11:22:24 CEST] <furq> is there an echo in here [11:22:57 CEST] <kerio> is there an echo in here [11:24:00 CEST] <thebombzen> is there an echo in here [11:24:26 CEST] <BtbN> of course the same parameter twice overrides the other [11:24:46 CEST] <thebombzen> well, then I'm just wrong about that :P [11:25:10 CEST] <BtbN> That's just how ffmpeg cli works. The right-most one wins [11:25:38 CEST] <BtbN> no idea if you can combine x264 tunes somehow [11:25:50 CEST] <thebombzen> probably -x264-params or something [11:26:12 CEST] <JEEB> -x264-params lets you pass key=value pairs to libx264 straight, yes [11:34:14 CEST] <furq> -tune zerolatency,fastdecode appears to work [11:35:11 CEST] <furq> update: it definitely works [11:37:52 CEST] <JEEB> gotcha [11:58:33 CEST] <Fig1024> I'm trying to implement rtsp streaming client with FFMPEG C++ API. How can I check connection status using API? [12:26:11 CEST] <Fig1024> I can't find any list of streaming specific functions in FFMPEG API. Seems like streaming is done same way as writing file using URL for output. But then there's no way to check connection. If server is not running, encoder simply blocks on 'avformat_write_header' - there's not even a timeout! [12:56:24 CEST] <DHE> Fig1024: there are usually options you can pass in an AVDictionary and get timeouts. most ffmpeg command-line parameters -- especially format/protocol specifics -- are usable in an AVDictionary [12:58:48 CEST] <Fig1024> does ffmpeg use librtmp for streaming [13:00:52 CEST] <furq> it does if you built with librtmp [13:01:03 CEST] <furq> it has internal rtmp support now which might be better [13:07:05 CEST] <Fig1024> I want to find more API functions for controlling that part. I don't think AVDictionary options would be sufficient. I need basic things like checking connection status, network specific errors when something's wrong [14:11:53 CEST] <DHE> Fig1024: ffmpeg -h muxer=rtsp # and see what options are available [14:12:19 CEST] <DHE> while you can't directly monitor/manage the session, you may be able to set error thresholds [14:16:34 CEST] <Fig1024> thanks [16:35:09 CEST] <lilibox> c/win 15 [16:35:16 CEST] <lilibox> sorry [19:36:40 CEST] <PixelPerfect> I just want to put it out there that https://trac.ffmpeg.org/wiki/CompilationGuide/Centos is outdated [19:37:07 CEST] <PixelPerfect> The download links for libogg and libvorbis are plain wrong [19:38:09 CEST] <PixelPerfect> They've moved to https://ftp.osuosl.org/pub/xiph/releases/ogg/ and https://ftp.osuosl.org/pub/xiph/releases/vorbis/ [19:39:06 CEST] <PixelPerfect> Also, in the centos docker container at least, xmlto and file are both missing dependencies [19:59:25 CEST] <lindylex> I made a python project to edit video, photo and audio using various system calls mostly to FFmpeg. https://github.com/MotionDesignStudio/commandlinemediahelper Hope it is useful to someone. [20:05:45 CEST] <Hopper_> lindylex: What is it capable of? [20:07:12 CEST] <lindylex> Hopper_ : the following https://github.com/MotionDesignStudio/commandlinemediahelper/blob/master/RE… [20:10:05 CEST] <Hopper_> Neat! [20:11:55 CEST] <Hopper_> Question to all, I'm currently looking to transmit a .ts file ATO as it is being created, I'm currently using a UT-100 modulator. My issue is all the programs I've found that push .ts files to my modulator will not send a file as it is being generated. Any ideas? [20:13:18 CEST] <c_14> PixelPerfect: as long as the download links at xiph.org still point to the old links I'd keep them as they are. (they do 301 redirect to the other links). But if you want to change them, create an account on trac and edit the page [20:13:52 CEST] <kepstin> Hopper_: you probably want to do something like have ffmpeg write to a pipe rather than (or in addition to) a file [20:14:43 CEST] <Hopper_> kepstin: Where should I read about this? [20:15:37 CEST] <kepstin> Hopper_: oh, wait, you said you were switching to windows, didn't you? [20:15:44 CEST] <kepstin> I have no idea how to do that on windows :/ [20:16:37 CEST] <Hopper_> I am now in windows. The .ts file plays just fine locally as it is being recorded, it seems to be an issue with the program that creates some sort of metadata for itself when the file is selected. [20:17:01 CEST] <Hopper_> Wish I was in linux, but the drives just don't work for my modulator. [20:17:28 CEST] <kepstin> Hopper_: consider using ffmpeg's segment writer to split up the .ts files into e.g. 10 second chunks or something, then send them separately? [20:18:21 CEST] <Hopper_> That's my next option, but I was hoping to do it in one chunk to reduce delay and to keep me from having to write the transmission software from the ground up. [20:19:09 CEST] <Hopper_> I'm also concerned about buffering the files to create seamless playback. [20:19:49 CEST] <kepstin> yeah, that's where writing to a pipe for ipc rather than a file would be the best solution [20:19:59 CEST] <kepstin> but I really have no idea how that could be done in windows [20:22:02 CEST] <Hopper_> It sounds like a good solution, but then I have to figure out how get the pipe and transmission software to interact. [20:40:08 CEST] <lindylex> Hooper_: Thanks [20:57:58 CEST] <lilibox> btw, does anybody still maintain ffmpeg for old rhel4 at least prores support? [20:58:32 CEST] <BtbN> no [20:58:51 CEST] <BtbN> pretty sure whatever is in rhel5 is also long dead [20:58:56 CEST] <kepstin> hasn't rhel4 been end of life for many years anyways? why would someone maintain ffmpeg for an unmaintained distro? [21:00:55 CEST] <nicolas17> kepstin: rhel4 super-super-extended support expired in March 2017 [21:01:16 CEST] <kepstin> oh, wow :/ [21:01:20 CEST] <nicolas17> https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle [21:03:30 CEST] <lilibox> and guys, do you think is unpossible to build it from souce for such old distros? [21:04:19 CEST] <nicolas17> lilibox: try it :P [21:06:20 CEST] <lilibox> nicolas17: please, point me for page where is described how to build static version [21:06:44 CEST] <kepstin> lilibox: assuming you're ok with manually installing a bunch of deps (yasm, libx264, etc.), it'll probably still work. [21:07:07 CEST] <nicolas17> if there was a detailed and up-to-date on how to build static ffmpeg specifically for rhel4... surely the person maintaining the guide would just provide their binaries? [21:07:47 CEST] <nicolas17> download the code and check the README / INSTALL / whatever [21:12:01 CEST] <kepstin> there are a bunch of general guides for building static ffmpeg around, I imagine there's not really too much difference between e.g. ubuntu and rhel in that regard (aside from some package names) [21:12:57 CEST] <c_14> I mean, you can just build everything from new sources except for the libc (or even use a static musl or something) [21:17:52 CEST] <kepstin> do the static builds on https://www.johnvansickle.com/ffmpeg/ not work on rhel 4? (is the kernel too old or something?) [21:18:37 CEST] <kepstin> huh, i guess it is, you don't get a 2.6.32 kernel until rhel6. [21:24:36 CEST] <nicolas17> I still don't understand why changes to the timebase would affect the bitrate of an x264 encoding if I'm using crf mode :/ [21:27:45 CEST] <JEEB> if you have enough features enabled the rate control does try to look at how "quickly" things go by [21:27:52 CEST] <JEEB> and either use or not use bit rate on details etc [21:28:04 CEST] <JEEB> oh wait, just the time base? [21:28:12 CEST] <JEEB> not actual timestamp values per se? [21:28:25 CEST] <kepstin> yeah, x264 has optimizations where it looks for "fast motion" in the video, and doesn't bother encoding details it doesn't think the eye will see [21:28:34 CEST] <JEEB> although I'm not sure if libx264 itself supported timebase switches? (It might but I am not sure) [21:29:03 CEST] <kepstin> if you change the timebase without changing pts values, then that's equivalent to changing the framerate, but I dunno what you're actually doing? [21:29:30 CEST] <azarus> What's the difference between encoding with libvorbis vs vorbis, or libopus vs opus? [21:29:58 CEST] <JEEB> internal vs external library [21:30:07 CEST] <JEEB> also the internal vorbis encoder should just be thrown out [21:30:10 CEST] <kepstin> azarus: 'vorbis' will use ffmpeg's builtin vorbis encoder, which isn't particularly good, while 'libvorbis' uses the reference library [21:30:15 CEST] <JEEB> it's barely a bit stream writer [21:30:21 CEST] <JEEB> (just like the AAC encoder was, although even worse) [21:30:45 CEST] <JEEB> the AAC encoder thankfully got improved, and the opus one is gaining dev traction it seems [21:30:55 CEST] <azarus> So I should avoid internal encoders? [21:30:59 CEST] <kepstin> azarus: depending on the version of ffmpeg you use, 'libopus' and 'opus' may or may not do different things [21:31:06 CEST] <kepstin> azarus: depends on the codec. [21:31:55 CEST] <azarus> Are builtin encoders faster? [21:32:05 CEST] <kepstin> azarus: depends on the codec. [21:32:10 CEST] <kepstin> and the settings :) [21:32:22 CEST] <azarus> Okay, kinda expected that :p [21:32:39 CEST] <azarus> The best thing would be to try them all, right? [21:32:54 CEST] <kepstin> if you ask about a specific codec, we can give recommendations [21:33:10 CEST] <azarus> I'd mostly like to convert audio to opus. [21:33:19 CEST] <JEEB> then for now use libopus [21:33:22 CEST] <kepstin> but in general, you should be as specific as possible when telling ffmpeg which codec to use. [21:33:41 CEST] <JEEB> if you had said AAC the internal AAC encoder is the best distributable one [21:33:42 CEST] <kepstin> E.g. in old ffmpeg, you could say "-c:a opus" and since there was no internal opus decoder, it would use libopus [21:34:07 CEST] <kepstin> but now that there's an internal encoder, that does something different now [21:34:13 CEST] <azarus> I use a new ffmpeg with an internal opus encoder, so I'd need to specify libopus, right? [21:34:20 CEST] <kepstin> yes. [21:34:44 CEST] <kepstin> (and ideally make sure you have libopus 1.2.1 installed, since 1.2 adds some nice improvements) [21:35:27 CEST] <azarus> I have opus-1.2 in gentoo, dunno if that's libopus 1.2.1. [21:36:06 CEST] <kepstin> close enough, I think 1.2.1 was mostly build fixes, maybe minor bugfixes [21:36:42 CEST] <kepstin> "fixes a relatively rare issue where the 1.2 encoder would wrongly assume a signal to be bandlimited to 12 kHz and not encode frequencies between 12 and 20 kHz" hmm. [21:36:53 CEST] <azarus> Nothing big then :) [21:37:27 CEST] <azarus> What's everyone's favourite audio codec? :) [21:37:43 CEST] <kepstin> opus, obviously ;) [21:37:43 CEST] <azarus> I'm split between opus and vorbis! [21:38:05 CEST] <kepstin> opus is better than vorbis in pretty much every way except hardware player compatibility :/ [21:38:40 CEST] <nicolas17> I had a video where at one point there was some microphone feedback, causing a loud tone [21:38:47 CEST] <azarus> Pretty much, some of my players don't support opus, that's why I still need vorbis sometimes. [21:38:53 CEST] <nicolas17> (on 8mm tape) [21:39:26 CEST] <nicolas17> I was encoding it to DVD-Video... that loud tone made ffmpeg's mp2 encoder crash... I don't remember if I ever reported it :x [21:39:50 CEST] <JEEB> lol [21:39:55 CEST] <azarus> BTW, has anyone too had really slow vp9 encodes? x265 seems to be much faster for me :s [21:40:12 CEST] <JEEB> libvpx is slow as molasses although with anything usable x265 probably is, too [21:40:27 CEST] <kepstin> azarus: well, both are really slow, but vp9 has worse threading optimizations [21:40:36 CEST] <JEEB> usable as in that actually gives you perf benefit in compression ratios compared to libx264 [21:40:46 CEST] <JEEB> (with same speed) [21:40:51 CEST] <kepstin> make sure you're using a recent git build of vp9, of course, the release versions are all way out of date. [21:40:56 CEST] <azarus> vp9 for me is about 50% the speed as x265, am I doing something wrong? [21:41:11 CEST] <azarus> Of course, I can build libvpx from git if needed. [21:41:12 CEST] <kepstin> azarus: you're not running x265 with slow enough settings, probably. [21:41:16 CEST] <JEEB> you are not mentioning any other parameters so I will guess they are just differently configured :P [21:41:54 CEST] <JEEB> azarus: basically there's tags in the libvpx repo that are meant for the different chrome versions. latest of those is generally recommended [21:42:07 CEST] <JEEB> s/chrome/chromium/ although effectively is the same [21:42:21 CEST] <nicolas17> JEEB: is there even such thing as "vp9 and x265 configured the same way"? :) [21:42:28 CEST] <JEEB> to the same speed that is [21:42:50 CEST] <kepstin> azarus: general recommendation is that unless you need H.265 for some other reason, you probably shouldn't use any faster settings than -preset veryslow (use x264 instead) [21:42:53 CEST] <JEEB> so saying X is slower than Y without mentioning any parameters is just bullshit [21:43:15 CEST] <azarus> h265 is not free, that's why I kinda want to get away from x265 :( [21:43:28 CEST] <nicolas17> define "free" [21:43:38 CEST] <azarus> not patent-encumbered [21:43:45 CEST] <JEEB> everything is patent-encumbered [21:43:49 CEST] <kepstin> in terms of dealing with the patents h265 is much worse than h264, of course. [21:43:57 CEST] <JEEB> the question is whether something is de facto considered "free to use" [21:44:00 CEST] <nicolas17> H264 has plenty of patents [21:44:01 CEST] <furq> azarus: i think you still need libvpx from git for the new multithreading mode [21:44:08 CEST] <furq> although idk how much faster it is [21:44:17 CEST] <azarus> Thanks for the answer, furq [21:44:31 CEST] <JEEB> also it really depends on the use case. AVC for example didn't require any fees for freely available internet video [21:44:40 CEST] <azarus> vp9 is much for free than h264, for example. [21:44:41 CEST] <kepstin> hmm, the chrome 59 tag should give you working new multithreaded mode, I think, but the 60 tag is probably better [21:44:46 CEST] Action: nicolas17 shrugs [21:44:52 CEST] <kepstin> 58 has it about half-implemented iirc [21:44:56 CEST] <JEEB> and I think the HEVC licensing pools (which is complete bullshit btw) did kind of come to their senses [21:45:00 CEST] <JEEB> in that regard [21:45:04 CEST] <furq> kepstin: sure, but that's still a tag [21:45:14 CEST] <furq> the static builds generally use release versions [21:45:33 CEST] <kepstin> yeah [21:45:39 CEST] <JEEB> the main issue I have with people calling VP9 libre or whatever is that those people generally never saw how it was developed. it was created behind closed doors with just el GOOG [21:45:51 CEST] <JEEB> that's the whole antithesis of OSS or anything similar IMHO [21:45:52 CEST] <kepstin> i wish they'd just make the chrome tagged versions official "releases" or something [21:45:58 CEST] <furq> it's free as in the one that stallman doesn't like [21:46:06 CEST] <azarus> Is it a good idea then to build the newest version from git? [21:46:12 CEST] <furq> but it's still better than paying four bars to drink one beer [21:46:12 CEST] <nicolas17> JEEB: yeah, iirc by the time it was made public, the bitstream was already frozen [21:46:21 CEST] <azarus> of libvpx I mean* [21:46:24 CEST] <furq> azarus: yes [21:46:39 CEST] <JEEB> furq: kind of. I guess it got enough adoption that you could de facto consider it "free to use" [21:46:40 CEST] <kepstin> azarus: git head is sometimes a bit wonky, which is why i normally use the chrome tags, but probably ok? [21:46:52 CEST] <furq> well yeah i meant it's freeware [21:46:58 CEST] <JEEB> because there's always the thing that you might get someone trying to screw the party [21:47:02 CEST] <JEEB> because effectively nothing is patent-free [21:47:03 CEST] <JEEB> :V [21:47:17 CEST] <furq> idc if google handle the litigation [21:47:23 CEST] <nicolas17> what ever happened with that cisco-patenting-x264-algorithm thing? [21:47:29 CEST] <furq> obviously they might lose and then the party is over, but google can afford it [21:47:37 CEST] <JEEB> yea, if google handles it [21:47:45 CEST] <lilibox> kepstin nicolas17 i am getting installers of CentOS it is pretty hard to wind centos4upg3 these days :) [21:47:46 CEST] <JEEB> it would get funky if google just leaves someone to struggle :D [21:48:28 CEST] <JEEB> anyways, at this point with AOM I kind of dislike it less than libvpx and the VPx formats, since it's no longer a single-vendor race [21:48:29 CEST] <nicolas17> http://x264.nl/developers/Dark_Shikari/tandberg.html [21:49:04 CEST] <azarus> Although I don't think I'll make use of a lot of threading though, I have a 2-core 2-thread processor :p [21:49:34 CEST] <kepstin> azarus: hey, it should still go from being super super slow to being merely super slow. [21:49:47 CEST] <azarus> What an improvement! ;) [21:50:06 CEST] <JEEB> nicolas17: ah right that stuff. that said cisco actually joined VDD with a talk regarding their patent-avoiding Thor thing [21:50:12 CEST] <JEEB> like a year or two ago [21:50:31 CEST] <JEEB> right, VDD '14 [21:50:32 CEST] <JEEB> *15 [21:50:38 CEST] <nicolas17> VDD [21:50:39 CEST] <nicolas17> ? [21:50:46 CEST] <JEEB> https://vimeo.com/141153289 [21:50:57 CEST] <JEEB> nicolas17: the primary event for OSS multimedia devs [21:51:04 CEST] <JEEB> done every year so far [21:51:13 CEST] <nicolas17> I also didn't know of Thor [21:51:15 CEST] <JEEB> VideoLAN being nowadays an umbrella organization [21:51:44 CEST] <JEEB> nicolas17: they joined other efforst later [21:51:45 CEST] <nicolas17> is Thor still a thing or did it get consumed by AO1? [21:52:54 CEST] <JEEB> pretty sure they joined the group efforts [21:53:03 CEST] <JEEB> also man it was surprising getting some "suit" people :D [21:53:15 CEST] <JEEB> compared to the usual OSS nerd folk [21:53:17 CEST] <azarus> Can vaapi accelerate my vp9 encodes= [21:53:20 CEST] <azarus> *? [21:53:34 CEST] <JEEB> even if it could, you still wouldn't get the compression ratios as with SW encoders [21:53:46 CEST] <JEEB> unless something magical happens and the software encoder is really bad [21:53:48 CEST] <BtbN> Is there even hardware that does vp9 hw encode? [21:53:55 CEST] <nicolas17> JEEB: I think similarly of patents and of "thou shalt not reverse engineer", and this is what I think of the latter https://pbs.twimg.com/media/Czf29XDXUAAdBcd.jpg:large [21:54:02 CEST] <furq> azarus: it can accelerate it by offloading the decode [21:54:08 CEST] <furq> that's all i'd use it for [21:54:22 CEST] <azarus> Good point, decoding h264 is a task by itself too! [21:54:39 CEST] <JEEB> nicolas17: hehe. RE is fun! [21:54:59 CEST] <nicolas17> iirc I tweeted the latter with "fuck the IP police" [21:55:08 CEST] <JEEB> I need to get the new version of IDA I guess :V [21:55:42 CEST] <JEEB> although I'm generally OK with the OSS debuggers [21:56:32 CEST] <nicolas17> I once spent a week manually decompiling ARM64 code (because Hopper can only decompile 32-bit arm, for ARM64 it only disassembles) and added a button I wanted to the iOS mail app [21:56:55 CEST] <JEEB> also if you want to know what happened with libvpx last year https://vimeo.com/181634997 [21:57:45 CEST] <JEEB> there's also great talks from the last two years regarding the AAC encoder updates etc [21:59:17 CEST] <nicolas17> JEEB: I finally got my program to produce a .mp4 bitwise identical to what ffmpeg.c produces [21:59:29 CEST] <JEEB> nicolas17: that can be both a good and a bad thing :D [21:59:34 CEST] <JEEB> because ffmpeg.c is ffmpeg.-c [21:59:37 CEST] <JEEB> *.c [22:00:11 CEST] <nicolas17> JEEB: https://paste.kde.org/pr0cjy1y5 [22:01:17 CEST] <kepstin> BtbN: no vp9 hw encode as far as I know. There's some hw decode support around, e.g. nvidia [22:01:35 CEST] <BtbN> nvidia and intel have decode support [22:01:45 CEST] <BtbN> but I can't think of any consumer hw encoders [22:02:12 CEST] <jkqxz> Latest Intel has encode support. (8-bit only, 10-bit just has decode.) [22:04:13 CEST] <kepstin> huh, I wonder how much of that is in hw vs. software (the media sdk stuff is all a bit purposefully unclear about that) [22:04:43 CEST] <jkqxz> Pretty much all hardware. (Easily does 4K60.) [22:05:54 CEST] Action: JEEB can do HLG in VP9.2 with his TV and that's kind off is nice :3 [22:21:34 CEST] <azarus> Right, I now have compiled and installed a brand new libvpx from git, let's see if this improves my encodes. [22:23:35 CEST] <azarus> There were 923 commits to master since 1.6.1 (the release I was at before) so surely some changes were made to improve performance :p [22:29:34 CEST] <kepstin> azarus: you'll probably want to recompile your ffmpeg against the new libvpx as well. there's a few things in the ffmpeg codec which are conditionally enabled based on the libvpx features available. [22:29:53 CEST] <azarus> kepstin: Already in the middle of recompiling ffmpeg :p [22:30:05 CEST] <kepstin> azarus: in particular, the "-row-mt" avoption :) [22:30:35 CEST] <azarus> kepstin: Never heard of that! Do I have to enable a compiler flag for that? [22:30:49 CEST] <TD-Linux> azarus, you can make libvpx pretty fast with the --cpu-used option (8 fastest, 0 slowest) but you do throw out compression gain doing that. [22:31:01 CEST] <kepstin> azarus: no, as long as you build ffmpeg against a new enough libvpx version, that'll be available. [22:31:55 CEST] <azarus> TD-Linux: Does a loss of compression gain mean an increase in file-size? [22:32:02 CEST] <azarus> kepstin: Thanks for informing me :) [22:32:05 CEST] <TD-Linux> azarus, yup. [22:32:14 CEST] <TD-Linux> azarus, same as x265 does with its default speed (medium iirc) [23:14:40 CEST] <azarus> I want to do 2-pass encoding with vp9. Why is the command 'ffmpeg -i in.mkv -c:a libopus -c:v libvpx-vp9 -pass 1 -f mkv /dev/null' invalid while 'ffmpeg -i The.Grand.Tour.S01E12.WEBRip.X264-DEFLATE\[ettv\].mkv -c:a libopus -c:v libvpx-vp9 -pass 1 -f webm /dev/null' is valid? [23:14:58 CEST] <azarus> Ah whoops. Pasted a bit too much! [23:15:58 CEST] <nicolas17> I'm not sure if ffmpeg has a special interpretation of [] characters but I'd recommend avoiding them just in case :P (rename input file) [23:23:19 CEST] <JEEB> (it doesn't - it's all up to your shell) [23:23:34 CEST] <JEEB> only img2 has special features in there [23:24:45 CEST] <furq> both of them already left [23:25:02 CEST] <furq> i understand the first guy leaving, i wouldn't want anyone to know i watched the grand tour either [23:35:06 CEST] <JEEB> lol [00:00:00 CEST] --- Tue Jul 11 2017

1 0

ffmpeg-devel.log.20170709
by burek 10 Jul '17

10 Jul '17

[00:25:40 CEST] <kevmark> How not to do testing? https://github.com/rg3/youtube-dl/pull/13449#issuecomment-313878863 [00:42:47 CEST] <Compn> ydl, a vastly underrated project :) [00:45:20 CEST] <kevmark> I use it all the time, it's terrific. But their extractor testing is in dire need of an overhaul [00:47:09 CEST] <kevmark> If only because your version of ffmpeg decides whether some tests pass or not [10:09:27 CEST] <hanna> I wonder if you would be willing to accept a change to make base64.c/h use a fixed `int in_size` (alongside the `int out_size`) instead of relying on the input being NULL-terminated [10:09:38 CEST] <hanna> Seems like that would be strictly more compatible (you could still use strlen() if you have nul-terminated strings) [10:53:57 CEST] <durandal_1707> anybody knows how huffman lenghts can be up to 15 [10:58:43 CEST] <durandal_1707> with huffman function from ffmpeg i get bigger lengths [11:20:41 CEST] <durandal_1707> michaelni: ^ [11:26:21 CEST] <michaelni> nb_bits passed to *init_vlc multiplied by the depth used in the vlc decode macro have to be larger of equal to the longest code [11:26:37 CEST] <michaelni> that can be lnger than 15 [11:27:36 CEST] <michaelni> but maybe i misunderstood what set of vlc functions you meant ... [11:30:45 CEST] <durandal_1707> michaelni: this is for encoding [11:33:47 CEST] <durandal_1707> basically doing reverse process for magicyuv [11:47:59 CEST] <michaelni> if you want to create a vlc set with length of <=16, the mjpeg encoder also needs vlcs below a maximum length, the code from libavcodec/mjpegenc_huffman.c can likely be shared [12:42:19 CEST] <durandal_1707> michaelni: issue is mjpeg one unused symbols sets to 0 [12:42:37 CEST] <durandal_1707> while magicyuv doesnt [13:39:28 CEST] <durandal_1707> michaelni: how to handle cases when frequency/count is 0? [13:49:58 CEST] <michaelni> if a symbol doesnt occur it doesnt need a vlc unless required by some syntax constraint [13:53:33 CEST] <ubitux> michaelni: do you want me to look up for some <<><<<>< patterns in the db? [13:53:42 CEST] <ubitux> do you have a grep pattern to suggest? [13:54:06 CEST] <ubitux> i'm expecting stuff like "<<<<<<<<<<" and ">>>>>>>>>" used for "styling" but that's all [14:17:47 CEST] <ubitux> michaelni: ./6/6/6/4/1cb707c078d833eb988ec424d80b0431:<b><<< ÓÍÀÊÑ ÒÈÉÌ < 2015 > UNACS TEAM >>></b> [14:17:54 CEST] <ubitux> yeah, that kind of stuff& [14:22:06 CEST] <michaelni> ubitux, yes, testcases with stuff like this should be usefull for fate [14:26:19 CEST] <ubitux> heh, some ppl use << and >> for « and » [14:31:16 CEST] <ubitux> oh i guess it was the ocr they used [14:32:07 CEST] <RiCON> and keyboards that don't have «», maybe [17:07:06 CEST] <atomnuker> iive: the avx2 version should've been dropped too, it was slower than sse42 iirc [17:29:40 CEST] <iive> atomnuker: yes, indeed. [17:30:35 CEST] <atomnuker> and the avx version was no faster too IIRC [17:30:56 CEST] <iive> on older intel cpu and ryzen avx is fastest [17:32:01 CEST] <atomnuker> huh, ok [17:33:47 CEST] <iive> btw, you can try 128bit avx2, the only difference should be the broadcastv instructions [17:36:24 CEST] <atomnuker> how? [17:36:56 CEST] <iive> the int last 2 lines of the assembly, change the INIT_YMM to INIT_XMM :D [17:37:21 CEST] <iive> the int/in the [18:02:49 CEST] <jamrial> avx2 using xmm only gets you reg -> reg broadcast intructions, double word pblend, and variable bit shift intructions [18:03:59 CEST] <BtbN> wonder how avx2 used that way works on Ryzen, as it's only kind of emulating the 256bit [18:06:19 CEST] <atomnuker> it helps apparently because there's less overhead to decode instructions [18:08:22 CEST] <kierank> BBB: is ff_h264_update_thread_context allowed to edit the source context [18:34:21 CEST] <nevcairiel> kierank: its const, so no [18:34:47 CEST] <kierank> hmm didn't notice that [18:34:48 CEST] <kierank> hmmm [18:34:59 CEST] <kierank> leads to insane side data race conditions [18:43:54 CEST] <kierank> BBB: so my problem is caption data is stored in field 1 (thread 2), update_thread_context needs to pass it to field 2 (thread 2) and then zero the pointer in thread 1, is there a proper way of doing that? [18:46:44 CEST] <kierank> or maybe michaelni knows? [19:07:03 CEST] <iive> BtbN: btw, would you test v4 too? I want to know if the x64_reg define still makes thing faster/slower. [19:07:13 CEST] <iive> it's not urgent. [19:12:01 CEST] <michaelni> kierank, maybe a AVBufferRef can be used to create a new ref to the data in the new thread, and the old would be freed at the end of the old thread and not be set to NULL. But maybe i misunderstand [19:12:26 CEST] <kierank> yes, I was thinking the same [19:12:39 CEST] <kierank> thanks [19:13:35 CEST] <kierank> maybe i need to make a caption buffer for field 1 and field 2 [19:38:51 CEST] <tmm1> is a decoder allowed to change avctx->framerate at any time? [19:39:30 CEST] <atomnuker> yes, and timebase, and resolution and format and pretty much everything [19:39:34 CEST] <DHE> shouldn't that be more of a demuxer's job? [19:51:51 CEST] <cone-295> ffmpeg 03Marton Balint 07master:b406f387c809: avcodec/noise_bsf: add support for dropping packets [19:53:17 CEST] <BBB> kierank: no, source is const [19:53:34 CEST] <tmm1> i'm seeing that on some platforms, the mediacodec mpeg2 decoder deinterlaces as well and outputs at double the framerate [19:54:10 CEST] <BBB> kierank: this isnt so much a convention but a necessity, because the previous thread expects the contents not to change under its feet while the current frame is decoding concurrently with the next frame [19:54:13 CEST] <nevcairiel> you can change the framerate, but you cant really convince the caller to update its timebase so you're probably screwed [19:54:25 CEST] <kierank> BBB: yeah, seems bufferrefs are the only way to do what I want [19:54:25 CEST] <BBB> kierank: so allowing to update the source context would open 10 new cans of worms, IMO [19:54:55 CEST] <BBB> why do you need to zero the pointer in thread 1? [19:55:03 CEST] <BBB> I mean, I probably understand the problem oorly [19:55:14 CEST] <BBB> but it soudns like you have a way forward so Id just go try it out ;) [19:55:31 CEST] <BBB> oh right michaelni had a good idea [19:55:40 CEST] <BBB> I think hes right [20:07:26 CEST] <mateo`> tmm1: wouldn't it be better to just rescale the frame pts (if you have the correct framerate in the first place) ? [20:11:53 CEST] <tmm1> looks like framerate and time_base are both set to {0,1} in mediacodecdec [20:11:59 CEST] <tmm1> so the only thing being used is pkt_timebase? [20:15:33 CEST] <mateo`> yes [20:20:57 CEST] <tmm1> what i'm seeing is if i input two frames with ts=1 and ts=3, on the output side i get four frames with ts=1 2 3 4 [20:22:08 CEST] <tmm1> seems like that would just work since we rescale the pts back to the pkt_timebase no? [20:22:44 CEST] <kierank> 6:54 PM <"BBB> why do you need to zero the pointer in thread 1? --> i've noticed that it still stays around during non mod 2 thread counts otherwise [20:24:23 CEST] <mateo`> tmm1: that should work [20:30:06 CEST] <ubitux> michaelni: since almost every remaining tsan issue seems to come from mpeg(4?), are you going to look into this? [20:30:33 CEST] <ubitux> (since you're likely the maintainer of this code, and you like tools who raise C errors ;)) [20:30:56 CEST] <ubitux> it would be nice to have a clean tsan for the frame threading [20:32:57 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170709010307&slot=x86_64-archlinux… [20:33:55 CEST] <ubitux> slice threading is still a bit more racy, but if at least we could have the frame threading instance green [20:34:02 CEST] <ubitux> that would help detecting new races [21:06:24 CEST] <michaelni> ubitux, need to install gcc7 first, my gcc 6 tsan seems to have stoped working after a recent update [21:07:04 CEST] <iive> michaelni: there is bug that nasm and tsan doesn't play well, something with debug info [21:07:57 CEST] <michaelni> hmm, that could be it too [21:10:31 CEST] <ubitux> michaelni: yeah, you just need to --x86asmexe=yasm [21:10:47 CEST] <ubitux> assuming you're refering to the lack of symbols [21:10:57 CEST] <ubitux> see https://trac.ffmpeg.org/ticket/6516 [21:14:48 CEST] <atomnuker> --as=nasm still works [21:14:53 CEST] <atomnuker> *yasm [21:16:21 CEST] <nevcairiel> --as controls something else, doesnt it [21:17:54 CEST] <jamrial> atomnuker: --as is not for nasm/yasm [21:20:02 CEST] <atomnuker> huh, I guess I've been doing it wrong then [21:28:03 CEST] <kierank> surely with av_buffer_realloc an a non writeable frame the original needs to be unrefd? [21:28:06 CEST] <kierank> this makes no sense at all [21:32:38 CEST] <kierank> * @note the buffer is actually reallocated with av_realloc() only if it was [21:32:38 CEST] <kierank> * initially allocated through av_buffer_realloc(NULL) and there is only one [21:32:38 CEST] <kierank> * reference to it (i.e. the one passed to this function). In all other cases [21:32:38 CEST] <kierank> * a new buffer is allocated and the data is copied. [21:32:46 CEST] <kierank> a new buffer is allocated and what happens to the old one? [21:33:00 CEST] <kierank> the caller can't unref because the caller doesn't know if copying has happened? [21:45:01 CEST] <BBB> ubitux: michaelni: re mpeg4, I believe all you need to do is change the memcpy(Dst, src, sizeof(MpegEncContext)); in mpv_update_thread_context (or whatever) to only copy the fields that are needed in the next thread [23:52:07 CEST] <michaelni> BBB, at least padding_bug_score wont work so well as its updated at the end of slices, also this looks like very boring work [00:00:00 CEST] --- Mon Jul 10 2017

1 0

ffmpeg.log.20170709
by burek 10 Jul '17

10 Jul '17

[01:48:07 CEST] <hiihiii> hello [01:50:27 CEST] <hiihiii> running this command to stream to youtube [01:50:54 CEST] <hiihiii> ffmpeg -re -i input.mp4 -threads 0 -c copy -f mp4 rtmp://a.rtmp.youtube.com/live2/key-key-key-key [01:52:26 CEST] <hiihiii> gives me the following error https://thepasteb.in/p/Vmh0QNBm0gNs4 [01:53:25 CEST] <hiihiii> I'm getting it's due to seeking but I'm not sure how to enable it [01:53:45 CEST] <hiihiii> with ftp it's : -ftp-write-seekable 1 [01:53:58 CEST] <hiihiii> with rtmp there's no option for it [01:54:13 CEST] <furq> -f flv [01:54:21 CEST] <nicolas17> "streaming" and "seekable" are fundamentally contradictory :P [01:55:10 CEST] <hiihiii> wouldn't it encode the input? [01:55:17 CEST] <nicolas17> no because you said -c copy [01:55:17 CEST] <furq> no [01:55:27 CEST] <nicolas17> I wonder why you are streaming a static video file though... why not just... upload it to youtube? [01:55:27 CEST] <hiihiii> or just muxing itno flv [01:55:41 CEST] <hiihiii> just testing [01:55:47 CEST] <nicolas17> it was already demuxing the mp4 and remuxing into mp4 anyway [01:55:59 CEST] <nicolas17> now it will demux the mp4 and remux into flv [01:56:11 CEST] <nicolas17> in either case it won't reencode the actual video stream because you used -c copy [01:56:46 CEST] <hiihiii> thanks. yes it makes sense but why doesn't it work with -f mp4 [01:57:16 CEST] <nicolas17> I think when you output to an mp4 file, it has to rewrite the header at the beginning of the file, when it *finishes* encoding [01:57:59 CEST] <hiihiii> oh ok [01:58:20 CEST] <nicolas17> if you output to an mp4 live stream, it can't go back to the beginning of the "file" and write some data when it finishes :P [01:58:31 CEST] <hiihiii> I noticed that when I output FLVs, even if the encoding hasn't finished I can open the output [01:58:36 CEST] <nicolas17> exactly [01:58:43 CEST] <hiihiii> with MP4 it gives an error [01:59:17 CEST] <hiihiii> okay thx that makes much sense [02:40:11 CEST] <thebombzen> hiihiii: mp4 is not a format that you can record to a nonseekable device, like a stream [02:40:55 CEST] <thebombzen> mp4 files have a table of contents, which by default is written at the end of the file after you've written the rest, but that means anyone reading it has to be able to seek to the end to have it, which isn't possible if you're streaming it [02:41:37 CEST] <thebombzen> when you're done writing the file, you can move the table of contents (called a moov atom) to the beginning, but again, doesn't work with streaming. [03:02:31 CEST] <hiihiii> thebombzen: I read that, thx [03:13:26 CEST] <Anthony_> hello [03:13:40 CEST] <Anthony_> having problems with ffmpeg [03:14:01 CEST] <Anthony_> something about a missing AVFilterGraph [04:05:02 CEST] <behael> 'Ello guys [04:05:23 CEST] <behael> I need some help to understand a weird behavior of ffmpeg [04:11:55 CEST] <dystopia_> what weird behavior [04:14:48 CEST] <behael> god, cant use the pastebin https://pastebin.com/post.php ERR_SPDY_PROTOCOL_ERROR [04:14:53 CEST] <behael> sec, let me try again [04:17:11 CEST] <behael> I managed to paste in another site, let me know if thats allowed to show here [04:17:30 CEST] <dystopia_> just paste the link [04:17:43 CEST] <behael> http://pasted.co/6fa9bb2d [04:18:11 CEST] <behael> if you look at the paste - at my phys host ffprobe returns mpeg video for the "sample.m4v" [04:18:43 CEST] <behael> but inside the lxc container, it returns GSM [04:19:03 CEST] <behael> same ffmpeg, same ffprobe, same debian - diff is one is phys the other is a lxc container [04:20:01 CEST] <behael> at the phys host I am able to convert from m4v to mp4 - but inside the container it gens a huge mp4 (about 50MB) with weird sounds and tons of "missing gsm magic" errors [04:36:22 CEST] <behael> the "file" cmd returns (host or LXC) the same result: sample.m4v: MPEG sequence, v4, video, advanced simple @ L1 [04:45:12 CEST] <furq> pastebin the command and full output [04:45:20 CEST] <nicolas17> he did [04:45:29 CEST] <nicolas17> http://pasted.co/6fa9bb2d [04:45:59 CEST] <furq> there's no command or output there [04:46:42 CEST] <nicolas17> ... [04:46:59 CEST] <nicolas17> "ffprobe sample.m4v" is the command, and it gives different output on the same file [04:47:10 CEST] <furq> 03:20:01 ( behael) at the phys host I am able to convert from m4v to mp4 - but inside the container it gens a huge mp4 (about 50MB) with weird sounds and tons of "missing gsm magic" errors [04:47:14 CEST] <furq> i meant this command [04:47:27 CEST] <nicolas17> not sure if it matters? [04:47:34 CEST] <nicolas17> if ffprobe alone gives different results on the input file [04:47:43 CEST] <furq> well it might at least give us something to go off [04:48:03 CEST] <nicolas17> behael: are you *sure* the .m4v is the same in both systems? run sha1sum on both [04:48:06 CEST] <furq> yeah [04:48:37 CEST] <furq> if they're the same then i can only imagine there's some major issue with your container [04:57:27 CEST] <FurretUber> Hi, I am trying to encode a video with 10-bit depth with libx264. I tried to capture screen and tried to encode other videos. There is a warning about incompatible pixel format and the resulting videos loses a lot of its colours, here is the output of ffmpeg when capturing the screen: https://pastebin.com/di2yj11x I have built from the ffmpeg snapshot of 05-07-2017 [04:59:10 CEST] <behael> the cmd for converting ? The default one ffmpeg -i sample.m4v sample.mp4 [04:59:16 CEST] <behael> and the hashs matchs [05:00:29 CEST] <nicolas17> FurretUber: I don't know why the x264 encoder refuses to use 10bit because I never dealt with 10bit myself [05:00:54 CEST] <nicolas17> but I really wonder if the x11grab input stream will support 10 bit... [05:01:04 CEST] <FurretUber> What I am actually using is 8-bit and produces, according to https://trac.ffmpeg.org/wiki/Encode/H.264#LosslessH.264 is lossless, is https://pastebin.com/wSWwg5fw [05:02:08 CEST] <nicolas17> the input stream (x11grab) is bgr0, pretty sure that's 8 bit [05:02:28 CEST] <nicolas17> so if you manage to get x264 to accept 10 bit... you'll be upscaling from 8 bit to 10 bit, which seems somewhat pointless [05:04:43 CEST] <FurretUber> I believe this is true, but from what I have searched, the resulting 10-bit video would be smaller. Unless the Google bias to my search history is showing me lies [05:05:43 CEST] <nicolas17> heh, I wonder if someone compared same crf with 8 bit and 10 bit to come to that conclusion :P [05:05:43 CEST] <furq> FurretUber: you need a separate libx264 with 10-bit support [05:06:01 CEST] <nicolas17> (the x264 crf has a different range in 10 bit) [05:06:13 CEST] <thebombzen_> FurretUber it depends on how it's deepened, but yes [05:06:41 CEST] <FurretUber> crf 0 would still be lossless with 10-bit libx264? [05:06:48 CEST] <furq> -qp 0 is lossless [05:07:03 CEST] <FurretUber> Is https://trac.ffmpeg.org/wiki/Encode/H.264#LosslessH.264 wrong? [05:07:14 CEST] <nicolas17> define "lossless" [05:07:18 CEST] <furq> no [05:07:23 CEST] <thebombzen_> You can get lossless with -crf 0, but you should just set -qp 0 in that case [05:07:24 CEST] <furq> -crf 0 is lossless with 8-bit x264 [05:07:27 CEST] <furq> -qp 0 is lossless with both [05:07:36 CEST] <thebombzen_> Really? Huh [05:08:02 CEST] <nicolas17> if you have RGB input and you convert it to 4:2:0 YUV, it won't be "lossless" whether it's 8bit or 10bit ;) [05:08:06 CEST] <furq> also yeah [05:08:13 CEST] <furq> i doubt you'll get a noticeable compressibility difference [05:08:30 CEST] <furq> and the colours will be equally wrong either way [05:08:32 CEST] <thebombzen_> nicolas17, true, but irrelevant [05:08:39 CEST] <FurretUber> -crf 0 -qp 0 will work for both? [05:08:52 CEST] <thebombzen_> Use -qp 0 for lossless [05:09:25 CEST] <thebombzen_> Note that if your version of libx264 is 10bit, then libx264rgb will not work correctly. [05:09:56 CEST] <thebombzen_> Or might not. In this case it's better to convert to yuv444p10le and encode that [05:11:01 CEST] <thebombzen_> I'm not sure, but I think yuv444p is slightly more compressible that gbrp anyway. It might work better with a non-lavc decoder as well [05:11:32 CEST] <nicolas17> gbrp? [05:11:44 CEST] <thebombzen_> Green Blue Red Planar [05:12:05 CEST] <FurretUber> My inputs are, generally, RGB. I was trying to make the encoded videos both 10-bit and don't lose the colors as they done with that command [05:12:17 CEST] <thebombzen_> it's rgb24 but green/blue/red, and planar rather than interleaved [05:13:10 CEST] <FurretUber> I could make it have the rgb colors correctly, but couldn't make any 10-bit video yet. [05:13:13 CEST] <thebombzen_> Upping 8 to 10 has basically no benefit in lossless mode. [05:13:37 CEST] <FurretUber> I have to go now, tomorrow I will build libx264 with support and will try again. Thank you [05:14:12 CEST] <thebombzen_> Upping 8 to 10 can be more efficient because it allows more room for low-bit quantization error [05:14:18 CEST] <thebombzen_> err, and gone. [05:15:16 CEST] <thebombzen_> nicolas17: gbrp is planar RGB sorted by green, blue, red [05:16:11 CEST] <thebombzen_> gbr is the order for parallel with yuv. Y is mostly based on the green channel. U and V are blue and red chroma respectively [05:39:13 CEST] <behael> I really cant fix it... I just moved to a nfs share and a few scripts to do a "remote convert from m4v to mp4" [05:39:33 CEST] <behael> I tried diff containers, with diff versions of debian - all showing the same behavior [05:40:36 CEST] <behael> since the files are small and the host is the host of the containers, its good for now - but I will investigate it [05:40:46 CEST] <behael> thanks guys [05:41:07 CEST] <nicolas17> weird as hell [05:42:03 CEST] <behael> Yeah I never saw it, file systems are ok no fault drive or anything [05:42:23 CEST] <behael> I also tried to host a ubuntu container, centos container all the same behavior [05:43:08 CEST] <furq> i guess you want strace and diff [05:43:15 CEST] <furq> also fyi m4v is mp4, you can probably just rename it [05:43:33 CEST] <behael> probably some lxc underground conf [05:43:51 CEST] <nicolas17> memory_corruption=off [05:43:53 CEST] <nicolas17> (?) [05:44:15 CEST] <behael> yeah I tried, but the m4v are generated by the guacenc (guacamole encoder) from RDP session recordings. And they need to be played over html5 [05:44:21 CEST] <furq> oh [05:44:24 CEST] <furq> yeah you'll need to convert it then [05:44:28 CEST] <behael> So, html5 is refusing to play m4v or mp4 (renamed) [05:44:41 CEST] <furq> yeah it's mpeg4, not h264 [05:45:09 CEST] <furq> but yeah ffprobe inside the container is somehow misdetecting the container and the codec [05:45:24 CEST] <furq> and if the checksums match then something is seriously wrong there [05:45:54 CEST] <furq> especially if it's happening with multiple different storage types [05:46:46 CEST] <behael> yupe, I cant say the old "it used to work" b/c I never did it - so I will try a few diff confs tomorow - if I find something I will let you guys know [05:46:59 CEST] <behael> thanks guys - almost 2am here time to hit the bed [05:47:03 CEST] <behael> cya around [05:48:06 CEST] <nicolas17> I'm removing the C++ wrappers I made around ffmpeg [05:48:19 CEST] <nicolas17> so I can get a plain C program again and post it here and get help on why the hell it's misbehaving [05:48:23 CEST] <nicolas17> -_- [18:28:22 CEST] <lindylex> I am trying to concat two videos and I get a longer video than the sum of all the videos and I only see the first video. This is my command : ffmpeg -f concat -i l.txt -i cornerFinalBlack.png -codec:v libx264 -profile:v baseline -preset slow -pix_fmt yuv420p -b:v 3500k -threads 0 -an -y out.mp4 This is a link to all my assets http://mo-de.net/d/fh/ [18:31:06 CEST] <c_14> the input videos are different fps [18:31:29 CEST] <c_14> so ffmpeg assumes the first video's fps for the other video [18:31:50 CEST] <lindylex> Ok match the fps and that will solve it? [18:32:01 CEST] <c_14> presumably [18:32:40 CEST] <c_14> compressed/full range might also cause issues but not length related [18:34:39 CEST] <lindylex> I do not understand you last sentence. [18:35:11 CEST] <lindylex> One sec let me set the frame rate now and test. [18:36:20 CEST] <c_14> the first video is yuv420p and the second is yuvj420p which means that the first video has mpeg (compressed) range and the second jpeg (full) range [18:36:26 CEST] <c_14> this may cause bleaching of colors etc [18:36:42 CEST] <lindylex> I see. [18:37:13 CEST] <lindylex> So it is combination of framerate and compressed range? [18:37:44 CEST] <c_14> the length issue is probably just the framerate, the range should only cause color bleaching etc [18:37:57 CEST] <lindylex> One sec let em test. [18:42:40 CEST] <lindylex> I am try to make the image into a video setting the frame rate to 29.97 like this: ffmpeg -loop 1 -i cornerFinalBlack.png -framerate 30000/1001 -c:v libx264 -t 5 -pix_fmt yuv420p c1.mp4 I get a video with 25 fps instead [18:42:57 CEST] <c_14> -framerate before -i [18:43:03 CEST] <lindylex> ok [18:43:42 CEST] <lindylex> Thanks that worked! [18:44:55 CEST] <lindylex> Ok I got the duration to make sense. Now I need to have the second video show up. [18:48:14 CEST] <lindylex> I did this: ffmpeg -loop 1 -framerate 30000/1001 -i cornerFinalBlack.png -c:v libx264 -t 5 -pix_fmt yuvj420p c1.mp4 to create the first video the second video does not display. [18:53:27 CEST] <c_14> try adding -profile:v baseline [18:58:38 CEST] <zyclonicz> How do I add a thumbnail in the beginning of my webm? [19:06:32 CEST] <lindylex> c_14: the out.mp4 http://mo-de.net/d/fh/ is so strange. I looks like it is skipping frames but it does show up. [19:07:03 CEST] <lindylex> c_14: this is what I used to create the first video : ffmpeg -loop 1 -framerate 30000/1001 -i cornerFinalBlack.png -profile:v baseline -c:v libx264 -t 5 -pix_fmt yuvj420p c1.mp4 [19:09:10 CEST] <The_8472> zyclonicz: mkvpropedit foo.webm --add-attachment "thumb.jpg" [19:11:01 CEST] <The_8472> although that might be a non-compliant webm [19:11:12 CEST] <The_8472> mkv is a superset [19:11:39 CEST] <nicolas17> wouldn't webm players ignore any mkv thing they don't support? [19:11:54 CEST] <The_8472> yeah [19:12:15 CEST] <The_8472> but it also means they won't show the thumbnail he wants [19:17:48 CEST] <atomnuker> I just insert 1-frame video packets to serve as cover art [19:18:09 CEST] <atomnuker> any proper player will correctly display the 1 frame and still continue to play the audio [19:18:12 CEST] <The_8472> that might be annoying when they loop. you would need VFR to make it zero-duration [19:18:34 CEST] <atomnuker> mpv doesn't loop [19:18:56 CEST] <atomnuker> it would only loop once it reaches the last stream's packet [19:19:31 CEST] <The_8472> just saying that solution is not universal. he asked about webm, so i assume it's for... well... web use. [19:23:00 CEST] <atomnuker> all web browsers handle it correctly [19:23:16 CEST] <atomnuker> and I really do mean it, the only player that won't handle it correctly is vlc [19:23:25 CEST] <atomnuker> which doesn't handle many things correctly like colorspace [19:23:56 CEST] <atomnuker> (its because vlc nih their demuxers rather than use libavformat) [19:24:12 CEST] <atomnuker> so its pretty universally supported [19:27:01 CEST] <The_8472> I mean... what do they do when you loop it? do they flash that one frame? [19:27:28 CEST] <The_8472> that's why I meant you need to make it 0-duration [19:31:32 CEST] <lindylex> c_14: the solution I have to convert them like this ffmpeg -i c2.mov -c copy -bsf:v h264_mp4toannexb -f mpegts i2.ts and concat the .ts files. [19:33:06 CEST] <atomnuker> The_8472: no, you don't get it [19:33:43 CEST] <atomnuker> the decode video, they present it, they run out of packets of video to present so they don't decode it again, they don't draw it again, they do nothing to the video surface [19:34:30 CEST] <atomnuker> they just leave the surface as is once they decode the last video frame, so it sticks [19:34:57 CEST] <The_8472> that only works if you want to play audio with cover art. not have a video with a specific thumbnail [19:35:12 CEST] <atomnuker> what do you mean, a specific thumbnail? [19:35:27 CEST] <The_8472> websites thumbnail videos [19:35:48 CEST] <atomnuker> yes, they take the first frame [19:35:54 CEST] <atomnuker> so they take the cover art [19:36:02 CEST] <The_8472> well, if you want to customize it you need to do something else [19:36:10 CEST] <The_8472> cover art is not the same thing [19:36:22 CEST] <The_8472> cover art is dedicated metadata for that sole purpose [19:37:02 CEST] <atomnuker> nothing on the internet supports cover arts muxed in webms [19:37:11 CEST] <atomnuker> so that's why the hack exists [19:38:12 CEST] <The_8472> yes, but that's cover art. not a video thumbnail. different things. [19:38:49 CEST] <nicolas17> cover art is for music [19:40:05 CEST] <atomnuker> it'll appear as a thumbnail if muxed this way [21:24:16 CEST] <lilibox> hi, i would like to make conversion and archiving some files grabbed to .mpg from DV source, could anybody recomende me, please, which format and which setting is optimal these days? I would like to have standard 2k resolution as output, decent color correction and maybe deinterlacing, here are input format parameters [21:24:21 CEST] <lilibox> https://pastebin.com/zsnEznEA [21:24:57 CEST] <lilibox> pretty thank you for any advice points me to success :) [21:33:53 CEST] <DHE> well that's not 2k content. why upscale it? [21:35:16 CEST] <lilibox> upscale is no needed then [21:47:40 CEST] <kantlivelong> is there some issue with recording from pulse device? i get a crazy amount of stuttering [21:47:59 CEST] <kantlivelong> seems okay with some devices but my 48k optical its throwing up wiht [21:49:46 CEST] <nicolas17> okay! [21:51:58 CEST] <nicolas17> https://paste.kde.org/pt8uuzaey here's my source code [21:52:26 CEST] <nicolas17> https://paste.kde.org/pbmytvmit the output video is much larger than what I get with ffmpeg.c despite using the same x264 crf [21:54:09 CEST] <nicolas17> clearly I'm doing something wrong with the ffmpeg API to get such different output... [21:59:09 CEST] <nicolas17> omg I think I just figured it out, if I make outCodecCtx->time_base and outputVideoStream->time_base the same, the file size becomes correct [22:00:53 CEST] <nicolas17> but why? I'm not even using bitrate, I'm using crf [22:38:09 CEST] <thebombzen> nicolas17: timebase refers to the timestamps of frames, not the bitrate [22:38:32 CEST] <thebombzen> my guess is that libavformat is duplicating or dropping frames if your timebase is incorrect [22:38:42 CEST] <thebombzen> causing the actual amount of encoded data to be different [22:40:51 CEST] <nicolas17> thebombzen: as you can see in the paste, the size of *each* frame is bigger [22:41:16 CEST] <nicolas17> pkt_pts=0 pict_type=I pkt_size=30895 with ffmpeg.c [22:41:29 CEST] <nicolas17> pkt_pts=0 pict_type=I pkt_size=80392 with my program not setting that time_base properly [22:42:04 CEST] <thebombzen> That's not a surprise, because x264 is receiving different data and has quality-based ratecontrol [22:42:54 CEST] <thebombzen> with dups, bframes work better with accurate references so using mroe data on an iframe makes sense [22:43:52 CEST] <nicolas17> both videos have the same number of frames and packets (confirmed with ffprobe -show_frames -show_packets) [22:44:15 CEST] <nicolas17> only their sizes differ [22:46:17 CEST] <thebombzen> possibly relevant is the difference between AVC1 and Annex-B formatting [22:46:38 CEST] <thebombzen> er, AVCC and Annex-B [22:47:16 CEST] <nicolas17> yeah, I can't figure that one out either... how do I make my code output avcc like ffmpeg.c is? and why does it matter? :/ [22:47:18 CEST] <thebombzen> also notice the set framerate is wrong in your (incorrect) program encode [22:47:25 CEST] <thebombzen> it says 30.15 [22:47:38 CEST] <thebombzen> the solution is something you already figured out though. which is to make sure the timebase is correct [22:48:24 CEST] <nicolas17> which of the three timebases? there's AVStream.time_base, AVCodecContext.time_base for the encoder I create, and AVStream.codec.time_base which is deprecated but still causes yet another difference if I tweak it [22:49:17 CEST] <nicolas17> I get correct fps in ffprobe if I set the AVStream.codec.time_base to {1,30} [22:50:21 CEST] <nicolas17> if I set all three timebases to {1,15360}, ffprobe reports 30.30fps [22:54:46 CEST] <thebombzen> I would recommend against changing the deprecated one [22:54:54 CEST] <thebombzen> but otherwise, I don't know [22:56:36 CEST] <nicolas17> the extradata difference also makes me think I'm doing something different from ffmpeg.c, but despite lots of source code grepping I can't figure out what it is [23:01:44 CEST] <CoJaBo> VP9 apparently confuses the hell out of me :/ [23:02:32 CEST] <CoJaBo> Does the 2-pass encoding actually do anything (and if so, what) when using -crf without a bitrate? [23:03:14 CEST] <CoJaBo> Also, -speed -8 is supposed to be "slowest possible encoding"; why is it encoding faster than x264 veryfast? >_> [23:03:17 CEST] <thebombzen> CoJaBo: when using crf, 2-pass shouldn't do anything [23:03:20 CEST] <iive> 2 pass encoding should not do anything without target size [23:03:56 CEST] <thebombzen> 2-pass more accurately fits into target size. crf just uses "bits as needed" to get the right quality. doing that again doesn't help [23:09:20 CEST] <CoJaBo> thebombzen: That's what I'd thought.. a LOT of examples/guides I'm finding are listing it tho.. can someone suggest one that isn't stupid [23:11:14 CEST] <CoJaBo> (What I'm trying to do, BTW, is batch reencode a ton of videos; trying to optimize for smallest possible size with roughly-equiv quality, encoding time does not matter) [23:13:09 CEST] <CoJaBo> And current command line I'm trying, if anyone cares: -i in.wmv -c:v libvpx-vp9 -crf 50 -b:v 0 -speed -8 -c:a libopus -b:a 32000 out.webm [23:19:35 CEST] <The_8472> I think crf50 would result in pretty poor quality. [23:26:52 CEST] <Ingersol> Hello. [23:27:56 CEST] <Ingersol> what is right way to read packets from the media file - fread to buffer or something else? [23:28:28 CEST] <Ingersol> i got different examples of different versions of ffmpeg so a bit confused [23:37:49 CEST] <nicolas17> Ingersol: there are versions of ffmpeg where the API changed and the examples/documentation still used the old deprecated API, so you should look at the latest version [23:38:00 CEST] <nicolas17> Ingersol: are you reading from a file? [23:44:49 CEST] <CoJaBo> The_8472: I'm trying to find a CRF approximation for MovieMaker's default ("barf") quality setting. [23:53:43 CEST] <BtbN> barf? Sounds like something bad [23:59:08 CEST] <Ingersol> nicolas17, yep [00:00:00 CEST] --- Mon Jul 10 2017

1 0

ffmpeg-devel.log.20170708
by burek 09 Jul '17

09 Jul '17

[00:03:07 CEST] <nevcairiel> jamrial: that didnt change anything [00:03:15 CEST] <jamrial> ah well [00:04:10 CEST] <iive> well, the derective is %error, so it is expected to generate error :D [00:05:57 CEST] <jamrial> ah, guess then that yasm needs -Werror to be specified, whereas nasm doesn't [00:51:12 CEST] <mrec__> hi, anyone awake? I have a 50fps h265 video here and ffplay starts to play 25fps for the first few seconds [00:51:24 CEST] <mrec__> does anyone have an idea where this can be adjusted? [00:52:13 CEST] <mrec__> https://pastebin.com/BKZHaFKL [01:15:27 CEST] <BtbN> Don't see anything indicating 25fps there [01:16:08 CEST] <mrec__> right, but it's not decoding 50 FPS [01:16:14 CEST] <mrec__> for the first few seconds [01:16:21 CEST] <BBB> hows your cpu usage? [01:16:27 CEST] <BBB> (for the first few seconds) [01:16:40 CEST] <BBB> (or does it use hw decoding?) [01:16:56 CEST] <BtbN> ffplay can't do that, except via cuvid/qsv [01:17:00 CEST] <BtbN> but it doesn't on its own [01:17:03 CEST] <mrec__> oddly it's 27FPS, I added some debug at avcodec_decode_video2, seems like there aren't more frames available [01:17:20 CEST] <BtbN> It's probably just busy [01:17:47 CEST] <mrec__> cpu 45% [01:17:55 CEST] <BBB> Could not find ref with POC -56 isnt fatal from what I recall, right? so it will just use another existing ref? [01:18:00 CEST] <BBB> (and generate minor artifacts) [01:18:01 CEST] <mrec__> but once the video is smooth it jumps up to 100+ [01:20:36 CEST] <mrec__> the ffmpeg h265 decoder works quite well, but the video start is not good [01:24:13 CEST] <mrec__> seems like the same behaviour if I play the h265 video from a file (not streaming) [01:27:35 CEST] <iive> the laggy start is something i've seen in ffplay, but not specifically to h265 [01:27:52 CEST] <iive> i thought it might be a sync issue or something. Haven't noticed it lately. [01:28:20 CEST] <nevcairiel> ffplay isnt the most optimized player, you should not really judge it by its performance of anything [01:29:41 CEST] <mrec__> I compared ffplay with all the other players when it comes to hevc it's the only working one and the performance is better than with other players [01:30:12 CEST] <mrec__> vlc is doing some optimizations by itself it adds additional cpu load to the whole story [01:37:50 CEST] <iive> mrec__: try running some cpu graph program, like gkrellm and see if there is big cpu usage at the start. [01:38:03 CEST] <mrec__> iive: there isn't [01:38:54 CEST] <iive> then maybe the file is variable framerate and the start is slow. [01:39:22 CEST] <iive> or another possibility, it has been cut at open gop and the missing frames need a missing reference . [01:39:25 CEST] <mrec__> it has something to do with the decoding part not with the displaying part [01:40:14 CEST] <iive> try ffprobe, it might tell you more details. [01:40:36 CEST] <iive> also, ask in #ffmpeg [01:41:20 CEST] <mrec__> if I wait for the first keyframe .. the slow video will start from the point where the keyframe is available [01:42:10 CEST] <mrec__> if I don't wait for the keyframe everything's fine at the point where the keyframe is available [01:42:26 CEST] <iive> ?? [01:43:15 CEST] <mrec__> https://pastebin.com/Fvg78HeW [01:44:13 CEST] <mrec__> if I use the disabled section the slow framerate will be there for much longer [01:58:31 CEST] <mrec__> ok got it... just use sync video .. [02:04:16 CEST] <mrec__> hmm not really but it shows the problem [02:04:28 CEST] <mrec__> video is indeed smooth with it [10:43:11 CEST] <mrec__> BtbN: ok I found my problem yesterday, I'm just delaying the videoframes until it catches up with the audio timestamp [10:43:38 CEST] <mrec__> the default behaviour is a bit weird... it starts to adapt the video frames to the audio pts [11:57:01 CEST] <ubitux> so i can confirm that --x86asmexe=yasm fixes tsan [11:57:10 CEST] <ubitux> will add it to fate until it's solved [11:57:39 CEST] <ubitux> i don't know why it's messing it up so badly [11:57:45 CEST] <ubitux> even for non simd code [11:59:43 CEST] <nevcairiel> its a shame nasm seems to be collecting various issues. yasm worked basically fine for everything, except not being developed anymore and thus lacking support for new instructions [12:03:08 CEST] <cone-175> ffmpeg 03Paul B Mahol 07master:01e545d04680: avfilter: add limiter filter [12:10:10 CEST] <iive> we don't have yet avx512 assembly, do we? [12:10:15 CEST] <nevcairiel> not yet [12:10:19 CEST] <iive> aka we don't need the extra instructions. [12:10:47 CEST] <iive> well, report the bugs to nasm, it is actively developed so they will be fixed [12:13:56 CEST] <iive> what exactly is the issue with the tsan, iirc this is thread sanitizer, how does it interfere with the assembly? [12:14:30 CEST] <nevcairiel> the question rather is how or why does the assembly interfere with tsan [12:14:56 CEST] <ubitux> i'd guess that it interferes with the stack reconstruction [12:15:20 CEST] <ubitux> maybe it's adding garbage on the stack confusing the lib [12:15:56 CEST] <ubitux> but OTOH it's not related to SIMD, so it's pretty confusing [12:16:01 CEST] <iive> then in might be x86inc macro doing something diffrent on nasm, [12:16:29 CEST] <ubitux> ah, the debug flags are different! [12:16:46 CEST] <ubitux> "-g -F dwarf" vs "-g dwarf2" [12:16:54 CEST] <nevcairiel> flag syntax is just different between the two [12:17:02 CEST] <nevcairiel> both basically mean "create dwarf debug symbols" [12:17:56 CEST] <nevcairiel> but perhaps the debug info is broken [12:18:12 CEST] <iive> dwarf version matters [12:18:59 CEST] <nevcairiel> nasm only has "dwarf" or "stabs", it doesnt list a dwarf version [12:19:39 CEST] <nevcairiel> you can query nasm about its debug formats by using "nasm -f elf -y" (replace elf as appropriate, if necessary) [12:20:00 CEST] <iive> just did that :D [12:35:38 CEST] <durandal_1707> who will apply dolbye? [13:31:25 CEST] <iive> elvis, who else? [14:59:24 CEST] <kierank> field h264 decoding is a nightmare [17:22:21 CEST] <ubitux> BBB: symbols are back [17:22:56 CEST] <ubitux> (re: tsan) [17:23:39 CEST] <ubitux> and if you need them locally: --x86asmexe=yasm [18:00:30 CEST] <BBB> ubitux: ty! [18:00:37 CEST] <BBB> ubitux: wait, are you saying nasm destroys debug symbols? [18:01:30 CEST] <BBB> I cannot possibly imagine how that would go, but uh, wow, good regression tracing there [18:02:10 CEST] <jamrial> same happens with msvc it seems [18:04:22 CEST] <ubitux> BBB: yeah :p [18:14:14 CEST] <cone-175> ffmpeg 03hexpointer 07master:3fa8f263abf9: libswresample: check input to swr_convert_frame for NULL [18:51:00 CEST] <JEEB> nice perf improvement with the bit stream reader [19:30:05 CEST] <kierank> michaelni or BBB: do you know how this code works with threads: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264dec.c#L614 [19:30:21 CEST] <kierank> I want to reset sei per field pair not per field [19:31:29 CEST] <BBB> kierank: no idea, sorry [19:32:25 CEST] <BBB> atomnuker: we can enable it by default if we have evidence it actually speeds up; Im pretty sure it slows down cases where we use the low-level bitstream reader API directly [19:32:39 CEST] <BBB> atomnuker: as a general rule, evidence always beats feelings [19:46:39 CEST] <kierank> funman: won't work because there can only be one type of side data per frame [19:59:18 CEST] <kierank> oh lordy the bug is even worse, the side data just leaks [20:23:01 CEST] <kierank> definitely some paff threading bugs [20:27:22 CEST] <kierank> durandal_1707: do you know about frame threads [20:27:29 CEST] <kierank> and how it works in h264 [20:28:47 CEST] <durandal_1707> i only fixed pts issues in parser [20:35:02 CEST] <BBB> kierank: I know generally how frame threading works [20:35:22 CEST] <kierank> I get weird behaviour with paff if my number of threads is mod 2 [20:35:25 CEST] <BBB> kierank: if you have a bug where frame-mt in any way produces different output than w/o frame-mt (including poc or whatever), feel free to poke me and I can check [20:35:37 CEST] <BBB> add it to trac ;) [20:36:00 CEST] <kierank> i need to find a public sample but yes I will do that if I can [20:41:42 CEST] <ubitux> so no one has a benchmark script for testing the bitstream patch? [20:42:27 CEST] <BBB> not me [20:44:15 CEST] <ubitux> actually, we just need samples [20:44:22 CEST] <ubitux> the benchmark is straightforward [20:44:28 CEST] <atomnuker> ubitux: I'll test it tonight on me old trusty rpi 1 [20:44:32 CEST] <ubitux> do we have a compilation of sample we acn use for benchmarks? [20:44:53 CEST] <ubitux> atomnuker: i have various arm32 and 64 around, so we can compile results [20:45:47 CEST] <atomnuker> I have an rpi3 gathering dust but I'll be damned if that thing can even compile ffmpeg without breaking [20:46:17 CEST] <jamrial> ubitux: maybe concat demuxer using one of the utvideo fate samples? [20:46:40 CEST] <jamrial> or create a long one [20:46:47 CEST] <atomnuker> last time I tried to install archlinux on it the images were broken [20:47:04 CEST] <ubitux> you can crosscompile it easily, crosstool-ng has preset for the rpi* [20:47:45 CEST] <ubitux> jamrial: would be nice to have a bunch of samples so we can test a wide range of codecs [20:48:30 CEST] <kierank> BBB: so general frame thread questions, does decode_frame dispatch threads or is it called by a "higher layer" in a new thread? [20:49:30 CEST] <BBB> you mean AVCodec.decode_frame()? [20:49:49 CEST] <BBB> a higher layer (pthread_frame.c) calls AVCodec.decode_frame() in separate threads [20:53:21 CEST] <kierank> ok [20:53:39 CEST] <kierank> and I guess there's a some kind of context syncing mechanism [20:58:45 CEST] <BBB> kierank: yes [20:58:52 CEST] <BBB> kierank: AVCodec.update_thread_context() [20:59:35 CEST] <kierank> BBB: my problem is i have a sample with side data on paff field 1 but currently this data is lost on output [20:59:47 CEST] <kierank> i have patched the problem but it only works with threads non mod 2 [20:59:55 CEST] <kierank> so i am going to try and understand h264dec and fix it [21:00:09 CEST] <kierank> durandal_1707: cfhd will benefit from new bitstream reader btw [21:01:15 CEST] <jamrial> kierank: wm4 had to deal with something like that with hevc recently i think [21:05:39 CEST] <BBB> kierank: like I said, need sample, incredibly hard to make generic statements without sample [21:10:43 CEST] <kierank> BBB: yeah, i'll have to ask on monday if i can share it [21:10:51 CEST] <BBB> ty [21:12:37 CEST] <kierank> is there a way to get thread id with ffmpeg's threading api? [21:14:03 CEST] <BBB> pthread_self()? [21:17:00 CEST] <kierank> ah I tried to use pthread_getthreadid_np [21:20:23 CEST] <jamrial> pthread_self() is not supported by the w32/os2 wrappers, though [21:29:46 CEST] <kierank> BBB: do you know if paff fields are decoded per thread, or merged? [21:30:14 CEST] <BBB> whatever the container does (if no parser involved), or the parser does in terms of avpacket splitting (if a parser is involved) [21:30:23 CEST] <BBB> I would expect the parser to do 1 frame (2 fields) per packet [21:30:28 CEST] <kierank> hmmmm [21:30:28 CEST] <BBB> but both can happen [21:30:33 CEST] <BBB> what container? [21:30:36 CEST] <kierank> my code sends fields [21:30:38 CEST] <kierank> but i dunno what ffmpeg does [21:30:52 CEST] <BBB> parser is in lavformat [21:30:52 CEST] <kierank> guess I have to see what the parser does [21:30:56 CEST] <BBB> so if you use only avcodec, its fields [21:31:04 CEST] <kierank> to debug I'm testing in ffmpeg.c [21:51:59 CEST] <ubitux> atomnuker: so you let down the pthread name thread? :p [21:52:12 CEST] <atomnuker> no, not yet [21:52:22 CEST] <atomnuker> just haven't had time to fx it [21:52:30 CEST] <atomnuker> not that there's anything to fi [21:52:35 CEST] <atomnuker> *fix [23:31:09 CEST] <leif> I'm trying to build ffmpeg with openh264 support. I keep getting the error: "ERROR: openh264 not found using pkg-config" [23:31:32 CEST] <leif> I have added the openh264 directory to my PKG_CONFIG_PATH. [23:31:57 CEST] <leif> for example: "$ pkg-config --libs openh264 [23:31:58 CEST] <leif> -L/usr/local/lib -lopenh264y [23:32:27 CEST] <leif> I've also tried building it with: ./configure --enable-shared --disable-sdl2 --disable-indev=jack --libdir='@loader_path' --enable-libopenh264 --pkgconfigdir=/Users/leif/src/openh264 [23:32:50 CEST] <leif> Does anyone have any suggestions how I can tell ffmpeg's configure script where to find the openh264 pkg-config pc file? [23:34:36 CEST] <BtbN> check the config log [23:38:08 CEST] <leif> BtbN: Oh interesting. pkg-config --exists --print-errors openh264 returns nothing, even though pkg-config --libs openh264 does. [23:38:34 CEST] <BtbN> returning nothing seems like a success to me? [23:39:39 CEST] <leif> Ah, good point. [23:41:06 CEST] <leif> BtbN: Here is the full log: https://gist.github.com/LeifAndersen/7b59aa17c96956038aaa685c38dd7ebc [23:42:43 CEST] <BtbN> fatal error: 'wels/codec_api.h' file not found [23:42:52 CEST] <BtbN> it's missing its includes, not the pkg-config module. [23:44:58 CEST] <leif> I see. It 'should' be in: codec/api/svc/codec_api.h, perhaps if I add it to the include dirs... [23:45:05 CEST] <leif> (I thought pkg-config took care of that.) [23:46:33 CEST] <cone-598> ffmpeg 03Michael Niedermayer 07master:2061de8a3f73: avcodec/sbrdsp_fixed: Fix integer overflow in sbr_hf_apply_noise() [23:46:33 CEST] <cone-598> ffmpeg 03Michael Niedermayer 07master:fe9242204d33: avcodec/ylc: Fix vlc of 31 bits [23:46:50 CEST] <leif> OHOHOH, okay. [23:47:02 CEST] <leif> THe pkg-config file for openh264 is wrong. [23:47:11 CEST] <leif> That makes sense... [23:47:27 CEST] <leif> Thank you [00:00:00 CEST] --- Sun Jul 9 2017

1 0

ffmpeg.log.20170708
by burek 09 Jul '17

09 Jul '17

[00:00:33 CEST] <thebombzen> CFS-MP3: consider the setsar or setdar filter [00:00:39 CEST] <furq> he is using setdar [00:00:46 CEST] <thebombzen> ah you are, I didn't read that [00:01:07 CEST] <furq> fyi you can still chain filters together in filter_complex [00:01:13 CEST] <furq> you don't need labelled outputs for every single filter [00:01:32 CEST] <relaxed> he probably needs setsar too [00:01:36 CEST] <CFS-MP3> furq I do that a bit for clarity (for myself) [00:02:00 CEST] <furq> [0:v][0:s]overlay,scale=416:-1:flags=lanczos,setdar=dar=16/9,split=2[in1][in2] [00:02:04 CEST] <CFS-MP3> setdar seems to only apply for the ouput video, but is ignored for the output .jpg (apparently) [00:02:06 CEST] <furq> maybe it's just me but that reads much more clearly [00:02:09 CEST] <relaxed> fir non-square pixels [00:03:26 CEST] <thebombzen> CFS-MP3, that's not a surprise. Consider take your final output (I will call it [out] here for clarity) and then use "[out]split[out1][tempout2];[tempout2]fps=1/10[out2]" [00:03:40 CEST] <thebombzen> then map [out1] and map [out2] as appropriate [00:03:50 CEST] <furq> i don't think setdar will do anything for images [00:04:03 CEST] <thebombzen> This is also the case, yea. JPEG images don't understand DAR [00:04:18 CEST] <thebombzen> you will have to insert a scale filter if you really want to do that [00:04:30 CEST] <furq> setdar just sets a flag in the bitstream iirc [00:04:36 CEST] <furq> so if the codec doesn't have that, it won't do anything [00:04:36 CEST] <relaxed> he said the video is different- "but the size in the player is different" setsar=sar=1/1,setdar=dar=16/9 [00:04:41 CEST] <CFS-MP3> I figured that... so how to do emulate the behavior (i.e. create a image that will look as a video frame)? [00:05:07 CEST] <furq> relaxed: 23:02:04 ( CFS-MP3) setdar seems to only apply for the ouput video, but is ignored for the output .jpg (apparently) [00:07:59 CEST] <furq> you'd probably need to scale the second split output relative to ih [00:08:29 CEST] <furq> scale=ih*(16/9):ih [00:08:45 CEST] <furq> except you'll probably have to make it mod2 [00:09:41 CEST] <nicolas17> what the heck is is_avc in h264 anyway? [00:10:31 CEST] <CFS-MP3> mod2? [00:10:34 CEST] <CFS-MP3> ah yes [00:11:10 CEST] <thebombzen> nicolas17: AVC is another name for H.264 [00:11:37 CEST] <thebombzen> so is_avc is most likely "is this thing even h264?" although I'm not sure what "is" means in this case [00:11:49 CEST] <nicolas17> typedef struct H264Context { [00:11:50 CEST] <nicolas17> /** Used to parse AVC variant of H.264 */ [00:11:52 CEST] <nicolas17> int is_avc; ///< this flag is != 0 if codec is avc1 [00:12:11 CEST] <nicolas17> (not actually the first member, I trimmed a hundred things) [00:12:19 CEST] <thebombzen> well that's weird cause the full name of the codec is H.264 / MPEG-4 AVC. [00:12:39 CEST] <nicolas17> looks like is_avc is set differently depending on nal_length_size [00:12:41 CEST] <thebombzen> although avc1 is not the same thing as avc [00:13:00 CEST] <furq> isn't that start code prefixed [00:13:00 CEST] <thebombzen> avc1 IIRC is a special subset of H.264, but you should get a second opinion on that [00:13:03 CEST] <furq> as opposed to annex b [00:13:27 CEST] <nicolas17> so focusing on nal_length_size instead: I wonder why ffmpeg-generated video has it set to 4 and my code ends up with 0 [00:13:35 CEST] <nicolas17> ffmpeg = command line tool [00:21:57 CEST] <Nicolas_> thebombzen: no. that didn't work. just as slow as before. maybe I made a mistake when compiling the codec? [00:22:34 CEST] <thebombzen> I don't know at this point without delving deeper [00:22:43 CEST] <Nicolas_> sigh [00:22:49 CEST] <Nicolas_> thx anyways [00:22:58 CEST] <thebombzen> Someone else might know, but I don't use macOS so you're reaching the end of my knowledge [00:23:16 CEST] <Nicolas_> sure [00:23:18 CEST] <thebombzen> nicolas17: for future reference, often we use the term "ffmpeg.c" to refer to the CLI tool as opposed to the FFmpeg project [00:23:33 CEST] <nicolas17> great [00:24:19 CEST] <CFS-MP3> furq, can this resize be optimized? [overlaid]scale=iw*sar:ih[scale1];[scale1]scale=416:-1:flags=lanczos[resized];[resized]setdar=dar=16/9[vdar]; [00:24:42 CEST] <CFS-MP3> I tried the obvious thing but it complained about width not being divisible by 2 [00:25:00 CEST] <CFS-MP3> however that is doing what I need [00:25:02 CEST] <nicolas17> looks like furq is right, that is_avc thing is indeed for annex-b vs... not [00:25:06 CEST] <CFS-MP3> Got the topic here: https://lists.ffmpeg.org/pipermail/ffmpeg-user/2011-November/003203.html [00:25:49 CEST] <Nicolas_> CFS: try scale=416:-2? [00:28:06 CEST] <CFS-MP3> Nicolas: Tried that, doesn't help... [00:28:21 CEST] <CFS-MP3> basically what I'd like now obviously is to have one scale, not two [00:28:43 CEST] <Nicolas_> CFS: k. sorry. [00:29:30 CEST] <AndrewMock> Can ffmpeg downmix DTS-HD-MA or TrueHD to 2.0 using the embededd coefficients? [00:32:54 CEST] <CFS-MP3> OK I think this could work: 416:ih*416/iw*sar [00:37:44 CEST] <CFS-MP3> Nah... height not divisible by 2 (416x495) [00:45:32 CEST] <nicolas17> urgh this makes no sense [00:49:15 CEST] <CFS-MP3> Solved the division thing which is as trivial as doing a trunc(.../2)*2 [00:49:30 CEST] <CFS-MP3> but definitely I didn't solve the height correctly, now I have a square [00:49:53 CEST] <CFS-MP3> anyway I'm on the right track, just need to do the math properly :-) [00:50:22 CEST] <CFS-MP3> Ah wait I think I know that it is [00:55:09 CEST] <nicolas17> https://paste.kde.org/phoqw9x9n D: [00:59:34 CEST] <CFS-MP3> This is doing a good job: scale=416:trunc ((ih*416/(iw*sar))/2)*2:flags=lanczos [00:59:43 CEST] <furq> CFS-MP3: you should just need one scale=416:234 [00:59:55 CEST] <furq> if you just want 16:9 output [01:00:29 CEST] <CFS-MP3> furq the problem with that is that the .jpg and the .mp4 have different real (by this I mean as displayed) sizes [01:00:58 CEST] <furq> you mean they do now or you want them to [01:01:22 CEST] <CFS-MP3> that was what happened with a trivial resize like 416:-1, or -2, or 234 [01:01:41 CEST] <CFS-MP3> however "converting to square pixels" solves the problem apparently [01:04:50 CEST] <relaxed> furq: I win ? [01:40:05 CEST] <nicolas17> furq: any idea why my program could be producing much bigger files than ffmpeg.c, if it's using the same x264 parameters? https://paste.kde.org/phoqw9x9n [01:40:21 CEST] <nicolas17> I need to get rid of all my C++ wrappers and go back to plain C and post the source [01:52:17 CEST] <dystopia_> diff framerate and diff bitrate [01:52:31 CEST] <dystopia_> what were your ffmpeg commands? [01:53:00 CEST] <dystopia_> i think the decimation screwed things up to get weird framerate [01:53:10 CEST] <dystopia_> but that wouldnt really affect the bitrate [01:56:40 CEST] <nicolas17> I'm using crf 23 [01:56:45 CEST] <nicolas17> in both [01:57:24 CEST] <nicolas17> ffmpeg.c command line: ffmpeg -y -f image2 -pattern_type glob -framerate 30 -i "168GOPRO/G00187*.JPG" -r 30 -s 640x480 -vcodec libx264 -crf 23 -preset fast -pix_fmt yuv420p ffmpeg.mp4 [01:58:39 CEST] <dystopia_> is source video already 4:2:0 ? [01:59:24 CEST] <nicolas17> source is yuvj422p [01:59:30 CEST] <dystopia_> ahh ok [02:00:03 CEST] <nicolas17> in my encoder I'm passing it through a SwsContext with AV_PIX_FMT_YUV420P output [02:00:05 CEST] <dystopia_> well the ffmpeg command ^ seems to be working [02:00:27 CEST] <dystopia_> your app has the higher bitrate and the 30.15fps [02:00:40 CEST] <dystopia_> so somthing funky is going on in it's input settings [02:01:17 CEST] <nicolas17> would bitrate matter if I'm using crf? [02:02:37 CEST] <dystopia_> crf would lead to diff bitrates, but both are crf23 so i think it's somthing else [02:02:57 CEST] <nicolas17> and if I was using bitrate, a bad framerate would affect file size (since bitrate is set per second, not per frame), but since I'm using crf that shouldn't matter either [02:04:13 CEST] <dystopia_> yeah [02:04:32 CEST] <dystopia_> but somthing is causing your apps bitrate to be 5x ffmpeg.c's [02:05:25 CEST] <nicolas17> I just tried setting AVStream.avg_frame_rate={30,1}, it made no difference in either file size or ffprobe's reported fps [02:06:03 CEST] <dystopia_> hmmm [02:06:47 CEST] <dystopia_> ffmpeg.c = is_avc=true | your app = is_avc=false [02:06:50 CEST] <dystopia_> very weird [02:07:01 CEST] <dystopia_> cuz both have x264 header [02:07:22 CEST] <nicolas17> dystopia_: apparently is_avc is related to the extradata [02:08:01 CEST] <dystopia_> ahh [02:08:17 CEST] <dystopia_> yeah im out of ideas :| hopefully someone else can help you [02:08:19 CEST] <nicolas17> http://aviadr1.blogspot.com/2010/05/h264-extradata-partially-explained-for.… [02:08:25 CEST] <The_8472> is there a way to seek a stream and then get the current frame number it has seeked to? most things refer to timestamps, but that doesn't take VFR into account. [02:09:39 CEST] <The_8472> in libav* [02:09:56 CEST] <nicolas17> dystopia_: "why is one using avcc extradata and the other using annex-b extradata" *is* another question though [02:10:03 CEST] <nicolas17> but that shouldn't affect bitrate either [06:33:06 CEST] <hiihiii> hello [06:33:33 CEST] <hiihiii> I'm trying to run ffmpeg through a server but I'm facing issues [06:34:32 CEST] <hiihiii> here's my command [06:34:33 CEST] <hiihiii> -f lavfi -i testsrc=duration=15:size=480x360:rate=30 -c:v libx264 -vf "format=yuv420p" -movflags +faststart testsrc.mp4 [06:34:46 CEST] <hiihiii> here's my output [06:35:29 CEST] <hiihiii> https://thepasteb.in/p/RghnZjmW8OVFz [06:36:15 CEST] <nicolas17> dystopia_: I found one difference, ffmpeg.c was using bicubic resizing and I was using bilinear... but using bicubic myself made the difference in bitrate even bigger! [06:36:59 CEST] <furq> hiihiii: ulimit -u [06:37:46 CEST] <hiihiii> furq: sorry wut??? [06:38:00 CEST] <furq> what's the output of ulimit -u [06:41:30 CEST] <hiihiii> 1400 [06:41:47 CEST] <kepstin> The_8472: the only way to get frame numbers in general is to demux each frame from the start and count them. If you seek, you have no idea how many frames you skipped over, that information's not stored in the container index. [06:42:26 CEST] <kepstin> (if you know that the video is CFR, you can calculate which frame you ought to be on given the timestamp) [06:46:20 CEST] <furq> hiihiii: try increasing that [06:46:25 CEST] <furq> e.g. ulimit -u 8192 [06:46:56 CEST] <furq> failing that, try adding -threads 1 [06:47:18 CEST] <furq> if that doesn't work then you probably want to break out strace [06:49:11 CEST] <hiihiii> fruq : https://thepasteb.in/p/y8h6VqXx8jBIO [06:51:28 CEST] <hiihiii> -threads did work [07:00:41 CEST] <hiihiii> not sure what you meant by your last sentence though [07:12:59 CEST] Action: nicolas17 throws in the towel [07:23:26 CEST] <Tatsh> how come ffmpeg takes a while when using -ss ? [07:23:30 CEST] <Tatsh> doesn't seem like it should be that slow [07:23:45 CEST] <Tatsh> i'm skipping ahead like an hour [07:24:01 CEST] <hiihiii> put -ss before input [07:26:02 CEST] <Tatsh> wow, way faster [07:35:40 CEST] <hiihiii> how can you upload to a server with ftp(host+user+pw info) or any other way? [07:38:00 CEST] <hiihiii> I read about this [07:38:02 CEST] <hiihiii> ftp://[user[:password]@]server[:port]/path/to/remote/resource.mpeg [07:38:41 CEST] <hiihiii> but I wonder will there be any issues of timeout [07:46:07 CEST] <tdr> most sane admins disable ftp though [07:46:18 CEST] <tdr> scp or sftp or rsync or ... [10:49:45 CEST] <hiihiii> I am trying to output directly to a remote server via ftp [10:50:59 CEST] <hiihiii> my input is located on a server too [10:51:54 CEST] <hiihiii> and I'm running my commands through a server [10:53:35 CEST] <hiihiii> -i input.mp4 -c copy "ftp://USERNAME:PASSWORD@HOST:PORT/path/output.mp4" [10:56:26 CEST] <hiihiii> https://thepasteb.in/p/k5hYG8PVY6MtE [11:00:32 CEST] <hiihiii> I tried setting ftp-write-seekable to 1 but still no results [11:01:57 CEST] <hiihiii> the final line I get from this command is : [11:01:58 CEST] <hiihiii> video:2890kB audio:1226kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [11:03:12 CEST] <hiihiii> that tells me it had done its job, however, I can't find the output [11:04:46 CEST] <hiihiii> ah solved [11:05:01 CEST] <hiihiii> I forgot to set my permissions [20:54:36 CEST] <hiru> there is something wrong with my ffmpeg conversion. I'm converting a mkv to mp4 but the resulting file has not thumbnail and makes premiere pro crash [20:55:11 CEST] <hiru> this is the command I used: ffmpeg -i "input" -ss 9.250 -to 16 -c:v libx264 -b:v 12000K -vf "crop=500:300:700:350" "output" [20:57:51 CEST] <hiru> the input source is a obs recording and it is using this config: color i444, yuv 709, yuv range partial, 12mbps cbr, cpu preset ultrafast [20:58:27 CEST] <hiru> webm conversions are totally fine, the only problem is with the libx264 [21:00:01 CEST] <BtbN> "has no thumbnail"? [21:00:11 CEST] <BtbN> I don't think mp4 has an embedded thumbnail in general. [21:00:24 CEST] <hiru> well I thought it was weird so I mentioned it [21:00:41 CEST] <hiru> I'm talking about the windows file explorer btw [21:00:57 CEST] <hiru> the video plays fine but if I try to import in a premiere pro project the whole thing crashes [21:00:58 CEST] <BtbN> did you interrupt ffmpeg while creating the mp4? [21:01:09 CEST] <hiru> nope [21:01:19 CEST] <hiru> when I convert the same file with handbrake it works fine [21:01:39 CEST] <hiru> and the file shows a thumbnail [21:02:00 CEST] <BtbN> try forcing yuv420p [21:02:05 CEST] <hiru> I'm mentioning file thumbnails becasue generally videos without thumbnails are corrupted [21:02:07 CEST] <BtbN> 444 isn't exactly well supported [21:03:28 CEST] <hiru> oh it worked :O forcing yuv420p generated a working file [21:04:53 CEST] <BtbN> the old file was working fine just as well [21:05:02 CEST] <BtbN> Just broken software crashing at the sight of yuv444 [21:05:46 CEST] <hiru> uhm actually ffmpeg converted it without errors [21:05:58 CEST] <BtbN> ffmpeg is not the broken part here. [21:06:02 CEST] <hiru> oh [21:06:06 CEST] <BtbN> The software that crashed is. [21:06:22 CEST] <hiru> but it's not just the software I think [21:06:29 CEST] <hiru> otherwise the file won't look corrupted [21:06:42 CEST] <hiru> speaking of how it is showed in the file explorer [21:06:45 CEST] <BtbN> The Windows-Thumbnailer aparently also does not support yuv444 [21:06:53 CEST] <BtbN> That does not make the file corrupted [21:07:08 CEST] <hiru> not using that thumbnailer tho [21:07:12 CEST] <hiru> how it is called again [21:07:30 CEST] <hiru> icaros [21:07:37 CEST] <hiru> using that [21:07:45 CEST] <BtbN> You are using Windows Explorer. So you are using Windows capabilities to generate thumbnails of various filetypes [21:07:51 CEST] <BtbN> yuv444 is seemingly not on that list [21:08:13 CEST] <hiru> icaros generates the thumbnails windows explorer can't generate tho [21:08:28 CEST] <BtbN> Well, doesn't seem to work too well for yuv444 either. [21:09:11 CEST] <hiru> I can't tell unfortunately [21:09:24 CEST] <hiru> anyway thanks for pointing me in the right direction [21:09:32 CEST] <hiru> now I know what it was not working [21:09:53 CEST] <furq> i'm surprised premiere can't handle yuv444p [21:10:00 CEST] <furq> not too surprised though [21:11:30 CEST] <hiru> I'll record a mp4 file with yuv444p [21:11:33 CEST] <hiru> I'll tell you what happens [21:11:49 CEST] <JEEB> adobe things tend to use mainconcept's decoder for AVC, which means it will work up to 4:2:2, 10bit [21:11:53 CEST] <JEEB> not 4:4:4 as far as I know [21:12:06 CEST] <furq> yeah i'd have been more surprised if it didn't do 4:2:2 [21:12:17 CEST] <JEEB> most corporate decoders don't [21:12:22 CEST] <furq> that's a lot more common for editing isn't it [21:12:32 CEST] <JEEB> for editors I'd probably recommend ut video since it has modules for most of those closed source frameworks [21:12:47 CEST] <JEEB> it's huge because it's not made for high compression or !lossless [21:12:53 CEST] <furq> is premiere still using quicktime/vfw [21:13:11 CEST] <JEEB> yea, for AVI it uses VFW as far as I know, and on macs it's QT based I bet [21:13:32 CEST] <JEEB> I'd recommend ffv1 if someone made those modules for it, but alas that's not the case :P [21:13:35 CEST] <furq> yeah [21:13:51 CEST] <furq> ut is quite good anyway isn't it [21:14:18 CEST] <JEEB> as a lossless format it does what you'd usually require. it's just simple huffman coding so it's not exactly good at compression ratios [21:14:33 CEST] <furq> oh i thought it was fancier than that [21:14:42 CEST] <furq> i've not really messed with it since ffmpeg got an encoder for it [21:14:53 CEST] <hiru> so. I generated a mp4 file with the 444 color scheme and icaros can't generate a thumbnail for it and premiere pro can't open it, crashing as well [21:14:58 CEST] <hiru> so it isn't a ffmpeg problem [21:15:02 CEST] <JEEB> furq: I wrote the initial version of the FFmpeg encoder :D [21:15:16 CEST] <furq> this was so long ago that i was probably using the vfw codec with fraps [21:15:32 CEST] <JEEB> yea, umezawa's done an alright job with it [21:15:50 CEST] <JEEB> it's just GPL so no code from it can be utilized unless he relicenses it for your use [21:16:59 CEST] <furq> speaking of licensing lossy codecs [21:17:09 CEST] <furq> s/y/less/ [21:17:13 CEST] <furq> does anyone use those stupid closed source lossless codecs like magicyuv [21:17:34 CEST] <JEEB> I bet someone does. durandal_1707 seems to have been reverse engineering them for decoding purposes [21:17:40 CEST] <furq> neat [21:18:10 CEST] <furq> i assume someone is using them for video because i've seen more than one TAK album in the wild [21:18:20 CEST] <furq> and why would you ever do that [21:18:38 CEST] <JEEB> same as for APE [21:18:51 CEST] <JEEB> "zomg this format gives me X per cent better compression ratio" [21:19:46 CEST] <furq> ape is actually open source though isn't it [21:19:53 CEST] <furq> it's just gpl incompatible because the author's an idiot [21:19:58 CEST] <JEEB> I don't remember exactly :P [21:20:08 CEST] <JEEB> but if the license is what it is then it has to be more or less RE'd [21:20:25 CEST] <durandal_1707> im writing magicyuv encoder [21:20:34 CEST] <furq> apparently it's open source, it has a clause in the license that says you can use it in gpl projects, but then the rest of the license is gpl incompatible [21:20:45 CEST] <JEEB> durandal_1707: lol [21:20:52 CEST] <furq> durandal_1707: is it any good [21:21:05 CEST] <furq> the codec, i mean [21:21:34 CEST] <durandal_1707> its very fast lossless codec [21:21:37 CEST] <furq> the guy who wrote it is incredibly bullish about it but i've never tried it [21:46:25 CEST] <leif> Does the mp4 codec require a header/footer beyond just what av_write_trailer does? [21:46:54 CEST] <leif> I ask because videos I create (using the C API) seem to play in VLC but not mplayer. [21:47:34 CEST] <DHE> container? [21:49:12 CEST] <leif> DHE: WOops ya, the mp4 container. [21:49:18 CEST] <leif> h264 video codec and aac audio codec. [21:49:26 CEST] <leif> (ffprobe can handle the output just fine) [21:50:29 CEST] <leif> Oh, also, woops, I meant quicktime player can't play it. [21:50:34 CEST] <leif> VLC and mplayer can play it just fine. [21:51:19 CEST] <JEEB> what sort of colorspace are you using for AVC? are you using fragments or not for the container? [21:51:46 CEST] <DHE> that is very likely. quicktime and a lot of vendor decoders only handle yuv420 [21:51:58 CEST] <leif> yuv420p [21:52:12 CEST] <leif> I'll paste the output of ffprobe [21:52:26 CEST] <holgersson> thebombzen_: Hi, just as an info: VLC did play this awfully corrupted files suprisingly well - and transcoding with it worked. Dunno why ffmpeg works in this case though. [21:52:37 CEST] <holgersson> *these [21:54:44 CEST] <leif> JEEB: DHE Here is the output of ffprobe: https://gist.github.com/LeifAndersen/81f3dcd5f3e4bd69955afbcf127b23e5 [21:55:48 CEST] <JEEB> oh, mpeg-4 part 2 video? I'm actually not sure if QT supports that one [21:55:57 CEST] <JEEB> try with AVC with libx264 for shits and giggles [22:00:41 CEST] <leif> Testing. [22:01:02 CEST] <leif> (It'll take a bit because I was linking against a build of ffmpeg that didn't have x264) [22:01:32 CEST] <leif> JEEB: HA, nice. It worked. [22:01:55 CEST] <leif> Thank you. [22:02:00 CEST] <JEEB> np [22:02:09 CEST] <leif> I presume ffmpeg needs x264 to output h264 then? [22:02:40 CEST] <JEEB> there are some other encoders if you cannot comply to the GPL as well [22:02:43 CEST] <JEEB> such as openh264 [22:03:08 CEST] <JEEB> but generally the best quality/perf is gotten from libx264 [22:03:17 CEST] <JEEB> but it is GPL of course [22:04:11 CEST] <leif> Its more that I am trying to bundle the libs with my application. [22:04:21 CEST] <leif> (currently apache, but I don't mind making it gpl) [22:04:45 CEST] <leif> But that just means I have a whole other dependency chain to go down for x264. :) [22:04:53 CEST] <leif> Anyway, thank you again. That was extremely helpful. [22:05:00 CEST] <JEEB> x264 should be pretty self-contained :) [22:05:37 CEST] <JEEB> (you don't need the command line app which might link to FFmpeg as well) [22:06:12 CEST] <leif> That makes sense. Thanks a bunch, ths has ben extremely helpful. [23:35:39 CEST] <buu> Why does ffmpeg occasionally output 'File 'clone.mkv' already exists. Overwrite ? [y/N] Not overwriting - exiting' without ever asking for input? [23:36:07 CEST] <nicolas17> maybe you have stdin redirected to something else [23:37:01 CEST] <buu> I actually don't [23:37:10 CEST] <buu> My terminal might be slightly busted though [23:37:52 CEST] <thebombzen_> Fenrirthviti: I didn't figure out what software H.264 encoder it's using. The MP4 metadata didn't say. It's not x264 though. (Unless they're doing dubiously legal things and stripping the SCSI so nobody knows... but that's unlikely.) [23:38:29 CEST] <Fenrirthviti> huh, weird. [23:38:42 CEST] <thebombzen> The WebM encoder is vp8/vorbis regardless of the resolution. They should be using Opus, although they already had libvorbis linked probably [23:38:42 CEST] <Fenrirthviti> thanks for the info though [23:39:32 CEST] <thebombzen> given that the game audio assets are vorbis-in-ogg, It's unsurprising that the audio is Vorbis and not Opus, but the bitrate was high (128k) so it doesn't really matter tbh [23:40:04 CEST] <thebombzen> vp8 makes sense because vp9 is slow af, although in some ways none of it really makes sense other than the H.264 hardware encoder [23:40:39 CEST] <thebombzen> I took *ages* to software encode the 4k video as vp8. I went to get a snack. The hardware encoder I just sat and watched the progress bar [23:41:20 CEST] <thebombzen> Given that every single highlight has the Overwatch logo at the end of it, you're most likely going to be temporally truncating it and re-encoding with x264 anyway if you care about that stuff [23:42:22 CEST] <thebombzen> which means that there isn't much reason to use any options other than 4k@60 fps, 3x supersample, "Ultra Quality," hardware encoded MP4 [23:42:48 CEST] <thebombzen> Even if you want 1080p, or 720p, might as well render in 4k, so when you zscale it down to 1080 or 720 you get an antialiasing effect. [23:43:54 CEST] <thebombzen> Also, because it renders in yuv420p, afaik if you use -vf zscale=1920x1080,format=yuv420p10le, it'll actually scale to 10-bit directly and correctly without scaling to 8bit and then deepening to 10. I think zscale does that [23:44:29 CEST] <thebombzen> Also, if you care about 4:4:4, rendering in 4k will produces 1080p chroma planes, so you can use -vf zscale=1920x1080,format=yuv444p (or yuv444p10le) and the chroma planes won't be scaled. [23:44:55 CEST] <thebombzen> Fenrirthviti: is that enough of an infodump lol [23:45:35 CEST] <Fenrirthviti> well it's just using nvenc for hardware if you have it, right? [23:45:44 CEST] <Fenrirthviti> wonder if it'll use quicksync/vce/amf as well [23:45:55 CEST] <thebombzen> It says "hardware encoder." It didn't specify. However NVENC is my only hardware encoder, so it definitely used that [23:46:29 CEST] <thebombzen> I tried enabling my iGPU in the bios to try that out, but it ended up screwing with my X server. I'd have to do a bit of extra configuration to figure out how to do that. [23:47:21 CEST] <thebombzen> My monitor is plugged into my 1070 and my bios has PCI1 as the primary graphics card and GRUB and Win10 work fine, but enabling the iGPU causes my X server to fail. Frustrating. [23:47:54 CEST] <thebombzen> I'd have to diagnose that but in the meantime I just leave it disabled seeing as it's not all that useful. I have no idea how good the i7-6700k's integrated GPU is but I assume "way worse than the 1070" [00:00:00 CEST] --- Sun Jul 9 2017

1 0

ffmpeg-devel.log.20170707
by burek 08 Jul '17

08 Jul '17

[00:00:13 CEST] <durandal_1707> peloverde: i dont with my code, fdkdecoder chokes [00:02:58 CEST] <peloverde> I'm not following [00:06:09 CEST] <peloverde> I'm literally seeing 0 error compared to the reference with ftp://mpaudconf:adif2mp4@ftp.iis.fhg.de/mpeg4audio-conformance/compressedMp4/al01sf_48.mp4 [00:06:24 CEST] <peloverde> (I had forgotten about the sf suffixed files, they are 960) [00:06:59 CEST] <peloverde> And it's abundantly clear that decode_spectrum_and_dequant() isn't handling 120 length windows properly [00:14:56 CEST] <kierank> J_Darnley: will publish it properly tomorrow [00:15:42 CEST] <J_Darnley> Hey, mirc flashed this time. Also: ACK [03:28:58 CEST] <cone-432> ffmpeg 03Derek Buitenhuis 07master:fde9013ab424: mpegtsenc: Don't pass NULL to memcpy [03:49:35 CEST] <cone-432> ffmpeg 03Rafaël Carré 07master:3b9cf943c97f: h264dec: remove unneeded prototype [03:49:36 CEST] <cone-432> ffmpeg 03Wan-Teh Chang 07master:dc11a467e622: ffmpeg: Fix typos in the comment for decode() ("." vs. "->") [04:06:18 CEST] <cone-432> ffmpeg 03Steven Liu 07master:23e21130bbbe: avformat/hlsenc: add warn message when use both fmp4 and single_file [04:09:54 CEST] <cone-432> ffmpeg 03Derek Buitenhuis 07master:2d417076a2a7: avformat/hlsenc: Add missing error check [04:42:41 CEST] <cone-432> ffmpeg 03Muhammad Faiz 07master:1af615683e4a: avcodec/fft_template: use ff_thread_once on costable initialization [09:47:33 CEST] <durandal_1707> peloverde: so whats missing in that spectrum function? [10:02:14 CEST] <jya> when decoding a profile 2 vp9 (10 bits YCbCr), ffmpeg colorspace gives me AVCOL_SPC_UNSPECIFIED, can I safely assume it to be Rec 2020 ? [10:03:33 CEST] <nevcairiel> there is no way to know what was used for encoding [10:03:44 CEST] <nevcairiel> unless someone put it into the bitstream [10:04:43 CEST] <jya> nevcairiel: i guess hence the "safely" bit :) [10:05:03 CEST] <jya> likely better than thinking it's BT709 [10:05:22 CEST] <nevcairiel> youtube vp9 encodes put such info in the container, might want to snoop there for info [10:06:46 CEST] <jya> right... let me see what I got from that youtube video I downloaded [10:07:46 CEST] <nevcairiel> Obviously you need to guess some colorspace, and while i've seen 10-bit 709 encodes quite a bit as well, maybe not specifically in vp9 [10:08:14 CEST] <wm4> unless there's a container or bitstream flag that something doesn't read, you can't know [10:11:12 CEST] <jya> yep, AVCOL_SPC_BT2020_NCL [10:11:37 CEST] <jya> that's reading youtube [10:12:42 CEST] Action: jya wondering what's the difference between AVCOL_SPC_BT2020_NCL and AVCOL_SPC_BT2020_CL [10:13:05 CEST] <JEEB> non-constant luminance and constant luminance [10:13:29 CEST] <JEEB> someone like hanna can tell about how CL is objectively better but everyone seems to use NCL [10:18:31 CEST] <hanna> yeah we should be using CL [10:18:40 CEST] <hanna> because the only reason not to is uh.... it's slightly more difficult to implement! [10:18:56 CEST] <hanna> you have to actually change the algorithm instead of just slapping new matrix constants onto existing code! [10:19:03 CEST] <nevcairiel> NCL is basically how shit worked for years, people are slow to change =p [10:19:13 CEST] <hanna> does that statement include anime people [10:19:17 CEST] <hanna> why aren't anime releases CL yet [10:19:24 CEST] <hanna> especially anime would benefit from this [10:19:30 CEST] <nevcairiel> anime people just jump on hype tech, not on smart tech [10:19:34 CEST] <hanna> because it *significantly* reduces color ringing due to subsampling [10:19:36 CEST] <hanna> around lines [10:19:43 CEST] <hanna> well then we know what the problem is [10:19:47 CEST] <hanna> somebody needs to hype CL [10:19:56 CEST] <hanna> make comparison screenshots, spam on /a/ and /g/ [10:20:09 CEST] <nevcairiel> also it would probably reduce playback support significantly [10:20:27 CEST] <hanna> although that being said, CL is standardized in all of the relevant standards I know [10:20:40 CEST] <hanna> so it's not like this is some hack non-standard modification [10:20:53 CEST] <hanna> CL is also a thing for HDR :D [10:21:12 CEST] <hanna> if you're going to bother implementing HDR you might as well bother implementing CL, no? [10:21:45 CEST] <hanna> (for HDR, it's called ICtCp) [10:21:53 CEST] <hanna> (and no, mpv doesn't support it yet :() [10:21:57 CEST] <hanna> (test clips welcome) [10:23:30 CEST] <nevcairiel> apparently CL loses details in the green parts of a RGB image, oddly enough [10:24:13 CEST] <nevcairiel> ITU-R BT.2246-6 has some fancy comparisons between CL and NCL [10:26:48 CEST] <hanna> oh yeah, that report is pretty damn good [10:26:59 CEST] <hanna> I lost track of the number of times I've quoted from it [10:28:06 CEST] <JEEB> nevcairiel, hanna - anime people didn't get to using CL because the input is BT.709/BT.709/BT.709 [10:28:19 CEST] <hanna> here are some of my really really old screenshots [10:28:23 CEST] <nevcairiel> guess so, noone makes native bt2020 content for anime [10:28:29 CEST] <hanna> JEEB: you can transcode between CL and NCL [10:28:32 CEST] <hanna> it's just a different representation [10:28:39 CEST] <hanna> oh I see what you mean [10:28:42 CEST] <nevcairiel> its not defined for 709 tho [10:28:46 CEST] <hanna> you mean applying CL to BT.709 is non-standard [10:29:04 CEST] <hanna> ncl.png https://0x0.st/0nM.png [10:29:05 CEST] <nevcairiel> you could put 709 into a 2020 container, but you would probably waste more "space" then you would gain [10:29:06 CEST] <hanna> cl.png https://0x0.st/0nB.png [10:29:08 CEST] <JEEB> other than UHD BD, nevcairiel - but those aren't exactly massively ripped (there's some anime in that format but it's all lol upscales) [10:29:24 CEST] <hanna> both are 4:2:0 subsampled [10:29:54 CEST] <hanna> but the boundary between green and red is much smoother for cl because it has the same luminosity [10:29:58 CEST] <hanna> just the color shifts [10:30:14 CEST] <hanna> whereas the mixing of red and green in non-constant luminance, as usual, darkens the result [10:30:43 CEST] <hanna> JEEB: 4K HDR wide-gamut anime when? [10:30:46 CEST] <hanna> seriously anime wide gamut would be amazing [10:30:55 CEST] <hanna> imagine something like katanagatari in wide gamut [10:31:25 CEST] <hanna> watching the katanagatari OP stretched to wide gamut is pretty damn impressive, although the skin tones are all off which is why you can't do it in practice [10:34:08 CEST] <JEEB> hanna: well if we get any of the UHD BD animoo ripped we will get a "properly mastered" wide gamut sample of it [10:36:08 CEST] <hanna> so they're out, just not cracked? [10:36:10 CEST] <hanna> or what [10:36:25 CEST] <hanna> anyway I expect anime studios to trail behind like 30 years here [10:36:43 CEST] <hanna> because producing wide gamut / 4K / HDR anime would mean investing in wide gamut / 4K / HDR equipment [10:44:32 CEST] <JEEB> yea, they're out but not actually available as source material [11:51:17 CEST] <nevcairiel> heh its always amusing when ISO/IEC tries to sell you a standards document, and the same standard was also published by the ITU under their own name for free [11:52:31 CEST] <nevcairiel> (in case anyone wonders, ISO/IEC 23001-8:2016 is available as ITU-T H.273) [11:54:33 CEST] <JEEB> funky [11:54:53 CEST] <JEEB> also I remember the time in 2012 when ITU-T had H.222 available for free for a while :P [11:55:01 CEST] <JEEB> that seemed to be a mistake though [11:55:15 CEST] <nevcairiel> i must've grabbed it at such a time, because i have one [12:01:41 CEST] <kierank> i have it aswell [12:03:54 CEST] <cone-863> ffmpeg 03DongHoon Kang 07master:db8f615d6866: libavcodec/htmlsubtitles.c: make tags case-insensitive [12:31:33 CEST] <J_Darnley> atomnuker: can I bug you with more questions about vc2/dirac? [12:32:36 CEST] <atomnuker> J_Darnley: don't ask to ask, just ask [12:32:50 CEST] <J_Darnley> Well, it was more "are you here" [12:35:01 CEST] <J_Darnley> How should the coeffs be arranged for the idwt? Should all the lowest be together? Should higher ones be interleaved in some fashion? [12:35:25 CEST] <atomnuker> up to you [12:35:35 CEST] <J_Darnley> What? [12:36:03 CEST] <J_Darnley> What does that mean? How can I do a transform if the coeffs are all wrong? [12:36:08 CEST] <atomnuker> the traditional way is to have them as 4 rectangles adding up to the size of the original image [12:36:58 CEST] <atomnuker> what I mean is that transform order or the way a transform is done is not important, you can do it any way you'd like [12:37:45 CEST] <atomnuker> but obviously you'd like to not have to permute the coefficients after you receive them [12:38:38 CEST] <atomnuker> vc2 sends coefficients in the traditional way, so you end up with rectangles of coefficients adding up to the size of a single slice [12:39:11 CEST] <J_Darnley> So all the lowest ones come together first in the bitstream? [12:39:19 CEST] <atomnuker> yes [12:40:29 CEST] <atomnuker> you receive an LL and you use the LH, HL, HH to upscale it to the second level from the bottom up [12:41:10 CEST] <atomnuker> then your new upscaled LL becomes the LL to use in your second level transform using LH2, HL2, HH2 [12:41:56 CEST] <atomnuker> (that's why you're not send an LL after the bottom level) [12:42:16 CEST] <atomnuker> this is exactly how the forward transforms work but in reverse [12:42:41 CEST] <atomnuker> I think the decoder uses an odd scheme where it interleaves the coefficients for some reason [12:42:52 CEST] <J_Darnley> It appears to, yes [12:43:13 CEST] <J_Darnley> The stride for the lowest level is 4 times the stride of the plane [12:44:23 CEST] <atomnuker> told ya, the encoder would've been easier [12:44:44 CEST] <J_Darnley> But kierank says the encoder already works, or something [12:44:54 CEST] <kierank> atomnuker: why is the encoder easier? [12:45:18 CEST] <J_Darnley> Okay, moving past my ignorance of how that transform works. I think understand the bitstream order... [12:45:30 CEST] <atomnuker> because the transforms are usable as-is on a per slice basis without having to write new ones [12:45:38 CEST] <atomnuker> and you know how difficult it is to write new ones [12:46:07 CEST] <iive> is this about snow? [12:46:15 CEST] <kierank> oh i see [12:46:18 CEST] <kierank> ok J_Darnley do what atomnuker says [12:46:21 CEST] <J_Darnley> iive : no vc2/dirac [12:46:58 CEST] <iive> during inital snow development i do remember that somebody did a change, making it work on a slice at a time [12:47:27 CEST] Action: J_Darnley WTFs [12:47:29 CEST] <iive> and it did also brought quite nice speed improvement, because it was more cache efficent. [12:47:50 CEST] <iive> they are all wavelets ? [12:48:27 CEST] <J_Darnley> Fuck you wavelets! [12:49:23 CEST] <atomnuker> iive: that's what I saw when I modified the vc2 encoder to do that [12:49:28 CEST] <atomnuker> it was a huge increase indeed [12:53:24 CEST] <J_Darnley> atomnuker, kierank: just so I am clear... I am supposed to modify the encoder so it does a per-slice transform rather than a whole plane transform? [12:53:32 CEST] <kierank> yes [12:56:52 CEST] <kierank> http://obe.tv/about-us/obe-blog/item/46-optimising-and-modernising-ffmpegs-… [13:08:07 CEST] <wm4> " Using git-blame to identify the last time a line was changed you can use git-show to show that patch and the message. If that wasn't related then use git-blame again on the preceding commit to see the time it was changed before then. Keep going until you discover the origin." [13:08:20 CEST] <wm4> if you use gitk it's usually just a few clicks [13:08:54 CEST] <kierank> wm4: remember you are more of a neckbeard if you do stuff a hundred times more complicated on the CLI [13:09:02 CEST] <kierank> instead of two clicks in a gui [13:09:10 CEST] <kierank> there's stuff I do in sourcetree that takes 5 commands [13:14:55 CEST] <wm4> gitk is written in tcl/tk and looks fugly, so it should be neckbeard compatible [13:17:55 CEST] <J_Darnley> I'd rather use tig but I don't know it well enough yet. Plus it can never hurt to know how to use the base tools [13:28:09 CEST] <iive> wm4: gui requires using graphic environment, xorg, wayland, mir. No video develop uses such a thing. That's also why source code and commit messages should be limited to a single text screen. [13:28:51 CEST] <iive> /s [13:28:52 CEST] <wm4> all of that is false [13:33:46 CEST] <iive> well, gui does require graphics [13:34:44 CEST] <iive> gui also change their interface from time to time. CLI is usually kept consistent for much longer. [13:36:18 CEST] <nevcairiel> should totally build a ncurses git gui just to show you! [13:36:58 CEST] <iive> nevcairiel: git <command> -i :P [13:37:28 CEST] <iive> also, does the gui tcl/tk parts get used under windows? [13:40:42 CEST] <JEEB> they can be used, although I've only ever used them under cygwin myself [13:40:54 CEST] <JEEB> I wouldn't be surprised if you could build them for native windows as well [13:42:08 CEST] <iive> but are they? becuse the gui part can easlity become a magnitude bigger than the git itself. [13:56:21 CEST] <hanna> re: test files for HDR crap, what would be the best way to dump out a single frame of a file into a new .mkv while preserving the metadata? [13:56:34 CEST] <hanna> Might try making some ICtCp files as well [14:53:36 CEST] <durandal_1707> kierank: if care for speed let work on bitstream reader? [14:56:02 CEST] <atomnuker> (not speed, latency) [15:05:05 CEST] <kierank> durandal_1707: not worried about speed, i care about sub-frame latency [15:05:59 CEST] <durandal_1707> thats very dissapointing [15:07:57 CEST] <kierank> durandal_1707: i am not getting involved in bitstream reader drama [15:08:16 CEST] <durandal_1707> im very very sad [15:13:12 CEST] <kierank> durandal_1707: Sad! [15:13:44 CEST] <durandal_1707> usa [15:14:47 CEST] <BBB> lol [15:15:11 CEST] <BBB> J_Darnley: where is blog? [15:15:55 CEST] <J_Darnley> http://obe.tv/about-us/obe-blog/item/46-optimising-and-modernising-ffmpegs-… [15:18:37 CEST] <BBB> unfortunate effect of legacy code: you dont always remember why :D [15:18:39 CEST] <BBB> indeed [15:19:19 CEST] <durandal_1707> so whats left to do? [15:19:20 CEST] <BBB> one of the nice thing about blogs is that we can write about it so its preserved forever [15:19:29 CEST] Action: funman looks for help with PAFF [15:19:32 CEST] <BBB> durandal_1707: it was pushed a few weeks ago, so in practice nothing [15:19:42 CEST] <funman> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_slice.c;h=6d… is that comparison right? [15:20:09 CEST] <funman> looking at http://streams.videolan.org/samples/V-codecs/h264/422/h264_422.ts I can see that frame_num does not increment every frame (or every 2 fields) [15:22:11 CEST] <funman> e.g. looking at 75 coded fields, I only see 14 different values of frame_num [15:22:59 CEST] <funman> reading h264 7.4.3 Slice header semantics frame_num seems more complex than the name suggests [15:25:34 CEST] Action: funman notices https://github.com/FFmpeg/FFmpeg/commit/12d96de3acf660d53d6931e2045ec21fd8a… mentions reference pictures [15:35:29 CEST] <kierank> 2:19 PM <funman> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_slice.c;h=6d… is that comparison right? [15:35:32 CEST] <kierank> that's a heuristic i think [16:05:28 CEST] <J_Darnley> WTF is this crap? How is that function pointer 0? [16:06:17 CEST] <atomnuker> durandal_1707: dirac doesn't really use any part of the bitstream reader to read coefficients [16:06:27 CEST] <atomnuker> look at libavcodec/dirac_vlc.c [16:06:54 CEST] <atomnuker> it used to, but it was not fast and was never going to be as fast as this lookup table based one [16:07:14 CEST] <atomnuker> I tried to use the vlc reader we had but couldn't figure out how to generate tables [16:07:44 CEST] <atomnuker> (even though the golomb codes are similar to the codes used in h264, they're quite different) [16:08:31 CEST] <atomnuker> and I think it would have been slower still if I had used that one [16:09:02 CEST] <atomnuker> since alot of the coefficients turn to 0 and you'd still need to run the entire decoding process on them [16:09:15 CEST] <iive> atomnuker: remind me to look up the vlc code generation, after pvq_search is committed. [16:09:56 CEST] <atomnuker> the dirac_vlc reader knows however and can SFMD multiple coefficients together [16:10:00 CEST] <iive> atomnuker: btw, they are static, right? no statistic/probability updates on them. [16:10:03 CEST] <atomnuker> (single function multiple data) [16:10:06 CEST] <atomnuker> they're static [16:19:53 CEST] <mateo`> jamrial: Hello, I've looked at checkasm on arm, I did not get any failure on two armv7 boxes, and the asm code that calls the tested functions does not override the returned value [16:20:47 CEST] <jamrial> mateo`: ok, cool [16:20:57 CEST] <jamrial> wonder why that one arm fate box reported a failure on checkasm-float_dsp, then [16:21:00 CEST] <jamrial> thanks for looking [16:22:56 CEST] <mateo`> jamrial: this one http://fate.ffmpeg.org/report.cgi?time=20170704083953&slot=armv7l-panda-gcc… ? [16:23:23 CEST] <jamrial> yeah [16:43:07 CEST] <mateo`> jamrial: well, I don't why those tests fail on this box, maybe the memory poisoning option has to do with it, i'll take some time to investigate later on [16:44:36 CEST] <iive> btw, what does checkasm test for? what does it run as reference? a non poisoned asm function? [16:50:08 CEST] <mateo`> iive: it runs both the C and ASM functions of a dsp and compares its output [16:50:19 CEST] <mateo`> the input in generated with random [16:52:03 CEST] <iive> i can't spot the place where it gets the pointer to the C function. [16:53:30 CEST] <ubitux> the dsp points on the c function if you init with the 0 cpuflags [16:56:13 CEST] <iive> that's the thing that confuses me. I see only one initialization of dsp context, in the function, outside of any macro. [17:06:39 CEST] <Gramner> iive: it's basically lots of evil preprocessor macro stuff behind the scenes going on [17:07:27 CEST] <iive> maybe it runs the first test with cpuflags=0 and same ref and new functions ? [17:07:33 CEST] <Gramner> it calls another function to do a lookup in a binary search tree for a pointer to the reference function [17:07:59 CEST] <Gramner> it's called with cpuflags=0 first [17:08:06 CEST] <Gramner> and saves that function pointer for later [17:08:55 CEST] <Gramner> see checkasm.c and checkasm.h [17:14:56 CEST] <iive> another lame question. can I run checkasm without running the whole fate? [17:15:27 CEST] <ubitux> yes [17:15:34 CEST] <ubitux> make checkasm && ./tests/checkasm/checkasm [17:15:40 CEST] <ubitux> or make fate-checkasm [17:15:52 CEST] <iive> thanks [17:16:19 CEST] <Gramner> optional --bench=<prefix> parameter for benchmarking stuff [17:16:41 CEST] <iive> oh, i have to do it from the root of ffmpeg source, not from tests/ [17:17:43 CEST] <ubitux> s/source/build dir/ (which can be the source tree) [17:20:24 CEST] <iive> do we support now building outside the source tree? [17:20:36 CEST] <nevcairiel> always have [17:21:13 CEST] <nevcairiel> the default fate script in the tests directory even does that, so most fate boxes prboably do [17:21:36 CEST] <iive> i remember somebody trying to implement it and doing it wrong... [17:27:19 CEST] <ubitux> aren't you remembering the reproducible state thing with the src link? [17:27:38 CEST] <nevcairiel> ah yeah the dumb debian hacks that never worked [17:35:16 CEST] <thardin> reading the itu jpeg spec. seems jpeg is a lot more sophisticated than i thought [17:36:04 CEST] <thardin> hierarchical encoding especially [17:36:36 CEST] <thardin> almost waveletish [17:45:08 CEST] <J_Darnley> Woo! random noise output! [17:45:30 CEST] <J_Darnley> except for the last 3(?) slices, lol [17:47:32 CEST] Action: J_Darnley is afk for dinner [17:47:36 CEST] <peloverde> durandal_1707: during unpacking your coef window stride is 128 but when reading them in the transform it's 120 [17:48:10 CEST] <peloverde> Looking at it further, I think changing it in the itx-windowing is probably easier [17:48:30 CEST] <peloverde> There are a ton of 128 short window strides littered through out the codebase [17:57:12 CEST] <durandal_1707> atomnuker: utvideo decoding speed: libav 117fps, my bitreader 178fps [17:58:22 CEST] <cone-885> ffmpeg 03Tobias Rapp 07master:8bf9572e9a54: avformat: remove obsolete commented-out DEBUG define [18:03:20 CEST] <atomnuker> durandal_1707: wow, nice [18:44:26 CEST] <peloverde> durandal_1707: Did you amend or change the commit recently I have 1c04fa5daced305ba820f5f64e39ab8451e73bdd exploding and 38e8d39e084d9b909a23d0a72426e32d5335c7a5 decoding with artifacts [18:47:12 CEST] <peloverde> Ahh looks like you added the 120 swb tabs, I thought I remembered those being missing [18:49:00 CEST] <durandal_1707> peloverde: and sbr something [18:49:17 CEST] <durandal_1707> but i always get artifacts [19:08:03 CEST] <peloverde> So I think I've fixed the artifacts, but mdct_error.flv has a bitstream desync that wasn't there before [19:15:00 CEST] <peloverde> The bitstream desync is before my changes [19:30:22 CEST] <durandal_1707> peloverde: have patch? [19:33:07 CEST] <peloverde> durandal_1707: https://pastebin.com/drs9Lk9k [19:33:26 CEST] <peloverde> The top part I'm suspicious of, the bottom part I'm confident about [19:39:15 CEST] <peloverde> I'd like to find a reference sample that goes all the way to max_sfb on short windows [19:40:11 CEST] <peloverde> err max_sfb goes all the way to num_swb [19:56:49 CEST] <durandal_1707> peloverde: i still get artefacts with isobmff sample [19:59:08 CEST] <peloverde> durandal_1707: That's HE-AAC, lots of additional changes will be necessary [19:59:21 CEST] <peloverde> filterbank is a good place to start [19:59:46 CEST] <peloverde> but AAC-LC 960 is a farily cohesive unit and can probably move forward without HE-AAC [20:00:00 CEST] <durandal_1707> what needs change? [20:01:36 CEST] <peloverde> The filterbank needs to support 960 input and 960 and 1920 output [20:03:40 CEST] <peloverde> And the filterbank is implemented on top of the mdct so it will probably get ugly [20:04:28 CEST] <peloverde> It's probably best to move forward with LC first and just disable SBR with short frame length flags [20:11:50 CEST] <peloverde> If you turn off SBR you should trade the artifacts you are getting for a loss of high frequencies [20:52:03 CEST] <BBB> uhm [20:52:04 CEST] <BBB> s->cache = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) << s->cache | s->cache; [20:52:06 CEST] <BBB> ??? [20:52:22 CEST] <BBB> I assume that middle s->cache should be s->bits_left? [20:53:06 CEST] <BBB> durandal_1707: ^^ [20:55:52 CEST] <durandal_1707> fixed [20:55:58 CEST] <atomnuker> durandal_1707: I think it should be enabled by default and disabled on demand [20:57:06 CEST] <durandal_1707> atomnuker: i think other way arround [20:57:15 CEST] <jamrial> atomnuker: that depends on how many codecs see gains with this. if most do, then sure. but if most don't, then it should be enabled on demand. [20:58:56 CEST] <BBB> can cache be 32bits on 32bit (HAVE_FAST_64BIT=0) systems? [20:59:12 CEST] <BBB> (s/can/should/ maybe) [21:00:09 CEST] <atomnuker> that'd be fine too [21:04:26 CEST] <iive> if you are going to have a cache, then you can at least do an aligned reads. this way byteread macros won't need to do its own double read and shuffles. [21:12:28 CEST] <durandal_1707> iive: what you mean exactly.? [21:15:14 CEST] <peloverde> durandal_1707: So the only ref that uses all SWBs is the PNS ref where there are no coef reads anyway :( [21:24:44 CEST] <iive> durandal_1707: since the code use index>>3 I do assume that's byte granularity. So on architecture (like arm) that does not allow unaligned access, the macro would either do 4 byte reads or 2 dwords and then shift them 8,16,24 bits. [21:33:05 CEST] <nevcairiel> if that is the case we can always put it under HAVE_FAST_UNALIGNED or whatever [21:33:54 CEST] <iive> well, a number of intel cpu have severe penalty if doing a read that crosses cache lines, that's 64 bytes. [21:34:30 CEST] <nevcairiel> anyway AV_RL32 etc are designed to work on unaligned data [21:34:35 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:b603ef0870f3: bitpacked: Remove dead store [21:34:35 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:704b774ae029: af_tempo: Add missing error check [21:34:36 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:f7daed854532: scpr: Added missing error check [21:34:37 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:179bf86fa2f5: opusdec: Remove dead code [21:34:38 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:d74ba68acf30: ffmpeg_opt: Make get_timecode actually return errors [21:34:39 CEST] <nevcairiel> we specifically have AV_RL32A for things we know are aligned [21:34:40 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:aa2bc61a3e32: cngenc: Remove dead store [21:34:40 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:c27d7c027cd7: rtmpproto: Fix error return [21:34:41 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:b198e0913854: af_amix: Add missing error check [21:34:42 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:51db26231255: bitstream_filter: Add missing error check [21:34:43 CEST] <tdjones> I'm having a problem where switching to a short window in the vorbs encoder requires a shorter residue partition length than long windows. Even with identical codebooks to libvorbis, terrible noise is introduced whenever a short window is being encoded. https://0x0.st/07P.jpg [21:35:08 CEST] <nevcairiel> (actually, AV_RN32A since it only supports native endianness) [21:35:25 CEST] <iive> nevcairiel: my point is, that once the buffer is aligned, we can keep it aligned by doing only 32bit reads. [21:35:48 CEST] <tdjones> It must either be a problem with encoding the partition codeword for each channel or encoding the residual values inside each partition [21:36:00 CEST] <nevcairiel> sounds like unnecessary optimizations to me, it seems plenty fast without such complexity [21:36:09 CEST] <tdjones> Anybody have any suggestions on how to debug this? [21:36:22 CEST] <atomnuker> tdjones: might be bitstream desyncs [21:36:44 CEST] <iive> nevcairiel: it's actually a simplification. [21:37:09 CEST] <atomnuker> tdjones: encode a single frame using -aframes 1 and put printfs on the first value read on the encoder and decoder [21:37:19 CEST] <nevcairiel> you dont even know if the buffer it is given is aligned in the first place, so you need checks, and checks add cost [21:37:29 CEST] <atomnuker> tdjones: or if you want to just printf and abort in the decoder [21:38:02 CEST] <atomnuker> first see if the last value you read in the decoder is the same as the value you put on the encoder side [21:38:23 CEST] <atomnuker> then I'd suggest moving from top (e.g. start of bitstream) down to the bottom [21:42:51 CEST] <iive> nevcairiel: it doesn't have to be aligned, you can align it at init, and load the partial start in the cache. [21:49:35 CEST] <tdjones> atomnuker: Are you saying the values after the residue and floor have been decoded? Or the encoded input for the decoder? [21:50:39 CEST] <tdjones> The audio sounds correct if a large residue is encoded for short frames, but it raises an error in the decoder because it believes that the residue will be too large for the output buffer [21:53:39 CEST] <atomnuker> tdjones: that doesn't matter, what I'm saying is that the encoder writes or doesn't write something it should [21:53:52 CEST] <atomnuker> and since the decoder doesn't know it gets out of sync and starts reading wrong values [21:54:50 CEST] <atomnuker> so you need to put a printf on values you encode and values you decode in the decoder until you find a mismatch [21:55:04 CEST] <atomnuker> and then you'll know what's either missing or what's added that shouldn't be there [22:16:30 CEST] <kierank> durandal_1707: do you know name of filter that shows frame side data [22:17:24 CEST] <durandal_1707> sidedata? [22:18:23 CEST] <kierank> yes [22:18:29 CEST] <kierank> there was a filter iirc or a way of printing [22:19:08 CEST] <durandal_1707> sidedata filter [22:20:24 CEST] <kierank> ah [22:20:25 CEST] <kierank> thanks [22:25:50 CEST] <durandal_1707> but it just not print at all only select or delete [22:32:01 CEST] <kierank> I add my own printf [22:33:34 CEST] <durandal_1707> what sidedata you want? [22:33:45 CEST] <kierank> i want to understand why field h264 loses side data [22:33:55 CEST] <kierank> and how to merge it [22:40:58 CEST] <ubitux> if someone has some benchmark script/samples i can try to run the bs reader in the two modes on different hardware [22:41:15 CEST] <ubitux> i mean on a few arm32 & 64 [23:04:30 CEST] <kierank> funman: [23:04:31 CEST] <kierank> - if (!h->first_field) [23:04:31 CEST] <kierank> + if (!h->first_field) { [23:04:31 CEST] <kierank> h->cur_pic_ptr = NULL; [23:04:31 CEST] <kierank> - ff_h264_reset_sei(h); [23:04:31 CEST] <kierank> + ff_h264_reset_sei(h); [23:04:32 CEST] <kierank> + } [23:04:35 CEST] <kierank> was there a reason this didn't work [23:09:24 CEST] <BBB> ah, the google guy followed through on my suggestion, nice [23:09:28 CEST] <BBB> I believe his patch is correct this time [23:10:00 CEST] <BBB> ubitux: should fix the spurious tsan warnings [23:10:08 CEST] <BBB> ubitux: so only mpeg4 left for frame threading [23:11:03 CEST] <BBB> ubitux: the debug symbols for the tsan/slice station are broken btw [23:11:34 CEST] <ubitux> BBB: nice about the patch [23:11:45 CEST] <ubitux> BBB: ah, that's not good news, let me check if i messed up something [23:11:54 CEST] <BBB> configure flags look fine tbh [23:11:58 CEST] <BBB> no idea [23:12:21 CEST] <BBB> oh tsan/frame-mt is also broken [23:12:23 CEST] <BBB> did you update tsan? [23:14:07 CEST] <ubitux> it's distributed by gcc, which has been updated yes [23:14:44 CEST] <BBB> I thought tsan was clang? [23:14:48 CEST] <BBB> is it in gcc now? [23:15:12 CEST] <nicolas17> I think they share that code [23:15:21 CEST] <ubitux> both use libtsan [23:15:26 CEST] <BBB> aha [23:15:27 CEST] <BBB> ok [23:15:29 CEST] <BBB> tnx for explaining [23:15:30 CEST] <BBB> brb [23:15:40 CEST] <nevcairiel> tsan was developed by google, both gcc and clang use it [23:17:04 CEST] <ubitux> seems it broke with the nasm/yasm switch [23:17:10 CEST] <ubitux> unless i'm missing something [23:17:20 CEST] <nevcairiel> nasm seems generally to cause a bunch of issues [23:17:30 CEST] <nevcairiel> its unfortunately not quite as flawless of a replacement as people made it out to be [23:17:38 CEST] <ubitux> according to the fate history it broke between 664ac7c5e2 and 5cae5a1def [23:18:22 CEST] <ubitux> btw, nasm broke object dependencies too [23:18:43 CEST] <ubitux> i'm going to trash the .ccache though just in case [23:19:01 CEST] <nevcairiel> the ironic thing is, it even was one of the quoted enhancements for nasm to generate the deps without a second invocation =p [23:19:48 CEST] <jamrial> yeah [23:20:00 CEST] <jamrial> should probably be reported to nasm [23:20:12 CEST] <ubitux> we may be misusing it too [23:20:24 CEST] <nevcairiel> i was meaning to figure out which asm file causes msvc to break [23:20:32 CEST] <jamrial> http://www.nasm.us/doc/nasmdoc2.html#section-2.1.7 [23:20:35 CEST] <nevcairiel> so the nasm guys can fix their shit [23:21:04 CEST] <jamrial> ubitux: -MD is correct, supposedly [23:21:14 CEST] <jamrial> it's just not really getting all the dependenceis [23:21:19 CEST] <nevcairiel> it generates some information, its just not complete, doesnt it [23:22:15 CEST] <jamrial> it allowed me to do some testing changes on x86util without having to reassemble every .asm file, though :p [23:22:20 CEST] <jamrial> but yeah, ideally, it should work as intended [23:23:26 CEST] <iive> btw, I have a feeling that (separate) asm dependency generation has been removed, and that it might be needed when yasm is used. [23:23:29 CEST] <jamrial> nasm seems to error where yasm instead warns [23:23:30 CEST] <iive> am I wrong? [23:23:50 CEST] <nevcairiel> it should still be there if you use yasm [23:23:53 CEST] <jamrial> yes, you're wrong. yasm is still being called the same way [23:24:48 CEST] <iive> yasm compilation , yes. dependency... [23:25:34 CEST] <nevcairiel> why dont you just try it instead of speculating? :p [23:25:39 CEST] <nevcairiel> it still works as before if you use yasm [23:27:24 CEST] <iive> nevcairiel: my ffmpeg is using nasm, that's why. [23:27:34 CEST] <nevcairiel> you can override that [23:27:57 CEST] <nevcairiel> configure --x86asmexe=yasm [23:28:30 CEST] <iive> maybe later... i don't feel like rebuilding everything. [23:35:51 CEST] <funman> kierank: iiuc the h264context was different (1 per thread/field) [23:36:41 CEST] <kierank> ah yes you are right [23:37:33 CEST] <funman> but even -threads 1 showed different pointers [23:38:21 CEST] <funman> did you try running h264_export_frame_props() for each field rather than only "second" field? [23:40:02 CEST] <kierank> no, going to bed [23:41:04 CEST] <funman> have sweet interlaced dreams [23:56:48 CEST] <nevcairiel> jamrial: interestingly the linker error on msvc goes away if i disable debug linking .. but of course that fails to generate full debug symbols then, which is kinda one of the main reasons to use msvc :D [23:57:36 CEST] <jamrial> nevcairiel: did you try reverting the strip commit from a week or so ago? [23:57:41 CEST] <jamrial> maybe that's the problem [23:57:49 CEST] <nevcairiel> i'll try that next [23:58:09 CEST] <jamrial> 18f09524f7 [23:58:10 CEST] <nevcairiel> i thought maybe generating debug info in nasm might help, but it failed to do that and errored out on a bunch of files =p [23:58:38 CEST] <jamrial> haha [23:59:41 CEST] <jamrial> nasm seems to error on things yasm instead warns, though, like the x86inc stuff that reports sse instructions used in the wrong functions [00:00:00 CEST] --- Sat Jul 8 2017

1 0

ffmpeg.log.20170707
by burek 08 Jul '17

08 Jul '17

[00:37:54 CEST] <Samizdat> Is there some way to script rtmpdumphelper to hang onto a .swf URL longer than the yoctosecond alotted before expiration? [00:39:53 CEST] <Samizdat> "Allotted," even. [00:46:48 CEST] <nemosphere> Samizdat is a name i heard years ago, in France [00:47:44 CEST] <Samizdat> Oui [00:48:12 CEST] <nemosphere> it's off-topic, sorry [00:48:31 CEST] <Samizdat> Je ne sais qua les specifiques, mon frere. [00:49:06 CEST] <iive> nemosphere: i thought that samizdat means "self - publish" [00:49:20 CEST] <Samizdat> roger that [00:49:30 CEST] <Samizdat> In Russkii [00:50:02 CEST] <Samizdat> Isn't ffmpeg the more relaxed channel, topic-wise? [00:50:08 CEST] <nemosphere> it's just an old memory, it just hit myself right now; sorry [00:50:21 CEST] <Samizdat> nigh whirries, Mite [02:30:06 CEST] <c3r1c3-Win> I'm starting to get the impression that the FFMPEG Audio filters aren't meant for real-time operations. [03:11:18 CEST] <durandal_1707> c3r1c3-Win: why [04:13:31 CEST] <llq> hello, i want to use the mediacodec by ffmpeg in android, i can use the "avcodec_find_decoder_by_name("h264_mediacodec")" success found the codec, but when i open the codec by "avcodec_open2" it return fail, who knows how to solve the problem? thanks! [04:16:18 CEST] <llq> https://pastebin.com/SP8wUqSx my code is like this [04:22:06 CEST] <llq> anyone here ? hehe [07:39:09 CEST] <llq> hello, i want to use the mediacodec by ffmpeg in android, i can use the "avcodec_find_decoder_by_name("h264_mediacodec")" success found the codec, but when i open the codec by "avcodec_open2" it return fail, who knows how to solve the problem? thanks! [07:39:22 CEST] <llq> https://pastebin.com/SP8wUqSx my code is like this [07:47:55 CEST] <verb5> Hello everyone [07:48:54 CEST] <llq> hello verb5 [07:50:03 CEST] <verb5> guys i need help not exactly ffmpeg related question but someone here could now how to do it [07:50:30 CEST] <verb5> i am trying to visualize 10 mpeg2 streams coming from dvb-s tunner into webpage [07:51:32 CEST] <verb5> but i haven't found any usefull info on how to do it ... i don't want to transcode because i don't have enough resource to do it [07:52:36 CEST] <verb5> please if anyone have any idea on how to do it let me know [07:53:00 CEST] <llq> ffmpeg using MediaCodec, avcodec_open2 says error code:-1 (0xffffffff) text: Operation not permitted [07:53:20 CEST] <llq> who knows this problem ? thanks [08:15:46 CEST] <chuckleplant> Nacht: thanks for the NAL units intro from yesterday! [13:44:45 CEST] <_Vi> How do I concatenate two H.264 mp4 files with FFmpeg (with re-encoding)? With "ffmpeg -f concat ..." I get a lot of H.264 decoding errors after it gets to the second file (there is second "Auto-inserting h264_mp4toannexb bitstream filter" message). [13:48:46 CEST] <squ> _Vi: try to run 2 file to see if it has error [13:51:07 CEST] <_Vi> squ, Converting just the second file is OK. Also converting the first + third. [13:51:19 CEST] <_Vi> But the second file has a bit incompatible bitstream. [13:54:48 CEST] <_Vi> Found the answer: instead of "-f concat -i ...." use "-i file1 -i file2 -i file3 -filter_complex concat". [13:55:03 CEST] <_Vi> But now sound got broken... [13:57:42 CEST] <squ> concat=n=1:v=1:a=1 [13:57:54 CEST] <squ> need to tell it a=1 (audio) [13:58:14 CEST] <squ> and have correct -map stuff [14:00:14 CEST] <_Vi> squ, There are further video filters after concat. [14:05:08 CEST] <_Vi> Finally got it right after remembering that there may be ';' inside a filter_complex string. [14:08:40 CEST] <_Vi> Why filter that does nothing called null (anull) instead of identity (aidentity)? [14:09:24 CEST] <_Vi> And why null can't work with both audio and video like concat? [14:54:10 CEST] <durandal_1707> c3r1c3-Win: why? [14:55:23 CEST] <c3r1c3-Win> durandal_1707: It's just being a bit tongue-in-cheek. It's been hard integrating 2 programs that handle audio in similar, but completely different ways. [15:45:18 CEST] <Guest68152> Hi guys, do you know where the camera model is stored in the mp4 metadatas ? [20:38:49 CEST] <ShaneVideo> hi guys, any tips on how to get ffmpeg to exit when it hangs. Sometimes when I have bad input I get: Could not write header for output file #0 (incorrect codec parameters ?): Immediate exit requested. and it never exits [20:47:46 CEST] <holgersson> ShaneVideo: Hi, as a wild guess, does maybe '-xerror' help? I just searched the manpage for 'exit' and this sounds useful. [20:47:55 CEST] <ShaneVideo> thanks [20:56:28 CEST] <thebombzen_> Hm, yesterday Blizzard added a feature to Overwatch to encode video. [20:56:43 CEST] <thebombzen_> Including a software H.264 encoder [20:57:58 CEST] <thebombzen_> Does anyone happen to know which one they use? Assuming it's not the GPLed x264, is there a way for me to try to dump metadata to figure that out? [20:58:48 CEST] <ChocolateArmpits> thebombzen_, I would probably first look for any libraries in the install directory [20:59:11 CEST] <thebombzen_> I meant from the H.264 bitstream [20:59:41 CEST] <thebombzen_> it's pretty easy to tell if it's x264, because you can do that with 'strings' [20:59:47 CEST] <ChocolateArmpits> unless it's as verbose as x264 then unlikely [21:00:10 CEST] <ChocolateArmpits> they could be using hardware encoding capabilities [21:00:22 CEST] <ChocolateArmpits> probably is best for gaming scenarios [21:00:28 CEST] <thebombzen_> It's a checkbox, you can turn that on or off [21:01:08 CEST] <ChocolateArmpits> of course they would dumb it down [21:01:11 CEST] <thebombzen_> If it's on it's definitely NVENC on my system (seeing that my iGPU is bios disabled) [21:01:20 CEST] <thebombzen_> But if it's off? idk [21:02:01 CEST] <thebombzen_> What's annoying is you cannot render at 120 fps, which is what I game at, so I still need to use my OBS replay buffer [21:02:45 CEST] <thebombzen_> They also provide a "webm" encoder but I do not know if it's libvpx-vp8 or 9, or vorbis or opus [21:02:58 CEST] <thebombzen_> My best guess is vp8/vorbis [21:03:36 CEST] <thebombzen_> although it should be vp8/opus for <=1080p and vp9/opus for >4k [21:04:09 CEST] <holgersson> Is there any tool to automagically repair h264 video streams? I have some source material created by an video casette convert and if I convert this source into xvid/MPEG4 I get many (different) errors like decode_slice_header error or corrupted macroblock 0 5 (total_coeff=-1) and the created files have artefacts in the video (grey areas until something moves). [21:05:01 CEST] <thebombzen_> holgersson: have you ever been able to decode the stream? [21:05:27 CEST] <thebombzen_> Are you sure it's a corrupted bitstream and not a container? [21:06:21 CEST] <thebombzen_> I ask because ffh264 is pretty good about error concealment so you might just have to fix it by decoding what you have [21:07:08 CEST] <holgersson> thebombzen_: What do you mean exactly with decode the stream? (Sorry if I lack of proper vocabulary, Im still quite new here). [21:07:31 CEST] <holgersson> I can play the source material with e.g. mpv and have way less artefacts - and mpv doesnt complain. [21:08:09 CEST] <thebombzen_> Well mpv uses FFmpeg to do that, so my best guess is your FFmpeg is out of date. [21:08:30 CEST] <thebombzen_> What command produces the errors? [21:10:18 CEST] <holgersson> thebombzen_: Its ffmpeg 3.3.2 on Gentoo; USE flags represent more or less the configure flags, and Ill append these to the paste. [21:11:00 CEST] <thebombzen_> That's recent, hm. Also ffmpeg outputs its configure flags to stderr [21:11:12 CEST] <thebombzen_> You don't need to do that manually [21:18:51 CEST] <holgersson> thembozen_, thx, I now see that :D [21:25:44 CEST] <holgersson> thebombzen_: Sorry, my internet connection drops out here and now. [21:25:44 CEST] <holgersson> thebombzen_: https://paste.xinu.at/LHAR52/ (~30 lines text paste) [21:26:37 CEST] <holgersson> (ignore line 3 though..) [21:32:33 CEST] <Fenrirthviti> thebombzen_: if you figure out what it's using let me know, I'm curious :P [21:34:15 CEST] <eesh> Hey you guys. [21:34:37 CEST] <eesh> I want to know something. [21:34:44 CEST] <eesh> But I don't know how to phrase it. [21:34:48 CEST] <eesh> it's with ffplay [21:35:06 CEST] <nicolas17> eesh: once you figure out how to phrase it, you may find the answer too; rubber-duck debugging :) [21:35:08 CEST] <eesh> I want the window to look really cool when giving it pure-audio files. [21:40:42 CEST] <holgersson> Thats the outstanding best description I heard in a while :-D [21:42:37 CEST] <nicolas17> you want audio visualizations? [21:43:18 CEST] <nicolas17> there's probably better choices of player than ffplay if you want that [21:56:48 CEST] <thebombzen_> holgersson: what happens if you play the input with ffplay? i.e. do this: ffplay -i source.avi [22:00:24 CEST] <thebombzen_> Also for future reference, most external libraries are off by default, so you don't need to clutter up your configure line with them [22:04:40 CEST] <eesh> nicolas17: I want audio visualizations to enter via bash terminal on Linux that will use an audio visualization other than the 3 default ones using the '-filter' command-line option. [22:06:14 CEST] <holgersson> thebombzen_: The video plays in same quality as with mpv, but doesnt quit when video and audio are played: https://paste.xinu.at/5hKrq/ [22:07:15 CEST] <holgersson> thebombzen_: Thanks, good to know - maybe Ill ask the ffmpeg maintainer about this. I dont set the configure flags by hand though, our build system/package manager does this based on the USE flags. [22:07:45 CEST] <thebombzen_> holgersson: Sounds like the biggest problem is with your encoding. Try this: ffmpeg -i input.avi -c copy output.mkv [22:08:06 CEST] <thebombzen_> Then see what happens with output.mkv [22:09:15 CEST] <thebombzen_> There's no real reason to convert to mpeg4, so you should probably avoid that [22:10:08 CEST] <holgersson> thebombzen_: I need mpeg4 for a special device. Otherwise Id just use x264. [22:10:55 CEST] <holgersson> while copying ffmpeg throws this error: https://paste.xinu.at/sDHUFZc/ [22:11:31 CEST] <thebombzen_> Why does it say x264? Paste full command and output [22:12:19 CEST] <thebombzen_> General guideline here: Unless you know why not to, post the exact command you executed and the uncut output [22:12:44 CEST] <thebombzen_> Because now I have to ask again, when I otherwise wouldn't have. [22:16:27 CEST] <holgersson> Sure :) However, Ill pasted you "ffmpeg -i original-source.avi" earlier: https://paste.xinu.at/LHAR52/ (30 lines, from 21:25 UTC +2) [22:16:27 CEST] <holgersson> Here comes the full output of "ffmpeg -i original-source.avi -map 0:0 -c:v copy new-source.mkv": https://paste.xinu.at/qPS5HN9/ [22:17:49 CEST] <thebombzen_> Okay, but what happens if you play the new mkv file? [22:18:23 CEST] <holgersson> thebombzen_: With ffplay or mpv (if this makes as difference, as mkv *uses* ffmpeg..)? [22:19:01 CEST] <thebombzen_> It shouldn't (although try to see if it works in either one) [22:19:50 CEST] <thebombzen_> They use the same demuxer and decoder, but mpv is a proper player and ffplay is a primitive thing that basically just works like ffmpeg.c [22:21:23 CEST] <eesh> I wish ffplay came with more than 3 audio visualizations kind of like how Linux Mint 17.3 comes with 89 full-sized unique wallpapers out-of-the-box. [22:21:37 CEST] <eesh> poor me. [22:21:46 CEST] <thebombzen_> eesh: ffplay is not a proper player [22:21:54 CEST] Action: eesh turns up sad music [22:22:11 CEST] <thebombzen_> If you really want visualizations then VLC might have them bundled [22:22:39 CEST] <thebombzen_> Also could probably do that with VapourSynth but I have never used it so I have no idea how [22:22:50 CEST] <eesh> no. I want ffplay because I can't use vlc or mplayer2 packages because they require packages that I don't want to install. [22:22:59 CEST] <eesh> I compiled the latest ffmpeg and I am proud. [22:23:01 CEST] <nicolas17> port the VLC visualizers to ffmpeg filters [22:23:03 CEST] <nicolas17> have fun [22:23:20 CEST] <thebombzen_> eesh: Good very good, now compile VLC [22:23:56 CEST] <thebombzen_> What you want to do is use a feature of software that doesn't exist. So you need to try something else [22:23:58 CEST] <Fenrirthviti> eesh: Check out ProjectM [22:24:00 CEST] <eesh> but I'm 99% sure compiling VLC is not easy as ffplay is everything I want except VLC's preset audio visuals. [22:24:08 CEST] <eesh> Fenrirthviti: k. [22:24:22 CEST] <thebombzen_> Totem might also do that [22:24:44 CEST] <thebombzen_> But it's gstreamer-based *shudders* [22:28:38 CEST] <eesh> Maybe I'll just download all 48576 packages that I can see with apt-cache and program an AI-super-bot to fetch all of the latest source code for each project and do a `grep -RsHIni visuals $HOME/all-source-code/` and then when I go to the bathroom to take a shit I take that 14 minutes of time (assuming I ate 5 medium-sized prunes 7 hours earilier) to read this 10000 page grep output with 12pt Times New Roman font 1.5-spaced-lines with [22:28:38 CEST] <eesh> .5" inch margins? Maybe after like 50 shits I'll realize that you're all assholes. [22:28:40 CEST] <holgersson> thebombzen_: https://paste.xinu.at/m-3mu1KHw/ -- both outputs on the same webpage [22:28:40 CEST] <holgersson> thebombzen_: Just 'ffplay new-source.mkv &> ffplay_new_source_mkv' & 'mpv new-source.mkv &> ffplay_new_source_mkv' [22:28:40 CEST] <holgersson> thebombzen_: And I had to kill ffplay again with ctrl-c. Looks to me as some frames are now missing though, i.e. both players jump [22:29:21 CEST] <holgersson> eesh: Wow, using commata would make your text at least readable.. [22:29:45 CEST] <thebombzen_> holgersson no I meant, when you played them, did it work? [22:30:03 CEST] <thebombzen_> At least as much as you wanted it to? [22:30:20 CEST] <eesh> holgersson: but I was in a hurry because I wanted to look cool :c [22:30:46 CEST] <thebombzen_> Because if the bitstream is corrupt you can't really fix that but you can try to do better than you did before with the unusable artifacts and all [22:31:02 CEST] <holgersson> thebombzen_: No, it doesnt. There are no more of these artefacts, but instead it looks like parts are just missing (and I think its all the broken stuff). [22:31:13 CEST] <thebombzen_> eesh: calling random internet people assholes does not make you cool [22:32:54 CEST] <thebombzen_> holgersson: I guess a better question for me to ask is, "You got terrible decoder errors when you tried to transcode to mpeg4 directly, even if the file played somewhat correctly. After you remuxed to matroska, does the file play as it did before? Or is it worse?" [22:34:25 CEST] <thebombzen_> Because if it isn't worse then before, try remuxing to matroska (with the audio) using: ffmpeg -i input.avi -c copy temp.mkv [22:34:26 CEST] <holgersson> thebombzen_: It got worse as now entire frames are missing. I dont know if frames is correct: I mean images in the lenghts of some milliseconds that are missing (and I can see them because movements of people now has jumps) [22:34:37 CEST] <eesh> thebombzen: but I was 14% sure all of those cool facts I presented in the former run-on sentence would redeem the inflictable glory of the latter derogatory word used in the last sentence of my main primary influx of the need to tell everyone I really do not want to be on IRC right now. I just want these fucking visuals and no matter what I say in this CHANNEL, there probability I'm gonna get what I want is neglectable no matter what I [22:34:37 CEST] <eesh> say. Therefore I conclude that the only solution is to l? hard. Do whatever it is you gotta do that's your job. And niggas gonna hate, but that's their problem. [22:35:13 CEST] <thebombzen_> If the missing frames were hideously corrupted then there isn't much you can do about that [22:36:15 CEST] <thebombzen_> a btoken file sometimes can't be saved. However, after remuxing it to matroska, you can try to encode that to an mpeg4 video file that you say is required [22:37:47 CEST] <holgersson> I dont think that will help. Ill try it with some of the files I have though. [22:37:56 CEST] <holgersson> thebombzen_: However, thank you! [22:37:57 CEST] <thebombzen_> If you want to fill in the missing frames with duplicates of correct frames, you can try adding -vsync cfr [22:38:14 CEST] <holgersson> Ill try it [22:38:23 CEST] <thebombzen_> But that's only if the unsaveable frames are dropped [22:39:31 CEST] <thebombzen_> Your input is 24.84 fps, which is weird and possibly incorrect, so watch the dup= and drop= in the stats [22:45:47 CEST] <holgersson> thebombzen_: Yes, s.o. else in this channel mentioned this (I dont recall who it was though). The video was recorded from an analog video tape camera through some magical blackbox that converted the analog input to this h264 mess + pcm audio stream. [22:46:08 CEST] <holgersson> thebombzen_: How can I fix dup= and drop=? [22:49:08 CEST] <holgersson> thebombzen_: Cool, -vsync cfr improved the quality much. Maybe thats enough. Again thanks! [22:54:45 CEST] <Nicolas_> Hi! I'm trying to compile ffmpeg on Mac OSX as a static binary. It does work but it is significantly slower than the prebuilt binaries for mac offered by ffmpegmac or evermeet on ffmpeg.org. Like up to 5 times slower! Do you have an idea why that might be? Configure settings can be found here: https://pastebin.com/fGGDE53k I used the latest snapshot. Thanks. [22:58:34 CEST] <eesh> Nicolas_: assuming your compilation of ffmpeg on MacOSX is 5.00000 times slower than the build that came with ffmpegmac, I would copy and paste the ffmpegmac build's ./configure line, add --disable-shared --enable-static, build it. Try `time ffmpeg -i from.avi to.mp4 #to do a benchmark time` and if that is as fast then you are adding a `./configure' command-line option that makes the static binary slow. [22:59:09 CEST] <eesh> by "" I meant infinite 0's/accuracy of the number '5'. [23:03:24 CEST] <Nicolas_> i did exactly that (time ffmpeg etc.) and got these results for example: mine: 2m31.166s | evermeet: 0m40.526s | ffmpegmac: 0m49.035s [23:04:08 CEST] <Nicolas_> I did not replicate the configure settings exactly because I did not want to build all dependencies though. [23:05:04 CEST] <Nicolas_> Maybe I can prebuild them with homebrew? [23:07:15 CEST] <Nicolas_> ... or I just leave the codecs out that I did not built before. [23:15:59 CEST] <alexpigment> hey guys, I've got an interesting one for you [23:16:15 CEST] <alexpigment> I'm doing some transcodes into MPEG-1 for a particular project [23:17:06 CEST] <alexpigment> and I need to do one transcode to MPEG-1 elementary stream at full resolution, one elementary stream at a small thumbnail-ish resolution, and one where the audio is converted to a vorbis elementary stream [23:17:33 CEST] <alexpigment> In some cases on some machines, doing 3 separate simultaneous processes is faster [23:17:49 CEST] <alexpigment> In other cases, doing all 3 encodes with one input file on a single command line is fster [23:17:51 CEST] <alexpigment> *faster [23:18:04 CEST] <alexpigment> Is there a way to force some sort of multithreading so that it's always faster? [23:22:32 CEST] <thebombzen_> holgersson: dup= and drop= is the number of duplicated and dropped frames. [23:23:16 CEST] <thebombzen_> If both numbers get very large it's likely that the forced framerate is incorrect [23:23:32 CEST] <nicolas17> converting a video with ffmpeg, ffprobe -show_streams says r_frame_rate=30/1 avg_frame_rate=30/1 [23:23:51 CEST] <holgersson> thebombzen_: OK, Ill take a look [23:24:09 CEST] <nicolas17> converting a video with my own little program using lavc/lavf, ffprobe -show_streams says r_frame_rate=30/1 avg_frame_rate=1000/33 [23:24:16 CEST] <nicolas17> what could cause the difference? [23:24:22 CEST] <nicolas17> is avg_frame_rate calculated from the timestamps? [23:25:09 CEST] <holgersson> thebombzen_: Ill take a deeper look into this tomorrow. [23:25:16 CEST] <nicolas17> my pts seem to be all fine though [23:25:31 CEST] <thebombzen_> nicolas17: yes. Are you using matroska? [23:25:37 CEST] <nicolas17> mp4 [23:25:45 CEST] <thebombzen_> What is your timebase? [23:26:22 CEST] <nicolas17> 90k, and pts increases by 3000 on each frame [23:27:41 CEST] <thebombzen_> Try increasing the probesize and see what it says? [23:27:53 CEST] <thebombzen_> and also the analyzeduration [23:28:22 CEST] <thebombzen_> It's possible the average is off because it read veryblittle [23:28:24 CEST] <nicolas17> I don't see that in the ffprobe manpage, is it just -probesize 10000? [23:28:56 CEST] <thebombzen_> I set it as high as I can do it whines that it's too high and prints the max [23:29:01 CEST] <thebombzen_> then I use that [23:29:25 CEST] <thebombzen_> I can never remember the max [23:29:39 CEST] <thebombzen_> also yea, -probesize and -analyzeduration [23:29:39 CEST] <nicolas17> I meant syntax, if it was just -probesize <number> [23:29:46 CEST] <thebombzen_> yes that [23:29:55 CEST] <thebombzen_> that is correct [23:30:22 CEST] <nicolas17> no difference after setting both ridiculously high [23:31:08 CEST] <thebombzen_> shrug, then idk. I probably can't without seeing your simple muxer and I don't use lav* so someone else will have to help with that [23:31:55 CEST] <thebombzen_> Nicolas_ could be optimization. What CFLAGS are used to compile the things? [23:32:48 CEST] <thebombzen_> One way to check is to run htop (or just top) while it's compiling to see the exact compile flags used [23:33:41 CEST] <thebombzen_> GCC's optimization is decent. Not incredible, but decent. [23:34:37 CEST] <Nicolas_> Dunno... Just passing the "-I includes" I guess. [23:35:12 CEST] <Nicolas_> I tried the same arguments as ffmpegmac but its still as slow as before. [23:36:21 CEST] <nicolas17> what's the default swscaler scaling method if I just pass -s 640x480 to ffmpeg? [23:37:30 CEST] <relaxed> man ffmpeg-scaler [23:37:32 CEST] <Nicolas_> I don't know about htop/top. [23:37:44 CEST] <Nicolas_> looks freaky [23:37:46 CEST] <nicolas17> relaxed: it doesn't say [23:38:12 CEST] <relaxed> "Default value is bicubic" [23:38:34 CEST] <nicolas17> must have been added later, I don't have last version [23:38:49 CEST] <Nicolas_> This compiling just for --non-free is killing me. But now I want to know why it's not working. [23:44:19 CEST] <thebombzen> nicolas17: it does say yea, and it's said for a while [23:47:35 CEST] <nicolas17> hmm... my program is also producing a much larger file than ffmpeg [23:47:42 CEST] <Nicolas_> @thebombzen 'top' doesn't seem to show any CFLAGS or I just don't know how to use it [23:48:08 CEST] <thebombzen> nicolas17: http://0x0.st/0FJ.png [23:48:36 CEST] <thebombzen> notably though, -vf zscale uses bilinear as its default [23:48:38 CEST] <thebombzen> not bicubic [23:52:33 CEST] <thebombzen> Nicolas_: Try adding "-march=native -mtune=native -O3 -pipe" --optflags [23:54:10 CEST] <Nicolas_> thebombzen: where? To the configure command? [23:54:32 CEST] <thebombzen> yea, if you look at ./configure --help, there's an --optflags option (I think that's what it's called) [23:54:40 CEST] <thebombzen> also ditch --arch, it's used for cross compiling. no need for a native build [23:55:43 CEST] <Nicolas_> okay, cool. thx. will try. [23:56:33 CEST] <CFS-MP3> I need some help... this should be trivial but it's driving me crazy [23:56:36 CEST] <CFS-MP3> I'm running this: ffmpeg -hide_banner -i udp://239.168.100.2:5000 -deinterlace -filter_complex [0:v][0:s]overlay[overlaid];[overlaid]scale=416:-1:flags=lanczos[resized];[resized]setdar=dar=16/9[vdar];[vdar]split=2[in1][in2];[in1]fps=12[out1];[in2]fps=1/10[out2] -map [out1] -codec:v libx264 -x264opts keyint=120:min-keyint=120:no-scenecut -f segment -segment_time 10 -segment_start_number 1 [23:56:36 CEST] <CFS-MP3> -reset_timestamps 1 -segment_list_type m3u8 /mnt/tvcapturework/BBC2/_%06d.mp4 -map [out2] /mnt/tvcapturework/BBC2/_%06d.jpg [23:56:57 CEST] <CFS-MP3> where the goal is to generate a video every 10 seconds, and a frame capture every 10 seconds [23:56:59 CEST] <CFS-MP3> that works great [23:57:09 CEST] <CFS-MP3> the video plays fine [23:57:19 CEST] <CFS-MP3> but the image size is different on screen [23:58:23 CEST] <CFS-MP3> both are 416x340, but the size in the player is different. I assume this is DAR related, but I don't know how to fix [23:59:34 CEST] <nicolas17> another difference I see when comparing ffmpeg vs my program: [23:59:36 CEST] <nicolas17> -is_avc=true [23:59:37 CEST] <nicolas17> -nal_length_size=4 [23:59:39 CEST] <nicolas17> +is_avc=false [23:59:40 CEST] <nicolas17> +nal_length_size=0 [00:00:00 CEST] --- Sat Jul 8 2017

1 0

ffmpeg-devel.log.20170706
by burek 07 Jul '17

07 Jul '17

[00:30:16 CEST] <iive> atomnuker: not only who would report them, but mostly to whom would you report them. copyright is not /was not crimie, so somebody must own the rights and enforce them. [00:30:32 CEST] <iive> and they did, but a lot later... [00:50:16 CEST] <iive> imho, the boom of ISP was possible, becasue it was free to just nail ethernet cables wherever you like. The last mile access is still the biggest bottleneck everywhere in the world. [00:51:51 CEST] <nevcairiel> BtbN: i'm on telekom and i can smtp fine [00:53:50 CEST] <nevcairiel> a quick google suggests its just their router, not actually their network [00:53:57 CEST] <nevcairiel> who uses speedports anyway [00:54:15 CEST] <nevcairiel> (and apparently an option you can turn off) [00:54:32 CEST] <rcombs> in the US everybody uses HFC (DOCSIS) [00:55:39 CEST] <nevcairiel> its not like I have numbers, but i feel like DSL is more wide spread here [00:56:40 CEST] <nevcairiel> if anything it has more ISPs offering service, while cable is limited to one national ISP and a few local ones [00:57:23 CEST] <rcombs> we don't quite have any national ISPs, unless you count dial-up [00:57:40 CEST] <nevcairiel> US is too huge, i guess [00:57:51 CEST] <rcombs> nah, we've got cartels instead [00:58:20 CEST] <rcombs> they all mark out their territory and nobody steps on each other's toes [00:58:28 CEST] <rcombs> Comcast, Charter, Time Warner, few others [00:58:53 CEST] <rcombs> everybody's got some territory and no two of them serve the same area [00:58:53 CEST] <nevcairiel> not being in competition helps everyone, except the customers [00:59:25 CEST] <nevcairiel> god beware they would actually have to compete with quality service [00:59:53 CEST] <rcombs> the only competition is between the cable-TV incumbents (^that group) and the phone incumbents (AT&T, Verizon, and the few other remnants of the AT&T antitrust breakup of yore that they haven't bought back up yet) [01:00:38 CEST] <rcombs> cable providers use DOCSIS, phone incumbents are a mix of various types of DSL, or& also DOCSIS [01:01:19 CEST] <nevcairiel> being in a smaller country definitely helps with such things, we have 3 huge mobile carriers that have more or less full coverage, you get a choice in phone and internet service, etc [01:01:52 CEST] <rcombs> these days e.g. AT&T is moving towards a coax network instead of actual individual phone lines, since whaddayaknow, it's cheaper to have a single line with taps than a huge-ass bundle of individual twisted pairs for individual houses all the way to the node [01:02:38 CEST] <nevcairiel> (used to be 4 carriers, but the two smaller ones merged) [01:58:00 CEST] <iive> btw, you can have monopoly with more than 1 copany controlling the market. i've heard that 30% of the market are enough for that. [01:58:55 CEST] <iive> company... [01:59:23 CEST] <iive> remember google fiber? [03:04:33 CEST] <iive> google fiber never made [03:04:53 CEST] <iive> it [03:07:02 CEST] <iive> i mean, cartel is more when players on same market "reach an agreement" to play together. But when clients are physically separated and one cannot get service from anybody else, then we have a monopoly [03:11:14 CEST] <jamrial> michaelni: your arm7 fate clients are running out of disk space and it's making the reports useless [04:05:58 CEST] <michaelni> jamrial, managed to login after waiting for minutes for a prompt, i think ill make a backup of the fate configs and try to reboot it [04:07:20 CEST] <jamrial> michaelni: cool [04:30:12 CEST] <michaelni> seems rebooting ... really slow [04:39:31 CEST] <michaelni> it rebooted, really funny, the shutdown took like 30min and the startup seems to have been so quick i missed it [04:40:45 CEST] <michaelni> 14gb disk is 97% full [04:42:01 CEST] <cone-889> ffmpeg 03Michael Niedermayer 07master:f1baafac7129: avcodec/interplayvideo: Clean up frames on parameter change [04:50:05 CEST] <michaelni> wonderfull over 5gb of useless kernel images [07:42:51 CEST] <ubitux> 01:07:08,360 --> 01:07:11,920 [07:42:52 CEST] <ubitux> And that was all <? br /> - I do not remember [07:42:56 CEST] <ubitux> hello wm4 :D [07:43:06 CEST] <ubitux> (yeah that one makes no sense) [07:47:16 CEST] <ubitux> 00:07:35,022 --> 00:07:38,557 [07:47:18 CEST] <ubitux> - Ja sam tvoj seminar natrag <br / > u New Yorku u '91. [07:48:06 CEST] <ubitux> 00:38:07,760 --> 00:38:09,890 [07:48:08 CEST] <ubitux> Sei tu il medico che...?< br /> Non si ottiene il bambino? [07:48:10 CEST] <ubitux> yeah anyway [07:48:13 CEST] <ubitux> wm4: there are some. [09:25:01 CEST] <wm4> ubitux: so, "<br" whitespace "/" whitespace ">" ? [09:38:55 CEST] <ubitux> wm4: < [09:39:15 CEST] <ubitux> wm4: <\s*[Bb][Rr]\s*/\s*> [09:39:30 CEST] <ubitux> with \s = whitespaces [09:45:55 CEST] <wm4> so uh why don't you just rewrite it to do generic tag parsing, instead of this special-cased mess intermixed with sscanfs? [09:53:44 CEST] <ubitux> wm4: just push your br patch [09:53:57 CEST] <ubitux> if you can add the trailing / support easily, please do [09:54:01 CEST] <ubitux> otherwise, whatever. [09:54:53 CEST] <ubitux> i didn't write that decoder in the first place (i wrote one in mplayer though) [10:00:44 CEST] <wm4> rewriting it might still be worth it though [10:03:00 CEST] <wm4> the current parser seems to eat that though [10:03:38 CEST] <wm4> weirdly fails on upperspace characters in the tag [10:05:33 CEST] <cone-025> ffmpeg 03wm4 07master:f605b56ad9c5: htmlsubtitles: support <br> tag [10:14:17 CEST] <jkqxz> wm4: I've no idea; Diego complained about it in some previous code and I just copied it forward. [10:14:23 CEST] <jkqxz> So, cargo-culting, I guess... [10:18:10 CEST] <jkqxz> Some previous code = <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext_vaapi.c;…>. [10:19:51 CEST] <wm4> seems just as unjustified [12:27:41 CEST] <durandal_1707> peloverde: have you had time to check it out? [12:51:12 CEST] <J_Darnley> Good god! I knew passing around these "opaque" structs was bad. Look at that! It is altering it! [12:52:48 CEST] <J_Darnley> Why can't these people just use a normal block based transform? [12:55:42 CEST] <nevcairiel> normal is another word for boring [12:57:54 CEST] <J_Darnley> It is another word for understandable [12:58:01 CEST] <J_Darnley> Even if I have no idea how multiplies, adds, and subs do a frequency transform I can understand what the code is doing [13:51:46 CEST] <funman> does git bisect need something special to work with the merges? [13:53:44 CEST] <nevcairiel> There is a script in the tools folder to help with that. But basically just skip commits that are on the wrong side [14:01:28 CEST] <RiCON> ubitux: hehe https://i.fsbn.eu/YtW8.png (my rss parser removed the <br>) [14:03:54 CEST] <RiCON> hm, no, seems specific to the atom feed [14:09:03 CEST] <ubitux> seems to appear fine :p [14:09:24 CEST] <ubitux> try commiting <script ...> now [14:10:40 CEST] <RiCON> difference is probably here: http://git.videolan.org/?p=ffmpeg.git;a=rss http://git.videolan.org/?p=ffmpeg.git;a=atom [14:11:03 CEST] <RiCON> one seems to sanitize the tag, the other doesn't [14:11:26 CEST] <RiCON> but the one that does sanitize it actually doesn't show it(?) [14:48:29 CEST] <ubitux> wm4: you may want to poke mateo` about the frame pool; he reintroduced it in lavfi for a & v, i think he wants to work on unifying it with lavc [14:49:29 CEST] <wm4> sounds like a good idea [16:15:33 CEST] <wm4> nice, AV_OPT_TYPE_BINARY relies on undefined behavior [16:29:09 CEST] <J_Darnley> Oh good. [17:09:26 CEST] <rcombs> wm4: fun, how's that? [17:13:54 CEST] <wm4> rcombs: the binary option consists of a void*/int pair (the latter to store the length of the allocation), and it simply gets the pointer to the int field via pointer arithmetics [17:14:01 CEST] <wm4> pretty sure that's Not Allowed [17:14:48 CEST] <rcombs> afaik that's implementation-defined, not UB [17:15:07 CEST] <rcombs> the resolution type works the same way (with 2 ints) [17:15:40 CEST] <wm4> at least with the same type it's slightly safer due to no alignment fun [17:15:49 CEST] <rcombs> no relevant implementation pads between a pointer and an int (or between 2 ints), so it should be fine [17:16:22 CEST] <wm4> that sounds too much like "2222not UB by coincidence [17:16:32 CEST] <wm4> stupid keyboard [17:17:47 CEST] <rcombs> pretty sure it wouldn't be UB regardless [17:17:58 CEST] <rcombs> since writing to struct padding isn't UB [17:18:35 CEST] <rcombs> just, the C standard doesn't provide a guarantee that that code will end up writing to the field it intends to (it could instead write to padding) [17:18:54 CEST] <rcombs> so, implementation-defined and fine in all supported implementations, but not UB [17:20:28 CEST] <J_Darnley> I give up. I've just reimplemented the same shit. Clearly the coeffs are not going where I thought they were. [17:28:51 CEST] <wm4> rcombs: I find that surprising [17:29:17 CEST] <rcombs> well what part of that are you expecting to be UB? [17:30:18 CEST] <wm4> making assumptions about the struct layout, and even writing to the padding [17:32:43 CEST] <rcombs> writing to padding has to be legal; else you wouldn't be able to memset() a struct [17:35:54 CEST] <wm4> memset might be a special case just like memcpy [17:36:07 CEST] <wm4> and I think in theory memset could be different from default initialization [17:38:58 CEST] <rcombs> pointer arithmetic can be UB in certain circumstances (going more than 1 past the end of an array) [17:39:25 CEST] <rcombs> a pointer to a non-array is treated like a pointer to a 1-element array for the purposes of overflow and UB requirements [17:39:33 CEST] <wm4> and you don't think going from struct member to member is UB? [17:39:45 CEST] <rcombs> and incrementing to 1 past the end of an array is guaranteed not to overflow and is not UB [17:40:31 CEST] <rcombs> so incrementing a valid pointer is not UB [17:44:47 CEST] <rcombs> https://www.securecoding.cert.org/confluence/display/c/ARR37-C.+Do+not+add+… see ARR37-C-EX1 [17:48:18 CEST] <wm4> yeah, but that doesn't mean anything for the next field in a struct [18:03:58 CEST] <rcombs> it doesn't guarantee that the resulting pointer will be to the next field (that's struct layout, which is implementation-defined), but the arithmetic itself is not UB [18:14:52 CEST] <wm4> well, dereferencing the pointer to past-the-last-array-element is still UB, even if the pointer is valid [18:33:39 CEST] <jamrial> ubitux: ping [19:09:52 CEST] <ubitux> jamrial: pong [19:12:16 CEST] <jamrial> ubitux: whenever you have time, can you test https://pastebin.com/jwC5Tcd2 ? [19:12:54 CEST] <jamrial> wrote that blindly, so it may not work at all and need a simple change here and there [19:13:23 CEST] <ubitux> what is it for? speed attempt? [19:13:30 CEST] <jamrial> it allows that neon function to work for any value of i between 0 and 63 instead of only a bunch (which are the ones the aac decoder actually needs) [19:13:59 CEST] <jamrial> it's not really necessary, but would make the checkasm test be more thorough [19:15:03 CEST] <jamrial> the c version and x86 version i wrote work for all values of i, but that arm one was microoptimized for the specific values the aac decoder currently uses [19:15:57 CEST] <jamrial> at least with the x86 version, when i tried to implement the same optimization i didn't see any speed improvements, so i suppose the same may happen with this neon one [19:16:28 CEST] <jamrial> better check in any case, since after all in aarch64 the stereo_interpolate functions didn't perform as expected [19:20:15 CEST] <ubitux> jamrial: we don't have a test for checkasm for this function [19:20:33 CEST] <ubitux> didn't you had a patch for this? [19:21:18 CEST] <ubitux> (it will be easier for me to test) [19:23:00 CEST] <jamrial> ubitux: https://pastebin.com/hT5dZiKg this tests every value of i, and https://pastebin.com/5iyDhRS7 tests only 3 and 5 (what the aac decoder uses) [19:23:39 CEST] <jamrial> wrote that back when you first submitted the checkasm test, not sure if they apply cleanly with what you committed [19:24:40 CEST] <ubitux> ps_hybrid_synthesis_deint_neon (aacpsdsp.c:166) [19:24:42 CEST] <ubitux> - aacpsdsp.hybrid_synthesis_deint [FAILED] [19:25:31 CEST] <ubitux> (or bus error without your asm modification but that's expected) [19:25:53 CEST] <jamrial> figures, getting it right blindly the first time is rare :p [19:26:07 CEST] <ubitux> :) [19:26:33 CEST] <ubitux> i confirm the "safe" test currently works (without your changes) [19:26:43 CEST] <jamrial> ok, if you feel like finding what else needs to be done to get it working then i can apply the full range test, otherwise i'll just apply the test for values 3 and 5 [19:27:11 CEST] <ubitux> sorry i don't have time for this currently [19:27:20 CEST] <jamrial> alright [19:27:38 CEST] <jamrial> thanks for testing the above anyway [20:06:44 CEST] <atomnuker> the total amount of threads cannot change during runtime, right? [20:08:36 CEST] <atomnuker> (more specifically avctx->thread_count) [20:12:47 CEST] <atomnuker> BBB: supposing you run avctx->execute2 and you'd like to prevent thread contention on a single variable [20:12:56 CEST] <atomnuker> is there a mutex or something I can use? [20:13:44 CEST] <BBB> contention? [20:13:53 CEST] <BBB> you mean multiple access without lock? [20:14:04 CEST] <BBB> most people would use atomics, but it sounds like you want something else? [20:15:28 CEST] <nicolas17> what does codec_time_base (as reported by ffprobe -show_streams) aka tbc (as reported by av_dump_format) mean? [20:15:47 CEST] <nicolas17> it seems to be read from AVStream.codec.time_base, but that's deprecated [20:15:58 CEST] <atomnuker> BBB: can't, need a mutex or something similar [20:16:07 CEST] <atomnuker> I have a bufqueue which I can't touch [20:16:22 CEST] <atomnuker> I could move it outside the avctx->execute and get away without it though [20:16:36 CEST] <BBB> if possible, move it outside, yes [20:16:47 CEST] <BBB> Im not sure what you want to do precisely so its hard to suggest something specific [20:17:20 CEST] <atomnuker> opus can output multiple frames in a single packet [20:17:29 CEST] <atomnuker> up to 6 [20:18:11 CEST] <atomnuker> I do most of my time dependent analysis before but the majority of the search can be run in separate threads [20:18:25 CEST] <atomnuker> and quantization and encoding [20:18:40 CEST] <BBB> right [20:18:47 CEST] <atomnuker> (actually up to 48 frames per single packet if you go down to 2.5 msec frames) [20:18:50 CEST] <BBB> I would encourage doing the bufqueue access outside the execute [20:19:06 CEST] <BBB> execute is primarily designed for having no concurrent access at all within it [20:19:21 CEST] <BBB> so whatever you do that needs protection needs to be done manually with mutexes and will have significant overhead [20:21:46 CEST] <durandal_1707> this aac 960/120 mdct is really obnoxious [20:21:55 CEST] <atomnuker> tell me about it [20:22:33 CEST] <atomnuker> there's a horrid condition right in the busiest path of the forward mdct [20:23:05 CEST] <atomnuker> and I'm pretty sure branch prediction gets it 100% wrong 100% of the times and that's why its not that fast [20:23:24 CEST] <atomnuker> since the prediction depends on a randomly distributed variable from a randomly chosen point in a lookup table [20:23:53 CEST] <atomnuker> (actually its kinda linear, there's a stride) [21:36:44 CEST] <cone-353> ffmpeg 03Derek Buitenhuis 07master:99c68861f9c7: concatdec: Do not pass NULL to memcmp [21:39:55 CEST] <cone-353> ffmpeg 03Ricardo Constantino 07master:3b3501f75cb2: configure: require pkg-config for libvorbis [22:49:21 CEST] <durandal_1707> atomnuker: you sure mdct15 of 3 aka mdct120 works without artefacts? [22:49:47 CEST] <atomnuker> yes, absolutely, the opus decoders and encoders use it [23:02:21 CEST] <BBB> J_Darnley: what happened to the blog post? [23:16:41 CEST] <peloverde> durandal_1707: where's your sample? [23:18:31 CEST] <durandal_1707> peloverde: aac samples are on trac.ffmpeg.org/ticket/1407 [23:20:18 CEST] <durandal_1707> another one is linked on wiki.multimedia.cx/index.php/Advanced_Audio_Coding in table of features [23:22:01 CEST] <durandal_1707> dont use streams they are not properly marked as 960/120 [23:52:06 CEST] <peloverde> durandal_1707: Which of those in the ticket uses only long windows, none of the conformance vectors are lc960 without sbr [23:55:00 CEST] <durandal_1707> latm from ticket sample have very minimal artifacts mostly long windows [23:55:38 CEST] <J_Darnley> Gah [23:56:09 CEST] <J_Darnley> BBB: it was published here http://obe.tv/about-us/obe-blog/item/46 [23:56:49 CEST] <J_Darnley> I swear mirc doesn't flash in the taskbar anymore when I have a highlight [23:58:26 CEST] <peloverde> durandal_1707: for the latm one i'm just getting errors from demux about codec parameters [00:00:00 CEST] --- Fri Jul 7 2017

1 0

ffmpeg.log.20170706
by burek 07 Jul '17

07 Jul '17

[00:05:49 CEST] <nemosphere> hi there. I never succeed to install FFMPEG the right way for audacity to find it's requested lib. I decided to learn enough for being able to do it. Why my fresh compiled from sources ffmpeg didn't provide that libavformat.so.55 that audacity requires please ? [00:06:12 CEST] <c_14> --enable-shared probably [00:06:23 CEST] <nemosphere> default yes, no ? [00:06:32 CEST] <c_14> It's not the default, you need to add it [00:06:52 CEST] <nemosphere> mmh, i go compile it again [00:08:37 CEST] <nemosphere> --enable-shared build shared libraries [no] [00:08:42 CEST] <nemosphere> you're right [00:08:47 CEST] <c_14> I'm always right [00:08:57 CEST] <furq> stop stealing my gimmick [00:09:19 CEST] <BtbN> you don't want to install that globally into your system [00:09:23 CEST] <BtbN> it's most likely going to collide [00:09:29 CEST] <nemosphere> do i have another trap to manage ? [00:09:40 CEST] <nemosphere> for using audacity with ffmpeg inside [00:09:45 CEST] <BtbN> Install it somewhere in your homedir, and point audacity there [00:09:53 CEST] <BtbN> static libs should work just fine for that [00:10:10 CEST] <nicolas17> yes, pass a --prefix=$HOME/myownffmpeg to configure too [00:10:43 CEST] <nemosphere> i don't understand collide [00:10:55 CEST] <nemosphere> i know collapse [00:11:10 CEST] <nemosphere> i'm not an english speaker [00:11:11 CEST] <c_14> If your system installs a different version of ffmpeg they'll clash [00:11:18 CEST] <nemosphere> oh [00:11:18 CEST] <c_14> things will (most probably) break [00:11:23 CEST] <nemosphere> thx [00:11:31 CEST] <nicolas17> are you compiling audacity from source? [00:11:36 CEST] <nemosphere> yes [00:11:58 CEST] <nicolas17> do you need to install ffmpeg from source? why not install the -dev packages from your distro? [00:12:26 CEST] <nemosphere> i don't think it's an available package, i'm using slack [00:12:38 CEST] <nicolas17> slackware? [00:12:42 CEST] <nemosphere> yep [00:13:02 CEST] <nicolas17> yeah probably need to compile your own then [00:13:18 CEST] <nemosphere> in fact i remember i tried, but audacity don't see what he is looking for [00:13:42 CEST] <nemosphere> that's why i try from sources, i want to win against the machine :) [00:14:35 CEST] <nemosphere> i have some scripts i called avi2wav, or things like that, but now i would like to gain time, and comfort [00:15:27 CEST] <nemosphere> thx for your quick answers, i read it again for being sure to understand well, then try [01:23:52 CEST] <nicolas17> I managed to produce a video! [01:23:57 CEST] <nicolas17> but it doesn't play properly [01:24:11 CEST] <nicolas17> and it reports pretty bad metadata [01:30:31 CEST] <nicolas17> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 2592x1944, 7070412 kb/s, 15515.15 fps, 15360 tbr, 15360 tbn, 60 tbc (default) [02:14:17 CEST] <hexptr> hi, I'm trying to call swr_convert_frame with a NULL input to flush the buffered data out at the end (as the docs tell me to) [02:14:58 CEST] <hexptr> but this seems to lead to a sigsegv on line 143 of swresample_frame.c where "in" is dereferenced despite being NULL [02:15:09 CEST] <hexptr> what am I doing wrong? [02:15:23 CEST] <hexptr> this is ffmpeg 3.3.2 btw [02:19:53 CEST] <atomnuker> no, its not wrong, its just the way it is [02:20:29 CEST] <atomnuker> just put your data plane pointers in an array and give swr the pointer of the array [02:20:39 CEST] <atomnuker> and specify 0 as the number of input samples available [02:20:44 CEST] <atomnuker> it'll then flush itself out [02:20:55 CEST] <atomnuker> do remember that the return value is what's important [02:21:18 CEST] <atomnuker> the function which tells you how many samples swr can output gives you a ceiling, not the actual amount that will be output [02:21:26 CEST] <hexptr> all this time I've been passing in empty AVFrames, assuming that swr would allocate the buffers for me [02:21:39 CEST] <hexptr> I take it I'm not meant to be doing that then [02:22:21 CEST] <atomnuker> of course not, you have to allocate your avframe buffers prior to calling swr [02:22:51 CEST] <hexptr> aha. [02:22:53 CEST] <atomnuker> populate format, layout, sample rate and the number of samples and then call av_frame_get_buffer(frame, 0) [02:23:20 CEST] <hexptr> I was lured into thinking that that was valid because it seemed to work all the way until I needed to flush [02:23:20 CEST] <atomnuker> after that you can call swr_convert like this: [02:23:44 CEST] <atomnuker> frame->nb_samples = swr_convert(swr, frame->data, frame->nb_samples, src, input_samples) [02:24:16 CEST] <hexptr> I see what you mean, I'll end up doing that, thanks [02:24:17 CEST] <atomnuker> with src being defined as "const uint8_t *src[] = { (const uint8_t *)src_samples };" [02:24:26 CEST] <hexptr> but looking at the docs for swr_convert_frame [02:24:42 CEST] <hexptr> pretty sure it suggests that the output buffers can be unallocated: [02:24:46 CEST] <hexptr> "If the output AVFrame does not have the data pointers allocated the nb_samples field will be set using av_frame_get_buffer() is called to allocate the frame." [02:25:39 CEST] <hexptr> I mean the grammar is a bit odd, but I took from that that swr would call av_frame_get_buffer for me [02:25:43 CEST] <atomnuker> swr_convert_frame? [02:25:49 CEST] <hexptr> yes [02:26:20 CEST] <atomnuker> huh, didn't realize there was such a function [02:26:25 CEST] <atomnuker> nevermind then, I guess it works [02:27:42 CEST] <hexptr> well, I wish it worked as claimed... [02:28:07 CEST] <hexptr> I'll dig into the code and see if I can propose a patch [02:28:13 CEST] <hexptr> either to docs or to the code [02:28:34 CEST] <hexptr> thanks for clarifying anyway :) [02:29:32 CEST] <atomnuker> nevermind what I said, I was assuming you used swr_convert(), not swr_convert_frame() [02:30:01 CEST] <atomnuker> it should always allocate data planes if there's enough data to output [02:31:14 CEST] <hexptr> hm, reading the code I'm pretty sure it's just missing a NULL check in the calculation of number of samples to allocate [02:32:19 CEST] <hexptr> getting late, I'll deal with this later [02:47:08 CEST] <nicolas17> still clueless here [02:47:34 CEST] <nicolas17> can't figure out what other parameter I'm missing [02:50:54 CEST] <nicolas17> is it okay for my output AVFormatContext, AVCodecContext, and AVStream's AVCodecParameters to have bit_rate=0? [02:55:19 CEST] <nicolas17> I'm using crf so I guessed I didn't need to set the bitrate [03:51:36 CEST] <nicolas17> when I encode with ffmpeg, I get a debug line with all the libx264 options, how do I print that from my own program? [03:51:50 CEST] <nicolas17> [libx264 @ 0x55fd6e35d220] 264 - core 148 r2795 aaa9aa8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 etc=etc [05:02:46 CEST] <nicolas17> my video ends up with correct timestamps and all [05:02:52 CEST] <nicolas17> but ffprobe -show_streams says codec_time_base=33/2000 [05:02:57 CEST] <nicolas17> only way I found to change that is [05:03:08 CEST] <nicolas17> outputVideoStream->codec->time_base = {1,30} [05:03:17 CEST] <nicolas17> but AVStream.codec is deprecated and I shouldn't be using it [05:04:00 CEST] <nicolas17> why the heck are there two different AVCodecContexts anyway? the one in AVStream.codec and the one I create and feed with data [05:11:13 CEST] <Tangome> Hello [05:31:34 CEST] <thebombzen> why do people do that [05:31:57 CEST] <nicolas17> this is weird [05:32:50 CEST] <nicolas17> av_dump_format, which prints the '30 fps, 30 tbr, 15360 tbn, 60 tbc' line, gets the tbc from AVStream.codec [05:33:08 CEST] <nicolas17> ffprobe gets the number for "codec_time_base=" from AVStream.codec [05:33:15 CEST] <thebombzen> I was referring to saying "hi" and leaving less than 40 seconds later but why would you set the timebase to be 1/30? [05:33:20 CEST] <nicolas17> the only way I found to set that timebase is AVStream.codec [05:33:25 CEST] <nicolas17> yet it's deprecated [05:33:38 CEST] <thebombzen> 1/30 second time base sounds extremely high [05:33:39 CEST] <nicolas17> yet it's clearly being saved somewhere in the file [05:33:51 CEST] <thebombzen> for reference, mpegts uses 1/90000 as its timebase [05:33:56 CEST] <thebombzen> why would you want a 1/30 timebase? [05:33:57 CEST] <thebombzen> :O [05:34:30 CEST] <nicolas17> also I see time_base=1/15360 [05:34:45 CEST] <nicolas17> which I'm using to calculate the pts [05:34:47 CEST] <nicolas17> so what *is* the codec timebase? [09:29:35 CEST] <nemosphere> Hink, i tried to compile ffmpeg in my home with --enable-shared, but something is missing for 'make' compiling libavcodec/libavcodec.so.57 [09:30:05 CEST] <nemosphere> /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: libavcodec/mqc.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC [09:30:59 CEST] <nemosphere> wait a mn, i'm in doubt [09:31:08 CEST] <nemosphere> i will try all that again [09:31:13 CEST] <nemosphere> sorry for the noise [09:55:15 CEST] <nemosphere> in fact it seems ok after a make clean [09:58:42 CEST] <nemosphere> not fun ! I compiled the libavformat.so successfully, in my home but then audacity don"t take it. He said that lib is still absent [10:09:02 CEST] <chuckleplant> I have a broad question about h264 encoding. How many NAL units are generated per frame? What does that number depend on? Hope it's not too broad, a very broad/generic answer would work for me at this point [10:28:00 CEST] <squ> chuckleplant: why NAL units are important to you? [10:28:14 CEST] <squ> I don't know what they are [10:29:58 CEST] <Nacht> There isn't a fixed number of NAL units per frame. I kinda depends on the video and what it includes [10:30:17 CEST] <Nacht> But there's always an AUD per frame [10:31:10 CEST] <Nacht> A good page explaining NAL units is this one: http://yumichan.net/video-processing/video-compression/introduction-to-h264… [10:31:16 CEST] <Nacht> I found it to be quite helpfull [10:31:31 CEST] <squ> thank you [11:44:16 CEST] <gallegr> hello! anyone here? [11:44:41 CEST] <hexptr> if you have a question just ask :) [11:46:56 CEST] <gallegr> i'm trying to segment an mp4 video into segments (every segment of different rime lenght). [11:47:16 CEST] <squ> -t -ss [11:47:53 CEST] <gallegr> i'm using this code https://pastebin.com/WxPV6M4t, but it generates only segments of 10 seconds. I've tryed both on Windows and Ubuntu [11:48:11 CEST] <furq> you usually can't do that with -c copy [11:48:17 CEST] <furq> every segment has to start on a keyframe [11:49:25 CEST] <gallegr> doesn't force_key_frames do that? [11:49:29 CEST] <furq> no [11:49:32 CEST] <furq> that does nothing with -c copy [11:53:33 CEST] <gallegr> i'll do some more research and try, thanks for advice [12:38:06 CEST] <middleman> Hello, i have a problem sanyo camera model VCC-HD2300P with ffplay returns "Server returned 400 Bad Request" [12:38:25 CEST] <middleman> What may be the problme ? [13:45:00 CEST] <tlhiv_laptop> i'm trying to combine audio streams in an MP4 and a WMA file. The MP4 has a video stream and may or may not have an audio stream. The WMA file only has an audio stream. I want to create an output MP4 that copies the video stream and "merges" the audio streams from the two input files (which may merge only one audio stream or two depending on whether the input MP4 contains an audio stream or not). The following does not seem to w [13:45:01 CEST] <tlhiv_laptop> ork [13:45:28 CEST] <tlhiv_laptop> ffmpeg -i foo.mp4 -i foo.wma -vcodec copy bar.mp4 [14:42:59 CEST] <kepstin> tlhiv_laptop: you want a single output audio stream that contains a mix of the audio from both files? [14:43:12 CEST] <kepstin> or do you want the result to have multiple (selectable) audio tracks? [14:44:56 CEST] <tlhiv_laptop> kepstin: the former [14:46:25 CEST] <kepstin> tlhiv_laptop: no way to do that with one command that'll work in all cases, you'll have to check whether the mp4 has an audio track first [14:46:38 CEST] <tlhiv_laptop> :-/ [14:47:25 CEST] <tlhiv_laptop> writing a script in Windows may be challenging ... if it were Linux, then it would be a piece of cake [14:47:44 CEST] <kepstin> but the command will be something like ffmpeg -i foo.mp4 -i foo.wma -filter_complex '[0:a][1:a]amix=inputs=2[audio]' -map 1:v -map '[audio]' <codec options> bar.mp4 [14:48:57 CEST] <tlhiv_laptop> what would "ffmpeg -i video.mp4 -i audio.wav -filter_complex amix=duration=first -vcodec copy -y foo.mp4" do? [14:49:25 CEST] <tlhiv_laptop> i cannot test it at the moment [14:49:43 CEST] <kepstin> tlhiv_laptop: take the "first two" audio tracks and mix them, and if there's fewer than two audio tracks, fail with an error. [14:50:10 CEST] <kepstin> and I'm uncertain about which streams will be included in the output, would have to double-check that [14:53:34 CEST] <tlhiv_laptop> what about "ffmpeg -i video.mp4 -i audio.wav -vcodec copy -y foo.mp4" ? [14:54:26 CEST] <kepstin> tlhiv_laptop: without any map options, ffmpeg will select one video and one audio stream (usually the first of each) and use those stream unmodified in the output [14:55:31 CEST] <tlhiv_laptop> then it seems like i need to play with windows batch file programming ... it's been a long time since i've done that [14:56:14 CEST] <kepstin> maybe consider powershell, instead? (I haven't used it, but it's probably better than batch files) [14:56:28 CEST] <tlhiv_laptop> is that native to windows? [14:56:59 CEST] <kepstin> yeah [14:57:04 CEST] <tlhiv_laptop> thanks for the tip [14:57:18 CEST] <tlhiv_laptop> i may just grab a windows bash :-) [14:58:56 CEST] <tlhiv_laptop> unxutils :-) [15:21:43 CEST] <tlhiv_laptop> thank you again kepstin ... i'm going to code it with bash [16:42:03 CEST] <nicolas17> so! [16:42:09 CEST] <nicolas17> trying again in another timezone :P [16:42:26 CEST] <nicolas17> what is the 'tbc' shown in, for example, ffprobe? [16:44:45 CEST] <nicolas17> it seems that's taken from AVStream.codec.time_base when encoding, and read from the same field by av_dump_format [16:45:03 CEST] <nicolas17> same for codec_time_base in ffprobe -show_streams [16:45:11 CEST] <nicolas17> but AVStream.codec is deprecated [16:46:02 CEST] <nicolas17> and I don't understand what the "codec timebase" *is*, conceptually, since players seem to interpret pts timestamps using the container's timebase [17:22:54 CEST] <krzee> im running mint 17.3 (based on debian trusty) and mmpeg is not in my apt [17:23:05 CEST] <krzee> should i install from source or is there a repo i can use? [17:24:13 CEST] <kepstin> ffmpeg you mean? [17:24:25 CEST] <krzee> oops, yes [17:24:33 CEST] <kepstin> and there's no 'debian trusty'; I think it's based off ubuntu trusty (14.04) instead [17:24:33 CEST] <krzee> i spelt it right in the shell ;] [17:24:39 CEST] <kepstin> which is... kind of old [17:24:43 CEST] <pgorley> there's this ppa which is (i find) well-maintained: https://launchpad.net/~jonathonf/+archive/ubuntu/ffmpeg-3 [17:24:54 CEST] <krzee> thank you sir [17:25:33 CEST] <kepstin> I hope mint switches to an ubuntu xenial or newer base at some point, then you'll have a working ffmpeg in the standard repos. [17:26:37 CEST] <krzee> that did it, installed now =] [17:26:59 CEST] <pgorley> kepstin: mint 18 is based on 16.04, no? [17:27:38 CEST] <kepstin> oh is it? I have no idea what the mint version numbers mean :) [17:28:07 CEST] <pgorley> just checked, and yes, 18 is based on xenial [17:29:04 CEST] <kepstin> of course, you only get ffmpeg 2.8 in xenial, so it's still kind of old (would want a newer one for the aac encoder, at least) [17:36:27 CEST] <krzee> so im trying to turn a directory of screenshots into a small slideshow, i used this command: k@smallaptop:~/mom > ffmpeg -r 1/3 -i pics/*.jpg -vcodec copy out.mp4 but i just ended up overwriting all the images in the directory with the first image, and made a slideshow of the single image that copied to all the others :D [17:56:24 CEST] <krzee> i see one issue is that my geometry doesnt match, i will use gm to fix that... do i have some problem with my -i pics/*.jpg that is causing the overwrite? [17:56:51 CEST] <nicolas17> yeah [17:56:59 CEST] <nicolas17> that will be expanded by your shell into [17:57:10 CEST] <krzee> -i <all files> [17:57:15 CEST] <nicolas17> -i pics/pic1.jpg pics/pic2.jpg pics/pic3.jpg [17:57:17 CEST] <nicolas17> which means [17:57:27 CEST] <nicolas17> use pic1.jpg as an input, and pic2.jpg and pic3.jpg as outputs [17:57:36 CEST] <krzee> ahhh [17:57:50 CEST] <krzee> so i need a -i for every pic? i can do that [17:58:02 CEST] <nicolas17> you could let ffmpeg expand the wildcard [17:58:06 CEST] <nicolas17> -pattern_type glob -i "pics/*.jpg" [17:58:15 CEST] <krzee> ahhh [17:58:31 CEST] <krzee> nice thank you! [18:00:08 CEST] <krzee> hey that seems to have worked without even using gm to resize them all to the same [18:01:03 CEST] <krzee> now i just need to slow this sucker down, -r 1/3 and -r 1/8 are both light speed [18:01:19 CEST] <nicolas17> oh you're making a slideshow? [18:01:25 CEST] <krzee> yessir [18:01:54 CEST] <krzee> automagically generating a slideshow of adoptable dogs for my moms dog rescue's weekly dog adoption day [18:02:37 CEST] <krzee> already built the scraper that grabs the dogs pics from her website and watermarks them with the dogs name =] [18:05:37 CEST] <nicolas17> too bad doing ken burns effect with ffmpeg video filters would be a pain in the ass :P [18:06:49 CEST] <krzee> haha totally [18:07:02 CEST] <nicolas17> it's probably *possible* but :P [18:07:07 CEST] <krzee> but she never imagined that this could be automated, she'll be fine without effects [18:07:27 CEST] <krzee> just scrolling through the dogs at like 2-3 sec per dog is greatness [18:07:44 CEST] <krzee> and i even see ffmpeg will let me add audio, that may end up happening later on [18:08:29 CEST] <krzee> this will free up extra time for a volunteer that will be able to spend that extra time with the doggies every week :) [18:24:28 CEST] <krzee> oh wow your transition suggestion led me to diascope [18:25:36 CEST] <krzee> its pretty crazy but seems to totally simplify doing this, it's a cli frontend for making slideshows using gm and ffmpeg [18:28:22 CEST] <krzee> diascope creates a long shell script to do all the craziness, which is funny because i [18:28:58 CEST] <krzee> i'll have a short shell script generating the diascope file, and calling diascope to make a much longer shell script :D [18:29:27 CEST] <krzee> thanks nicolas17, i actually will do transitions now :D [19:38:12 CEST] <ShaneVideo> I read ffserver was going to be deprecated, is it still in the project or is there a replacement? [19:40:53 CEST] <BtbN> It's in there, but nobody maintains it [19:40:59 CEST] <BtbN> the moment it gets in the way, it will go [19:41:06 CEST] <ShaneVideo> i see, thanks [19:41:17 CEST] <BtbN> it's horrible and should not be used anyway [19:41:48 CEST] <ShaneVideo> is there an alternative or better way? [19:41:54 CEST] <BtbN> for what? [19:41:57 CEST] <DHE> nginx-rtmp enjoys popularity [19:42:16 CEST] <ShaneVideo> I need to stream a mjpg and h264 stream at the same time [19:42:21 CEST] <ShaneVideo> from /dev/video1 [19:42:25 CEST] <DHE> to what? [19:42:55 CEST] <ShaneVideo> mjpg to client web browsers, h264 to vlc [19:43:04 CEST] <BtbN> I doubt Browsers can play mjpeg [19:43:14 CEST] <ShaneVideo> IOS plays it great [19:43:23 CEST] <BtbN> But why would you do that? It's huge [19:44:11 CEST] <ShaneVideo> its part of a webapp, it just needs to show a preview of whats happening on the live feed [19:45:56 CEST] <krzee> weird... i came back to ffmpeg cause that other frontend for it is too old to use, i found that ffmpeg -r 1/3 -pattern_type glob -i "pics/*.jpg" out.flv gives me a slideshow video file that plays how i want, but i cant get the same results with .mpg .avi or .mp4 [19:46:46 CEST] <krzee> even converted the flv to avi and then even that stays at the first image [19:56:34 CEST] <krzee> boom got it, ffmpeg -framerate 1/3 -pattern_type glob -i "pics/*.jpg" -c:v libx264 -r 30 -pix_fmt yuv420p out.mp4 [20:00:52 CEST] <BtbN> you will want to specify a bitrate, or it will look horrible [20:01:04 CEST] <BtbN> or a crf, or at least something [20:01:11 CEST] <furq> x264 should look ok with default settings [20:02:45 CEST] <furq> if it's a slideshow then you probably want -tune stillimage [20:04:24 CEST] <kepstin> ShaneVideo: if you wactually want to send stuff to browsers, why not do e.g. HLS to the browser, and then not even require vlc at all? [20:05:09 CEST] <nicolas17> I was disappointed to find VLC can't seek in HLS [20:05:14 CEST] <nicolas17> at least the version I have and with the stream I tried [20:06:01 CEST] <kepstin> well, yeah, it depends a lot on the stream. A live stream where the playlist only includes a few recent segments, for example, won't be seekable. [20:06:35 CEST] <kepstin> but it should be able to seek if all the segments from the start are available, and the playlist has correct segment duration info [20:06:42 CEST] <nicolas17> it wasn't live [20:07:34 CEST] <nicolas17> 'vlc http://devstreaming.apple.com/videos/wwdc/2016/504m956dgg4hlw2uez9/504/hls_…' [20:07:51 CEST] <nicolas17> which is a video *about* HLS, enjoy the meta :P [20:08:32 CEST] <kepstin> seeking works in that video in mpv, fwiw. [20:08:39 CEST] <kepstin> so yeah, i guess it's a vlc issue [20:18:27 CEST] <Hopper_> Hey FFmpeg, looking to move this from linux to windows. https://pastebin.com/PxGTyER9 I know I need to change v4l2 to dshow, what else am I missing? [20:34:28 CEST] <kepstin> Hopper_: well, the value for -i to use with dshow is quite a bit different, I think it takes a device name or something. Run "ffmpeg -h demuxer=dshow", it might have an option to list devices, and you can double-check the other options there too. [20:35:07 CEST] <Hopper_> Ya, I'm working on that part now, either of them work independently, but when I try to use both I get an error on the second feed. [20:36:11 CEST] <kepstin> hmm. I think with dshow, you might be able to do something to grab multiple devices with a single input [20:36:39 CEST] <Hopper_> I don't really know what dshow is, should I be using that or something else? [20:37:04 CEST] <kepstin> dshow (short for 'directshow') is the name of the windows specific api to grab frames from typical cameras. [20:37:26 CEST] <Hopper_> So it's the standard? [20:37:29 CEST] <kepstin> looks like it should work with multiple inputs; can you pastebin the complete command & output from a failing command? [20:37:39 CEST] <Hopper_> Yup [20:38:00 CEST] <kepstin> Hopper_: on linux you use 'v4l2', which is the "video for linux (version 2)" api [20:38:08 CEST] <kepstin> these are just all os-specific drivers. [20:38:16 CEST] <Hopper_> I understand. [20:40:37 CEST] <kepstin> but if you're using the same config on all the cameras, doing something like -i "video=Camera1DeviceName:video=Camera2DeviceName" might work. worth a try, anyways. [20:40:48 CEST] <Hopper_> Man, is there an easier way to copy in WindowsCMD? [20:41:11 CEST] <Hopper_> I'll look into that as well, they will be identical. [20:41:13 CEST] <Hopper_> https://pastebin.com/Avb5UzwM [20:41:14 CEST] <kepstin> Hopper_: I thought they improved that in windows 10, hmm. [20:41:31 CEST] <Hopper_> I'm in 7, not used to it. So much more work than debian. [20:41:52 CEST] <kepstin> ah, yeah, 7 still has the old terminal window. It's a lot better in 10 :/ [20:42:43 CEST] <kepstin> Hopper_: you forgot to include "-f dshow" before the second input, so it's trying to open a file named "Logitech HD Pro Webcam C920" [20:42:55 CEST] <Hopper_> Hm, didn't have to do that in linux. [20:43:22 CEST] <nicolas17> well /dev/video0 is certainly a v4l device [20:43:26 CEST] <kepstin> Hopper_: a quirk, I think on linux, there's some magic where the special dev files /dev/video* are recognized as v4l devices [20:43:41 CEST] <nicolas17> but "Logitech HD Pro Webcam C920" *could* be a relative path to a file with whatever [20:43:56 CEST] <kepstin> Hopper_: it wouldn't be wrong to put another -f v4l2 before the second input on linux :) [20:44:00 CEST] <tdr> kepstin, its not some implied magic, its just where the device nodes are created [20:44:26 CEST] <Hopper_> kepstin: Got it, my linux syntax was wrong. [20:44:44 CEST] <buu> When I'm using the concat filter/filter complex and I start off by saying [0:0] [0:1] and so on, I know that 0:0 is the first stream of the first input but how is this information passed to the rest of the command? [20:44:54 CEST] <kepstin> tdr: the magic is that inside ffmpeg, it uses the v4l driver to read the device rather than just opening it as a file and trying to read a video stream... [20:44:54 CEST] <buu> Is this something specific to how concat= is defined to take arguments? [20:44:56 CEST] <kepstin> I think? [20:45:13 CEST] <tdr> kepstin, ah ok, so inside ffmpeg not "kernel magic" got it [20:46:26 CEST] <nicolas17> tdr: yeah, magic like "if the path is /dev/video0 then use -f v4l2 by default" [20:46:34 CEST] <nicolas17> like it does for file extensions [20:46:35 CEST] <tdr> very cool [20:47:50 CEST] <buu> does the order of the -map '[v]' /[a] lines matter? [20:48:52 CEST] <kepstin> buu: yes, the order that you use the map options is the order the streams will be included in the output [20:51:18 CEST] <krzee> furq: adding -tune stillimage makes the filesize go from 3mb to 3.5mb for my video but i cant see a difference when playing it, i dont see it in the manpage nor in ffmpeg -h so im not sure what its doing [20:51:46 CEST] <nicolas17> krzee: are you using crf or bitrate or what? [20:52:38 CEST] <furq> http://vpaste.net/FqDLA [20:52:48 CEST] <krzee> ffmpeg -framerate 1/3 -pattern_type glob -i "pics/*.jpg" -c:v libx264 -r 30 -pix_fmt yuv420p -tune stillimage out.mp4 [20:53:03 CEST] <furq> it should generally look a bit sharper [20:53:13 CEST] <nicolas17> no point playing with -tune if you're not even setting a basic parameter for quality vs size :P [20:53:23 CEST] <nicolas17> furq: what's the default crf? [20:53:25 CEST] <furq> 23 [20:53:37 CEST] <krzee> oh maybe its because the source images arent that special in quality i dont see a difference [20:54:14 CEST] <nicolas17> krzee: maybe using -tune stillimage means you can afford to use a higher crf and get a smaller file [20:54:48 CEST] <nicolas17> maybe with crf 23 the quality is so good you won't see the difference, but with a higher crf (lower quality, smaller file) you'll notice -tune stillimage vs no tuning [20:55:08 CEST] <kepstin> well, i seem to recall that the '-tune stillimage' was originally designed for encoding single-frame "video" (i.e. using x264 as a still image format, rather than video) [20:55:42 CEST] <kepstin> it can be used on video, and I think it'll preserve sharpness better? not sure [20:55:59 CEST] <nicolas17> kepstin: he's making a slideshow, so [20:56:07 CEST] <furq> yeah [20:56:11 CEST] <kepstin> but yeah, -crf values are *not the same* across different tune and profile options [20:56:27 CEST] <furq> higher aq-strength and lower deblock should increase sharpness [20:56:58 CEST] <furq> i assume those psy settings will do the same but i forget how that actually works now [20:57:00 CEST] <nicolas17> let's try this again: [20:57:23 CEST] <nicolas17> does anyone know what tbc is, in the "30 fps, 30 tbr, 15360 tbn, 60 tbc" line? [20:57:57 CEST] <kepstin> note that the reason crf values are not equivalent across tunes is the same reason as why you shouldn't change tune between first and second pass of video encodes ;) [20:58:02 CEST] <furq> apparently it's the timebase from AVCodecContext [20:58:13 CEST] <nicolas17> it's read from AVStream.codec.time_base, and if I set that field when encoding, I get the same value back when decoding [20:58:27 CEST] <nicolas17> same for codec_time_base in "ffprobe -show_streams" output [20:58:37 CEST] <nicolas17> but what *is* it? it doesn't seem to change anything when playing [20:59:10 CEST] <krzee> ya with -crf 30 -tune stillimage its 1.8M now, looks the same too, very sweet [20:59:41 CEST] <nicolas17> krzee: nice, do you see a difference with and without tuning at that crf? [21:00:07 CEST] <krzee> i dont see any difference at all, just better file size [21:00:31 CEST] <krzee> quite a bit better, from 3M (3.5 with -tune stillimage) to 1.8M [21:01:16 CEST] <buu> kepstin: ok [21:01:26 CEST] <nicolas17> I meant crf30 vs crf30+tune [21:01:28 CEST] <buu> Is there any actual difference between audio being stream 0 and video being stream 1? [21:01:32 CEST] <buu> or vice versa [21:01:45 CEST] <Hopper_> Does anyone know of a guide to the -v options? [21:01:58 CEST] <buu> Also in the filter man page, "The stream sent to the second output of split, labelled as [tmp], is processed through the crop filter", why does it say "sent to the output" [21:02:08 CEST] <furq> Hopper_: https://ffmpeg.org/ffmpeg.html#Options [21:02:11 CEST] <furq> ^F loglevel [21:02:24 CEST] <krzee> ahh, crf30 = 1.9M, +tune is 1.8M, still no visable difference when watching [21:02:25 CEST] <kepstin> buu: if you've only got 1 audio and 1 video stream? I don't think any players will care about the order. [21:02:27 CEST] <buu> Is this just bad english or is there some convention that you send things to outputs of filters? [21:02:34 CEST] <nicolas17> furq: also AVStream.codec is deprecated [21:02:36 CEST] <buu> kepstin: Yeah, what about multiples of either? [21:02:39 CEST] <Hopper_> furq: Thanks [21:02:56 CEST] <nicolas17> buu: I think it means split sends the stream to its output, but let me read the whole thing [21:03:13 CEST] <buu> https://ffmpeg.org/ffmpeg-filters.html#Filtering-Introduction [21:03:14 CEST] <kepstin> buu: filters have inputs and outputs. You send frames to the inputs of a filter, then the filter does something and sends fromes to its outputs, which then might be connected to the inputs of other filters [21:03:24 CEST] <buu> kepstin: That is what I expected [21:04:05 CEST] <buu> Also, reading further, does what the split filter actually do is copy the input? [21:04:08 CEST] <kepstin> buu: if you have multiple audio tracks, a player that allows switching between them will show them in the order that you use the -map otpions in. [21:04:09 CEST] <nicolas17> "the stream you told the 'split' filter to send to its second output..." :) [21:04:35 CEST] <buu> nicolas17: I'm not sure that works =] [21:04:37 CEST] <nicolas17> buu: yes [21:04:55 CEST] <buu> I think the actual problem is that when it says 'stream' it means 'name' [21:04:56 CEST] <nicolas17> split is like Unix 'tee', it copies the input into multiple outputs [21:05:07 CEST] <buu> i.e. you're naming the outputs coming from split [21:05:32 CEST] <furq> "the name...is processed through the crop filter" [21:05:34 CEST] <furq> that doesn't work [21:05:35 CEST] <kepstin> a "stream" is a series of frames (video) or samples (audio). it means exactly what it says. [21:05:53 CEST] <furq> also "the name, labelled as [tmp]" [21:06:27 CEST] <buu> Ohh [21:06:30 CEST] <buu> I see what it means [21:07:03 CEST] <buu> Something about "sent to the output of split" just read really oddly [21:07:34 CEST] <buu> "The second output of split, the stream labeled [tmp], is processed through the crop filter.." ? [21:42:24 CEST] <alexpigment> hey guys, if i get a warning while encoding mpeg2video that says "warning, clipping 1 dct coefficients to -255..255", i can safely ignore this, right? [21:42:46 CEST] <alexpigment> i'm working within a particular set of constraints and my tests show that things look mostly fine [21:43:24 CEST] <alexpigment> if there were a simple workaround that wouldn't introduce a speed hit, though, i'd try it of course [21:46:11 CEST] <alexpigment> for what it's worth, "-mbd rd" eliminates those warnings, but a) there's a significant speed hit, and b) i don't notice a huge improvement in quality [21:52:28 CEST] <alexpigment> http [21:52:40 CEST] <alexpigment> oops - ignore last message [21:59:42 CEST] <kepstin> alexpigment: looks like that message is printed only when using -mbd simple, I guess because the other values for mbd reconstruct the mb and account for the clipping when making decisions, but simple doesn't. [21:59:48 CEST] <kepstin> alexpigment: so, it just is what it is. [22:00:31 CEST] <alexpigment> kepstin: thanks for the reply. not knowing enough about it, it seems like I should be able to ignore it [22:00:43 CEST] <alexpigment> I just didn't know if there were deeper implications that I didn't observe in my tests [22:00:48 CEST] <kepstin> alexpigment: if the quality looks good enough for you, then yeah [22:01:12 CEST] <alexpigment> good to know. thanks again [22:01:13 CEST] <kepstin> it just means that it's not making optimal decisions, so you're getting an efficiency loss (lower quality/bit) [22:01:59 CEST] <alexpigment> yeah, i'm already having to bit starve this encode anyway, so it's really hard to tell what decisions are "bad" or "good" when the scenes get too intense [22:34:55 CEST] <leif> I am using the asetpts filter to slow down audio (the documentation for setpts says you can do 2*(PTS-STARTPTS) to do it), but the resulting file has the same length. [22:35:29 CEST] <leif> I am feeding it in a ~3 minute file, and ffmpeg says it produced a ~6 minute file, but when I play it the file is only 3 minutes long, and sounds the same. [22:35:33 CEST] <leif> Here is the command: https://gist.github.com/LeifAndersen/4ad123e2bf3b528f5d13b10d4f78d973 [22:35:39 CEST] <leif> Any suggestions? [22:35:46 CEST] <leif> (command+output ^) [22:43:40 CEST] <leif> Also asetpts=2*PTS seems to have the same result. [22:45:57 CEST] <ShaneVideo> I've currently got a 5 second delay when using HLS, is there something im missing to get that lower? [22:46:32 CEST] <ChocolateArmpits> leif, i would guess mp3 doesn't support timestamps like that, so you would have to either interpolate the audio or lower the sampling rate, onlya guess though [22:47:18 CEST] <ChocolateArmpits> try wrapping to mkv and see if that works [22:48:28 CEST] <ChocolateArmpits> ShaneVideo, is hls an input stream ? [22:48:36 CEST] <ShaneVideo> yes from /dev/video1 [22:49:08 CEST] <ChocolateArmpits> a video device that gives hls ?? [22:49:14 CEST] <leif> ChocolateArmpits: OH, that would make sense. I'll play with this a bit more. Thanks. [22:49:25 CEST] <ShaneVideo> When I use ffserver and encode to mjpeg, the latency is 100ms, when I convert to a m3u8 the delay is 8 seconds [22:49:27 CEST] <ShaneVideo> *5 [22:49:53 CEST] <ChocolateArmpits> HLS delay is primarily affected by segment length [22:50:04 CEST] <leif> Also nope, sadly adelay didn't work. :( [22:50:17 CEST] <leif> (for delaying the audio) [22:51:24 CEST] <ShaneVideo> Thanks [22:53:32 CEST] <leif> ChocolateArmpits: So, when I use mkv I seem to get the track twice. [22:53:42 CEST] <leif> (At least it still seems like it has the same pitch.) [22:53:53 CEST] <leif> I'll try a different song. [22:54:42 CEST] <leif> OH NO [22:54:53 CEST] <leif> Actually, my media player is now just playing it twice as fast. [22:54:59 CEST] <leif> That's very odd. [22:55:02 CEST] <leif> Thanks btw. [22:58:08 CEST] <leif> ChocolateArmpits: Here is the ffprobe of the two files: https://gist.github.com/LeifAndersen/a2a3892d5aa1c2c7a48a735087ad0bad [22:58:35 CEST] <ChocolateArmpits> leif, is there a problem ? [22:59:31 CEST] <leif> Even though one is twice as long as the other, they both take the same amount of time to play. Although I think that's because of the differing bitrates. [22:59:41 CEST] <leif> But if that is expected behavior that is fine. Thanks. :) [23:00:30 CEST] <ChocolateArmpits> try playing back with ffplay or any other libav based player [23:03:21 CEST] <leif> ChocolateArmpits: Hmm...same behavior. [23:03:26 CEST] <leif> (I was testing it with mplayer before) [23:03:47 CEST] <leif> AH, okay [23:03:59 CEST] <leif> VLC worked as expected. (aka, really choppy, and half speed) [23:04:01 CEST] <leif> Thanks. :) [00:00:00 CEST] --- Fri Jul 7 2017

1 0