Chris Needham

This breaks down into two further questions: * How to detect capability for different means of carrying the event information, e.g, HLS playlist or media in-band DASH `emsg` events? *...

I don't think there's a need for capability detection for that case, as an implementation that can handle one `emsg` schema could equally handle any schema. In the context of...

Discussed on the [2020-09-21 call][1]. Some implementations don't support surfacing in-band cues ahead of time, and so such an `addcue` event could only be raised at the same time as...

The example code sets the `inBandMetadataTrackDispatchType` so that the TextTrack is scoped to include only SCTE-35 events. Other emsg boxes would be exposed through other TextTracks. This TextTrack per event-type...

I also prefer this, so I'm going to rework the examples to use a single metadata track (and add checks for the metadata type). I'm also thinking about simplifying the...

I have just published a change that fixes the inconsistencies, and changes the API to use a single text track per event type.

I'll close, having updated the explainer. Please take a look, and feel free to re-open if there's anything I've missed.

Looking at this a bit more, it seems to me that combining the `scheme_id_uri` and `value` into a single string for the `type` attribute (which I copied from the way...

Thanks. I'll update the explainer. For the emsg `id` field, the proposal we have is to expose this directly as `DataCue.id`, so we'd have something like: ``` DataCue.id // DOMString,...

Yes, this is true. The intention of the above is only to illustrate how emsg data can be exposed via DataCue. But this does raise a couple of questions: Should...