On 3/3/26 09:27, Bruce Roberts wrote:
Hi Nicolas,
Thank you so much for your response - it is most helpful!
Just to fill in some of the blanks in my original question, changing
the presentation timestamp of the input frames is precisely what I
want to achieve and the reason why I want to do that is, as you
guessed, to synchronise my external subtitle files with their
corresponding video streams.
The SOE/SOM timecodes of my source mxf video files varies from file to
file and the timings of the subtitles in my source stl subtitle files
are relative to the SOE of their corresponding video file.
So my plan, as part of the stl -> vtt subtitle conversion process
(which happens outside of ffmpeg), is to dynamically modify the webvtt
X-TIMESTAMP-MAP of each vtt file such that the MPEGTS value is the
static first frame pts I've set (or now most likely the default of
126000) and the LOCAL value is the specific SOE timecode of the
corresponding mxf. So I end up with:
X-TIMESTAMP-MAP=MPEGTS:126000,LOCAL:/hh/:/mm/:/ss/:/ff/
/
/
On the basis of what you've told me, it seems that the 126000
"default" pts is unlikely to change so I probably don't need to get
setpts working after all.
Having said that, it does seem odd to me that setpts isn't supported
when using the legacy mpegts format (assuming that is what you're
saying) because my understanding is that the whole notion of pts
originates from the mpegts format.
I would rather avoid switching to fmp4 if possible because that would
require a great deal of regression testing etc.
Anyway, with the information you provided, I now have a workable solution.
Thanks again for your help,
Bruce.
Hi Bruce,
Just to clarify: this is not a setpts nor generally an ffmpeg issue,
this is an mpegts format issue, and this is why apple tweaks it
specifically : the x-timestamp-map trick was not meant for ffmpeg. It is
a kind of "signature" of an encoder : each one has a specific "first
video frame pts", there is no standard in the current file based world.
Test another encoder, you will see the value is consistent but different
than the one of ffmpeg.
mpegts was not meant to be synced with external sources. Its primary
purpose is cbr live streaming. The first timestamp clock is non-zero
because "negative timestamp" (or timestamp rewraping as implemented in
mpegts) is not nice; you have similar thing with your mxf in presence of
precharge (gop..) : it is still common practice to show a first TC of
10:00:00:00 even if files has replaced tapes a long time ago; it allows
some technical discarded header frames to be set appropriately
(09:59...). Same with STL also... Broadcaster life!
Secondly, you can think of the first clock timestamp as the "start of
the streaming" : then you got necessary buffering, so a shift again...
You see, technical matter of mpegts...
Well, now, of course, for its own purpose, hls don't require all that
mpegts "machinery" (mostly redundant with an upper streaming protocol)
and apple do not follow mpegts strictly on some points (as many others,
apple don't follow standards even the standards that they write
themselves). So, I don't pretend to know everything on this subject, and
there might be some tweaks and tricks to go further "out of mpegts
specs" to cope with this x-timestamp-map "issue", so can wait and see if
someone else can share some experience about it on this list...
Nicolas
_______________________________________________
ffmpeg-user mailing list -- [email protected]
To unsubscribe send an email to [email protected]
