Weird, and basically I do not want to deal with this. So it does make a difference if I add an audio track with a delay to an already existing MKV with a video track, or if I create a brandnew MKV with video and audio tracks. And yes, this time the only way to avoid sync errors was to honor the audio delay for the muxing process. I just tried again and extracted both the video and audio tracks, then imported both tracks into MKVMerge to create a new MKV.
You are correct, I did not extract the video track at all, I just extracted the audio track and remuxed it into the source MKV.
#Mkvtoolnix 6.2 software#
The average user will not have such analysis skills (I certainly don't), and we have software like mkvextract and mkvmerge to do this automatically. Thanks mkver for the detailed analysis, but this is not really my point. But this is only true if you actually extracted both audio and video and remuxed the elementary tracks - your comment seems as if you didn't extract the video at all.ītw: Why extract the tracks to elementary tracks at all? If you have transmission errors (and therefore missing packets), you will loose A/V sync no matter whether the initial offsets were right. So you would have to subtract a further 1511ms - 65ms from track #3. This is a difference of 1511ms in order to keep AV sync, you would have to offset the audio by 1511ms, too extracting audio to elementary streams makes it loose its initial delay (here 5ms and 65ms) which already amounts to subtracting 5ms resp. If you extracted both track #2 and track #1 (the video) and muxed it back with mkvmerge, mkvmerge would give the lowest video frame a timestamp of 0ms and the first video keyframe a timestamp of 60ms. The first video keyframe has a timestamp of 1571ms, the lowest video frame has a timestamp of 1511ms (this file uses open GOP). The second audio track (track #3) starts at 5ms, the first audio track (track #2) at 65ms.
0 kommentar(er)
