[Matroska-devel] New Matroska field: Timescale

Jerome Martinez jerome at mediaarea.net
Thu Sep 24 17:16:48 CEST 2015

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 one.

More information about the Matroska-devel mailing list