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 141BB411BD for ; Tue, 15 Feb 2022 12:13:04 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0EDE268B2BD; Tue, 15 Feb 2022 14:13:02 +0200 (EET) Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3246668AF45 for ; Tue, 15 Feb 2022 14:12:55 +0200 (EET) Received: by mail-oi1-f169.google.com with SMTP id x193so20570007oix.0 for ; Tue, 15 Feb 2022 04:12:55 -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=VCJ+vRPXox4++jg871q9oP+UopXEFQpNxYm7KoaCNHE=; b=lLr+sv8nah8hvzpKx4c4mcuP2a9jZtixeN4+7ohyhqi2X/qabinAl5LMtsj0ZRS/QR 6TTgheMlTK2S+CUOGMLsDdfVfN/xJzYXSNnLzH23mh2FVnib5e4dQRZ/ClzP0HgnVY9B RMZ19QwKO/su6NRkugcSQHVMtns27XkdCWLlbzUsjUqRwb7i5vEzin4QFf+lX1sWk03g Jd8iT/Ribl9nUd1WrrcSDaSaAemBfCFHASDDLPtR/IANSKPDCKwZpNmIFaOH02PpFHd7 GY+711Vbh+X/nV2tCn8sE0CqyzCw0rF8f3BXt/EDVBC36oFN/WXFsX7OGU0ICr7Yvmv1 jluw== 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=VCJ+vRPXox4++jg871q9oP+UopXEFQpNxYm7KoaCNHE=; b=gJiH6cjmTKhNQqPdykd5gat0J98OWVFAXO1qJ6Xi5tqlm2APAxjNhXr+wspqCeZkEM ivRC7+2RuX/8Pg/7aHcWoNqxN62b+tnm+xVSWURQzUpDBeoUpogmU0nNQMwr9Hxtqc9R PAL7QQGlFMvDC12U74hKxvnRdZKXHjXn4ce6l3bemBCPvztLv8OQ0kv7vAk1ZsNAKkGu enQlHmOfZYcKn/mcdRdQZ7oF4TrPIr26QzgrRoNCWQhGsoLxPJPmvYeehTOr94cKPoqq vBAXAlVfYRe5jX88ksBDsi5coWc5mJlrC3RNoG5OcaQ4+R8/Hlg0t+VZ217oBwwfV16L RMig== X-Gm-Message-State: AOAM531JomeH302e8kXbxckyLA5SC1761nsf5sjz7uDwMrOoyj8ktJdf mtmWH9nikNwO2afKxo6/JF/KjxOdXKPVjg== X-Google-Smtp-Source: ABdhPJxReUrRnvpT4CXQpuX1J0+G2+PwoGryyDfr0HGXHO40Ek3wmDWobNEL3t/wkSPNpdvtOeBL5A== X-Received: by 2002:a05:6808:21a6:b0:2cf:be08:ec with SMTP id be38-20020a05680821a600b002cfbe0800ecmr1420064oib.135.1644927173779; Tue, 15 Feb 2022 04:12:53 -0800 (PST) Received: from [192.168.0.10] ([186.136.131.95]) by smtp.gmail.com with ESMTPSA id e9sm13879902oom.8.2022.02.15.04.12.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Feb 2022 04:12:53 -0800 (PST) Message-ID: Date: Tue, 15 Feb 2022 09:12:51 -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> <7d8d3b14-7fbf-f7fd-878a-c5f37a839a37@gmail.com> <164492660970.19727.6128970737155226820@lain.red.khirnov.net> From: James Almer In-Reply-To: <164492660970.19727.6128970737155226820@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 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 disadvantage for us is more complixity and we have to maintain the > list of delay BSFs. > _______________________________________________ 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".