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

Add a duration field to Frame #7

Open
koute opened this issue Sep 3, 2022 · 1 comment
Open

Add a duration field to Frame #7

koute opened this issue Sep 3, 2022 · 1 comment

Comments

@koute
Copy link

koute commented Sep 3, 2022

The Frame struct only contains a timestamp without a duration. This is problematic if you'd want to e.g. demux ASS subtitles since the raw subtitles are mangled and muxed into the .mkv without the timestamps.

For example, this is a raw line from an external .ass sub:

Dialogue: 0,0:00:12.36,0:00:12.40,Style,,0,0,0,,Insert text here

And if you'd mux that into an .mkv this is how it's going to look like:

14,0,Style,,0,0,0,,Insert text here

As you can see the timestamps are gone. The idea here is that you're supposed to recover them from the block timestamp + duration, as documented here.

For your reference, the symphonia_format_mkv crate does include the duration when demuxing.

@hasenbanck
Copy link
Owner

The duration is not a mandatory field in the EBML block (BlockDuration, 0x9B). Simple Blocks don't contain it at all.

So documentation says this about how to extract the duration from the EBML document:

The duration of the Block (based on TimestampScale). The BlockDuration Element can be useful at the end of a Track to define the duration of the last frame (as there is no subsequent Block available), or when there is a break in a track like for subtitle tracks. When not written and with no DefaultDuration, the value is assumed to be the difference between the timestamp of this Block and the timestamp of the next Block in "display" order (not coding order). BlockDuration **MUST** be set if the associated TrackEntry stores a DefaultDuration value.

This would need to be implemented by taking the default duration of the track (already exposed), the "BlockDuration" of a block (not exposed) or the time difference between the current and next frame into account (already exposed).

Not sure if this should be handled by the application or by the library though. PRs are welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants