Do all pts times need to be 0 for all merge

[Budman1]

My question is maybe a lot harder than it seems. Looking everywhere, there are numerous suggestions for splitting and joint at key frames. A LOT of them cause errors in the resulting merged video. The suggestions all result in a segment that does not start at 0 pts time. Muxdelay, noaccurate_seek, set frame rate, and other options all cause a different first frame pts but only one method i found results in 0 timestamp.

After all this, I was wondering, do all segments for all formats need to be start pts of 0 and if not what happens to the timestamps after you join them using a copy method instead of re-encoding?

This is an important question for me but I seem to find a lot of conflicting information when searching so any information would help me. Thanks

[pandy]

Technically you should provide continuous and monotonous PTS across stream (decoder may expect continuous and monotonous PTS) - usually (at least TS) special flag(s) is used to signal that something happen and PTS may be incorrect - sane decoder should be immune on such issues but i know that developers frequently don't care and stream with non continuous and non monotonous PTS may trig some unwanted behaviour (simply most of developers assume that you feed data perfectly and this is your fault/responsibility to do so).

[Selur]

What happens if join stuff with different pts depends on the way you join them.
If you join them and make at least sure that the pts is increasing in the joined file, most decoders&co will play the file and probably throw a warning if the distance between two pts entries seems too large and try some way to cope with the problem. Some decoders&co will simply assume the content is vfr and the output pts entries are correct. So if according to pts a frame is shown 2hrs it will show that frame that long.
If you join your parts and the time stamps are not monotone the decoders&co either abort since the stream obviously is broken, or try to cope with the issue by either looking a few frames further to see if it was just a glitch or simply assume the last 'playback length' of the frame should be repeated.
=> blindly keeping pts entries on cut&merge options is simply a stupid idea

If you create content where pts entries are not continual your simply create content that is broken and you are at the mercy of the decoders&co.

Cu Selur

[Budman1]

Thank you selur and pandy. The problem i notice most often is a frozen frame for the amount of time shown by ffprobe for the first frame yet audio plays from the start. E. G. I you cut an mp4 at an I-frame exactly to the microsecond ( 327.127127) on a 29.97 fps closed gop 250 frame gop, you get a 16 second video that freezes for 8 seconds while audio plays and then plays for 8 seconds correctly with audio out of sync. If I cut 2 frames early at 327.060394, I get a video that seems to play normal but actually has the audio out of sync for the time specified for the first frame. It varys, but in this video it will be 0.065983. That appears to make it important to start at 0 unless I re-encode which appears to redo all the pts times??

[Selur]

With vfr content you need to adjust the time stamps to make sense, but if your content is cfr, why get the delay of the audio, extract raw streams, remux the raw streams thus creating new time stamps and while remuxing adding the delay?
(iirc '-fflags +genpts' also tells ffmpeg to recreate the time stamps which should work fine for cfr content)
In case you reencode, you usally remux which creates new time stamps.

Cu Selur

[Budman1]

@selur I didn't quite understand. Did you mean I should extract raw,streams .264 and .aac and remux into mp4 again? Doesnt going from raw to mp4 recode? Genpts doesnt seem to work for me during copy operation. I may have it wrong in the output options but it doesn't give me 0 pts time only NEAR 0 like the description says.

[Selur]

I usually cut raw streams and then remux and have no problem, but gentpts should also work (for cfr content).

[Budman1]

Thank you I will definitely try those again.