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

Segmented IMSC1 and WebVTT guidance is missing #55

Open
mikedo opened this issue May 19, 2020 · 2 comments
Open

Segmented IMSC1 and WebVTT guidance is missing #55

mikedo opened this issue May 19, 2020 · 2 comments

Comments

@mikedo
Copy link
Contributor

mikedo commented May 19, 2020

The document (Section 15) only provides timeline guidance for simple use case sidecar IMSC1 and WebVTT files. Timeline guidance for Segmented files covering Multi-Period, ad insertion and post-produced content is needed. Unlike video and audio IMSC1 and WebVTT have timing within the sample data. 14496-30 requires a certain unusual presentation time calculation related to the @presentationTimeOffset that involves a "seek" into the sample to know what timed elements in the sample are to be presented and when.
For broadcast, it is acceptable to carousel an entire presentation of IMSC1 or WebVTT content as a single Segment (and FFMPEG originally worked that way - the entire document in a single sample in a single Segment but with different @presentationTimeOffsets). This is not particularly efficient but permitted by -30.
I think a new section (or perhaps 2 subsections under a general section 15) are needed to provide some guidance here - timeline for Segmented IMSC1 and WebVTT; and constrained sidecar (per existing text).

@sandersaares
Copy link
Member

For broadcast, it is acceptable to carousel an entire presentation of IMSC1 or WebVTT content as a single Segment (and FFMPEG originally worked that way - the entire document in a single sample in a single Segment but with different @presentationTimeOffsets). This is not particularly efficient but permitted by -30.

Should we recommend something one way or the other here?

@mikedo
Copy link
Contributor Author

mikedo commented May 20, 2020

Yes. But we will need both. Live will require short Segments, but we should permit the post-produced large Segments for both broadcast and OTT. I planto cover these and their timing in a forthcoming contribution.

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