On 27/07/2016 04:35, Steve Lhomme wrote:
> As the topic often resurfaces maybe it's time we discuss it in the
> context of CELLAR.
>
> There have been talks about ways to do it in the Matroska mailing
> before in this thread:
> https://lists.matroska.org/pipermail/matroska-devel/2012-October/004294.html
> https://lists.matroska.org/pipermail/matroska-devel/2012-October/004295.html
> https://lists.matroska.org/pipermail/matroska-devel/2012-October/004296.html
> https://lists.matroska.org/pipermail/matroska-devel/2012-October/004299.html
>
> An element to handle it was added (still in specdata.xml but commented)
> https://lists.matroska.org/pipermail/matroska-devel/2012-September/004289.html
> and later removed
> https://lists.matroska.org/pipermail/matroska-devel/2012-December/004317.html
>
> So far there was nothing conclusive but it seems it's not possible to
> do it properly in a backward compatible way.
>
> The constraints are simple:
> - backward compatible, so the 16 bits timestamp value in the
> (Simple)Block must remain unchanged. This value is multiplied by the
> scale (global and/or per track) to get the actual timestamp.
> - There could be some acceptable rounding between the two coexisting systems.
> - The rounding should happen in the current system, the rationale
> should always be exact (provided the source is exact)
> - A lot of Matroska elements are based on the timestamp scales. So
> they may be adjusted accordingly
> - We must minimize the elements where the same information is found
> twice. Basically only scale elements should be added. Maybe some
> elements for the Cluster timestamp might be added as well if
> necessary.
> - because of the 16 bits range per Cluster differences between a
> rationale system and the ns system must be tight.
> - we still want Clusters to be 4-5s long to minimize the scope of
> errors and buffering before playback. It may also correspond to some
> GOP values.
> - sample accuracy for audio would be good.
>
> Let the math begin.

Rationale Numbers for timestamps are usually for US style fixed 
framerate, so I think my answer in a previous email still applies.
https://mailarchive.ietf.org/arch/msg/cellar/WQCExNvAZy4goibE3_chnFB1w0c
Please comment about which need would not be fulfilled with this proposal.

Copy/paste:

I don't like the idea to have an incompatible change with such feature,
because this is not a "must have" for 99% of people, and Matroska "v5"
will not be adopted with that.
I think that we can have a workaround for having additional 0.99% happy
without the need of a break in compatibility:
- lot of people want to know the exact frame rate of a fixed frame rate
stream, people muxing from tapes know that the frame rate is fixed
(hardware limitation) so can set this element in the header. putting
frame rate info in the header with numerator and denominator is enough
for doing the difference between 30000/1001 and 29970/1000, and the
current millisecond timestamp is enough (a demuxer aware of the
framerate element can "correct" the timecode from e.g. 0.033s to
1001/30000 second; an old player just play the file with 1 ms
precision). We could add some rules in case a timecode does not fit the
frame rate (e.g. if timecode is 0.031, frame rate info is considered not
applicable)
- people having variable frame rate with very precise timestamp need to
know it before starting the muxing and can use a Timecodescale element
of 1 (so precision of 1 nanosecond, usually enough when there is no
fixed frame rate).
Which real life scenario can not deal with such workaround?


Compared to the concerns in:
https://lists.matroska.org/pipermail/matroska-devel/2012-October/004294.html
It is per track so it resolves most concern
For PCM, the corresponding video framerate is sometimes used and it 
would not be resolved correctly, right (i.e. at 30000/1001 fps, there 
are sometimes 1601 samples and sometimes 1602 samples and it is not 
possible to do the difference with the 16-bit timestamp having the 
millisecond precision)
Note that my proposal is similar to the one in the mail having criticism 
about TimecodeScaleDenominator (proposal of TrackTimeBaseNumerator and 
TrackTimeBaseDenominator)

If there is some issues with this idea, please say it so I stop to bug 
you with this idea.