[FFmpeg-devel] [PATCH] ffmpeg CLI multithreading

[James Almer]

On 11/13/2023 9:34 AM, Jan Ekström wrote:
> 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.

Someone with access to the M1 fate machine could do this.