[FFmpeg-devel] [PATCH] ffmpeg CLI multithreading

[Jan Ekström]

On Sat, Nov 4, 2023 at 11:22 AM Anton Khirnov <anton at khirnov.net> 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