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.


On Mon, Mar 2, 2026 at 6:54 PM Nicolas Gaullier via ffmpeg-user <
[email protected]> wrote:

> On 3/2/26 16:42, Bruce Roberts via ffmpeg-user wrote:
> > Hi there,
> >
> > I'm generating hls streams with ffmpeg and I want to set the first frame
> of
> > video for all streams with a static pts. This can be zero or anything
> else,
> > as long as it's the same value for all streams. But my attempts to use
> the
> > setpts/asetpts filters to achieve this haven't been successful.
> >
> > Here is my command:
> >
> > ffmpeg -y -v info \
> > -ss 00:00:00.000 -t 00:00:05.000 -i /input/input.mxf \
> > -filter_complex \
> >
> "[0:v:0][0:a:0][0:a:1][0:a:2][0:a:3][0:a:4][0:a:5][0:a:6][0:a:7]concat=n=1:v=1:a=8[vconcat][aconcat0][aconcat1][aconcat2][aconcat3][aconcat4][aconcat5][aconcat6][aconcat7];
> > \
> > [aconcat6][aconcat7]join=inputs=2:channel_layout=stereo[t7_8]; \
> > [aconcat4][aconcat5]join=inputs=2:channel_layout=stereo[t5_6]; \
> > [aconcat2][aconcat3]join=inputs=2:channel_layout=stereo[t3_4]; \
> > [aconcat0][aconcat1]join=inputs=2:channel_layout=stereo[t1_2]; \
> > [t7_8]asetpts=PTS-STARTPTS[t7_8setpts]; \
> > [t5_6]asetpts=PTS-STARTPTS[t5_6setpts]; \
> > [t3_4]asetpts=PTS-STARTPTS[t3_4setpts]; \
> > [t1_2]asetpts=PTS-STARTPTS[t1_2setpts]; \
> > [vconcat]format=pix_fmts=yuv420p[vconcat420]; \
> > [vconcat420]yadif=0:-1:0[vconcatdeint];
> > [vconcatdeint]setpts=PTS-STARTPTS[vconcatdeintsetpts]" \
> > -map "[t7_8setpts]" -f hls -hls_list_size 0 -hls_time 3.84 -vn -acodec
> > libfdk_aac /output/TEST01_T4_Audio.m3u8 \
> > -map "[t5_6setpts]" -f hls -hls_list_size 0 -hls_time 3.84 -vn -acodec
> > libfdk_aac /output/TEST01_T3_Audio.m3u8 \
> > -map "[t3_4setpts]" -f hls -hls_list_size 0 -hls_time 3.84 -vn -acodec
> > libfdk_aac /output/TEST01_T2_Audio.m3u8 \
> > -map "[t1_2setpts]" -f hls -hls_list_size 0 -hls_time 3.84 -vn -acodec
> > libfdk_aac /output/TEST01_T1_Audio.m3u8 \
> > -map "[vconcatdeintsetpts]" -f hls -hls_list_size 0 -hls_time 3.84 -an
> > -vcodec libx264 -aspect 16:9 -flags +cgop -g 48 -bf 0 -b:v 2M -maxrate 3M
> > -x264opts keyint=48:min-keyint=48:scenecut=-1 \
> > /output/TEST01_T0_Video.m3u8
> >
> > I'm expecting the pts of the first output video frame to be 0.
>
> > So my questions are please:
> >
> > 1. Why isn't the setpts filter working as I expect it to?
> > 2. Why does the pts of the first frame default to 126000?
> > 3. Given that a consistent pts value of 126000 would work fine for me, as
> > long as I can be confident that it will never be anything else, can I
> rely
> > on the first frame pts always being 126000 if I omit the pts filter
> > altogether?
>
> 1. The documentation for (a)setpts is: "Change the PTS (presentation
> timestamp) of the input frames.".
> This is rather a syncing tool, and anyway not what you are looking for.
>
> https://ffmpeg.org/ffmpeg-filters.html#setpts_002c-asetpts
>
> Note that the default (unless using -copyts) is to "remove the initial
> start time offset value." (see copyts documentation) : you don't have to
> care about it.
>
> 2. In general, there are tricks that makes this "first frame pts" not so
> easy, but here it seems your use case is quite straightforward.
>
> The issue is that you use the default hls output format, which is the
> legacy mpegts format : this is originally a transport protocol handling
> buffering etc. and thus deals with absolute timestamps, there is no
> explicit "starts here"/origin. This is why apple requires this value to
> be made explicit in their protocol: it is required to sync with an
> external subtitle file etc., and maybe you are indeed interested in the
> "first video frame pts" for this purpose.
>
> Currently, the first pcr (clock timestamp) is set to the ffmpeg's
> muxdelay and the dts are shifted by the muxdelay. The current muxdelay
> is 0.7 second and the ts timebase is 90k.
> So, 2*0.7*90000 = 126000, indeed. But this is not documented (cannot
> be), and I don't recommand you to tweak the muxdelay to get a consistent
> output.
>
> 3. There is also a "mpegts_copyts" option, but I really can't recommand
> it. I don't know its use case, but I have tried it brievly and it leads
> to a pcr wrap at file start, which sounds weird.
>
> Best is to use the fmp4 format. It is supported for a long time in iOS,
> so unless targeting a very specific ancient model, I assume there should
> not be any compatibility issue.
>
> Otherwise, you can simply check each new ffmpeg release you want to use
> to make sure your 126000 has not changed... And, if ever required (not
> very likely), you could still use the -muxdelay parameter to get this
> value again.
>
> Nicolas
>
> _______________________________________________
> ffmpeg-user mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
ffmpeg-user mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to