[Ffmpeg-devel-irc] ffmpeg.log.20200130

[burek]

[00:06:54 CET] <gregorycu> I'm trying to listen for a RTMP stream, and pump out the raw frame data to file descriptors. At the moment, at the start of the stream, it takes 800 ms for data to start to flow. Is there some way to reduce this delay?
[00:59:23 CET] <gregorycu> For the record, it's about 40 frames @ 60 fps, or about 650 ms.
[01:21:55 CET] <HickHoward> >doesnt ffmpegs ac3 encoder base on the reference ac3 thing from 1990
[01:22:04 CET] <HickHoward> someone on discord said this
[01:33:20 CET] <furq> ok
[03:09:40 CET] <cehoyos> HickHoward: This sounds unlikely, the ac3 encoder was part of the original commit, Dolby didn't like the code very much, if they had a copyright claim, and didn't make it, that would be hard to explain
[03:39:20 CET] <HickHoward> >Dolby didn't like the code very much
[03:39:22 CET] <HickHoward> dan
[03:39:23 CET] <HickHoward> damn
[03:40:07 CET] <HickHoward> anyway i just put that out there to put down some doubts regarding certain codec implementations someone seems to be having
[03:40:21 CET] <HickHoward> i mean
[03:40:29 CET] <HickHoward> okay not the best way to put it but anyway
[03:40:53 CET] <kingsley> I'm happy to report permission to bench mark on a Talos II computer that uses IBM's cool new POWER9v2 cpus.
[03:42:03 CET] <kingsley> I've been bench marking how fast the "libvpx" codec can render .webm.
[03:43:57 CET] <cehoyos> kingsley: We are not the developers of libvpx, interest here for libvpx performance tests are probably limited...
[03:44:32 CET] <cehoyos> HickHoward: I believe the fact that Dolby never tried to have to ac3 code removed from FFmpeg seems (to me) like a good indication that there was no copyright violation.
[03:45:03 CET] <cehoyos> And the fact that for a long time, there was only an ac3 encoder, no decoder, also supports the theory that this was not copied code.
[03:46:23 CET] <kingsley> Do any encoders besides "libvpx" support multi-threading for faster rendering?
[03:49:36 CET] <cehoyos> libx264,libx265,libaom (they are all not developed here)
[03:50:21 CET] <cehoyos> "ffmpeg -encoders" provides a list with threading information
[03:51:21 CET] <kingsley> cehoyos: Thank you very much! I'll check them out!
[03:51:21 CET] <cehoyos> To test FFmpeg, the mpeg4 encoder comes to mind
[03:52:33 CET] <cehoyos> But if this is to prove that a (Power) cpu with 256 cores runs faster than an (Intel) cpu with 20 cores, FFmpeg is likely the wrong tool: Video coding is scalable over cores, but only to a (very) limited degree, depending on the resolution
[03:52:39 CET] <kingsley> Feel free to run and/or tweak my humble benchmark. It is
[03:53:00 CET] <kingsley> $ threads_per_renderer=8 ; time ffmpeg -y -f lavfi -i mandelbrot=s=1920x1080 -loglevel fatal -threads "$threads_per_renderer" -row-mt 1 -frames 50 -c:v libvpx /tmp/bench.webm
[03:53:19 CET] <cehoyos> Yes, this tests libvpx performance.
[03:53:55 CET] <cehoyos> Note that I suspect mandelbrot has some computational complexity, testsrc2 would be a "faster" input
[03:55:08 CET] <kingsley> For what it's worth, my *preliminary* benchmarks of libvpx on a POWER9v2 with 2 CPUs, 22 cores/CPU and 4 threads/core are
[03:55:28 CET] <kingsley> One renderer using one thread: 1 frame per second (FPS).
[03:55:42 CET] <kingsley> One renderer using 8 threads: 3 FPS.
[03:56:08 CET] <kingsley> And 110 renderers using 2 threads each: 60 FPS.
[03:56:55 CET] <furq> the -encoders output isn't accurate for codecs with auto threading
[03:56:57 CET] <kingsley> So my *preliminary" results suggest 2-8 threads are best.
[03:57:15 CET] <furq> like libx264
[03:58:23 CET] <furq> but yeah libvpx generally has poor multithreading
[03:59:08 CET] <furq> x264 or something with proper frame threading will do a lot better, although you still get diminishing returns around 20 threads iirc
[04:02:08 CET] <kingsley> furq: I researching your comments...
[04:02:26 CET] <cehoyos> 20 would be impressive...
[04:03:00 CET] <furq> i mean severe diminishing returns
[04:03:07 CET] <furq> can't find the benchmark where i saw this though
[04:04:35 CET] <furq> if i had 256 cores and a workflow to split, encode and concat, i'd probably start benchmarking from 8 threads per instance
[04:18:13 CET] <kingsley> cehoyos: Thank you for suggesting "testsrc2" as input. I'm intrigued by distinguishing between fractal math (Mandelbrot) and rendering.
[04:21:49 CET] <kingsley> I particularly like its recognition of ffmpeg's "-threads <n>" option for bench marking how well it parallelizes.
[04:25:42 CET] <furq> you should probably benchmark with a non-synthetic clip
[04:29:12 CET] <HickHoward> that's quite interesting to hear that in regards to ac3
[04:29:46 CET] <HickHoward> with that being said i believe ac-3 encoding/decoding support holds up fairly well within ffmpeg even today
[04:35:22 CET] <furq> you probably shouldn't use ac3 at all any more
[04:35:27 CET] <furq> but if you have to then the ffmpeg encoder is pretty good
[04:41:44 CET] <kingsley> furq: If you happen to have the time, and are so inclined, please feel free to elaborate on how I might benchmark with a non-synthetic clip. Bonus points for a command line example!
[04:49:14 CET] <furq> http://ultravideo.cs.tut.fi/#testsequences
[04:49:18 CET] <furq> something like that
[05:50:15 CET] <Media_Thor> looking for a method to comapre two audio tracks: original and one with added translation on top of original. Is there any method to differenciate two ?
[06:06:34 CET] <EoE> usually when comparing two tracks my strategy is to invert one, and then mix down to a single track in audacity, so any parts that are the same combine to 0, and differences are left, in audacity
[06:08:11 CET] <EoE> looks like you could do this in ffmpeg using the https://ffmpeg.org/ffmpeg-filters.html#aeval filter, and then mixing them together
[06:09:08 CET] <EoE> the amerge filter should do that
[06:09:15 CET] <EoE> see https://trac.ffmpeg.org/wiki/AudioChannelManipulation
[12:27:51 CET] <Regor> hi friends how can i play m3u8 or .mpd files on cmus which uses ffmpeg backened ? i didnt find any cmus room so i am asking here
[14:09:25 CET] <GenTooMan> Greetings I noticed ffmpeg uses all the available processors by default, is it possible to control the number of processors it uses for threading? like make -j <#> does?
[14:09:54 CET] <JEEB> -threads before -i is decoders, after -i is encoders
[16:37:33 CET] <FireBurn> Is there a rough guestimate as to when the next release of ffmpeg will be? I'm guessing 4.3 or 5.0
[20:27:59 CET] <barg> does ffmpeg have an option to write back to the same file?
[20:28:12 CET] <JEEB> no
[20:28:55 CET] <JEEB> ffmpeg.c is not a "patching" application, after all
[20:30:00 CET] <Hello71> I mean... you can use the sponge utility
[20:30:02 CET] <JEEB> and while in theory removing a file should leave it around until the file handle is closed, it just makes more sense to first output to a separate file name and then handle the renaming otherwise (scripted or otherwise) afterwards
[20:30:07 CET] <Hello71> but probably you should use exiftool instead
[21:01:52 CET] <barg> ta
[21:01:59 CET] <barg> ta=thanks
[21:37:53 CET] <giaco> ffmpeg clip is buggy. I've tried both -ss + -to and -ss + -t, but the resulting file has a wrong number of seconds in it
[21:39:09 CET] <giaco> ffmpeg -i file.wav -ss 00:20:00 -to 01:20:00 results in a file of 3625 seconds
[21:39:41 CET] <giaco> audacity exports that just right
[21:52:33 CET] <giaco> using (-c copy)
[22:09:42 CET] <durandal_1707> giaco: use filters / atrim instead
[22:11:58 CET] <giaco> durandal_1707: I've just found out that is the other way around. Is the duration of the file loaded in audacity that differs from the one detected from ffmpeg
[22:12:27 CET] <giaco> durandal_1707: surprisingly 30 seconds are missing but I can't say where: head and tail sounds in place
[22:16:44 CET] <giaco> durandal_1707: Filtergraph 'trim=1000:2000' was defined for audio output stream 0:0 but codec copy was selected.
[22:20:04 CET] <durandal_1707> drop codec copy
[22:20:16 CET] <durandal_1707> it is pointlesss for wav and pcm
[22:20:51 CET] <giaco> durandal_1707: not really, I'm failing in reproducing the same file format without it
[22:21:19 CET] <durandal_1707> giaco: what codec you use?
[22:21:31 CET] <giaco> durandal_1707: ffprobe on the original file is Stream #0:0: Audio: adpcm_ima_wav ([17][0][0][0] / 0x0011), 48000 Hz, stereo, s16p, 384 kb/s
[22:22:01 CET] <durandal_1707> that can have any block size, so not really ffmpeg fault
[22:22:50 CET] <durandal_1707> besides audacity last time I checked hadnt had codec copy
[22:23:31 CET] <giaco> durandal_1707: exactly, I used audacity to check for file duration as I though ffmpeg was in error, but actually it seems the other way around
[22:24:00 CET] <giaco> if I open that wav with audacity the total duration differs. Exiftool and ffmpeg agrees on the duration, audacity days -30s
[22:24:26 CET] <giaco> no errors/warnings whatsoever displayed
[22:30:12 CET] <giaco> durandal_1707: where can I read more about that format?
[22:31:18 CET] <durandal_1707> giaco: about wav?
[22:36:33 CET] <giaco> durandal_1707: about "that can have any block size". I need something like this su succeed (ffmpeg -i input.wav -filter:a "trim=1000:2000" -c:a adpcm_ima_wav output.wav)
[22:36:52 CET] <giaco> it spits "Cannot connect video filter to audio input"
[22:37:22 CET] <furq> atrim
[22:37:31 CET] <giaco> oh, wait, my fault
[22:37:38 CET] <giaco> thanks
[22:37:47 CET] <giaco> I just realized it while pasting
[00:00:00 CET] --- Fri Jan 31 2020