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

Native vs application parsing of in-band cues #16

Open
chrisn opened this issue Dec 2, 2019 · 0 comments
Open

Native vs application parsing of in-band cues #16

chrisn opened this issue Dec 2, 2019 · 0 comments

Comments

@chrisn
Copy link
Collaborator

chrisn commented Dec 2, 2019

At TPAC 2019 we discussed UA vs application parsing of in-band cues.

To simplify cue handling for web applications, the UA should parse in-band cues and present them to the application as structured data. This means that implementations need to be able to parse a defined set of cue formats, which raises the following questions:

  • Which cue formats should be standardised across implementations?
  • How should new cue formats that are introduced in future be handled?
  • How does a web application know whether a particular cue format will be handled by the UA, to decide whether to parse the cues itself?

Given that in-band cues may carry arbitrary application-specific data, and it's not reasonable to expect implementations to parse all possible cue formats, a mechanism for the web application to parse the cue message data will be needed. We would want this work to happen off the main thread, to prevent stalling the UI. Possible approaches:

  • The web application parses media segments to extract in-band cues, prior to passing them to MSE appendBuffer(). This is what player libraries do today.
  • The web application registers a cue parser script, to be called when the implementation encounters cues matching a given format or scheme identifier.
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

1 participant