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 _______________________________________________ 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".