Thanks for the answer and comment! I will think about how best to
rework the patch and then send a new version.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
On Tue, Oct 25, 2022 at 8:56 AM Dmitrii Ovchinnikov
wrote:
>
> >> Why do you still impose an upper limit unconditionally even if the
> >>user has set his preferred number of threads?
> Libvpx-vp9 does not support number of threads greater than 64, so we impose
> an upper limit of 64.
> E.g. if we
>> Why do you still impose an upper limit unconditionally even if the
>>user has set his preferred number of threads?
Libvpx-vp9 does not support number of threads greater than 64, so we impose
an upper limit of 64.
E.g. if we set it any higher we get the following execution error:
[libvpx-vp9 @ 0x
OvchinnikovDmitrii:
> This change improves the performance and multicore scalability of the vp9
> codec for streaming single-pass encoded videos by taking advantage of up
> to 64 cores in the system. The current thread limit for ffmpeg codecs is 16
> (MAX_AUTO_THREADS in pthread_internal.h) due to
Removed unnecessary comment as requested by Ronald S. Bultje.
some more thoughts about the patch:
This is my deduction from what I could find - There was a hard limit of 16
threads in libvpx as there was no benefit to adding more threads based upon
the parallelism available in the the codec. Thi
