DASH event message box equivalency

[chrisn]

DASH emg events may be repeated between media segments, to ensure visibility.

Two emsg events are considered equivalent if their scheme_id_uri, value, and id fields are identical.

• Do we expect the UA to discard repeated equivalent events?
• If so, we need to define the equivalency rules in the (to be written) emsg box processing algorithm.
• If so, what is the lifetime of this equivalency?

See discussion from 15/03/2021

[chrisn]

Discussed 17/5/2021 minutes.

In the DASH event processing mode, discarding repeated equivalent events is an optimisation.

In a TextTrack based API for emsg events, we would expect the browser to avoid the browser creating duplicate DataCue instances for repeated equivalent events. Cues are equivalent if they have the same scheme_id_uri, value, and id values.

[nigelmegitt]

Cues are equivalent if they have the same scheme_id_uri, value, and id values.

I understood this differently, from the conversation yesterday: I thought I'd learned that there can only be one cue with those three values active at any moment, but there can be multiple cues with those three values in the same Text Track, but with different payloads. I came to this conclusion because the expected behaviour when there's a rewind event is that the state generated in the client at the new playhead position is what it would have been when playing through that moment first time around.

For example:

Time T_n: emsg arrives with a specific combination of (scheme_id_uri, value, id) and payload payload_n.

• Create a new Text Track Cue whose data include (scheme_id_uri, value, id) and payload_n, with begin time set to the emsg's arrival time emsg_n_begin. Do not set an end time.

Time T_n+1: emsg arrives with the same combination of (scheme_id_uri, value, id) and a different payload, payload_n+1.

• Find the last Text Track Cue with (scheme_id_uri, value, id) ordered by begin time (it should have no end time) and set its end time to this emsg's arrival time emsg_n+1_begin.
• Create a new Text Track Cue whose data include (scheme_id_uri, value, id) and payload_n+1, with begin time set to emsg_n+1_begin. Do not set an end time.

Repeat the second procedure for all subsequent emsg arrivals with the same combination of (scheme_id_uri, value, id).

The example in the call was one where the contents of the emsg were used to present some user-facing message that can change over time, and I thought I heard @irajs say that on a rewind event the same user-facing message should appear as it would have done on first play-through, even if a later emsg had arrived.

There are two different domains here, and the language from one needs some translation into the other. The phrasing that I found interesting was to do with how the client "depatches" emsg events. The conclusion I thought @irajs and I had agreed on was that this is equivalent to the creation of a Text Track Cue; then Time Marches On causes the handlers to run on entry and exit.

Clearly from a requirements perspective, we need to confirm which model is right.

[chrisn]

I suggest that we take the document that @irajs provided in #30 and adjust it to the HTML TextTrack and MSE terminology and use that to document the proposed dispatch model.

My own understanding of dispatching an event (per the document) is that it is dependent on the dispatch mode:

• For on-start dispatch mode, dispatching an event is equivalent to the prepare an event steps - i.e, the browser notifies the web application that the cue has started/ended.

• For on-receive dispatch mode, dispatching an event means the browser creates the TextTrackCue instance, and then notifies the web application that the cue has been created. There's no mechanism for the latter today in HTML as far as I know. The explainer talks about adding an addcue event for this purpose.

Perhaps @irajs can confirm, and also help clarify the equivalency rules in the examples in @nigelmegitt's comment.