I was wrong. `cat` and "concat:" help to solve the problem with real world videos.
Looks like ffmpeg can detect sudden resets of the PTS. I mean, if we concatenate two .ts files and both have STARTPTS=0 then ffmpeg will begin adding a certain number to the PTS in the remaining frames. This number seems to be the same for both video and audio even though the stream durations differ. However, if subsequent .ts files have STARTPTS where the previous .ts file ended then ffmpeg will not adjust PTS in them. In my sample second chunk STARTPTS=0, but in real world videos they are continuous. Actually, I don't know how to split a video into .ts chunks with continuous PTS. On 04.02.2021 10:26, [email protected] wrote: > > I tried both `cat` and `-i "concat..."`, but they produce the same artifact > in MPC-HC. > > I guess the audio PTS from the second chunk is adjusted relative to the video > duration of the first chunk. > > On 03.02.2021 1:05, Carl Eugen Hoyos wrote: >> Am Di., 2. Feb. 2021 um 22:18 Uhr schrieb Carl Eugen Hoyos >> <[email protected]>: >>>> Am 02.02.2021 um 20:09 schrieb [email protected]: >>>> >>>> I'm concatenating .ts chunks intended for an HLS player into a single .mp4 >>>> video. >>> You should instead concatenate all ts chunks into a single transport stream: >>> $ cat 1.ts 2.ts 3.ts > out.ts >> Or use the concat protocol instead of the concat demuxer. >> >> Carl Eugen >> _______________________________________________ >> ffmpeg-user mailing list >> [email protected] >> https://ffmpeg.org/mailman/listinfo/ffmpeg-user >> >> To unsubscribe, visit link above, or email >> [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
