Sample code needs to check cue.scheme_id_uri

[swenkeratmicrosoft]

Sample code for: Subscribing to receive in-band timed metadata cues

https://github.com/WICG/datacue/blob/master/explainer.md#subscribing-to-receive-in-band-timed-metadata-cues

The code is assuming that the only possible payload is “SCTE-35 data”. It needs to check that cue.value.schemeIdUri == “https://aomedia.org/emsg/ID3” before calling parseSCTE35Data. Otherwise that code will totally blow up on any ‘emsg’ box with a different scheme id.

In addition, I note that there's some inconsistency in the tables/code related to "messageData" vs "data". The table with a first row of "DataCue field" | "emsg value" says:
"any value" | "Object containing data, schemeIdUri, and value (see below)"

The table below it says the value field is "messageData" (not "data") The code uses "cue.value.data".

So which is it, "messageData" or just "data" for the member of cue.value that represents message_data in the 'emsg' box?

-Sam Wenker (MSFT)

[chrisn]

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 model is based on how HbbTV implements DataCue (see HbbTV spec section 9.3.2.2).

This may not be ideal, as it can result in a large number of TextTracks being created. We could instead prefer to expose all event types through a single metadata TextTrack - in which case, you're right that code will need to check the schema.

(Note the related issue on TextTrack ids and inBandMetadataTrackDispatchType)

Indeed, there's a mismatch between the example code and the table. I prefer cue.value.data, so will adjust the table to match.

Many thanks for your input!

[eric-carlson]

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 model is based on how HbbTV implements DataCue (see HbbTV spec section 9.3.2.2).

This may not be ideal, as it can result in a large number of TextTracks being created. We could instead prefer to expose all event types through a single metadata TextTrack - in which case, you're right that code will need to check the schema.

I prefer a single metadata track, and this is how WebKit implements DataCue. The metadata "type" is signaled through DataCue.type

[chrisn]

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 way that emsg type/schema is conveyed. Following the WebKit API, we can use DataCue.type, so we could combine the emsg scheme_id_uri and value into a single string, or set type to the scheme_id_uri and put the value in the DataCue.value object.

[chrisn]

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

[chrisn]

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

[swenkeratmicrosoft]

Just one comment on this comparison:

cue.type === 'urn:scte:scte35:2013:bin'

Shouldn't that comparison include a space character and a value?

Or is that what this comment is referring to? // TODO: the emsg value contains the pid, add to cue.type here:

That would make it consistent with the other comparison.

cue.type === 'urn:mpeg:dash:event:callback:2015 1'

[chrisn]

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 HbbTV sets the inBandMetadataTrackDispatchType) won't work well in practice.

I don't know SCTE-35 in any detail, but SCTE214-3 (which describes use of SCTE-35 messages as DASH emsg events) says:

value shall be the value of the SCTE 35 PID". value may be used by the application to distinguish between cue messages from different PIDs.

How would a website know what the PIDs are? Input on this from anyone more familiar with the details of SCTE-35 is welcome!

Similarly, for ID3 messages, the Carriage of ID3 Timed Metadata in CMAF spec says:

value may either be an absolute or relative user-specified URI which defines the semantics of the id field. Any relative URI is considered to be relative to the scheme_id_uri.

Instead, what I'd propose is that, for DASH emsg events, we use the scheme_id_uri alone for the type attribute, and move the value field into the DataCue.value object.

[swenkeratmicrosoft]

That's a really good point. In fact, the base DASH spec (ISO 23009-1) simply defines id as follows.

"id: a field identifying this instance of the message. Messages with equivalent semantics shall have the same value, i.e. processing of any one event message box with the same id is sufficient."

That means that future 'emsg' boxes for a new URN "foo" could simply define 'id' to be "any value that's unique per 'emsg' for URN foo", i.e. an encoder might just do 'id' = rand() for each 'emsg' for URN foo.

So, I definitely agree with your proposal.

[chrisn]

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, emsg `id`
DataCue.value // object
DataCue.value.data // emsg `message_data` as ArrayBuffer (unparsed),
                   // or object | string | whatever (parsed)
DataCue.value.emsgValue // DOMString, emsg `value`

[eric-carlson]

DataCue.id // DOMString, emsg `id`
DataCue.value // object
DataCue.value.data // emsg `message_data` as ArrayBuffer (unparsed),
                   // or object | string | whatever (parsed)
DataCue.value.emsgValue // DOMString, emsg `value`

This spec isn't just about exposing emsg cues, so attribute names should be type-agnostic.

[chrisn]

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 the data structures we expose via DataCue be standardised? There are two general classes of events: events that are standardised and widely supported and where interoperability is needed (e.g., ID3, DASH player control events), and events that are vendor or application specific. For the widely supported events, I'd prefer to see the data structure exposed via DataCue defined somewhere.

If we do want to standardise the data structures, where to do it? I wrote some thoughts on this in the explainer here.