15:55:25 <RRSAgent> RRSAgent has joined #me
15:55:25 <RRSAgent> logging to https://www.w3.org/2021/12/20-me-irc
15:55:28 <Zakim> Zakim has joined #me
15:55:48 <cpn> Meeting: Media Timed Events TF
15:55:59 <cpn> Agenda: https://www.w3.org/events/meetings/2b88a9a9-b1bc-463e-973f-018e98cb1558/20211220T160000
15:58:13 <xfq> xfq has joined #me
15:58:39 <takio> takio has joined #me
16:00:11 <cpn> present: Chris_Needham, Takio_Yamaoka, Kaz_Ashimura, Fuqiao_Xue
16:00:13 <cpn> chair: Chris
16:00:18 <kaz> rrsagent, make log public
16:00:23 <kaz> rrsagent, draft minutes
16:00:23 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/20-me-minutes.html kaz
16:01:00 <cpn> scribenick: cpn
16:06:18 <kaz> present+ David_Chiu
16:06:41 <cpn> Topic: Video SEI Events
16:07:30 <cpn> 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
16:08:30 <cpn> ... Also wanted to discuss the DASH event processing model
16:08:45 <cpn> s/Video SEI Events/Introduction
16:10:04 <cpn> ... Goal is to complete the explainer document
16:10:27 <cpn> ... https://github.com/WICG/datacue/blob/main/explainer.md
16:11:23 <cpn> ... The document discusses two things: one is the DataCue interface which allows web apps to create timed metadata cues
16:11:45 <cpn> ... The second part is specifically a mapping to MPEG DASH emsg event message boxes
16:12:06 <cpn> ... I think that DataCue API is reasonably well defined, in itself
16:12:23 <cpn> ... But the event message box part has a number of open questions
16:13:10 <cpn> ... 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
16:13:33 <kaz> q+
16:14:44 <cpn> 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
16:14:52 <cpn> ... and move the detail to separate documents
16:15:15 <kaz> cpn: that was kind of what I was also thinking about
16:15:25 <cpn> Chris: I agree, so how betst to split it up?
16:15:43 <kaz> s/cpn: that was kind of what I was also thinking about/
16:16:37 <cpn> ... Possibly we can have an explainer focused purely on the DataCue API
16:16:53 <cpn> ... And then another on DASH event mapping
16:16:59 <kaz> s/betst/best/
16:17:24 <cpn> ... The DataCue API is an extension of TextTrackCue API, part of the HTML spec
16:17:53 <cpn> ... So we get the benefit there of event triggering during media playback, defined in HTML TextTrack spec
16:19:03 <cpn> ... DataCue API is based on Webkit implementation. They have support for certain HLS timed metadata
16:19:57 <cpn> ... Questions about how DataCue works with DASH emsg events
16:21:32 <cpn> ... Integration with MSE source buffers (https://github.com/WICG/datacue/issues/30, https://github.com/WICG/datacue/issues/28, https://github.com/WICG/datacue/issues/27)
16:23:36 <cpn> ... 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)
16:24:52 <cpn> ... We haven't had much feedback to answer some of these questions
16:25:23 <cpn> Kaz: Do we need some more volunteers to update the document?
16:26:33 <cpn> Chris: Ideally, yes. But I don't know who is interested to help drive this forwards
16:28:39 <cpn> ... Any thoughts on use cases, or timing accuracy requirements? A use case needing frame accurate rendering might need a different proposal
16:29:28 <cpn> Kaz: It also depends on the expected workflow, e.g., concatenating video streams offline, can be slower
16:30:02 <cpn> ... If everything is done in a real time manner, this mechanism might not be enough yet
16:31:15 <cpn> Chris: Use cases we have maybe don't need frame level accuracy, so the existing timing guarantee from text track cues may be enough
16:31:58 <cpn> ... Another open question is about parsed vs unparsed message data, in the emsg mapping
16:32:28 <cpn> ... https://github.com/WICG/datacue/issues/21
16:34:35 <cpn> ... Complexity of parsed and unparsed events, variations across browsers and versions
16:35:02 <cpn> ... Would it be simpler overall to leave parsing the message data to the web application?
16:37:04 <cpn> ... 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
16:38:05 <cpn> ... This could be left to a mapping document to define, for those specific event types that need it
16:39:57 <cpn> ... Any comments or thoughts, or things we haven't considered so far?
16:40:47 <cpn> 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
16:42:14 <cpn> Chris: Yes, metadata was a topic at the workshop. Hopeful to follow up in the new year
16:42:19 <kaz> present+ Kazuhiro_Hoya
16:45:27 <cpn> ... Is it worth contacting other industry groups for input
16:46:13 <cpn> ... Don't know if there's still strong interest in this topic
16:46:47 <cpn> Topic: Next meeting
16:47:41 <cpn> Chris: Schedule for January 17, at same time. Happy to move to an earlier time if it makes it more convenient
16:48:35 <cpn> ... Hopefully we can use that meeting to look at the SEI event proposal
16:50:35 <cpn> [Adjourned]
16:50:41 <kaz> rrsagent, draft minutes
16:50:41 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/20-me-minutes.html kaz
17:17:51 <ovf> ovf has joined #me
17:48:17 <Karen> Karen has joined #ME
17:50:48 <kaz> kaz has joined #me
19:24:05 <Karen> Karen has joined #ME
22:10:17 <Zakim> Zakim has left #me
22:35:34 <Karen> Karen has joined #ME