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

[technogeek00]

Taking into the 4th edition now that we have directionality for DASH, updated information from December analysis will be posted here shortly.

[technogeek00]

DASH Alternate MPD Updates

Top Line Notes

• No significant changes from the List MPD and Linked Period Resolution Behavior
• Significant refactoring of the Alternative MPD behavior

Alternative MPD Behavior

• Introduction of Event@status attribute and combination with Alternative MPD to replace "return" events
• Modes replaced with explicit event types
  • Alternative MPD Insertion
  • Alternative MPD Replacement
  • Note: New types are baselined from the same Alternative MPD Type and then set behavior and potential attribute extensions
• Simplification of definitions based on feedback provided, no material change in function

Alternative MPD Event Types

• Baseline scheme information shared across
  • Dispatch Mode: "on-receive"
  • Not permitted for use in-band
  • EventStream objects at Period level
  • Alternative MPD linked to can be standard or List MPD
  • Common AlternativeMPD Type defined as a baseline for contained elements
• Alternative MPD Insertion Event
  • Scheme: urn:mpeg:dash:event:alternativeMPD:insert:2025
  • InsertMPD element contained within Event Element
• Alternative MPD Replacement Event
  • Scheme: urn:mpeg:dash:event:alternativeMPD:replace:2025
  • ReplaceMPD element contained within Event element

Common Alternative MPD Properties

Attribute	Description	Change Notes from last draft
@url	The URL the alternative media presentation can be found at	Now URL instead of URI
@earliestResolutionTimeOffset	The earliest time in seconds prior to the Event presentation time when the alternative media presentation can be downloaded, defaults to 60 seconds	None
@serviceDescriptionId	The ServiceDescription@id applicable to this event and all initiated alternate MPDs	New note that EventRestrictions concept introduced in Annex K 4.2.8
@maxDuration	The maximum time an alternative presentation can play for, when not defined implies unconstrained, effect on delayed activations controlled by @clip on ReplaceMPD element	Renamed from @clipDuration

Alternative MPD Insertion Event

• No additional properties defined outside the common ones for the InsertMPD element
• This insertion mode will always leave and return at the same point within the original presentation
• This mode is only allowed in static MPDs

Alternative MPD Replacement Event

• Additional attributes defined for the ReplaceMPD element

Attribute	Description	Change Notes from last draft
@returnOffset	A non-negative time offset from Event@presentationTime in units of EventStream@timescale where playback int he current media presentation will resume	Replaces @maxReturnOFfset and separates from @clipDuration to clearly influence resumption point independent of Alternate MPD length
@clip	Whether or not to clip the Alternative MPD in the case of a late execution start of the replacement (seek to or join mid-event case)	Allows for overrun from desired return offset or force return at expected offset point
@startAtPlayhead	Default false, indicating the Alternative MPD starts at the beginning. When true , indicates the Alternative MPD playback begins at the time delta between the Event start and Event execution	Allows for time aligned replacement independent of when the alternative MPD is evaluated. Note: Live Alternative MPDs always start from the live head

• The case of "replace+listen" is eliminated by use of Event@status
  • Event@status="update" indicates an update to a previous @schemeIdUri/@value/@id defined event, note that this event replaces the original because @id can only exist once
  • Alternative Replacement MPD event stream is always "listening" for new events which can introduce duration changes via "update" events.

Further Thoughts / Questions

• The separation of InsertMPD and ReplaceMPD seems a little unnecessary
  • InsertMPD has equivalent semantics to ReplaceMPD where @returnOffset=0
• The Event@status="update" effectively brings parity to the Date Range ability to update information across updates
  • However, there is a misconception that the HLS specification allows updates to all information
  • Specifically in HLS you may introduce additional attributes to existing Date Range tags by specifying the same ID/CLASS pair, but you may not update or change any previously announced attributes
  • This restriction can be applied into the DASH space with scheme level restrictions

DASH/HLS Interop Wise

• Specifications now have direct parallels
  • Alternate MPD Event Schemes <=> Interstitial Date Range Scheme
  • List MPD <=> Asset List
• For broader ecosystem concerns
  • The decisioning response can be easily captured in the List MPD including event streams containing pertinent metadata
  • The main content and the alternate content MPDs remain user-shareable if desired with the List MPD being the unique response
• DASH functionality has extended behavior not captured in HLS
  • Ability to provide a live stream as an alternate presentation
  • Ability to nest presentations
  • Earliest resolution time period explicitly captured, though HLS preload proposal closes this gap
• DASH functionality can now be parity to HLS in most regards
  • The delta between InsertMPD / ReplaceMPD doesn't materially impact interoperability
  • Either the cross-conversion is smart enough to bind differently or ReplaceMPD is only used with the appropriate restrictions for equivalent behavior

Scoring Update

Question	Answer	Points
Does the feature relate to an industry streaming use-case?	Yes, No	Yes, Ad Insertion
- What is the commonality of this use-case?	Very Common	2
- Is this an established or emerging practice?	Emerging	2
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	1
- What is the maturity of implementation support for both specifications?	HLS - Mature, DASH - Immature	1
- Are there known interoperability issues in both specifications?	Yes	2
- Has anyone implemented an interoperable solution for this?	No	0
- Is the feature missing in a specification with open proposals for it?	Yes - DASH	1
Has the industry defined de-facto mechanisms not present in both DASH and/or HLS?	No	-
- Why was the functionality defined outside of the main specifications?	N/A	0
- Has the functionality been standardized elsewhere? (DASH-IF, CTA, SVA, etc)	N/A	0
- Is the functionality proprietary or openly developed?	N/A	0
- Could the functionality be incorporated into specifications with evangelism?	N/A	0
	Total Score	9