W3C

– DRAFT –
Media Timed Events TF 17 May 2021

17 May 2021

Attendees

Present
Chris_Lorenzo, Chris_Needham, Gary_Katsevman, Greg_Freedman, Iraj_Sodagar, Kaz_Ashimura, Nigel_Megitt, Rob_Smith
Regrets
-
Chair
Chris
Scribe
cpn

Meeting minutes

TextTrackCue unbounded end time

Chris: Implementation status?

Rob: I've updated issue status to say the WebVTT and HTML changes have been made to allow unbounded end times, using +Infinity
… Ongoing discussion on if and how to support in the WebVTT file format
… Not seen any update on the browser implementations yet
… I've looked into how to contribute to Firefox myself. Having the web platform tests is useful
… Could follow with Philip on how to contribute to Chromium, hopefully someone at Google would do the implementation

Rob: I'll find out how to contribute

WebVTT unbound cues

Chris: Can we set a time for discussion?

Chris: Initially suggest Thursday at TTWG timeslot, alternate weeks
… Alternatively, Monday in this timeslot. But doesn't work for Gary
… Tuesday at 14:00 UTC, on weeks where there's no MEIG or Media WG meeting
… Third Tuesday, so 15th June at 14:00 UTC

DataCue API

Chris: Several parts: DataCue just carries timing and the data. No mapping to inband events
… In-band subscription API, subscribe by scheme id and allows you to set on-receive or on-start mode
… works with file-based and MSE based playback
… Where would the subscribe / unsubscribe methods sit?

Equivalency rules for emsg events

<kaz> WICG/datacue issue 28 - DASH event message box equivalency

Nigel: What data fields are there? If you rewind the playhead, what would be the expected behaviour?

Iraj: There's also event start time and duration. The reason for equivalency rule is that in many application use cases, a player may join at a given time, but hasn't seen the event
… So the content authors repeat the event multiple times in the stream
… If the event is placed multiple times, it's more efficient to dispatch one, not all to the application, as an optimisation
… If the application processes the event, its adequate if it receives the event more times, it has no impact on the interactivity, no additional information
… If you have event with those 3 values, the second one may not be dispatched. It should also have the same meaning to the application

Nigel: What's the expected behaviour if there's a rewind operation, e.g., to 1 hour before?

Iraj: The rule for equivalency, the client may choose not to dispatch. There's no rules for not dispatching, it's just an optimisation
… If you rewind and then playback, if it happens to have the same scheme id and value, it may choose not to dispatch it again
… There's no notion of order of applying the dispatching equivalency rule
… Equivalent means if the client acts on the event, it should have the same effect. You're not replacing the payload with another
… If the client shows a message on the screen, if the event is present multiple times it would have the same visual effect
… The idea is to use redundant events

Nigel: This suggests that the time marches on algorithm for text tracks applies in this case

Iraj: Events with the same scheme id uri, value are from the event stream
… Use id to check if the event has been dispatched already. Keep a list of ids already dispatched

Nigel: So dispatch means create a text track cue?
… So you create a cue object in a TextTrack with some begin and end time with payload
… The time marches on activates the cues.

Iraj: Yes, when the player time is within that time region, it shows those as active
… The UA could discard equivalent events, but not required. No hard rule for lifetime

Chris: We'd expect the browser not to create a duplicate in that case

Iraj: The second text track cue would be exactly the same as the previous one. The purpose of the id is to allow you to ignore the second one

Gary: This seems to map well to the unbounded cues API. Does emsg have an end time?

Iraj: It has two parameters: start time and duration. You can put a specific value to signify infinite duration
… Duration could be zero

Gary: If it's infinite duration, is the message active forever? For zero duration, is it active until next message?

Iraj: Zero duration means act on it, then done. Infinite duration means keep active forever

Gary: Is there a way to update the duration of an infinite duration message?

Iraj: There's no explicit way to say that one message is an update of another
… As part of the data payload, you can say it's an update. This is scheme owner specific.
… Or you can use equivalency rules, and put a specific duration on it. If the player gets the first message and not the second, it won't apply the update or change
… You should assume the UA won't receive all the history of changes of an event

Chris: So the payload must be designed so there's no dependency

Iraj: Exactly
… It's very important what you signal and what it means. Authors need to apply caution

Gary: I can see this maps easily to TextTrackCue. Zero duration is more complicated
… The way Safari handles it with ID3 cues, is that the cue is active until the next one comes in

Iraj: You can do that by making it scheme dependent

Gary: I'm thinking how you'd implement in the browser so that you don't lose it. There's a likelihood of missing it [using cuechange events
… Safari sets the duration to length of video, infinity. It then updates the end time when the next one comes in
… A new ID3 arriving means the previous one has finished

Iraj: I think we can build the same thing here, need to think about how to make it equivalent

Rob: This sounds very much like what we are talking about in WebVTT issue 496
… I'm interested in the zero duration cues. WebVMT does something similar, which is for stateful changes. It's a way of ending a cue
… If you have an infinite cue and you can update it with a zero duration cue that means "stop", and potentially then restart it later

Nigel: Regarding multiple text track cues with identical start/end times, the spec allows this
… Also where start and end time are identical. They're ordered by start time, then order of insertion

<nigel> Text Track Cue specification

Iraj: I recently wrote a document on the timing model for MSE, append, dispatch and purging process. We're discussing in DASH-IF and MPEG

Chris: I recommend adding to our issue tracker: https://github.com/WICG/datacue/issues

Next call

Chris: Next week, 24 May at 15:00 UTC

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC).