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 3F67D410AA for ; Sun, 13 Feb 2022 18:39:11 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CA41568B178; Sun, 13 Feb 2022 20:39:08 +0200 (EET) Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8589368B193 for ; Sun, 13 Feb 2022 20:39:02 +0200 (EET) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:105:465:1:4:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4JxbjK59hFz9sSD for ; Sun, 13 Feb 2022 19:39:01 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Message-ID: Date: Mon, 14 Feb 2022 00:08:41 +0530 MIME-Version: 1.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220209152858.2339-1-jamrial@gmail.com> <5ae2e409-77bd-cd38-d10b-d65f2c4e8a84@gmail.com> <7e822563-4ecc-ed9e-3518-56cf8b497f4f@gmail.com> <54f088c2-0ed9-6a62-001c-40c24e9c88b6@gmail.com> From: Gyan Doshi In-Reply-To: <54f088c2-0ed9-6a62-001c-40c24e9c88b6@gmail.com> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/setts_bsf: set the output packet duration to 0 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 2022-02-13 10:58 pm, James Almer wrote: > > > On 2/13/2022 2:22 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 2/13/2022 2:14 PM, Paul B Mahol wrote: >>>> Too soon. >>>> >>>> Wait more, >>> >>> Ok. >>> >>>> does this breaks something? >>> >>> There are no fate tests, and 0 is used when the duration is unknown, so >>> it shouldn't break anything. >>> >> >> It breaks the simple use-case where this filter is used to just shift >> the timestamps. > > How so? It's a documented value that means unknown. What breaks > because of it? Wouldn't it be revealing a bug if so? > > And in non simple use cases that completely replace or rescale the > timestamps, the old duration value is no longer valid, and something > definitely worse to have than 0. If the legacy value remains, a downstream processor can still use it for some reference or heuristic. And it can peek and compare adjacent timestamps to harmonize the duration value if needed. But once zeroed out, that hint is gone. Regards, Gyan _______________________________________________ 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".