On Tue, Oct 25, 2022 at 8:56 AM Dmitrii Ovchinnikov <ovchinnikov.dmit...@gmail.com> 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 set it any higher we get the following execution error: > [libvpx-vp9 @ 0x2f631c0] Failed to initialize encoder: Invalid parameter > [libvpx-vp9 @ 0x2f631c0] Additional information: g_threads out of range > [..64] > Error initializing output stream 0:0 -- Error while opening encoder for > output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, > width or height >
Deferring the check to libvpx should be fine and would mean less maintenance of this wrapper if there are any changes made there. > >>According to > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-November/236406.html the > >>maximum of 16 has not been chosen because of H.264, but because there > >>was some form of restriction in libvpx. Or at least there was belief in > >>the existence of such a restriction. > There is a restriction of maximum 64 threads, not 16. > > >>This code potentially calls av_cpu_count() twice. > Can you please clarify how it calls it twice? Thanks. > _______________________________________________ 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".
