Re: New Matroska field: Timescale

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

>
> We could store 2 timestamps per packet. But you bet there will be at
> least 1 muxer which writes two completely different timestamps (one of
> them broken), so users will consider a player broken, depending whether
> it interprets the broken timestamp.
>
> We could somehow store the difference between the rounded timestamp and
> the real timestamp per packet - this might be somewhat more robust, as
> even with broken timestamps, the difference will be at most +/- 1 ms,
> but it sounds complex and messy.
>
> And last but not least, we have to store other timestamp fields
> correctly, like in the seek index, chapter index, etc.
> _______________________________________________
> 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

_______________________________________________
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