Meeting minutes
Intro
Slides: https://
<Johnsim> chris: Agenda page - four things to cover. First is from Text Track Queue endtime proposal
Chris: Feedback on joint meeting a few weeks ago - about emsg box support
chris: Text TrackCue end time - proposal to have an unbounded end time so you can signal a timed metadata event with ..
… changes to html
RobSmith: From what Chris said, pull request in repository based on discussion on Chris' slides, HTML discussion RF297 - links in that..
… to the pull request for the changes. preliminary review - Philip from Google kicks things along
Rob: We have general support from the browser vendors. Philip said there'd need to be a corresponding update to WebVTT, which inherits TextTrackCue
… I've raised a WebVTT PR, awaiting response
<Johnsim> RobSmith: inherits end time from extract queue - everything else is inherited. Waiting on response
<Johnsim> Gary: proposal is fine but have not had a chance to look yet
<RobSmith> WHATWG/HTML PR: https://
<RobSmith> WebVTT PR: https://
Chris: Rob isn't a TTWG member, so what to do about the IPR issues?
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
Chris: Only issue is Rob's IE status
Nigel: There should be a way though
Chris: We'll follow up on that
Feedback from TPAC meeting
Andy: Any concern with manifest serving?
Iraj: Need input from MSE editors? Would they be involved
Chris: We need to drive this topic, with editor input. I would want to go back with specific question
Iraj: Early input from them would really help
Zack: This is something I can help with, need to figure out timing
… Matt raised good questions on the MSE integration, good starting point to work from
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
Chris: I agree, so we'd produce something like a patch spec against MSE
Capability detection
Andy: Do these changes apply to smartphone and laptops equally? Is the scope all experiences across all devices?
Chris: I think we'd want to be the same across devices
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
… Otherwise how to get from parsing no data to parsing some data
… What about messages that affect the player? That could be a reason for parsing in the UA?
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
… In smart TV and STBs, a model ships with a browser version that's fixed. We can handle by surfacing the raw payload
… 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
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