Consistent Invalid timestamps error while muxing from mkv to mp4.

[Amey8a]

In other words, muxing as MP4 fails, right? I'll try to generate a 1001/24000 video myself any see whether I can reproduce the failure.

Yes, muxing to mkv or mp4v2 never fails. Even videos with 24, 25, 30 fps where the timescale is really strong, the mp4 muxing is perfect without any issue. Its just that 23.976 (24000/1001 or 23976/1000) and may be also 29.976 (30000/1001 or 29976/1000) that makes issues for mp4 muxing.

PTS are not duplicated, else it would have been noted in Avidemux log.

That is correct. I am learning more about this log files recently and it helps me understand more.

[eumagga0x2a]

MP4v2 is irrelevant for now at least (it is legacy, should be removed).

[Amey8a]

MP4v2 is irrelevant for now at least (it is legacy, should be removed).

Thats one of the best thing that will happen with avidemux. The release version also don't have mp4v2 may be for the same reason.

[eumagga0x2a]

I can reproduce the issue with my sample, looking into it. Thank you very much for your report.

[Amey8a]

I can reproduce the issue with my sample, looking into it. Thank you very much for your report.

Glad the reports came out to be helpful. I appreciate the avidemux team for simplifying so many tasks for me. Thank you for your support.

[eumagga0x2a]

Nightly builds with changes which should fix the dts issue with MKV videos are available. MinGW 64bit build for Windows: https://avidemux.org/nightly/win64/

[Amey8a]

Nightly builds with changes which should fix the dts issue with MKV videos are available. MinGW 64bit build for Windows: https://avidemux.org/nightly/win64/

So, I did further testing for mkv to mp4 muxing using current avidemux build 20200703 with following files,

1. Mkv from mkvtoolnix
2. Mkv from avidemux
3. Mkv from ffmpeg,

Here are my results,

1. Avidemux_mkv always selects 83ms as a zero as seen from avidemux admlog which does not happen in case of  ffmpeg_mkv or mkvtoolnix_mkv.

2. The result is really awesome for mkv to mp4 muxing. No dts error in testing. The output mp4 agrees with ffmpeg and mediainfo as a true cfr video.

3.Output mp4 always delays audio tracks by -83ms (i.e delays video by 83ms) for all videos to keep pts>dts, my question is,

a) Is it necessary to add this delay when none of ffmpeg or mkvtoolnix adds any?
b) What will happen if the audio/video is not shifted at all?

[eumagga0x2a]

2. The result is really awesome for mkv to mp4 muxing. No dts error in testing. The output mp4 agrees with ffmpeg and mediainfo as a true cfr video.

Great, thanks, the fix seems to work.

a) Is it necessary to add this delay when none of ffmpeg or mkvtoolnix adds any?

This is the result of design decision to use unsigned values for timestamps in Avidemux, contrary to signed values in ffmpeg. For this reason it cannot shift decode timestamps of the first few frames into the negative range if B-frames are present to align the zero point of the timescale with the earliest PTS (in case of Avidemux, with the PTS of the first keyframe).

b) What will happen if the audio/video is not shifted at all?

uint64_t used to store DTS wraps around for the first few frames i.e. appears in a distant future, in any case the video won't play.

[Amey8a]

a) Is it necessary to add this delay when none of ffmpeg or mkvtoolnix adds any?

This is the result of design decision to use unsigned values for timestamps in Avidemux, contrary to signed values in ffmpeg. For this reason it cannot shift decode timestamps of the first few frames into the negative range if B-frames are present to align the zero point of the timescale with the earliest PTS (in case of Avidemux, with the PTS of the first keyframe).

b) What will happen if the audio/video is not shifted at all?

uint64_t used to store DTS wraps around for the first few frames i.e. appears in a distant future, in any case the video won't play.

Thats the correct answer I was looking for. So, as the muxing is going well now, I will be muxing my entire library of MKVs to MP4s without worrying for cfr to vfr issue and the dts errors anymore, thanks to this current build and the builder.

Believe me, I have encoded more than 10 videos just because of the dts error, thinking that the copies that I have might be damaged as avidemux never failed on me before i.e. when I was using release build 2.7.5. But after realizing that the error occurred at the same timestamp with current builds, I had to at least ask if it is just me or the error happened to anyone else.

The current ffmpeg also have issues in maintaining the source framerate mode when muxing using copy, so I will also need to speak to them on this matter.