Meeting minutes
Introduction
Chris: I want to follow up with Yuhao Fu on the SEI events proposal to see if there's alignment with work on DataCue API in this TF
… Also wanted to discuss the DASH event processing model
… Goal is to complete the explainer document
… https://
… The document discusses two things: one is the DataCue interface which allows web apps to create timed metadata cues
… The second part is specifically a mapping to MPEG DASH emsg event message boxes
… I think that DataCue API is reasonably well defined, in itself
… But the event message box part has a number of open questions
… So i was thinking about whether to separate those two parts, so that we can perhaps progress the API part, while we gather more input on DASH event handling
Kaz: It seems that this document is large, as an explainer. So it might be better to split it into several pieces, turn the explainer into a high level abstract description
… and move the detail to separate documents
Chris: I agree, so how best to split it up?
… Possibly we can have an explainer focused purely on the DataCue API
… And then another on DASH event mapping
… The DataCue API is an extension of TextTrackCue API, part of the HTML spec
… So we get the benefit there of event triggering during media playback, defined in HTML TextTrack spec
… DataCue API is based on Webkit implementation. They have support for certain HLS timed metadata
… Questions about how DataCue works with DASH emsg events
… Integration with MSE source buffers (https://
… Another is whether we need an API to allow application to subscribe for event types, or whether it's acceptable to surface all emsg events (not sure if we have an existing issue for that)
… We haven't had much feedback to answer some of these questions
Kaz: Do we need some more volunteers to update the document?
Chris: Ideally, yes. But I don't know who is interested to help drive this forwards
… Any thoughts on use cases, or timing accuracy requirements? A use case needing frame accurate rendering might need a different proposal
Kaz: It also depends on the expected workflow, e.g., concatenating video streams offline, can be slower
… If everything is done in a real time manner, this mechanism might not be enough yet
Chris: Use cases we have maybe don't need frame level accuracy, so the existing timing guarantee from text track cues may be enough
… Another open question is about parsed vs unparsed message data, in the emsg mapping
… https://
… Complexity of parsed and unparsed events, variations across browsers and versions
… Would it be simpler overall to leave parsing the message data to the web application?
… Example of validating message signature. I believe that comes from C2PA, but as far as I know they're not proposing to use emsg now
… This could be left to a mapping document to define, for those specific event types that need it
… Any comments or thoughts, or things we haven't considered so far?
Kaz: This topic also relates to the production workshop, timing and synchronisation is needed in a production context as well. So we could have further discussion on those details
Chris: Yes, metadata was a topic at the workshop. Hopeful to follow up in the new year
… Is it worth contacting other industry groups for input
… Don't know if there's still strong interest in this topic
Next meeting
Chris: Schedule for January 17, at same time. Happy to move to an earlier time if it makes it more convenient
… Hopefully we can use that meeting to look at the SEI event proposal
[Adjourned]