Rewrite timestamp intepretations using ticks #521
Conversation
|
Still missing the rewrite of the Using more of the Segment/Track Tick unit to make things easier to explain. |
|
Ready for review: the |
robUx4
changed the title
|
Cleaned up so all elements refer to a tick. We could remove the Matroska Ticks, just nanoseconds, to make this a bit lighter. Depending if we chose to keep |
It applies to all scaled timestamps.
excluding the deprecated elements (maxver="0" or DivX)
Even for the deprecated elements. It's clear that Info\Duration in float was the wrong choice, given it's in Segment Ticks which are integer nanosecond values.
- use the proper formula - mention it's a PTS - make global negative timestamps invalid normative
Either it should not be used and we already have the default formula Or it needs to be explained in #437.
Add SeekPreRoll and DiscardPadding which were missing a proper tick definition.
The file timestamps are in Segment Ticks. Put the reseved status in usage notes
Unfortunately it's in nanoseconds (Matroska ticks) and not segment or track ticks so it can (almost) never be sample accurate.
|
Rebased and fixed a sentence. This seems mergeable. |
Effectively reverts "rewrite the TimestampScale Rounding audio-only example" This is not the preferred solution as it won't be backward compatible anyway. Keep the rounding rules though as it's better than leaving people pick whatever they want.
|
And remove the section that explained how to get finer frame precision as it's not the way we're going to do it. (Ref #422 ) |
Draft: the Block, TrackTimestampScale are not rewritten yet
The notion of Matroska/Segment/Track ticks is introduced to make it easier to know what formula to apply. For example
Cluster\Timestampis using theTimestampScalebut NOT theTrackTimestampScale.The
Info\Durationis expressed in Segment Ticks, but it's in floating point which is odd, only Track Ticks may be in floating point due toTrackTimestampScale.Fixes #517