[FFmpeg-user] concat a/v desync (only in MPC-HC)

[basinilya at gmail.com]

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, basinilya at gmail.com 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 <ceffmpeg at gmail.com>:
>>>> Am 02.02.2021 um 20:09 schrieb basinilya at gmail.com:
>>>>
>>>> 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
>> ffmpeg-user at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".