Re: New Matroska field: Timescale

Le 24/09/2015 17:45, Hendrik Leppkes a écrit :
>
>
> Am 24.09.2015 17:27 schrieb "Jerome Martinez" <[email protected] 
> <mailto:[email protected]>>:
> >
> > 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).

> 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
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel