[FFmpeg-devel] [PATCH] ffmpeg CLI multithreading

[Anton Khirnov]

Quoting Michael Niedermayer (2023-11-11 21:10:34)
> On Sat, Nov 04, 2023 at 08:56:09AM +0100, Anton Khirnov wrote:
> > Hi,
> > after ~2 years of work and ~700+ preparatory commits, here is finally
> > the first "fully functional" version of multithreaded ffmpeg CLI. In
> > quotes because due to the scale of the changes I'm sure some things got
> > broken and I didn't notice - more testing very much welcome.
> > 
> > One thing which is most definitely broken is the
> > -fix_sub_duration_heartbeat option, which in its current form makes
> > assumptions about synchronization between distant components
> > (encoders/muxers -> decoders), which makes it fundamentally
> > non-deterministic when each of these components runs asynchronously
> > (note that its behaviour is unpredictable even now, it's just
> > deterministic across runs with the same options). I'm currently
> > disabling the option in 16/24, better suggestions on what to do with it
> > are welcome.
> > 
> > Runtime overhead of the threading seems to be negligible in typical
> > cases, though it may become significant when there is very little work
> > per packet. You should see significantly better CPU
> > utilization/wallclock speedup on multicore systems whenever transcoding
> > isn't dominated by a a single component and the components aren't
> > themselves already multithreaded.
> > 
> > The set is structured similarly to the previous RFC:
> > * 01-09/24 are preparatory fixes and could be pushed on their own well
> >   before the rest of the series; thanks to Paul for writing 02/24
> > * 10-17/24 move the two remaining components (encoding and filtering)
> >   into threads (as before it's "fake" threading where the main thread
> >   waits for the other thread to be done, and is thus not truly parallel)
> >   and do other preparatory changes - these may introduce significant
> >   temporary overhead and/or break some corner cases, so should be pushed
> >   when the whole set is ready;
> > * 18/24, the biggest individual patch, adds the transcode scheduler; as
> >   of that patch it does not yet do anything;
> > * 19-24/24 convert the individual components to use the scheduler; the
> >   conversion is split for review purposes, but will have to be squashed
> >   for the final push.
> > 
> > Some more information is in my recent VDD talk [1]. You can also fetch
> > the code from the 'ffmpeg_threading' branch in [2].
> > 
> > Reviews, testing, and constructive comments are all very much welcome.
> > 
> > [1] https://youtu.be/Z4DS3jiZhfo?t=1221
> 
> > [2] git://git.khirnov.net/libav
> 
> This one infinite loops:
> ./ffmpeg -i tickets//383/ranft.m2v -itsoffset -00:00:00.775 -itickets//383/ranft.ac3 -bitexact -target pal-vcd /tmp/vcd.mpg
> (file should be here: https://trac.ffmpeg.org/raw-attachment/ticket/383/smallfiles.zip)
> 
> so does this: (files attached just 320bytes)
> ./ffmpeg -f u8 -ar 8000 -ac 1 -i sync_audio.raw -f rawvideo -framerate 2 -s 192x144 -pix_fmt gray -i sync_video.raw -vcodec mpeg2video -acodec mp2 -y  -r 2 /tmp/mpeg2_mp2.mpg
> 
> These are with your branch merged into master

Both were the same issue, fixed in my branch now. I will resubmit the
set after dealing with the other comments.

Thanks,
-- 
Anton Khirnov