[Matroska-devel] About time scale denominators

Ben Wreder benwreder at hotmail.com
Thu Oct 4 00:56:47 CEST 2012


Hi,

I've seen plans to add a "TimecodeScaleDenominator" element in MKV and I have a few comments.

If I understand it correctly, both TimecodeScale and TimecodeScaleDenominator are shared by all tracks, so if exact timing is desired for all tracks a potentilly small fraction would have to be used (with all the denominators multiplied in the worst case), resulting in large Timecodes, plus the inability to know the original timebase of individual tracks. Moreover it's only backwards-compatible in the sense that the default value is what was assumed before, but files that actually attempt to use it will need updated demuxers.

Instead, maybe it would be a better idea to add a pair of optional elements to each track, TrackTimeBaseNumerator and TrackTimeBaseDenominator for example, that tell the exact timebase of the track, and then (on supporting demuxers) snap the block timecodes to that base.

For a non-supporting demuxer, the file looks exactly the same as it did before. A supporting demuxer will correct the timecodes to their exact values.

For example, you could use 1/30 for a video track. A timecode of 0ms would be output as 0/30, a timecode of 33ms as 1/30, a timecode 67ms as 2/30, and so on. You could use 1001/120000 for a VFR NTSC video track, as it's commonly stored in AVI. A value of 1/1000 would have no effect (for the default TimecodeScale).

This also works for audio codecs, for example Vorbis frames always have a power of 2 greater or equal than 64 samples, so 64/44100 would generate exact timestamps for any 44100Hz Vorbis stream (laced frames would still have some unknow timestamps, but that's a tangential problem).

For a track with over 1000fps (might be the case with PCM audio depending on how you split it), you'd have to lower the global TimecodeScale as you do now, but otherwise it'd still work fine.

On the muxer side this requires knowledge of the original track timebase (it's easy for most audio codecs which have it fixed, also for AVI and CFR MP4 video tracks, and manually user-specified constant framerates), and maybe special handling of edge cases, such as user-specified delay offsets (which would have to be snapped to an integral number of track timebase units). On the demuxer side it's even more straightforward. The DefaultDuration and block's Durations would probably have to be snapped too (right now they use different precisions, so if you take them literally you have gaps and overlaps - no software seems to care about this though).
 		 	   		  


More information about the Matroska-devel mailing list