With the latest release of the Unified Streaming Platform, it becomes possible to do Dynamic Ad Insertion for Live. This new solution is based on industry practices and relies on SCTE 35 markers to signal advertisement opportunities, in combination with third-party ad services that insert the actual ads. For most existing setups that use Unified Origin for Live this solution will be straightforward to implement.
A big advantage of Dynamic Ad Insertion, or DAI, is that ads are not inserted on the client-side but by a third-party ad service that also serves the ads. This makes it more difficult for end-users to circumvent the ads. Another advantage of this setup is that is puts less requirements on the player that runs on the end-user device, because it no longer is responsible for requesting and inserting the ads. Any player that works in an ordinary video streaming setup should therefore also work when DAI is implemented. This makes it easier to deliver an ad supported streaming service to the widest possible audience.
To be clear, DAI differs from a true Server-Side Ad Insertion solution like Unified Remix VOD for Ads (interactive demo available here). The latter is more powerful and produces a single, continuous stream that contains the regular content as well as the inserted ads. This makes it near impossible to block the ads, because the ads and the regular content are all part of the exact same bitstream.
However, SSAI is not yet available for Live, thus making DAI all the more interesting. This blog post will explain more about this new solution for Live. It will detail the role of Origin for Live in a DAI workflow and offer insight into the SCTE 35 markers that enable this new feature.
Currently, DAI for Live works with YoSpace’s third party ad insertion service (live demo available here), with the expectation that support for additional service’s such as Google’s DoubleClick for Publishers and Amazon’s AWS Elemental MediaTailor will be added soon.
Powered by timed metadata
As mentioned already, DAI for Live relies on SCTE 35 markers to signal ad opportunities. SCTE 35 markers are well known and widely used in the digital broadcast industry. They are timed metadata, as they are used to mark and signal information related to a certain timestamp or time range in a stream.
A SCTE 35 marker that signals an ad insertion opportunity basically says: an ad can be inserted in the stream at this exact timestamp and if it is inserted it should have a duration of this many seconds.
Like other content, timed metadata is delivered to Origin as a separate track. When such a metadata track contains SCTE 35 markers and Unified Origin ingests them, Origin will translate the information they contain into signaling for the DASH and HLS client manifests.
In a DAI for Live workflow, the DASH and HLS client manifests that Origin generates are not served directly to the player on the end-user device. Although they could be used to play back the stream, advertisements have yet to be inserted. Based on the DASH or HLS client manifests generated by Origin, this is taken care of by a third-party ad insertion or content replacement service.
Such a service takes the DASH or HLS client manifest as input and manipulates it to insert the ads or other content at the point where Origin has added the relevant signaling. Only then is the manifest or playlist served to the end-user device, after which Origin will handle requests for audio and video segments from the original stream and the ad network will serve the media for the ad that was inserted.
Figure 1: SCTE 35-based Dynamic Ad Insertion workflow with a 3rd party ad insertion service and a CDN to cache and distribute the stream’s main content
Do note that this description is oversimplified as most setups would use a proxy server and a caching layer in front of the Origin and the third-party service to handle incoming requests, as well as one or more Content Delivery Networks (CDNs) to make delivery of the content as fast and efficient as possible.
Splice points
SCTE 35 markers can contain info about a program or other relevant data, but for this blog it is most important that they can cue splice points in a stream, thereby signaling the start or end of something (e.g., a program, or, more relevant for this blog, an opportunity to insert ads).
Technically speaking, a splice point is a specific timestamp in a stream that corresponds with an IDR frame (Instant Decoder Refresh). An IDR frame is a specific kind of video frame: the video data of an IDR frame and of the frames that follow it cannot rely on video data from the video frames that came before the IDR video frame. This means that the video data from one IDR frame to the next can be decoded independently.
In other words: a player can start playback at every IDR frame, without knowledge of the video data that came before. Therefore, if a stream is spliced at an IDR frame, a player will be able to play it back without problems. The fact that an earlier part of the stream is missing does not matter. This is important when an ad is inserted into a stream, because the transition to the advertisement has to be seamless and playback of the original stream should continue without artifacts after the ad has ended.
In normal circumstances, an encoder will only insert an IDR frame at the start of each media segment that it pushes to Origin. This does not allow for much flexibility when splicing, making it impossible to seamlessly insert an ad at a random point in the stream.
To solve this problem, the encoder that produces the livestream should add an additional IDR frame at each timestamp that is signaled by a cue in a SCTE 35 marker. Then, if the --splice_media option is enabled on the publishing point, Origin will frame accurately splice the stream at the exact timestamp that is signaled by the cue.
One part of the spliced media segment will remain an individual segment, while the other part will be merged with either the previous or the next segment, depending on the exact point at which the segment was spliced. The benefit of this approach is that it maximizes compatibility because no discontinuities are introduced and the total number of segments in the stream does not change.
Inserting ads
In addition to splicing the media segments, Origin will signal the splice points in the Apple HLS and MPEG-DASH client manifests. Third party service can then be used to insert a clip into the livestream at such a splice point. In a DAI for Live workflow, such a clip will contain one or more ads.
Splice points make replacing the part of the media stream that is marked as an ad insertion opportunity a relatively simple process. It only involves manipulation of the client manifest.
The third-party service replaces the URLs of the media segments that fall within the ad insertion opportunity with URLs of segments that represent the advertisements that replace the original content. No further changes to the media are necessary.
A player that is playing back the stream makes requests for subsequent segments that are signaled in a client manifest. When it arrives at a part of the stream where the original content is replaced by a third-party service, it will simply start requesting the segments that correspond with the URLs put in place by the third-party service.
When the ad break ends, the client manifest will again signal URLs to the original content, thus ensuring that the player will switch back to the original stream. Because Unified Origin prepared the original stream for this process by splicing it at the start and end of the ad break, switching to the advertisement and back again will work seamlessly.
Cue-out events in client manifests
To summarize the additional responsibilities of Unified Origin in a DAI of Live workflow:
- Ingesting SCTE 35 markers and signaling cue points in HLS and DASH client manifest (this functionality is enabled using the
--timed_metadataoption) - Splicing media segments to precondition the stream for content replacement (this functionality is enabled using the
--splice_mediaoption)
As the main workflow has been explained, as well as the logic behind the media segment splicing, we will now take a closer look at the way in which Origin signals SCTE 35 cue points in both a HLS and DASH client manifest.
For HLS, the events are signaled using the EXT-X-DATERANGE tag and a combination of the EXT-X-CUE-OUT and EXT-X-CUE-IN tags, while for DASH they are signaled in DASH Event Messages. The EXT-X-DATERANGE and EXT-X-CUE-OUT plus EXT-X-CUE-IN tags in HLS present different ways of signaling similar information.
By adding several types of tags in HLS, compatibility with a broader range of 3rd party services is ensured. Some of these services rely on the EXT-X-DATERANGE tag being present (e.g., Yospace), while others expect EXT-X-CUE-OUT and EXT-X-CUE-IN tags (e.g., Google DoubleClick for Publishers and AWS Elemental MediaTailor).
HLS signaling of SCTE 35 cue points
In addition to SCTE 35 messages being added to the media playlists using the EXT-X-DATERANGE and EXT-X-CUE-OUT plus EXT-X-CUE-IN tags, the break_duration() of a cue-out event is signaled both in the PLANNED-DURATION attribute of the EXT-X-DATERANGE tag and as the value of the EXT-X-CUE-OUT tag.
The duration of the SCTE 35 cue-out event in the example below is 60 seconds and the last media segment in this date range is spliced at exactly 4 seconds to create a list of media segments that match the duration of 60 seconds:
7 * 8 seconds + 1 * 4 seconds = 60 seconds
The 4 seconds after the splice are prepended to the next media segment, which results in the TARGETDURATION of the next media segment being 1.5 times the original TARGETDURATION (signaled right after each EXTINF tag in the example below):
#EXTINF:8, no desc scte35-audio=69000-video=100000-192087768.ts #EXT-X-CUE-IN #EXT-X-PROGRAM-DATE-TIME:2018-09-11T21:42:24Z #EXTINF:8, no desc scte35-audio=69000-video=100000-192087769.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087770.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087771.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087772.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087773.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087774.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087775.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087776.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087777.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087778.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087779.ts #EXTINF:8, no desc scte35-audio=69000-video=100000-192087780.ts #EXT-X-DATERANGE:ID="187",START-DATE="2018-09-11T21:44:00Z",PLANNED-DURATION=24,SCTE35-OUT=0xFC302100000000000000FFF01005000000BB7FEF7F7E0020F580000000000000532C8ACE #EXT-X-CUE-OUT:24 #EXT-X-PROGRAM-DATE-TIME:2018-09-11T21:44:00Z #EXTINF:8, no desc scte35-audio=69000-video=100000-192087781.ts
MPEG DASH signaling of SCTE 35 cue points
For DASH client manifests, Origin signals a cue-out event in the same ‘period’ as the main event. It does not create a new ‘period’ for each ad insertion opportunity. The advantage of this is that the presentation remains backwards compatible with any device previously capable of playing this stream (if the player on such a device silently ignores the presence of the EventStream element).
Different than for HLS, cue-out events are not signaled in the timeline of the media segments. Instead, the SCTE 35 markers are carried in DASH Event Messages. The @presentationTime is relative to the Period@Start, the @messageData contains a base64 encoded representation of the message_data field in the emsg.
<EventStream schemeIdUri="urn:scte:scte35:2013:bin" timescale="1"> <Event presentationTime="1525119000" duration="60" id="55" messageData="/DAhAAAAAAAAAP/wEAUAAAA3f+9/fgBSZcAAAAAAAAAmObEZ"/> </EventStream>
When a third-party service is used to insert content based on the cue-out events in the DASH client manifest that is generated by Origin, this service can create a multi-period presentation based on the original client manifest. When doing so, it should insert a new period both at the start and end time of the cue-out event. The second of the newly created periods will represent a return to the main event, while the first will represent the content that is inserted (e.g., an ad).
The timing information required for this can be calculated based on the timestamp in the EventStream element of the MPD, where the start of the event is represented by the @presentationTime and the end of the event equals the sum @presentationTime and @duration.
Take it for a spin
If this in-depth look at Dynamic Ad Insertion has left you wanting more, you can check out our demo to see a working example of the workflow with Yospace. Of course, you can also contact us to discuss any opportunities for implementing a DAI workflow in your own environment.
