> On Dec 6, 2023, at 11:36 AM, Anton Khirnov <an...@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 _______________________________________________ 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".
