[Matroska-devel] New Matroska field: Timescale

Steve Lhomme slhomme at matroska.org
Sun Oct 4 16:42:22 CEST 2015


2015-09-24 11:09 GMT+02:00 Jerome Martinez <jerome at mediaarea.net>:
> Le 23/09/2015 17:43, Steve Lhomme a écrit :
>>
>> Following this week-end's VDD15 (Videolan Dev Days) we have some
>> productive talks with Dave Rice (working on the IETF specifications)
>> and a guy from YouTube on how we could improve Matroska for long term
>> storage/archival and also new features in video.
>>
>> There are a few fields that would need to be added to reach this goal.
>> I'll send an email for each (family of) field so the discussions are
>> easy to follow.
>>
>> One of the most common drawback mentioned when Matroska comes to mind
>> is the inaccurate approach for timestamps (that should not be called
>> timecodes which is something different in the video world).
>
>
> It would be great to replace "timecode" by "timestamp" everywhere in the
> documentation.

Will do, but first I need to edit the spec-generating document so the
generated code is still the same but the spec isn't.

>>   The proper
>> way to do it, at least for clock accurate digital sources should be
>> using a fraction format (numerator/denominator).
>>
>> See this page for own the basic math works:
>> http://matroska.org/technical/specs/notes.html#TimecodeScale
>>
>> (1233 + 564264) * 1000000 = 565497000000
>>       = 565497 ms
>>       = 565.497s
>>
>> With a numerator/denominator approach this example would become:
>> (1233 + 564264) * 1 / 1000 = 565.497s
>>
>> A NSTC movie (29.76fps) could have a better accuracy using 30000/1001
>> (or 30/1001 if you want a large range of values in your block).
>>
>> One of the drawback (and why it was not adopted in the first place) is
>> that when you mix heterogeneous sources you need to find a common
>> fraction that works for all tracks and still get enough range within
>> the 16 bits possible for a Block timecode. It was less of a problem
>> when we had TrackTimecodeScale to account for each track specifics,
>> but that element is deprecated.
>
>
> Why is TrackTimecodeScale deprecated? This is actually the right method from
> my point of view (but it is now too late for having it without breaking
> compatibility) because a scale is per track.

Because it's inconvenient to use and error-prone. It was designed to
be able to keep audio tracks for 24fps and 23.96fps versions of the
same video (or something like that, in Europe TV show music often
sound higher pitched because the audio has been stretch in a dirty
way).. But the muxing has to account for this to have proper
interleaving. And also, it's a floating point value. The one that
forced all timestamps to be in floating point in Matroska.

>>
>> If we decide to use fractions, it should be possible to keep backward
>> compatibility. The current TimecodeScale would be an approximation of
>> the fraction in nanoseconds. New players would take advantage of the
>> new fields as they are upgraded.
>
>
> Nanoseconds would not resolve the main issue: it is not accurate.
> It would be more accurate than today with a timescale of 1000000:
> - at 29700/1000, first frame is at 33366700 nanoseconds
> - at 30000/1001, first frame is at 33366667 nanoseconds
> so we can detect this difference, but FFmpeg will still not put 29700/1000
> or 30000/1001 because Matroska does not say that this is the real frame
> rate.

It's not precise for old player using the old field that's an approximation.

> So we may need to provide the time scale with a fraction, per track, without
> changing something else.

Having one fraction per track, in addition of the main fraction could
be a solution. Or maybe we don't need the main one at all. But the 16
bits value written in each block would have to be interpreted
correctly by both correctly. In that case you would probably need the
"deprecated" TrackTimecodeScale value. It's workable, except I doubt
many existing players, hardware or software, actually make use of that
value. The ones based on libmatroska are but I doubt about any other
(maybe libavformat is okay too).

> With it, I think it is not necessary to use nanoseconds, and:
> - players not supporting frame rate info per track with a fraction would use
> TimeCode field as today (33ms will stay 33ms)
> - players supporting frame rate info per track with a fraction would
> "convert" TimeCode field to the nearest real frame rate (33ms with a time
> scale of 1001/30000 will be converted to 33.366667ms because it is the
> nearest "valid" value, 21ms with a timescale of 1024/48000 will be converted
> to 21.333333ms because it is the nearest "valid" value)
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



-- 
Steve Lhomme
Matroska association Chairman


More information about the Matroska-devel mailing list