[FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

[Cosmin Stejerean]

> On Dec 6, 2023, at 11:36 AM, Anton Khirnov <anton at khirnov.net> wrote:
> 
>> In some cases the performance penalty because of threading is quite 
>> significant:
>> 
>> Example command line:
>> 
>> ffmpeg -f lavfi -i sine -af volume=6dB -f null none
>> 
>> After latest threading changes: speed=810x
>> Before latest threading changes: speed=1.13e+03x
>> With 6.0 branch: speed=1.43e+03x
>> With 5.1 branch: speed=2.92e+03x
>> 
>> This is a significant decline from 5.1, getting slower with each 
>> release... Is there anything that can be done about this?
> 
> Would guess this is caused by overhead from tons of tiny frames. So
> 1) generate larger frames

Larger frames would definitely help. With the command as is I get 4.75e+03x on 6.0 and 2.81e+03x on latest mutli-threading branch. 
However when adding asetnsamples this improves considerably. For example using asetnsamples=2048 as follows runs at 5.6e+03x on the multi-threading branch

./ffmpeg -f lavfi -i sine,asetnsamples=2048 -af volume=6dB -f null none

and it can be further improved by increasing the asetnsamples values to 4096 for example (9.18e+03x).

There is still a penalty as you could do asetnsamples without multi-threading and get even higher performance,
but given the general benefits of multi-threading and the fact that it's possible to increase the performance of this 
usecase arbitrarily by using larger and larger frames I think that's an acceptable tradeoff for this use case.


- Cosmin