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

Devin Heitmueller devin.heitmueller at ltnglobal.com
Wed Aug 9 19:36:50 EEST 2023


Hi Kieran,

Thanks for your review.

On Wed, Aug 9, 2023 at 9:55 AM Kieran Kunhya <kierank at obe.tv> wrote:
> How is this frame accurate? Surely "last_pcr" can be up to 100ms out. You need to actually be interpolating the true value in order to be frame accurate (not saying this is easy/doable in FFmpeg). But at the same time inaccurate splices aren't great either.

So it's worth noting that the patch I've proposed doesn't change the
existing logic in terms of how the timestamp is determined.  The patch
in question simply makes the existing timestamp available as side
data.

Second, in most cases the accuracy of the timestamp for the SCTE
message isn't actually that important for frame accuracy.  It's the
splice time that is important (usually specified as a PTS).  And hence
even if the timestamp of the SCTE message is off by a bit you can
still have frame accurate splicing.

Now it's true that the splice-immediate case does benefit by the value
being more accurate.  I have a separate patch which better tracks the
video PTS and uses that as the basis for specifying the SCTE-35
timestamp value (and that's what I use in production).  I will be
looking to submit that as a separate patch, but didn't want to muddy
the waters by introducing it in this patch series (where I'm not
trying to tackle that problem).

In short, this patch series does significantly improve the situation,
even though it doesn't attempt to tackle the problem of the SCTE-35
timestamp not being as accurate as it could be.

Devin


--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller at ltnglobal.com


More information about the ffmpeg-devel mailing list