Assertion failed: TimecodeDelay overflows with --timecode-scale -1 #707

Closed
mbunkus opened this Issue Jan 24, 2015 · 3 comments

1 participant

@mbunkus
Owner

Original reporter: mbunkus

Posted by Liisachan on Doom9:

I have this specific (but quite normal) AVC (x264 r2120) video in MP4 container, which causes "Assertion failed: TimecodeDelay >= int16(0x8000) && TimecodeDelay <= int16(0x7FFF), file lib/libmatroska/src/KaxCluster.cpp, line 280" if muxed with a normal-looking, stereo 48000 Hz Vorbis.ogg (aoTuV), using --timecode-scale -1.
Like:
mkvmerge -o out.mkv x264.mp4 vorbis.ogg --timecode-scale -1

The same command line works just fine if --timecode-scale 20832 is used explicitly (apparently that's what mkvmerge is trying to do for -1, though 1/48000 is 20833 ns).

The problem occurs only with a specific .mp4 file; other .mp4 files creaetd with the same version of x264 so far mux just fine with --timecode-scale -1. Also, if I transmux this.mp4 into tmp.mkv first, tmp.mkv and vorbis.ogg mux just fine as well. On the other hand, this specific AVC.mp4 doesn't mux with other vorbis files either, with --timecode-scale -1.

I'm on Windows (still XP), and the above happens with the current version (5.2.1) of mkvmerge, and also with older versions (tested v2.9.9, 3.0.0, 3.4.0, 4.0.0). With -v -r debug.log, the last message when this happens is:
Vorbis: samples_here at 246276000000 (orig -1 expected 246276000000): 128 (m_previous_samples_sum: 11821376)

The next line would have been:
Vorbis: samples_here at 246278666666 (orig -1 expected 246278666666): 128 (m_previous_samples_sum: 11821504)

@mbunkus mbunkus self-assigned this Jan 24, 2015
@mbunkus mbunkus closed this Jan 24, 2015
@mbunkus mbunkus added the fixed label Jan 24, 2015
@mbunkus
Owner

Original reporter: Liisachan2@faireal.net

(Comment) In the sample I provided (td.mp4/td.ogg), the problem can be worked around with --cluster-length 648ms or less, but not with --cluster-length 649ms.
TimecodeScale is 20832, and 648 ms = 31105.99 units is slightly less than 32767 (0x7FFF).

@mbunkus
Owner

Original reporter: mbunkus

Fixed in revision 10d3131. A new build for Windows including the fix will be available shortly from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (build numbers 420 and higher).

@mbunkus
Owner

Original reporter: Liisachan

Fix confirmed. So "floor" was missing... Good thing this was fixed, since the same code seems to be used for any MKA. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment