Started by Amey8a, June 27, 2020, 06:47:09 am
Quote from: eumagga0x2a on June 28, 2020, 04:46:17 pmIn 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.
QuotePTS are not duplicated, else it would have been noted in Avidemux log.
Quote from: eumagga0x2a on June 28, 2020, 05:20:35 pmMP4v2 is irrelevant for now at least (it is legacy, should be removed).
Quote from: eumagga0x2a on June 28, 2020, 06:55:48 pmI can reproduce the issue with my sample, looking into it. Thank you very much for your report.
Quote from: eumagga0x2a on July 03, 2020, 09:33:46 amNightly builds with changes which should fix the dts issue with MKV videos are available. MinGW 64bit build for Windows: https://avidemux.org/nightly/win64/
Quote from: Amey8a on July 03, 2020, 11:24:05 am2. 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.
Quotea) Is it necessary to add this delay when none of ffmpeg or mkvtoolnix adds any?
Quoteb) What will happen if the audio/video is not shifted at all?
Quote from: eumagga0x2a on July 03, 2020, 12:25:01 pmQuotea) 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).Quoteb) 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.