[Matroska-devel] New Matroska field: Timescale

Hendrik Leppkes h.leppkes at gmail.com
Thu Sep 24 17:45:57 CEST 2015

Am 24.09.2015 17:27 schrieb "Jerome Martinez" <jerome at mediaarea.net>:
> Le 24/09/2015 17:08, wm4 a écrit :
>> [...]
>> Basically we need to design with the worst case in mind, and we need to
have a plan how to deal with broken muxes. (But it's getting offtopic - I'm
just saying we should keep this scenario in mind.)
> I have that in mind too, we are on the same page.
>>> A protection against bad muxers could be to say that frame rate
>>> information is valid only if there is a valid number which fit the
>>> rounding, else frame rate information is discarded (frame rate info is
>>> considered as an helper for accuracy, nothing else)
>>> Example:
>>> timescale is 1000000 (so accuracy of 1 ms)
>>> track frame rate info is 30000/1001.
>>> if frame time stamp of 33ms, this is OK (timestamp from frame rate is
>>> 33.367ms, rounded to 33), accurate timestamp is 1001/30000
>>> if frame time stamp of 34ms, this is NOK (timestamp from frame rate is
>>> 33.367ms, rounded to 33, not 34), accurate timestamp is 34/1000
>>> if frame time stamp of 66ms, this is NOK (timestamp from frame rate is
>>> 66.733, rounded to 67, not 66), accurate timestamp is 66/1000
>>> if frame time stamp of 33ms, this is OK (timestamp from frame rate is
>>> 66.733ms, rounded to 67), accurate timestamp is 2002/30000
>>> If this rule is in the definition of this new Matroska metadata, there
>>> is no place for doubt and we handle buggy muxer as if the metadata does
>>> not exist (so as a player not supporting this metadata)
>> So you want to consider timestamps that deviate by more than 1 ms
>> invalid.
> Yes: we define the demuxer behavior in case of broken muxer, in order to
behave as if the new metadata does not exist, so we limit the risk of bad
player behavior due to bad muxer.
> More precisely:
> +/- 0.5ms in the case of timecodescale of 1000000.
> value to be adapted in case of other timecodescale (e.g. +/- 0.5ns in
case of timecodescale of 1)
> I think it is a safeguard against broken muxers, and should permit to
remove your worries about such metadata.
> Obviously, I am interested in another proposal if someone has a better

Its not that simple though, because of the rounding muxers will usually
write 33ms, 33ms, 34ms, ...., so the rounding error does not accumulate and
an average over a long time is accurate.

This sounds like quiet some complexity for demuxers, and for an optional
feature will as such not see any widespread use and hence become useless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20150924/14b6b460/attachment-0001.html>

More information about the Matroska-devel mailing list