Draft: Proposal to add some rational number in timestamps #425
Conversation
|
There could be a fraction in each track as well that is not dependent on the other tracks clock. In the end we would use this fraction rather than the global one (which would mostly be for Cluster timestamps) given more range per Blocks for each track. But the value would not be close to what old parsers would understand. In that case that means using a Matroska v5 and marking it unreadable by v4 parsers. I could live with that. After all MP4 CMAF didn't exist a few years back and now everyone switched to it. |
| TimestampScale When combined with <a href="https://www.matroska.org/technical/elements.html#TimestampScaleDenominator">TimestampScaleDenominator</a> the Timestamp scale is given by the fraction TimestampScale/TimestampScaleDenominator in seconds.--> | ||
|
|
||
| <element name="TimestampNumerator" path="\Segment\Tracks\TrackEntry\TimestampNumerator" id="0x2AF6A9" type="uinteger" range="not 0" maxOccurs="1" minver="4"> | ||
| <documentation lang="en" purpose="definition">Timestamp numerator to apply instead of the TimestampScale, when the TimestampDenominator is present as well.</documentation> |
There was a problem hiding this comment.
If TrackTimestampScale is revived it should be mentioned its value MUST be the rounded value in nanoseconds of this fraction.
| b = `Cluster`'s Timestamp | ||
| c = `TimestampScale` | ||
|
|
||
| For compatibility with older readers that don't understand these elements, the `TimestampScale` value *MUST* |
There was a problem hiding this comment.
More info about the TrackTimestampScale should be added.
|
This might be an addition to #437 but less prioritary. A fraction for the global |
robUx4
force-pushed
the
timestamp-fraction
branch
from
2b48ffc
to
df540ce
Compare
robUx4
force-pushed
the
timestamp-fraction
branch
from
df540ce
to
8e79705
Compare
|
Marked as v5. It may also wait for EBML rationale values to be supported. |
…TimestampScale This allows sample precision of each timestamp is some cases, mostly single track files. Wherever TimestampScale was used, if this fraction is found, it should be used instead.
robUx4
force-pushed
the
timestamp-fraction
branch
from
8e79705
to
06fe005
Compare
|
Maybe it is better to use the new Rational element type(which is not implemented yet in EBML) . Nothing is more precise as a rational number. |
robUx4
changed the title
As discussed in #422 there are some cases where proper timing and backward compatibility is possible.
Wherever TimestampScale was used, if the new fraction is found, it should be used instead.
The fraction cannot just be in each track as the Cluster timestamp is also involved in the equation. So the precision has to be kept there as well.
If we had a fraction type in EBML we could use that type to store the whole fraction.