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 DFCB9411B2 for ; Tue, 15 Feb 2022 11:48:22 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 257FE68B2BB; Tue, 15 Feb 2022 13:48:20 +0200 (EET) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3439468AED4 for ; Tue, 15 Feb 2022 13:48:14 +0200 (EET) Received: by mail-ot1-f51.google.com with SMTP id s6-20020a0568301e0600b0059ea5472c98so13569091otr.11 for ; Tue, 15 Feb 2022 03:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to:content-transfer-encoding; bh=ogs7xTLc/zz4EY6Ay77a0Xq1hQAnq6zso55v86aGEuY=; b=Xhp4KPQ2UWzy+sVYWfQ0NC/v6PDGy0a/K6EdrZVnbhcNeQwl/7GYJFPFfKbOa0W03K GcYIbFz8Pqi/YFyJI4IJZtdi+4E+Kw1pPS9Svf0xXMkaiH5V4YHgXKVUVMmSygwsIRJJ nK9dB/IRyQgUGAPAwDd7W05P/B0TzMrS25un6hJXeWoBRsumt3tJA9I3TutNn0weGsQO JyuC6Hd2e1RuMzu1m10NALkuaR+2nSuLY6wYMvqQrwmW+aA98vUJh7BIsOt4d6C2m3Xv QY6lQg/8iwgFvFg3EtX9FBKZiRvDS2UqEMDvVBDFkccMakLnaJRG6aqEFSJu200Q+36C gsJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=ogs7xTLc/zz4EY6Ay77a0Xq1hQAnq6zso55v86aGEuY=; b=c5jgGqBCve/ApobDSI9QE7Kl+VKP+aTKBw6vrMZE4nK8unStLHus4czArBBW8HzN3L sojCuNBPaMHCifpGrA2blTyIa8tHI58vXx092lRMgRys289e6K7xEaSgpPyDXxLLtzO6 UGwQcTR9enzZ8kA4lJEuT3+rvGDJFSUNlPCosDoPiKQT8kDDMDAs3Tpruemgn+D+wMKJ nH3z2xBgFQaIzBmXn9yu+uhUoIeoSaibvoJVs5rUUZIldCwFW+WGdJHiXy7b+notnU9f NCNFKVxf0fVb6z7x8MLj/bts0isR4i3RjvhxZ3wyg+rkGkwp5tj0drrprgmR0wLDjBuk xAkg== X-Gm-Message-State: AOAM533v1nRq2gkRevXXcuPXoQYqzgyKkt2JAY1uZWWFADyK5o0k+Mdn Y3e5VMuQ53O7BFqNkwOohWvwYay4PBgcSg== X-Google-Smtp-Source: ABdhPJwk3+C5bagF4dCCEfBDCIjhSZKWiLTeTJilt1jwuEzCKXCS3pvgzo6i805rYQEYuR1GVxHSfg== X-Received: by 2002:a9d:a61:: with SMTP id 88mr1097946otg.313.1644925692322; Tue, 15 Feb 2022 03:48:12 -0800 (PST) Received: from [192.168.0.10] ([186.136.131.95]) by smtp.gmail.com with ESMTPSA id q188sm14149803oig.15.2022.02.15.03.48.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Feb 2022 03:48:11 -0800 (PST) Message-ID: <7d8d3b14-7fbf-f7fd-878a-c5f37a839a37@gmail.com> Date: Tue, 15 Feb 2022 08:48:09 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220214224156.39862-1-jamrial@gmail.com> <20220214224156.39862-4-jamrial@gmail.com> <164492527737.9519.8869846058577360420@lain.red.khirnov.net> From: James Almer In-Reply-To: <164492527737.9519.8869846058577360420@lain.red.khirnov.net> 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-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 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. _______________________________________________ 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".