[FFmpeg-devel] [PATCH] ffmpeg: set extra_hw_frames to account for frames held in queues

[Marton Balint]

On Sun, 25 Feb 2024, Mark Thompson wrote:

> Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
> held multiple frames output by the decoder in internal queues without
> telling the decoder that it is going to do so.  When the decoder has a
> fixed-size pool of frames (common in some hardware APIs where the output
> frames must be stored as an array texture) this could lead to the pool
> being exhausted and the decoder getting stuck.  Fix this by telling the
> decoder to allocate additional frames according to the queue size.

[...]

> diff --git a/fftools/ffmpeg_sched.h b/fftools/ffmpeg_sched.h
> index 95f9c1d4db..315053ae42 100644
> --- a/fftools/ffmpeg_sched.h
> +++ b/fftools/ffmpeg_sched.h
> @@ -233,6 +233,13 @@ int sch_add_filtergraph(Scheduler *sch, unsigned 
> nb_inputs, unsigned nb_outputs,
>  */
>  int sch_add_mux(Scheduler *sch, SchThreadFunc func, int (*init)(void *),
>                 void *ctx, int sdp_auto, unsigned thread_queue_size);
> +
> +/**
> + * Default size of a thread queue, used if thread_queue_size is not set on a
> + * call to sch_add_mux().

Not precisely, as this thread queue size is used for both frame 
queues and packet queues.

Historically the thread_queue_size option was introduced for packet 
queues for demuxed packets, and recently on the output for muxing 
packets.

If we want to make the frame queue size adjustable as well, I think it 
should be a separate option and maybe a separate constant should be added 
for its default value.

> + */
> +#define DEFAULT_THREAD_QUEUE_SIZE 8

Regards,
Marton