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 5073A42065 for ; Mon, 21 Feb 2022 15:34:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C4B7A68B034; Mon, 21 Feb 2022 17:34:48 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9AD8668818E for ; Mon, 21 Feb 2022 17:34:42 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 1259A240179 for ; Mon, 21 Feb 2022 16:34:42 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 8Zh-ISpbhXDM for ; Mon, 21 Feb 2022 16:34:40 +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 DBDE5240175 for ; Mon, 21 Feb 2022 16:34:40 +0100 (CET) Received: by lain.red.khirnov.net (Postfix, from userid 1000) id EB73C1601AD; Mon, 21 Feb 2022 16:34:40 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: 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> <164492660970.19727.6128970737155226820@lain.red.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Mon, 21 Feb 2022 16:34:40 +0100 Message-ID: <164545768092.9519.5943772087784715189@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 13:12:51) > On 2/15/2022 9:03 AM, Anton Khirnov wrote: > > 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. > > Then we probably need to enforce it in the doxy, or at least strongly > suggest it with a @note or @warning line to ensure you get complete output. > Right now it's optional, mentioned as "If you send a NULL packet, it > will trigger EOF", meaning not doing so is still a valid scenario, and > there's nothing letting the user know he's got packets stuck in the bsf > even after receive_packet() returned EAGAIN if they don't. The doxy for av_bsf_send_packet() already says: If pkt is empty, it signals the end of the stream and will cause the filter to output any packets it may have buffered internally. But I can write something more explicit. -- 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".