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
sync.tar.xz
Description: application/xz
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
