[FFmpeg-devel] [PATCH] ffmpeg: set extra_hw_frames to account for frames held in queues
Marton Balint
cus at passwd.hu
Sun Feb 25 17:01:28 EET 2024
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
More information about the ffmpeg-devel
mailing list