[vlc-devel] [PATCH 2/2] codec: dav1d: limit automatic frame thread count

[Steve Lhomme]

It would be OK to limit that way in 3.0.

In 4.0, with push, the pool can be allocated in the Open of the decoder 
and if it fails we can allows loop to find the number of threads that work.

IMO if someone has 64 threads and 256 GB of RAM to decode/transcode as 
fast as possible, there's no reason to limit the decoding speed 
artificially.

This is less true for lavc as we only know the chroma to allocate after 
the decoder is started.

On 2020-11-19 17:15, Marvin Scholz wrote:
> Without this limit, on a processor with many cores it would use
> so many frame threads that it would fail picture pool allocation.
> 
> Fix #25190
> ---
>   modules/codec/dav1d.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/modules/codec/dav1d.c b/modules/codec/dav1d.c
> index dcb09213186..8611b0cdfe9 100644
> --- a/modules/codec/dav1d.c
> +++ b/modules/codec/dav1d.c
> @@ -396,7 +396,7 @@ static int OpenDecoder(vlc_object_t *p_this)
>           p_sys->s.n_tile_threads = VLC_CLIP(vlc_GetCPUCount(), 1, 4);
>       p_sys->s.n_frame_threads = var_InheritInteger(p_this, "dav1d-thread-frames");
>       if (p_sys->s.n_frame_threads == 0)
> -        p_sys->s.n_frame_threads = __MAX(1, vlc_GetCPUCount());
> +        p_sys->s.n_frame_threads = VLC_CLIP(vlc_GetCPUCount(), 1, 16);
>       p_sys->s.allocator.cookie = dec;
>       p_sys->s.allocator.alloc_picture_callback = NewPicture;
>       p_sys->s.allocator.release_picture_callback = FreePicture;
> -- 
> 2.24.3 (Apple Git-128)
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>