Dynamic Ad Insertion in Linear and VOD OTT Streams

by Martin Linderoth — Technical Product Owner and Architect

Background

Ad Insertion provides possibilities to better show relevant ads to the users. Relevant can be in the sense that the user sees something he or she is interested in but also something that is up to date. When watching pattern shifts from linear towards catchup it makes sense to choose the ads based on the time at playback rather when when the program was aired in the linear stream.

Historically, the reporting of ad impressions in the broadcasting universe has at its best been an educated guess. The nature of unicast streaming address this issue and enables more granular reporting. With this granular reporting, it is knowned when a particular ad has been served the number of times it has been paid for and when another ad can be in served instead. This leads to that a larger set of ads can be sold.

Goals

The architectural goals is to find a solution that:

• Support personalized ad insertion for VOD and linear streams.
• Support ad insertion for HLS and MPEG-DASH streaming formats
• Solution should be extendable with new client platforms
• Importance of separation of concerns — The ad insertion functionality should be an extesion of the existing streaming functionality making it possible to enable functionality to a limited user group, disable it when the system is under big load or when there are issues with the 3rd party systems
• Solution should be extendable with new broadcasters or ad servers
• Give the user a seamless experience similar to when ads are being served in the original stream.

Solution

Ad insertion can be done in two different ways; client side or server side. As the name suggests the difference is if the client or server that is responsible for incorporate the ads in the media playback. Client sided ad insertion may be suitable for VOD usage. Doing this for a linear stream however, is far more complex and error prone. With Server Side Ad Insertion the ads are being added or replaced on the server side. Given our goals the choice to go with server sided Ad Insertion was pretty straight forward.

The system contains a lot of components and inline with the goals listed above we wanted to keep the ad insertion functionality separated. To the left in the image below, we have a wide range of different clients. For example Comhem Play mobile app for iOS and Android. These clients consumes different streaming formats and DRMs so the solution needs to be agnostic to that. These clients communication over the internet with the backend components.

The blue box depicts the components that is used independent of ad insertion. There’s a streaming backend built with encoders and JIT packagers that converts a multicast transport stream to HLS and DASH output. In front of this sub system, there is a CDN in place so the system can scale with the amount of user.

The green box contains the services that inserts the ads in the streams. This is outside of our core business so we have teamed up with the company Yospace that does this for ur. The yellow box contains the services used for reporting.

System overview

This separation gives us the possiblity to replace a vendor, create our own ad server or improve redundancy. The ad insertion solution contains many moving parts. One of the biggest challenge is to fulfill the ask from the content providers and yet provide a good user experience to the end user. The users are accustomed with streaming services that provides a smooth and stable playback of media. Replacing ads must not affect the ability to supply a seamless service.

Linear

For linear streams, the Ad Insertion is in reality a replacement of ads rather than an insertion. The replacement requires information about the position and duration of an ad break in the original stream. To achieve this, the encoder and packager transforms SCTE-35 signals in the streams to tags in the HLS playlist and create multi period manifest for DASH. The system can based on these markers make request to the Ad Server to get a list of ads to serve for a particular user. The Ad Server returns this information using VAST specification.

Here is an example of some simplified VAST data that specifies an ad clip that is 30 seconds long. It also has a list of tracking urls that should be used for tracking; for example when the first quartile of the ad has been played out the clients makes a request to the end point that corresponds to the firstQuartile event.

<VAST version="2.0">
<Ad>
<Error>http://myErrorURL/error</Error>
<Impression>http://myTrackingURL/impression</Impression>
<Creatives>
   <Linear>
     <Duration>00:00:30</Duration>
     <TrackingEvents>
       <Tracking event="creativeView">http://myTrackingURL/creativeView</Tracking>
       <Tracking event="start">http://myTrackingURL/start</Tracking
       <Tracking event="midpoint">http://myTrackingURL/midpoint</Tracking>
       <Tracking event="firstQuartile">http://myTrackingURL/firstQuartile</Tracking
      <Tracking event="thirdQuartile">http://myTrackingURL/thirdQuartile</Tracking
      <Tracking event="complete">http://myTrackingURL/complete</Tracking>
      </TrackingEvents>
      <MediaFiles>...</MediaFiles>
   </Linear>
</Creatives>
</Ad>
</VAST>

To get a seamless experience the total duration of the ads in the VAST response needs to match the duration of the ad break. There are possibilities to fill smaller gaps with filler clips.

It’s also important that the ads are encoded with the same encoding parameters as the original stream to avoid playback interruptions or difference in sound level etc. To achieve this, the ad clips referenced in the VAST response is downloaded from the Broadcaster and transcoded to match the profiles being used in the linear stream. The transcoded clips are hosted on the CDN and will be served to all clients that will play that particular ad. The ad replacement is done according to the steaming standards so it is transparent for the media player on the client. However, to carry out proper reporting the client application needs to know when an ad starts and ends. The client application subscribes to events from the media player and compare this with markers in the stream and VAST data that defines which ad that is served at a given moment. The reporting is typically sent to the Broadcaster but also to an independent measurement services like MMS.

Video On Demand

For VOD, like movies or catchup, the Ad Insertion is done a bit differently. The Broadcaster provides ad free assets that are ingested into our system. At the time of playback, the client requests a manifest from Yospace which in turn queries the Ad Server about where and which ads to insert. This data is specified using the VMAP specification. The following VMAP data is an example that specifies that pre-, mid- and post-roll ads are inserted in a VOD asset.

<vmap:VMAP xmlns:vmap=http://www.iab.net/videosuite/vmap" version=1.0">
  <vmap:AdBreak timeOffset=start breakType=linear breakId=preroll
    <vmap:AdSource id="preroll-ad" allowMultipleAds=false
      <vmap:AdTagURI templateType="vast3">
        VAST uri that specifies which ad to serve
      </vmap:AdTagURI> 
    </vmap:AdSource>
   </vmap:AdBreak>
  
  <vmap:AdBreak timeOffset=00:00:15.000" breakType=linear breakId="midroll-1">
    <vmap:AdSource id="midroll-ad" allowMultipleAds=false
      <vmap:AdTagURI templateType="vast3">
       VAST uri that specifies which ad to serve
      </vmap:AdTagURI> 
    </vmap:AdSource>
  </vmap:AdBreak>
  
  <vmap:AdBreak timeOffset=end breakType=linear breakId=postroll
    <vmap:AdSource id="postroll-ad" allowMultipleAds=false
      <vmap:AdTagURI templateType="vast3">
        VAST uri that specifies which ad to serve
      </vmap:AdTagURI> 
    </vmap:AdSource>
  </vmap:AdBreak> 
</vmap:VMAP>

The information in the VMAP response is used on the server side to create one playlist/manifest where ads and media segment are combined. This results in an asset that looks like the picture below, where the green parts as ads and the white parts are the VOD asset splited up in two.

VOD asset with pre-, mid- and post-roll

Since the position of the ad breaks is signaled out of band it is possible that the ad breaks are changed into fewer but longer compared to the ad breaks in the original stream. Similar to linear, the ad insertion is transparent for the media player and reporting is done the same way.

Summary

Looking back at the ad insertion efforts, the solution fulfils the goals we outlined. We have a solid base that could be extended with more client platforms, broadcasters and channels when needed. We have separated the sub systems that handles ad insertion both on client and server which provides flexibility to handle changes in the future.