Server Guided Ad Insertion Mechanisms

[technogeek00]

Use Case Description

Utilizing manifest provided mechanisms to introduce alternative content that is either inserted into the main presentation experience or replaces a portion of the main content in the presentation experience.

Working Notes

• Potential alignment mechanisms are DASH Remote Resolutions and HLS Interstitials
• Ground work for SGAI compatibility between formats, important for advertising use cases

Open Questions

• Does DASH have a mature technology recommendation or is this still too early a topic under consideration? Xlink vs alts
• What media constraints exist due to this late-bound nature?
• Is there any forward signaling available in either format of potential differences in late-bound assets?

[technogeek00]

Question	Answer
Does the feature relate to an industry streaming use-case?	Yes, Ad Insertion
- What is the commonality of this case?	Uncommon
- Is this an established or emerging practice?	Emerging
Does this feature have related mechanisms in both DASH and HLS?	Yes
- What is the maturity of support in both specifications?	HLS - Immature , DASH - Immature
- What is the maturity of implementation support for both specifications?	HLS - Immature, DASH - Immature
- Are there known interoperability issues between specs?	Yes, DASH has multiple possible technologies
- Has anyone implemented this interoperably?	No
- Are there features missing in a specification with open proposals for it?	Unknown, needs investigation
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

[technogeek00]

Update 3/13/2024

• DASH potential technologies have aligned to XLink and Alternative MPD
  • XLink still requires MPEG DASH to provide semantic definitions but is being explored by ATSC 3.0
  • Alternative MPD is new in the 6th edition and could provide better direct interoperability with HLS but is underspecified in its initial form
• Alternative MPD specific notes
  • Specified for both manifest and media level (emsg) inclusion
  • Media level inclusion would not be considered for inclusion
  • Manifest level inclusion is convoluted by the usage of schemeIdValue and value as the behavior holders, this results in multiple EventStream objects being required for complex use cases like early cut back in live dai

Based on this and the creation of HLS Interstitials since the initial creation the updated questionaire results in a composite score of: 8 vs the original 3

Question	Answer
Does the feature relate to an industry streaming use-case?	Yes, Ad Insertion
- What is the commonality of this case?	Common
- Is this an established or emerging practice?	Emerging
Does this feature have related mechanisms in both DASH and HLS?	Yes
- What is the maturity of support in both specifications?	HLS - Mature , DASH - Immature
- What is the maturity of implementation support for both specifications?	HLS - Immature, DASH - Immature
- Are there known interoperability issues between specs?	Yes, DASH has multiple possible technologies
- Has anyone implemented this interoperably?	Potentially
- Are there features missing in a specification with open proposals for it?	Unknown, needs investigation
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

[ZmGorynych]

Alternative MPD is new in the 6th edition and could provide better direct interoperability with HLS but is underspecified in its initial form

What is missing / underspecified? I would be glad to help fixing it.

[technogeek00]

Done a more in-depth comparison of HLS Interstitials and DASH Alternate MPD full notes here

DASH Alternate MPD

Basics

• Basic event scheme for controlling switch to alternate content from main content timeline and potential early returns in live
  • Scheme is "urn:mpeg:dash:event:alternativeMPD:2022"
  • Scheme derives values from pairings of the scheme id uri and value specifications per event
  • The alternate content to insert is an MPD url carried as the message data in the event
• Carriage as either in-band emsg in segments or in MPD with EventStream objects
  • The paired usage of scheme id uri and value pair translate to multiple EventStream objects at the MPD level, this is being looked at in editorial for simplification

Behavior Functions

• Events are processed with on-receive semantics by the event model within the DASH player
• An event of value "insert" indicates playout of alternate content from the signaled start time for the total duration of the alternate MPD and then returning to playback in the main MPD at the original exit time
• An event of value "replace" indicates playout of alternate content from the signaled start time for the total duration of the alternate MPD and then returning to playback in the main MPD at the original exit time + the duration of the played alternate content. (note if this eclipses the end of the main content the presentation simply ends)
• An event of 'replace+listen" works semantically similar to the "replace" mechanics, but allows for an explicit return point to be signaled by a "return" event which carries the same id as the original "replace+listen" event.
  • In this case the player is expected to continue polling on the main MPD if it is live, while this is not explicitly required in other event cases
  • While unspecified, this would seem to indicate consistent behavior in off-live head scenarios, i.e a "replace+listen" and "return" event pair in the time shift buffer window should still be treated as a capped replacement period.
  • An underfill alternate content case is always handled the same, returning to the original exit time plus the duration of played content

Other Notes

• Multiple levels of nesting are permitted, but behavior on cases such as nested "replace+listen" need further specification and/or restriction for practical implementation perspective (purely semantically they make sense)
• The start time of an event is the explicit switch point and there is no requirement made on the condition of the stream at the start point, but it is suggested to provide a conditioned segment boundary at the point for seamless transition
• The amount of time of forward resolution of the alternate MPD is not specified
• There are no constraints on codecs or bitrates between main and alternate mpds
• Behavior of multiple events at the same point in time or overlapping is not specified

HLS Interstitials

Basics

• Basic event scheme for controlling exit and return within the primary M3U8 timeline
  • Class is "com.apple.hls.interstitial"
  • The alternate content may be specified as a either:
  • a single M3U8 URI
  • a URI to a json object (Asset List) containing a sequence of M3U8s to play along with their duration
  • Carriage of the scheme is within the EXT-X-DATERANGE tags in the primary variant playlists
  • Due to carriage in EXT-X-DATERANGE event semantics can update through subsequent playlist updates as attributes are further specified for previously specified events

Behavior Functions

• Events are processed with on-start semantics within the HLS players
• Events declare the point in time that interstitials tart relative to the main M3U8 timeline
• Events may specify a resume offset
  • Setting to zero will cause point in time insertion
  • Setting to a duration will cause fixed window replacement not related to the duration of the interstitial
  • Not specifying indicates fixed window replacement equal to duration of the interstitial
• Events may also provide limits to the duration of the interstitial played out unrelated to the main m3u8 timeline
  • If specified it is the maximum amount of interstitial played
  • If unspecified the full interstitial must be played out
• Events may specify how declared start and resume times should be treated exact vs snap:
  • Exact makes no requirement of segment boundary conditioning but does require players to adhere to exact timing semantics
  • "Snap" allows the player to snap transitions to the nearest segment boundaries to ensure seamlesness irrespective of conditioning
  • Exact vs snap may be specified for the enter and exit of an interstitial separately
• Events may carry user interaction behavior restrictions such as:
  • Preventing seeking while in interstitials
  • Forcing playout of interstitials when seeking over

Other Notes

• Only one level of insertion is allowed, they cannot be nested
• Forward resolution time for an interstitial is suggested to be at the edge of client buffering need, but clients are expected to give resolution servers significant time (a minute) to respond
• No constraints on codecs or bitrates between main and alternate content
• Multiple events declared at the same time are to be treated as a sequence, but overlapping of semantic behavior when not point in time insertions is undefined

Scenario Comparison

Scenario	DASH Alternate MPD	HLS Interstitials
Basic point in time insertion and return to same point after full playout	Utilize event with "insert" value semantics	Event with resume offset of zero
Replacement of fixed window in vod or live with replacement duration equal to alternate content duration (non-live edge)	event with "replace" value semantics	Event with no resume offset or playout limit specification
Replacement of fixed window in vod or live with replacement duration un-equal to alternate content duration (non-live edge)	potentially possible with "replace+listen" and "return" pair but not clear how to specify alternate content duration restriction independent of main timeline restriction	Event with resume offset set to desired main content replacement duration and playout limit set to desired alternate content duration restriction
Replacement of unknown window duration (live edge)	Event paring sharing ids with "replace+listen" occurring at start point and "return" at the force cut back point	Event with no limit specifications in first tag definition and later additive tag with resume offset and playout limit introduction
Playout beginning in the middle of active replacement (live edge)	Case underspecified	Play from beginning of interstitial
Multiple insertions at a single time point	Not explicitly prevented, but behavior undefined. Likely to suggest single MPD with multiple periods or alternatively have DASH experts explore asset list type concept	Events are expected to be interpreted in sequence of declaration, but behavior if overlap of resume offset underspecified. Recommendation to use asset list json object with ordered set of media within instead