Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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: Wed, 9 Aug 2023 12:36:50 -0400
Message-ID: <CAHGibzFkUYjEhP82VWgGFRLKrPwmu_JWCFiFZ7Anrxwvh6R-pg@mail.gmail.com> (raw)
In-Reply-To: <CAK+ULv4DVtDJSpAChqVjWx7vRHEZ5nwfcSsiMkovzU9Xj9O5JQ@mail.gmail.com>

Hi Kieran,

Thanks for your review.

On Wed, Aug 9, 2023 at 9:55 AM Kieran Kunhya <kierank@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@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".

  reply	other threads:[~2023-08-09 16:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-31 13:38 [FFmpeg-devel] [PATCH v4 0/4] Add passthrough support for SCTE-35 Devin Heitmueller
2023-07-31 13:38 ` [FFmpeg-devel] [PATCH v4 1/4] avcodec: Add new side data type to contain original PTS value Devin Heitmueller
2023-07-31 13:38 ` [FFmpeg-devel] [PATCH v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later Devin Heitmueller
2023-08-09 13:54   ` Kieran Kunhya
2023-08-09 16:36     ` Devin Heitmueller [this message]
2023-08-10 12:12       ` Kieran Kunhya
2023-08-10 12:20         ` Devin Heitmueller
2023-08-10 12:41           ` Kieran Kunhya
2023-08-10 12:48             ` Kieran Kunhya
2023-08-10 12:58               ` Devin Heitmueller
2023-08-10 13:08                 ` Kieran Kunhya
2023-08-10 15:12                   ` Devin Heitmueller
2023-08-10 15:53                     ` Kieran Kunhya
2023-07-31 13:38 ` [FFmpeg-devel] [PATCH v4 3/4] mpegtsenc: Add support for output of SCTE-35 streams over TS Devin Heitmueller
2023-07-31 13:38 ` [FFmpeg-devel] [PATCH v4 4/4] bsf: Add new bitstream filter to set SCTE-35 pts_adjustment when reclocking Devin Heitmueller
2023-08-04 11:16 ` [FFmpeg-devel] [PATCH v4 0/4] Add passthrough support for SCTE-35 Devin Heitmueller
2023-08-08 14:31   ` Devin Heitmueller
2023-08-08 15:30     ` Dennis Mungai
2023-09-01  9:29       ` Dennis Mungai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHGibzFkUYjEhP82VWgGFRLKrPwmu_JWCFiFZ7Anrxwvh6R-pg@mail.gmail.com \
    --to=devin.heitmueller@ltnglobal.com \
    --cc=dheitmueller@ltnglobal.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    --cc=kierank@obe.tv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git