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 0E6E5411B9 for ; Tue, 15 Feb 2022 12:03:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2F58368B2B5; Tue, 15 Feb 2022 14:03:38 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6CEC468991B for ; Tue, 15 Feb 2022 14:03:31 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id E6894240179 for ; Tue, 15 Feb 2022 13:03:30 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oVmRWbbhrVIi for ; Tue, 15 Feb 2022 13:03:29 +0100 (CET) Received: from lain.red.khirnov.net (lain.red.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.red.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id A7CA1240175 for ; Tue, 15 Feb 2022 13:03:29 +0100 (CET) Received: by lain.red.khirnov.net (Postfix, from userid 1000) id B4A0E1601AD; Tue, 15 Feb 2022 13:03:29 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <7d8d3b14-7fbf-f7fd-878a-c5f37a839a37@gmail.com> References: <20220214224156.39862-1-jamrial@gmail.com> <20220214224156.39862-4-jamrial@gmail.com> <164492527737.9519.8869846058577360420@lain.red.khirnov.net> <7d8d3b14-7fbf-f7fd-878a-c5f37a839a37@gmail.com> Mail-Followup-To: FFmpeg development discussions and patches Date: Tue, 15 Feb 2022 13:03:29 +0100 Message-ID: <164492660970.19727.6128970737155226820@lain.red.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 4/6] ffmpeg: don't skip packets before a keyframe was seen if a bsf with delay is used 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting James Almer (2022-02-15 12:48:09) > > > On 2/15/2022 8:41 AM, Anton Khirnov wrote: > > Quoting James Almer (2022-02-14 23:41:54) > >> A keyframe could be buffered in the bsf and not be output until more packets > >> had been fed to it. > >> > >> Signed-off-by: James Almer > >> --- > >> fftools/ffmpeg.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > >> index 6aa0986f02..48d9016b4c 100644 > >> --- a/fftools/ffmpeg.c > >> +++ b/fftools/ffmpeg.c > >> @@ -2026,7 +2026,8 @@ static void do_streamcopy(InputStream *ist, OutputStream *ost, const AVPacket *p > >> } > >> > >> if ((!ost->frame_number && !(pkt->flags & AV_PKT_FLAG_KEY)) && > >> - !ost->copy_initial_nonkeyframes) > >> + !ost->copy_initial_nonkeyframes && > >> + !(ost->bsf_ctx && ost->bsf_ctx->filter->capabilities & AV_BSF_CAP_DELAY)) > >> return; > > > > Wouldn't it be simpler to add an OutputStream field that tracks whether > > we've seen a keyframe packet yet? No new API required. > > Probably. It would also only trigger when a keyframe was seen instead of > unconditionally for all delay flagged bsfs. > > I still think this new API is a good addition, either way. Only a > handful of bsfs buffer packets and require the caller to flush them > after sending NULL (av1_frame_merge, vp9_superframe, and setts after > this set) so library users could have all this time never signaled EOF > and never noticed anything wrong, much like it happened here. > The presence of this flag might help library users know they really need > to signal EOF. I don't see where the advantage would be. The callers still need to have the flushing code, so might as well always call it. The disadvantage for us is more complixity and we have to maintain the list of delay BSFs. -- Anton Khirnov _______________________________________________ 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".