emsg with unknown duration

[chrisn]

The DASH standard section 5.10.3.3.4 says:

event_duration provides the duration of the event in media presentation time. [...] The value 0xFFFF indicates an unknown duration.

The DASH-IF "DASH Player's Application Events and Timed Metadata Processing Models and APIs" document says:

When the duration of the event is unknown, the vairable duration shall be set to its maximum value (xFFFFFFFF = 4,294,967,295).

Using 0xFFFFFFFF as a sentinel value would make more sense to me, as duration is an unsigned 32-bit value, but which is correct? And is this consistent for all message schemes? (I notice SCTE214-3 uses 0xFFFF.)

[technogeek00]

I can't find my personal notes for the maximum value from the 2019 May F2F but there is a minor summary in https://github.com/Dash-Industry-Forum/Events/issues/15.

0xFFFFFFFF is the intended alignment due to the data type being defined as unsigned int(32) in the Event API, this does differ from the DASH standard, but better accommodates MPD sourced events. The expectation is that the entity processing the in-band emsg event recognizes 0xFFFF as the unknown value and translates it to the API matching 0xFFFFFFFF unknown value.

[chrisn]

There's a proposal from @rjksmith to change the HTML TextTrackCue endTime to allow unbounded cue durations.

The DataCue spec for DASH emsg events can use this to map an event_duration of either 0xFFFF or 0xFFFFFFFF to set the cue endTime to undefined (as both values are in use, per https://github.com/Dash-Industry-Forum/Events/issues/15).

Does this mean we'd need to spec logic that checks the scheme_id_uri and value fields, or can we simply map both values for all emsg events?

[technogeek00]

There should be no need for scheme_id_uri / value inspection, this is a general cross scheme mechanism that should work for all emsg events.

[chrisn]

Sounds good to me. So should we use both 0xFFFF and 0xFFFFFFFF as special case values meaning unbounded duration?