On Sat, Nov 4, 2023 at 11:22 AM Anton Khirnov <[email protected]> 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.
Tested a version of this branch without the fix_sub_duration_heartbeat removal (https://github.com/jeeb/ffmpeg/commits/ffmpeg_threading_with_sub_heartbeat), and was expecting the functionality to be completely non-deterministic. Yet to my surprise a single GEN=1 update worked on all of the x86 devices from Thinkpad x230 to a gen3 Ryzen laptop. The threading seems to allow for the output to fall behind by some amount (in this case about ~200ms?), but the FATE test seems to be very deterministic with these components on the systems I could test and with THREADS set to 16/32/128, putting a load on the system etc. As a test I also switched the encoder to libx264, preset placebo and the only thing that affected was the amount of delay, but the test was still seemingly deterministic. I would request people to test "fate-ffmpeg-fix_sub_duration_heartbeat" on something a bit more exotic from this branch, just to see if the same result is attained. If it is, then this specific test case would seem to be stable stable and not blocking the threading work. As for output and input being not in synch, for this feature it should be completely fine, since the range is from "at the point of input" to "input has gotten all the way to EOF while output is playing catch-up", which just means that there is more and more information available when writing out the output, and the base value is always the point of input (you should (?) never be in a state where output is further than the input, and thus you are missing information from the input from that specific point of time). Jan _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
