[Matroska-devel] New Matroska field: Timescale

Hendrik Leppkes h.leppkes at gmail.com
Thu Sep 24 18:08:23 CEST 2015


Am 24.09.2015 18:03 schrieb "Jerome Martinez" <jerome at mediaarea.net>:
>
> Le 24/09/2015 17:45, Hendrik Leppkes a écrit :
>>
>>
>> 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
one.
>> >
>>
>> 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.
>
>
> I don't understand the issue here, the idea is just to correct the
timestamp, and the timestamp is usually correct (more or less the
precision: 33.333 is converted to 33 and 66.667 is converted to 67).

But you don't know that it's 33.3333 exactly. Who is to say the first frame
didn't start at 1.2222ms for some reason, and all the following should be
offset by that?

I don't think there are any guarantees that the first frame has to be at 0
exactly.

>
>
>> 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.
>
>
> We plan to use it (for us, it is important to differentiate e.g.
29700/1000 and 30000/1001), and I am ready to develop a patch for
libmatroska and FFmpeg (both muxing and demuxing).
> and if nobody else uses it, I think it is not harmful because we take
care of having no impact on players not supporting it.
>
> Again, the goal is:
>
>
> 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.
>
>
> we ask for this metadata because we want to use it.
> I understand this may be a limited usage, but it is not useless.
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20150924/84a534f2/attachment.html>


More information about the Matroska-devel mailing list