Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow TrackTimestampScale in Matroska v4 #437

Closed
wants to merge 2 commits into from
Closed

Conversation

robUx4
Copy link
Contributor

@robUx4 robUx4 commented Nov 1, 2020

Following the investigation in #422 it seems like a good tool to achieve sample accurate timestamp in many (more) cases.

In posts starting from #422 (comment)

@robUx4
Copy link
Contributor Author

robUx4 commented Nov 22, 2020

@mbunkus any opinion on that ? It seems libmatroska is not ready for that move but it's possible to work around it without breaking everything. That has a direct impact on support for this feature in VLC as well.

I have patches for libmatroska, VLC and libavformat (read and write). So it's at least possible to use it (with sample "accurate" timestamps, see #425). It should not be used by default because most existing readers, if not all, will not handle the value properly. But it can gradually be added. After all it's something that should have been supported since the beginning. And it is there in the specs up to version 3.

@mcr mcr requested a review from mbunkus December 1, 2020 20:24
@robUx4
Copy link
Contributor Author

robUx4 commented Dec 6, 2020

For the record, the feature is now available in libavformat for reading. For writing it depends on codec packing size(s) so we need a list of known packing sizes (in my test to generate files I used 8 by default which should give long enough Clusters in most cases).

@robUx4
Copy link
Contributor Author

robUx4 commented Mar 14, 2021

This is necessary but not sufficient to do sample accurate timestamps. For that we also need proper #439 documentation.

Following the investigation in #422 it seems like a good tool to achieve sample accurate timestamp in many (more) cases.
robUx4 added a commit that referenced this pull request Jul 11, 2021
Either it should not be used and we already have the default formula
Or it needs to be explained in #437.
@robUx4 robUx4 marked this pull request as draft July 11, 2021 12:14
@robUx4
Copy link
Contributor Author

robUx4 commented Jul 11, 2021

Turned into a draft until #521 is merged.

This now contains the formula to use TrackTimestampScale to get the Track ticks matching the sample number of each track.

robUx4 added a commit that referenced this pull request Jul 11, 2021
Either it should not be used and we already have the default formula
Or it needs to be explained in #437.
@robUx4
Copy link
Contributor Author

robUx4 commented Jan 23, 2022

The consensus on #422 is that reusing the element with some extra trick will likely not bring real world support. So it should be done with new elements instead.

Therefore I'm closing this, but parts could be reused to describe properly these elements.

@robUx4 robUx4 closed this Jan 23, 2022
robUx4 added a commit that referenced this pull request Jan 23, 2022
Either it should not be used and we already have the default formula
Or it needs to be explained in #437.
robUx4 added a commit that referenced this pull request Jan 30, 2022
Either it should not be used and we already have the default formula
Or it needs to be explained in #437.
@robUx4 robUx4 deleted the tracktimestampscale branch July 2, 2023 05:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarifications enhancement spec_main Main Matroska spec document target
Projects
Development

Successfully merging this pull request may close these issues.

Consider providing a facility for integer-fraction timescales
2 participants