[Matroska-devel] About time scale denominators
moritz at bunkus.org
Thu Oct 4 10:05:28 CEST 2012
On Thu, Oct 4, 2012 at 12:56 AM, Ben Wreder <benwreder at hotmail.com> wrote:
> 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.
That is a valid concern. Thanks for pointing it out.
> 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.
That is always the case, even with your proposal.
> 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.
While that would keep backwards compatibility it would also defeat the
purpose of what we're trying to accomplish (at least partially). With
such a schema you cannot have sample-precision unless you make the
TimecodeScale paramater small again -- and in that case you don't have
that much of an advantage over the current situation.
I'd rather we break compatibility once and do it right. In that
situation we could also do some more stuff that would break
> 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).
TrueHD has very, very small packets (e.g. 40 samples in a single
packet). For such streams your scheme would require a very small
TimecodeScale like I said above.
> 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).
Those are concerns valid no matter how we implement it. Gaps in the
stream are another such problem, but muxers have to deal with that
already -- albeit with less loss of precision (e.g. the ms resolution
usually used requires rounding such gaps/offset already).
More information about the Matroska-devel