[FFmpeg-devel] [PATCH V2] lavc/libvpx: increase thread limit to 64

[Andreas Rheinhardt]

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 a limitation in H.264 codec
> that prevents more than 16 threads being used.
> 
> Experiments show that 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.
> 
> Rationale for this change:
> Vp9 uses tiling to split the video frame into multiple columns; tiles must
> be at least 256 pixels wide, so there is a limit to how many tiles can be
> used. The tiles can be processed in parallel, and more tiles mean more CPU
> threads can be used. 4K videos can make use of 16 threads, and 8K videos
> can use 32. Row-mt can double the number of threads so 64 threads can be used.
> ---
>  libavcodec/libvpx.h    | 2 ++
>  libavcodec/libvpxdec.c | 2 +-
>  libavcodec/libvpxenc.c | 2 +-
>  3 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/libvpx.h b/libavcodec/libvpx.h
> index 0caed8cdcb..331feb8745 100644
> --- a/libavcodec/libvpx.h
> +++ b/libavcodec/libvpx.h
> @@ -25,6 +25,8 @@
>  
>  #include "codec_internal.h"
>  
> +#define MAX_VPX_THREADS 64
> +
>  void ff_vp9_init_static(FFCodec *codec);
>  #if 0
>  enum AVPixelFormat ff_vpx_imgfmt_to_pixfmt(vpx_img_fmt_t img);
> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> index 9cd2c56caf..0ae19c3f72 100644
> --- a/libavcodec/libvpxdec.c
> +++ b/libavcodec/libvpxdec.c
> @@ -88,7 +88,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>                              const struct vpx_codec_iface *iface)
>  {
>      struct vpx_codec_dec_cfg deccfg = {
> -        .threads = FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 16)
> +        .threads = FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), MAX_VPX_THREADS)
>      };
>  
>      av_log(avctx, AV_LOG_INFO, "%s\n", vpx_codec_version_str());
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 667cffc200..3ff86ad08d 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -942,7 +942,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>      enccfg.g_timebase.num = avctx->time_base.num;
>      enccfg.g_timebase.den = avctx->time_base.den;
>      enccfg.g_threads      =
> -        FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 16);
> +        FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), MAX_VPX_THREADS);
>      enccfg.g_lag_in_frames= ctx->lag_in_frames;
>  
>      if (avctx->flags & AV_CODEC_FLAG_PASS1)

1. Why do you still impose an upper limit unconditionally even if the
user has set his preferred number of threads?
2. 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.
3. This code potentially calls av_cpu_count() twice.

- Andreas