On Thu, Jan 5, 2023 at 2:42 AM Dmitrii Ovchinnikov <ovchinnikov.dmit...@gmail.com> wrote: > > From: Dmitrii Ovchinnikov <ovchinnikov.dmit...@gmail.com> > > This change improves the performance and multicore > scalability of the vp9 codec for streaming single-pass encoded videos. The > current thread limit for ffmpeg codecs is 16 (MAX_AUTO_THREADS in > pthread_internal.h) due to a limitation in H.264 codec that prevents more > than 16 threads being used. > > Increasing the thread limit to 64 for vp9 improves > the performance for encoding 4K raw videos for streaming by up to 47% > compared to 16 threads, and from 20-30% for 32 threads, with the same quality > as measured by the VMAF score. > > Did not need to add a check for limit in libvpx as it is already present > in libvpx/vp9/vp9_cx_iface.c: > RANGE_CHECK_HI(cfg, g_threads, 64); > As demonstrated by following message when -threads is set to anything more > than 64 > [libvpx-vp9 @ 0x30ed380] Additional information: g_threads out of range > [..64] >
The difference is that it will cause a failure rather than silently capping the value which might break some workflows. libaomenc caps at 64, so it may be best to match that implementation for now. I'll make that change before submitting unless there are other comments. With this change there will still be the misleading output from validate_thread_parameters() in pthread.c, though it's not a unique problem to libvpxenc: [libvpx-vp9 @ 0x5639aa4c0200] Application has requested 64 threads. Using a thread count greater than 16 is not recommended. _______________________________________________ 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".
