Alternative MPD events and SGAI now accessible with DASH

What can I do with Alternative MPD events?

Good question, and the answer is – quite a lot!

Ad insertion and ad replacement

For starters, there are two switching types: insert and replace.

‘Insertion’ events are straightforward and mainly target VOD. If a user watches a movie and it’s time for an ad: the movie pauses, let’s say a 30-second ad pod plays from an alternative MPD, then the movie resumes where it paused. If you’ve used CSAI and experienced rough ad transitions like stalls, buffering, or popping then it’s possible to achieve smoother QoE here with SGAI. The reason for this is that the triggers sit on the media timeline and can be precisely aligned with segment boundaries and the structure of the main media content. At the same time, a distribution pipeline can (and probably should) align the encoding and packaging of the ad content with the main content. This means that the client won’t receive arbitrary MP4 files but instead can reuse and leverage existing playback infrastructure to create a smooth user experience.

‘Replacement’ events are much more powerful by supporting live/linear use cases, ad replacement, and blackouts. 

For example: During an OTT live sports stream, a national ad break begins. Instead of using the main feed’s ad, the player switches to a personalized ad MPD for that viewer. The main stream remains available and when the break ends, the player smoothly switches back at the right time, at a valid/expected playback position, and without losing control of the live session. For live content, that usually means returning near the current live edge. For pre-recorded or time-shifted content, it may mean returning at a specific signaled point. This also helps avoid awkward playback resumes such as returning to an expired time-shift buffer position or the middle of a segment where decoding can’t start smoothly.

A nice benefit of this is unlocking additional monetizable inventory for OTT replay content by applying dynamic ad insertion (DAI) to previously aired broadcasts that still attract viewers. Ad pods can also have longer (or shorter) durations than the original ad break for further monetization opportunities. For example: an original 30 second break can be replaced with a 60 second targeted nonlinear ad pod, with the player returning to a point in the main stream that preserves playing valuable program content.

A central element to replacement events is they’re updatable: when an ad (alternative MPD) plays, the main content player keeps control in a background ‘listen mode’ by monitoring for potential MPD updates and lets the player behave dynamically. This lets you do things like:

• Differentiate events that are close to the live edge (where you must match defined ad break lengths) 
• Differentiate events elsewhere in a DVR window (where you can run longer ads than original break lengths)
• Respond to return-to-network signals

Return-to-network control

You can have a background MPD update cause the main broadcast to take back playback immediately instead of waiting for the ad to finish naturally.

This is useful in a number of situations, for example:

• A live sport broadcast cut to ads, but the game resumes earlier than expected
• A breaking-news live broadcast is needed for urgent presentation

You can also enable safe failure handling: if the alternative MPD is delayed, wrong, or no longer appropriate, the main presentation can recover.

And it’s easy to perform – all of this can be controlled through a single ‘maxDuration’ attribute in the MPD.

Manifest optimizations

With SSAI, a custom manifest is typically built per viewer that contains both main content and personalized ads. If a million viewers watch the same live event, the server must generate and send many manifest variations which contain much of the same information. 

A core aspect of SGAI is that the main content and ads are decoupled into separate manifests which can be optimized independently for scaling and per-viewer cost reduction. This is beneficial for both OTT and IPTV use-cases. The main content MPD only needs to be created once which avoids a significant amount of server-side manifest manipulation. That manifest is also potentially much smaller in size because ad placement opportunities simply need to reference alternative MPDs instead of being fully described – which saves bandwidth. Personalization is then isolated to the alternative MPD ad manifests which are both lightweight and only resolved when a viewer is about to see an ad. 

Plus, instead of every viewer asking an origin for a personalized manifest, the same main MPD can be reused through normal CDN caching – just like with CSAI. That matters for large-audience live events, where many clients may request the manifest at roughly the same time. 

DASH also now supports ‘List MPDs’ which essentially reference other MPDs, rather than directly describing the media itself. If a regular MPD is like a recipe, a List MPD is like a playlist where each item points to its own dedicated MPD. This opens optimizations by letting SGAI build multi-ad breaks without requiring the server to stitch everything into a custom alternative MPD manifest.

Let’s say a viewer will receive three targeted ads. A unique MPD fully describing all three would traditionally be constructed which creates work server-side. However, with a List MPD, per-ad MPD references are returned instead and the client composes them as a single ad pod. This helps keep server operations lean and scalable. Individual ad MPDs are also reusable across any number of ad pods. 

This approach works with VAST workflows: when the ad decision service (ADS) returns multiple ads, an SGAI endpoint can translate them into a List MPD.  Additionally, List MPDs can carry metadata for tracking, beaconing, max durations, and other ad-break management needs.

Prefetching for concurrency management

Prefetch times can be specified so client players can start fetching the alternative MPD and required resources in a way that spreads out requests during high-concurrency live events.

One example: A free ad-supported streaming TV (FAST) live event has millions of viewers. The MPD signals that an ad break is coming in 60 seconds. Clients can prefetch the alternative MPD and required ad segments at some randomized time beforehand to avoid a huge simultaneous request spike and reduce the chance of playback issues at the transition point.

Ad playback behavior control

There are a number of ad playback situations you have control over. 

• Delayed execution: What happens if a viewer arrives during an active ad break? It could be skipped, or the viewer could receive an entirely different targeted ad which fully fits the remaining break time (or the remaining portion could also be played if you have a use case for that).
• Repeated execution: What happens if a user viewed an ad and then rewinds past the same ad marker? You can choose if the event should be skipped, or if another ad request should be executed.
• No-jump / anti-seeking: Should a user seeking over an ad marker still trigger it? The player could skip the ad, or still execute the skipped event when playback resumes. If multiple ads are skipped with one jump, you can also decide if all of them should be played or only one.
• User-initiated skip: Should a user be able to skip a playing ad? You can allow the user to skip an active ad after a certain time with a button that resumes main content playback.

Nested alternatives

An alternative presentation can itself contain Alternative MPD events. Using regional sports blackouts as a use case: you could replace a football game with sports news or a different game, with that replacement content containing targeted ads during its own commercial breaks.

Stateless targeting

This is basically a way for the client player to add useful context to the Alternative MPD request using URL parameters, such as session ID, language, codec, bitrate, etc. With this approach an SGAI endpoint can choose relevant ads without having to maintain and remember a lot of per-viewer state information on the server. This matters because you may have millions of viewers hitting ad breaks at roughly the same time, so passing context in the URL makes the ad endpoint easier to scale, cache, and operate. It also means that you can keep both main and ad content manifests (and potentially even the List MPDs that serve ad pods) completely static and cacheable by your CDN.

IPTV opportunities

The SGAI approach can also open up other interesting use-cases. 

For example, replacement events can be used to enable dynamic targeted ads with live linear IPTV broadcasts. However, this requires hybrid IPTV and OTT playback like what’s offered with our PRESTOplay for Android player. You can detect the ad avail client-side (signaled with SCTE-35), trigger the ad request through SGAI/ADS integrations, and achieve seamless transitions between IPTV live programming and OTT-delivered ads.

Sounds great! How do I get started?

In general, to start using SGAI with DASH you’ll need to set up or modify a few components depending on your existing advertisement workflow.

Player client

Players are obviously a central component as SGAI shifts some responsibilities away from the server. With MPEG-DASH sixth edition, behavior is standardized across implemented video streaming players, so you’ll need one that supports DASH Alternative MPD event (and HLS Interstitial support if you also want to support HLS). 

💡 You should also ensure that your player can report SGAI-related ad events for analytics.

You can implement the player logic in-house, but it’s generally far easier to use a commercial player vendor. As we co-authored the SGAI paper mentioned above, it’s no surprise that we’ve been an early adopter with our PRESTOplay cross-platform players with a high degree of spec prototyping and testing for real-world deployment use cases. 🙂  

Discover our PRESTOplay cross-platform playback technology. 

Learn more

Packaging / origin sever

Your packager or origin server must generate a main DASH MPD manifest that specifies Alternative MPD events at the points where ads, replacement content, blackouts, or other alternatives should occur. This includes elements such as event timing, duration, prefetch window, return-to-network behavior, and whether the event is an insertion or replacement. 

In live stream workflows, your origin server may also need to generate MPD updates if you want it to act as a control channel for dynamic player instructions.

These are the steps needed to augment the main content manifest. However, in addition, your infrastructure should ensure that ad content delivered through an Alternative MPD event is compliant and compatible with the main content. In order to reach a wide set of target devices, the main and ad content should share at least the same codec and codec profile.

SGAI endpoint and ad decisioning

An SGAI endpoint is introduced into the workflow. The player requests alternative MPDs from this endpoint which handles the business logic and talks to the ADS for relevant ads. This is where the viewer URL parameter processing, ad selection, targeting, pod composition, and any VAST-to-SGAI translation activities live.

We’re friends with leading server component providers for smooth playback compatibility with our range of PRESTOplay players for connected TV, mobile, and web platforms.