Re: New Matroska field: Timescale

On Thu, 24 Sep 2015 16:37:04 +0200
Jerome Martinez <[email protected]> wrote:

> Le 24/09/2015 13:38, wm4 a écrit :
> > [...]
> > It's very hard to design this in a backwards compatible and robust way.
> >
> > If you define a per-track framerate to which timestamps should be
> > fixed, you won't support VFR. (Yes, such files exist.)
> 
> Exact, the item is for CFR only. as you said, It's very hard to design 
> this in a backwards compatible and robust way, and this is the reason I 
> do this proposal of per track frame rate which would not have any impact 
> on players not supporting it.
> Be aware that I don't explicit talk of frame rate, but of time scale, 
> and some VFR files have actually "frame drops" (frame at timestamp 0, 1, 
> 2, 4, 5, 6...), and such VFR files can be correctly handled too.
> I think that people doing fully VFR files are not interested by exact 
> timestamps, so not being able to handle such case should not be a big issue.
> again, this is only because we want to keep backward compatibility.
> 
> > Also, doesn't
> > default-duration already define such a per-track framerate?
> 
> default duration has the same problem (not a fraction).
> having a default duration with a fraction (numerator/denominator) could 
> answer the issue too.
> 
> >   It works
> > badly, because OF COURSE some muxers  write broken framerates. In one
> > case, the framerate was based on a single _rounded_ frame duration,
> > even though the actual framerate was different (other frames had a
> > different frame duration).
> 
> If we always think to broken muxers, we can't have any solution.

There will be broken demuxers. And players will add hacks for dealing
with broken muxes. 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.)

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