12 Ad Insertion Enablers

26.2473GPPProgressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)Release 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS

12.1 Background

This section provides recommendations for implementing server-based ad insertion in DASH. In the server-based model, all ad-related information is expressed via MPD and segments, and ad decisions are triggered by client requests for MPDs and for resources described in them (Segments, remote periods).

The server-based model is inherently MPD-centric – all data needed to trigger ad decision is concentrated in the MPD. In case where ad break location (i.e., its start time) is unknown at the MPD generation time, it is necessary to rely on MPD update functionality.

12.2 Enablers

12.2.1 Period elements and Remote Periods

A single ad may be expressed as a single Period element.

Periods with content that is expected to be interrupted as a result of ad insertion should contain explicit start times (Period@start), rather than durations. This allows insertion of new periods without modifying the existing periods. If a period has media duration longer then the distance between the start of this period and the start of next period, use of start times implies that a client will start the playout of the next period at the time stated in the MPD, rather than after finishing the playout of the last segment.

An upcoming ad break is expressed as one or more Period elements. Remote periods may have default content that will be played in case dereferencing fails. After dereferencing MPD may contain zero-duration periods or/and remote Periods.

Remote Periods are resolved on demand into one or more than one Period elements. It is possible to embed parameters into the XLink URL of the corresponding remote period, in order to have them passed to the ad decision system via XLink resolver at resolution time.

The remote period may be resolved into a period with zero duration. Such a period element will not contain any Adaptation Sets.

In case of Period@xlink:actuate="onRequest", XLink resolution should be done sufficiently early to ensure that there are no artefacts due to insufficient time given to download the inserted content. Care needs to be taken so that the client is given a sufficient amount of time to dereference the upcoming remote period.

In case of Period@xlink:actuate="onRequest", MPD update and XLink resolution should be done sufficiently early to ensure that there are no artefacts due to insufficient time given to download the inserted content.

Period@xlink:actuate="onRequest" shall not be used if MPD@type ="dynamic"

12.2.2 Asset Identifiers

AssetIdentifier descriptors identify the asset to which a Period belongs. This can be used for implementation of client functionality that depends on distinguishing between ads and main content (e.g. progress bar). Periods with same AssetIdentifier should have identical Adaptation Sets, Initialization Segments and same DRM information (i.e., DRM systems, licenses). This allows reuse of at least some initialization data across periods of the same asset, and ensures seamless continuation of playback if inserted periods have zero duration. Period continuity may be signaled.

AssetIdentifier descriptor shall be used for distinguishing parts of the same asset within a multi-period MPD, hence it shall be used for main content.

In order to enable better tracking and reporting, unique IDs should be used for different assets.

In the absence of other asset identifier schemes, a 3GPP-defined scheme may be used with the value of @schemeIdUri set to "urn:org:pss:dash:asset-id:2015". If used, the value of @value attribute descriptor is unspecified. It shall be the same for all parts of an asset.

If a Period has one-off semantics (i.e., an asset is completely contained in a single period, and its continuation is not expected in the future), the author shall not use asset identifier on these assets.

Periods that do not contain non-remote Adaptation Set elements, as well as zero-length periods shall not contain the AssetIdentifier descriptor.

12.2.3 MPD updates

MPD updates are used to implement dynamic behavior. An updated MPD may have additional (possibly – remote) periods. Hence, MPD update should occur as close as possible to the moment the start time of the upcoming ad break is known. Ad breaks can also be canceled prior to their start, and such cancellation will also result in a newer MPD version (i.e., in a need for MPD update).

Frequent regular MPD updates are sufficient for implementing dynamic ad insertion. Unfortunately they create an overhead of unnecessary MPD traffic – ad breaks are rare events, while MPD updates need to be frequent enough if a cue message is expected to arrive only several seconds before the splice point. Use of HTTP conditional GET requests (i.e., allowing the server to respond with "304 Not Modified" if MPD is unchanged) is helpful in reducing this overhead, but asynchronous MPD updates avoid this overhead entirely.