Re: [FFmpeg-devel] [PATCH v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

From: Devin Heitmueller <devin.heitmueller@ltnglobal.com>
To: Kieran Kunhya <kierank@obe.tv>
Cc: Devin Heitmueller <dheitmueller@ltnglobal.com>,
	FFmpeg development discussions and patches
	<ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later
Date: Thu, 10 Aug 2023 08:58:53 -0400
Message-ID: <CAHGibzELyFFYcs7hvWq_e5JtRgtG_NYpq9C++7jc6zj3Jc8ryg@mail.gmail.com> (raw)
In-Reply-To: <CAK+ULv4V+jJr+Y0oqyd+W84LJXPNFCOi8o0ToiddJyeCtSOORA@mail.gmail.com>

On Thu, Aug 10, 2023 at 8:48 AM Kieran Kunhya <kierank@obe.tv> wrote:
>
>
>
> On Thu, 10 Aug 2023 at 08:41, Kieran Kunhya <kierank@obe.tv> wrote:
>>
>> On Thu, 10 Aug 2023 at 08:20, Devin Heitmueller <devin.heitmueller@ltnglobal.com> wrote:
>>>
>>> On Thu, Aug 10, 2023 at 8:13 AM Kieran Kunhya <kierank@obe.tv> wrote:
>>> > The (closest?) video PTS is even worse than the last PCR because the VBV means the closest PTS can be quite far from the interpolated PCR.
>>>
>>> It's arguments like that which prompted me to explicitly exclude such
>>> a patch from the series.  It's a discussion to be had, but not
>>> relevant for this patch series (which makes no effort to change the
>>> logic for how the timestamp is determined).
>>>
>>> Wait until such a patch is submitted, and then we can debate at length
>>> the ambiguity in the specification and what the best approach is.
>>
>>
>> There is zero ambiguity in the specification.
>
>
> Like any other form of SI in MPEG-TS the timestamp (although there is actually no such thing) is "now", which by definition is the interpolated PCR.
> Taking a video frame PTS is incorrect.
>
> What's the point of submitting patches like this exposing things in the public API that you know to be wrong?

Again, this patch series makes no attempt to address the problem you
are complaining about.  It brings the situation from "completely
doesn't work" to "works fine the majority of the time except for the
splice immediate case where the timestamp may not be as accurate as it
could be".  And let's be fair, splice immediate is both an uncommon
use case in the industry and nobody doing a splice immediate expects
it to be frame accurate (as it's typically initiated by a human during
live programming).

I'm happy to have this discussion, but it doesn't have any bearing on
whether this patch series should be accepted.  Let's not throw out the
baby with the bathwater.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
_______________________________________________
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".