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
_______________________________________________
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".
