[FFmpeg-devel] [PATCH] ffmpeg CLI multithreading

[Michael Niedermayer]

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

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sync.tar.xz
Type: application/x-xz
Size: 300 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20231111/974e3948/attachment.xz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20231111/974e3948/attachment.sig>