From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 2EDEC47DBE for ; Sun, 25 Feb 2024 15:01:44 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9F33068C678; Sun, 25 Feb 2024 17:01:41 +0200 (EET) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0E88668C5A1 for ; Sun, 25 Feb 2024 17:01:35 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 40559E9FB1 for ; Sun, 25 Feb 2024 16:01:34 +0100 (CET) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEy5IApTAIYX for ; Sun, 25 Feb 2024 16:01:28 +0100 (CET) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id B0512E9FAF for ; Sun, 25 Feb 2024 16:01:28 +0100 (CET) Date: Sun, 25 Feb 2024 16:01:28 +0100 (CET) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <3deacbbf-0087-477c-83b9-910bdba15b7d@jkqxz.net> Message-ID: References: <3deacbbf-0087-477c-83b9-910bdba15b7d@jkqxz.net> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg: set extra_hw_frames to account for frames held in queues X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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-request@ffmpeg.org with subject "unsubscribe".