Carriage of Manifest Events

[technogeek00]

Use Case Description

Carriage of media timed events to end players through the authored manifests and playlists.

Working Notes

• In-band and Manifest layer events need separate description but fit well as the same interop case in Section 4 vs Section 5 of the spec.
• Previously also contained in-band in this ticket, now split to Carriage of In-Band Events #36

Open Questions

• Are there any conflicting statements on in-band event support between specifications?
• Can an HLS client operate on the DASH-IF Event timing model?

[technogeek00]

Manifest/Playlist Timed Metadata Events Based

Question	Answer
Does the feature relate to an industry streaming use-case?	Yes, Timed Metadata Events
- What is the commonality of this case?	Common
- Is this an established or emerging practice?	Established
Does this feature have related mechanisms in both DASH and HLS?	Yes
- What is the maturity of support in both specifications?	DASH - Mature, HLS - Mature
- What is the maturity of implementation support for both specifications?	DASH - Mature, HLS - Mature
- Are there known interoperability issues between specs?	Needs Discovery
- Has anyone implemented this interoperably?	Yes, for specific use-cases
- Are there features missing in a specification with open proposals for it?	Unknown
Has the industry defined defacto mechanisms not present in both DASH and/or HLS?	No
- Why was functionality defined outside of the main specifications?	N/A
- Has the functionality been standardized elsewhere (DASH-IF, CTA, SVA)?	N/A
- Is the functionality proprietary or openly developed?	N/A
- Could the functionality be incorporated into specifications with evangelism?	N/A

[nicoweilelemental]

In-Band Timed Metadata Events Based
The ID3/CMAF spec (https://aomediacodec.github.io/id3-emsg/) is in the AOM realm, not the HLS or DASH one. That would be great to integrate it into the core CMAF spec at MPEG, as this is a foundational mechanism.
The other main point of attention I see is the HLS playlist signaling: while we can tell the player which type of inband events is included in a given track, it's not possible in HLS. The common use cases we see in CMAF-based deployments are ID3 and KLV. Inband SCTE35 signaling, although implemented, is not a very popular feature as most of the ad insertion happens on the server side. Outside of ad insertion use cases, it's unlikely that other SCTE35 features like content chaptering would be implemented through inband signaling, as players need to get the information when a program is loaded initially, not during the playback session when loading a segment.

Manifest/Playlist Timed Metadata Events Based
It sounds like the main need for this section is to provide signaling examples. There is possibly an interesting convergence conversation to have on the key rotation early signaling topic, as it seems from the preliminary discussions that such a mechanism exists with Daterange for HLS, but there is no equivalent in DASH. The DASH-IF Content Protection taskforce would certainly be happy to look at this point, as it's an identified standardization need to provide a way to spread the DRM licenses requests over time.

[technogeek00]

Note that in-band moved to #36 relevant comment texts also copied

[technogeek00]

Working Notes 2022/01/25

DASH

Notes

• Main definitions in 5.10 Events (reference 4th edition)
• MPD Events (5.10.2) carried with the <Period> elements as <EventStream> structures
• EventStreams are differentiated by their @schemeIdUri and @value attributes. One combination of the pairs may only be used once in a single Period.
• Events are constrained to their containing Period, spanning Periods require re-declaration of the event in both Periods.
• Events are timed relative to the containing Period
• The usage of EventStreams and Events is described by individual scheme definitions.
• Individual events have no actual required attributes, but can specify a:
  • @presentationTime in the unit of the EventStream timescales
  • @duration duration of the event, unknown if not present
  • @id id scoped to the scheme definition, events with equal attributes and values must have the same @id value
  • Event data is contained within the Event element, the legacy attribute @messageData is discouraged

Open Questions

• Can a DASH event be added with manifest update without duration and a future update provide a duraiton? Or secondary instance with fixed duration?
  • Does not appear answered in the event model from 5th edition

HLS

Notes

• EXT-X-DATERANGE is the carriage mechanism for event data
• There is no signalling for event data in the multivariant playlist
• EXT-X-DATERANGE tags must be equally present across all primary media variants
  • Video if video is present, otherwise audio
  • Rendition groups (i.e. any EXT-X-MEDIA) should not have EXT-X-DATERANGE unless the stream typing matches the primary media type
• Grouped events are defined by equal CLASS attributes, but there is no structural grouping mechanism or requirement of a CLASS attribute
• Events timeline are tied to the complete variant timeline and are related to a required EXT-X-PROGRAM-DATE-TIME tag
• Event timelines are not effected by change of asset/discontinuity of media described by the variant
• Individual events must have:
  • an ID attribute that is unique to the event, events with equal IDs must have all present attributes equal
  • a START-DATE
• Events with an END-ON-NEXT=YES attribute
  • must have a CLASS attribute
  • must not contain a DURATION or END-DATE attribute
• Events with no DURATION, END-DATE, or END-ON-NEXT=YES attribute have no duration
• Events with DURATION and END-DATE must have START-DATE + DURATION == END-DATE
• Custom client attributes can be specified by X- tags
• An event with an existing ID can be added to a playlist to introduce new attributes while keeping the remaining consistent (or unspecified).
  • This means for time range representation you can use END-ON-NEXT functionality or always start a new range by specifying a duplicate Event with the finalized DURATION/END-DATE followed by a new Event
• There is no official event data attribute leaving each class/usage to define its own
• Location of EXT-X-DATERANGE does not matter, only the timing described

Open Questions

• Do EXT-X-DATERANGE relate to the closest declared EXT-X-PROGRAM-DATE-TIME tag? i.e. if a new one is dropped in the middle of the variant do only EXT-X-DATERANGE tags declared after it become effected?

Interoperability

Notes

• Requirement of @schemeIdUri/@value attributes in DASH will force usage of CLASS attribute in HLS
• Time specifications should be easily align-able with simple conversions between the date-time approach of HLS and timestamp approach of DASH
• HLS requirement of tag equivalency across all primary variants means that only one variant is needed in the cross conversion function for compliant media
• Ideally event streams are cross-converable without understanding of the scheme intentions, this should be possible but one open question on END-ON-NEXT=YES below.

Open Questions

• Is there an equivalent constraint on DASH events for END-ON-NEXT=YES or would it have to be a scheme specific functionality?
• There is nothing said about dispatch / access for HLS, has anyone performed a survey of player behavior?

[RufaelDev]

A lot of work is in progress on Events in DASH-IF Event TF , specifically related to authoring guidelines. MPEG-DASH including 5th edition leaves a lot of flexibility and optionality for usage of Event and EventStream attributes. What complicates more is the different schemeIdUri, scheme developers can have different recommendations on how the Event and EventStream attributes and values are used.

With regard to first question on DASH, as DASH client processing model does not dispatch duplicates, and the key is based on schemeIdUri, id and value, changing the duration is meaningless if it needs to be dispatched to a client. The behaviour you described about adding an event with duration 0 (no duration) and then with a fixed duration is not specifically restricted to be invalid, but I would not recommend it, or try restricing its usage in profiles like this. In MPEG-DASH amd 2 there was a proposal accepted to include an update mode overwriting a previous mode, however this is in early stage and not yet ready for hls/dash interop.

HLS EXT-X-DATERANGE END-DATE is optional, but it is often used in practice. Therefore for HLS-DASH interoperability I would recommend both DASH Events that do not change duration and for HLS DATE-RANGE to carry accurate END-DATE attribute. However we may still want to explore the use case of changing the duration further (it has some use cases).

For segment boundary alignment of events I would recommend including EXT-X-PROGRAM-DATE-TIME right after or before the EXT-X-DATERANGE to make sure that the date range aligns with the segment boundary (if that was intended) and allow the accuracy of the timing between both HLS daterange and DASH Event.

I think with regard to END-ON-NEXT I dont think something similar exists in DASH. Is this feature critical to be supported for interop ?

With regard to dispatch of HLS date-range, I dont think there is one defined, that would leave me to interpret the on-receive mode (which is also used for SCTE-35 events as defined in HLS), but more feedback from player vendors would be welcomed.

So a quick summary of what I would think makes sense:

• I would recommend fixed duration events and usage of END-DATE and EXT-X-PROGRAM-DATE-TIME right before or after the DATERANGE tag. Extending/shortening duration could be explored more if the use case is relevant.
• don't use END-ON-NEXT=YES
• CLASS attribute is still optional, as some schemes e.g. SCTE-35 are natively supported in HLS DATERANGE and no need to use CLASS, but it is good to document how this would be used for other schemes not natively supported so good idea to consider CLASS.

[technogeek00]

Additional Notes from 2022/01/26 Meeting

• Open Question 1 - DASH event duration addition / duplicate
  • It is not possible to specify an event duration in later update
  • Introducing a second copy of the event would have no net effect either
• Open Question 2 - EXT-X-DATERANGE time declaration
  • Miss-consideration at the time of research, the times are all absolute so the EXT-X-DATERANGE can still be specified anywhere and validly apply
  • A gap or overlap of time from EXT-X-PROGRAM-DATE-TIME tag declarations would cause problems only if the EXT-X-DATERANGE event was declared in that overlap/gap time, best to just avoid it
• Open Question 3 - DASH equivalent END-ON-NEXT=YES functionality
  • No there is no equivalent functionality
  • There is an open proposal to MPEG-DASH on adding an update functionality which would enable this
  • Semantically this may not be compatible with DASH Events as the END-ON-NEXT=YES functionality is implicitly capturing a detail of the CLASS scheme and the DASH Event is not intended to provide any scheme interpretation
• Open Question 4 - Access / timing model for HLS
  • Generally observed on-receive behavior for HLS players, but does not appear to have any official definition
  • Technically HLS interstitial functionality is an on-start behavior
  • Could likely align DASH-IF model if desired