15:50:31 RRSAgent has joined #me 15:50:31 logging to https://www.w3.org/2020/11/16-me-irc 15:50:35 Zakim has joined #me 15:50:53 Meeting: Media Timed Events / DataCue API TF 15:51:02 Chair: Chris 15:51:13 Agenda: https://lists.w3.org/Archives/Public/public-web-and-tv/2020Nov/0001.html 15:59:39 Present+ Gary_Katevman, Andy_Rosen 16:00:58 present+ Rob_Smith 16:01:10 RobSmith has joined #me 16:01:33 Present+ John_Simmons 16:01:36 fghilardi has joined #me 16:02:08 Johnsim has joined #me 16:02:52 nigel has joined #me 16:03:23 present+ Iraj_Sodagar 16:03:29 present+ Franco_Ghilardi 16:03:39 arosen has joined #me 16:03:56 Present+ Nigel_Megitt 16:04:09 scribenick: cpn 16:04:15 Topic: Intro 16:04:18 Slides: https://docs.google.com/presentation/d/19V_j8ZTo7crr6wWij6qmlBTNwR4vrPXACrbQ1BEVgqM/edit#slide=id.p 16:06:06 chris: Agenda page - four things to cover. First is from Text Track Queue endtime proposal 16:06:51 Chris: Feedback on joint meeting a few weeks ago - about emsg box support 16:08:38 chris: Text TrackCue end time - proposal to have an unbounded end time so you can signal a timed metadata event with .. 16:08:58 changes to html 16:09:50 RobSmith: From what Chris said, pull request in repository based on discussion on Chris' slides, HTML discussion RF297 - links in that.. 16:10:34 to the pull request for the changes. preliminary review - Philip from Opera kicks things along 16:10:43 s/Opera/Google/ 16:10:54 scribenick: cpn 16:11:26 ... We have general support from the browser vendors. Philip said there'd need to be a corresponding update to WebVTT, which inherits TextTrackCue 16:11:48 ... I've raised a WebVTT PR, awaiting response 16:11:48 RobSmith: inherits end time from extract queue - everything else is inherited. Waiting on response 16:13:05 Gary: proposal is fine but have not had a chance to look yet 16:13:38 WHATWG/HTML PR: https://github.com/whatwg/html/pull/5953 16:13:54 scribenick: cpn 16:14:13 WebVTT PR: https://github.com/w3c/webvtt/pull/493 16:14:46 Chris: Rob isn't a TTWG member, so what to do about the IPR issues? 16:15:36 Nigel: It's a substantive change, so needs IPR clearing, usually done by joining the WG. Not the only way though, we'll need to ask W3C staff contact, Atsushi, who leads on TTWG 16:16:15 Chris: Only issue is Rob's IE status 16:16:50 Nigel: There should be a way though 16:17:02 Chris: We'll follow up on that 16:17:20 Topic: Feedback from TPAC meeting 16:28:33 Andy: Any concern with manifest serving? 16:32:03 Iraj: Need input from MSE editors? Would they be involved 16:34:56 Chris: We need to drive this topic, with editor input. I would want to go back with specific question 16:35:07 Iraj: Early input from them would really help 16:35:47 Zack: This is something I can help with, need to figure out timing 16:36:43 ... Matt raised good questions on the MSE integration, good starting point to work from 16:38:52 Iraj: The approach should be to take the existing MSE spec, and if you want to add emsg box parsing, look at what you'd need to write? Matt could comment on it. Rather than write in our language then have to translate to MSE spec later 16:39:09 Chris: I agree, so we'd produce something like a patch spec against MSE 16:40:04 Topic: Capability detection 16:48:38 Andy: Do these changes apply to smartphone and laptops equally? Is the scope all experiences across all devices? 16:51:07 Chris: I think we'd want to be the same across devices 16:52:17 Rob: There'll be new data formats coming along, so just expose that and allow web apps to decide. If it needs to be parsed and structured, for emg, expose the binary but also have an indicator that the structured version is available 16:52:34 ... Otherwise how to get from parsing no data to parsing some data 16:55:28 ... What about messages that affect the player? That could be a reason for parsing in the UA? 16:56:40 Zack: There's context for handling the message. Complexity for type 1 players. Parsing underlying byte stream format vs parsing in app. Performing the ad insertion (for example) needs the app level state and context. It would be strange to push more of this requirement to the UA, and adds complexity 16:57:51 ... In smart TV and STBs, a model ships with a browser version that's fixed. We can handle by surfacing the raw payload 16:58:19 ... What's needed is to parse from the containing file format, and after that it's up to the application to figure out the message payload 17:01:13 Iraj: I agree. The only caveat is that the current design of emsg, is to allow Base 64, which the UA could decode, but the payload is still opaque. There's a flag in the message data whether it's base 64 or not. It's true for MPD events. emsg boxes are just binary 17:03:44 s/to the pull/... to the pull/ 17:04:02 s/changes to html/... changes to html/ 17:04:55 rrsagent, draft minutes v2 17:04:55 I have made the request to generate https://www.w3.org/2020/11/16-me-minutes.html cpn 17:05:11 rrsagent, make log public 17:06:16 i/Chris: Feedback/scribenick: JohnSim/ 17:06:20 rrsagent, draft minutes v2 17:06:20 I have made the request to generate https://www.w3.org/2020/11/16-me-minutes.html cpn 17:07:12 s/... We have general support/Rob: We have general support/ 17:07:14 rrsagent, draft minutes v2 17:07:14 I have made the request to generate https://www.w3.org/2020/11/16-me-minutes.html cpn 18:09:17 Karen has joined #me 18:15:06 Zakim has left #me 21:09:41 Karen has joined #me 21:46:05 Karen has joined #me 23:40:21 kaz has joined #me