Ads

Monetize your content by inserting ads into:

• Live Streams

  Ad insertions may take place:

  • Prior to Initial Playback: Use pre-roll ads to play ads before the viewer joins the live stream.
  • During Playback: Use mid-roll ads to play ads within a live stream. A player requests ads whenever an upcoming ad break is detected and our service stitches them into the live stream.

  • Live Events Only

    After Playback: Use post-roll ads to play ads after a live event.

• Video On-Demand (VOD)

  Upon initiating playback, our service determines the set of pre-roll, mid-roll, and post-roll ads that will be stitched into your on-demand content based off of your ad configuration.

Ads are stitched into your content to provide a seamless transition between your content and ads. Additionally, this prevents ad blockers from blocking your ads.

Ads are automatically upscaled to the highest quality rayA stream with a specific quality configuration based on set bit rate and resolution targets. Each ray is divided into slices. in your encoding profile. Our service upscales your ads without altering their frame rate.

How Does It Work?

The ad insertion workflow for live streams and VODVideo On-Demand (VOD) allows the playback of content that was previously encoded and stored within our system. One use for VOD is to allow viewers to stream your content at any time. is similar. The only difference between them is the timing for ad retrieval.

• Live Streams: Our service request ads whenever it detects an upcoming ad break.
• VOD: Our service requests ads for all ad breaks upon initiating playback.

Third-Party Ad Servers

Request ads from one or more of the following third-party ad servers:

• Verizon Media Ad Platform Video SSP
• Google Ad Manager
• Freewheel

Setup Overview

Perform the following steps to integrate a third-party ad server with live content, VOD, or both:

1. Create an ad configuration for the desired third-party ad server.

   How?

   1. Navigate to the Ad Server page.
   2. Click + Ad Config.
   3. In the Ad Config Name option, type the desired name for the ad configuration.
   4. From the Select Ad Server option, select the desired third-party ad server.
   5. Click Add.
   6. Fill out all required parameters (e.g., serverURL).
   7. Click Save.
2. Set up a slicer to add the desired ad breaks to your live content, VOD, or both.
3. Set up a third-party ad server to include ad-specific metadata as query string parameters of the playback URL.
4. Set up your media player to add pre-roll, mid-roll, and/or post-roll ads to your media via query string parameters in the playback URL.
5. Optional. Set up your media player to define how ad breaks will be handled via query string parameters in the playback URL.
6. Optional. Set up your media player to send verification data to an ad verification system via Open Measurement Interface Definition (OMID).
7. Apply a digital signature after the third-party ad server has added the desired query string parameters to the playback URL.

Ad break duration may be specified for an asset that is played back within a live stream. However, the length of an ad break for an asset that is played back as on-demand content is determined by the response from the ad decision server. As a result, you may not specify ad break duration for VOD and ad slate will not be inserted during playout. For example, if the ad decision server returns a 45.35 second ad response, then the duration of the ad break will be 45.35 seconds.

Ad-Specific Metadata

Query string parameter names vary by third-party ad server.

Metadata describing each ad should be included as query string parameters in the playback URL provided by the third-party ad server.

Example:

The following sample playback URL identifies an ad server configuration (i.e., VideoSSP) and a keyword (i.e., marketing).

Ad Breaks

A set of ads are requested prior to the start of an ad break. However, the total duration for those ads will rarely be an exact match to the ad break's duration. Ads that extend beyond the ad break's duration cause the viewer to fall further behind the live stream (i.e., latencyIndicates the delay between the capture of the source video and when it is displayed to the viewer.). For this reason, we provide the capability to determine how ad spots are handled when they exceed an ad break's duration.

Define the duration of an ad break when creating an ad pod or boundary.

The advantages and disadvantages for each method of handling ad breaks are shown below.

Method	Latency	Ad Fill	Ad Slate	Playback Drift	Flexible?Indicates whether you may adjust how long ad breaks may run over their scheduled duration before chopping or dropping ads.
Default Behavior	More	More	Less	More	No
Ad Chopping	Less	Less	Less	Less	Yes
Ad Dropping	Less	Less	More	Less	Yes

Default Behavior

By default, ads from the ad pool will be inserted into the ad break as long as the amount of time left in the ad break is greater than playback driftIndicates the amount of time that the live stream is behind the targeted latency. Configure artificial latency for each playback session via the delay parameter within the playback URL.. If playback drift exceeds the amount of time left in the ad break, all remaining ads will be dropped and the stream will cut back over to content.

Playback drift measures the amount of time that playback has fallen behind the targeted latency. Configure artificial latency for each playback session via the delay parameter.

Your ad.flex configuration increases the ad insertion window using the following formula:

If ad.flex has not been defined in your playback URL, then ads may be inserted for an additional 4 seconds beyond the requested ad break duration.

The timing for switching the stream back to content varies according to the quantity of ads served by the ad decision server.

• Ad Overfill: If the ad decision server returns too many ads, then ads will be inserted until the end of the adjusted ad break duration. This may introduce significant playback drift.
• Ad Fill: If the ad decision server returns an appropriate number of ads for the requested ad break duration and the last ad extends beyond the requested ad break duration, then the stream will switch over to content after the last ad.

• Ad Underfill: If the last ad ends before the end of the requested ad break duration, slate will be played until the end of the requested ad break duration.

  Slate may extend beyond an ad break by a few seconds.

Chopping and Dropping Ads

By default, an entire ad is played regardless of whether it exceeds an ad break's duration. Use the following query string parameters to override this behavior:

• ad.breakend: Use this parameter to prevent ads from exceeding an ad break's duration by either:

  • Chopping Ads: Upon reaching the end of the ad break, the current ad will be chopped, all remaining ads will be dropped, and the stream will switch over to content at the end of an ad break.

    An ad may extend slightly beyond an ad break.
    Learn more.

  • Dropping Ads: Ads that do not fit within an ad break will not be played and ad slate will be played until the end of the ad break.

    Slate may extend slightly beyond an ad break.
    Learn more.

• ad.flex: Use this parameter to define the number of seconds that an ad can extend beyond an ad break before being chopped or dropped.

Sample URL:

A digital signature should be applied to the above URL.

Ad Break Duration Calculation

As mentioned above, you may define the duration of each ad break via ad pods and boundaries. However, if you enable either the chopping or dropping of ads, then ad break duration will be automatically adjusted to account for playback drift using the following formula:

Prebid

Maximize content monetization by leveraging our PrebidAllows real-time bidding to occur before submitting a request for ads to an Ad Decision Server. service to ensure that ads that correspond to the highest value bids are served to your viewers. Prebid seamlessly inserts an additional step at the start of your ad workflow to ensure real-time biddingAllows advertisers to bid on ad supply in real time. (RTB) for your ad supplyIdentifies the opportunity to insert ads.. Your request for ads, along with these bids, are then submitted to the ad decision server. This allows an ad decision server to choose from:

• Direct ads: Identifies ads that were purchased in bulk through a prenegotiated deal. An ad decision server typically prioritizes direct ads over third-party ads (standard).

• Third-party ads (standard): Identifies ads generated by demand partners through real-time bidding (RTB) requested by an ad decision server.

  If an ad decision server prioritizes direct ads, then it will not initiate RTB. In turn, this prevents bids from advertisers without direct buys from being considered.

• Third-party ads (Prebid): Identifies ads generated by demand partners through real-time bidding (RTB) requested by our Prebid service. These bids are always submitted to the ad decision server.

Prebid grants more flexibility to your ad decision server by allowing it to choose from a wider variety of bids to determine the optimal set of creatives to fill your ad breaks. The benefits of using Prebid are:

• It maximizes content monetization by allowing bids from your demand partners to always be evaluated alongside direct ads.
• It increases viewer engagement and reduces ad fatigue by diversifying the set of ads served to your viewers.

To set up Prebid

1. Contact your account manager to activate the Prebid feature.

2. Set up a Prebid server.

   View Prebid documentation on how to set up a Prebid server.

3. Set up an adapter within your Prebid server for each desired demand partner.

   View Prebid documentation on how to set up an adapter.

4. Define a Prebid configuration for your Prebid server.

   1. Navigate to the Prebid Server page. How?From the main menu, navigate to Settings | Prebid Server.
   2. Click + Prebid Config.
   3. From the Prebid Config Name option, assign a name to this configuration.
   4. Click Create.

   5. Optional. From the podconfig.configid option, indicate the ID for the desired custom Prebid configuration.

      Contact your account manager if you would like to set up a custom Prebid configuration. Once configured, your account manager will provide its ID.

   6. From the URL option, type a URL that points to your Prebid server.

   7. Optional. Restrict bidding to ads that satisfy predefined criteria.

      1. From the pricegranularity.range.max option, define the maximum price for a bid in cents.

      2. From the pricegranularity.range.increment option, define how similarly priced bids will be grouped. Define the maximum number of cents by which bids in the same group may differ.

         Use a larger value to reduce the number of line items that you will need to define within your ad decision server to target bids.

      3. From the includebrandcategory.publisher option, indicate the ID assigned to your organization by Google Ad Manager.

         This option is required when using Google Ad Manager as your ad decision server.

   8. Click Save.

5. Add an ad.prbd query string parameter to the playback URL and set it to the name of the Prebid configuration, as defined in step 4.iii, that identifies your Prebid server and provides bidding instructions.

   ad.prbd=Prebid Config Name

   Example:

   ad.prbd=myPrebidServer
6. Create line items that target bids within your ad decision server.

Ad Verification

Ad verification is only supported when using VAST 3.x or 4.0.

Measure ad viewability by customizing your player to extract verification data from the manifest file and send it to an ad verification system via the Open Measurement Interface Definition (OMID).

Setup

Ad verification requires an Interactive Advertising Bureau account. If you do not currently have an account, please create one.

Setting up ad verification requires updating your player to:

1. Identify the type of ad verification data that will be inserted into the manifest file.
2. Extract ad verification data from the manifest file.
3. Send verification data to the ad verification system via OMID.

Steps 2 and 3 are outside the scope of this document. Please refer to the documentation provided by your ad verification system to learn how to provide ad verification data via OMID.

Ad Verification Data

Add ad verification data to the manifest by including one or more of the following query string parameter(s) in the playback URL:

Query String Parameter	Description
timedmeta.events.ads	Inserts tracking event data from the VAST response. This data is reported within an EXT-X-DATERANGE ad marker tag whose class/scheme identifier is urn:uplynk:ad-data:events. Example: timedmeta.events=complete,midpoint
timedmeta.extensions.ads	Inserts custom VAST extensions data. This data is reported within an EXT-X-DATERANGE ad marker tag whose class/scheme identifier is urn:uplynk:ad-data:data:extensions. Example: timedmeta.extensions=waterfall,geo
timedmeta.schemas.ads	Inserts ad viewability data. This data is reported within an EXT-X-DATERANGE ad marker tag whose class/scheme identifier is urn:uplynk:ad-data:omsdk. Example: timedmeta.schemas.ads=omsdk

Initiating a playback session with one of the above query string parameters will include the requested data from the ad node returned by the Preplay API within the manifest file. Information on how this data is inserted into the manifest file for HLS and DASH is provided below.

Test your ad verification workflow by passing staticomsdk=1 as a query string parameter in the playback URL for the desired live event or live channel. This parameter, which inserts a static JSON payload into the manifest, cannot be used to test the ad verification workflow for VOD content.

An ad marker tag (i.e., EXT-X-DATERANGE) will be inserted for each parameter defined in the playback URL. For example, if you specify both timedmeta.events.ads and timedmeta.extensions.ads, then two ad marker tags will be added to the manifest file.

Timed metadata does not currently return data that allows a player to signal their position in a stream. This means that players must still use data from the Ping API to signal their position in a stream.

HLS

Inserts a Base64-encoded JSON payload into the X-DATA attribute of the EXT-X-DATERANGE tag of an HLS manifest.

For each ad, the START-DATE attribute of the EXT-X-DATERANGE tag will have the same value as the corresponding EXT-X-PROGRAM-DATE-TIME tag. The specified timestamp doesn't reflect playback time. Instead, the first ad in a stream will be assigned a timestamp of 1970-01-01T00:00:00+00:00. Each subsequent ad will be assigned a value that takes place after the previous ad.

DASH

For each ad, an Event node will be inserted within an EventStream node in that ad's period within the DASH manifest. This Event node will contain the JSON payload as shown below.

In order to improve readability, a formatted version of the above sample JSON payload is provided below.

{
	"AdVerifications": [{
			"vendor": "iabtechlab.com-omid",
			"Verification": [{
					"browserOptional": "true",
					"apiFramework": "omid",
					"JavaScriptResource": "<![CDATA[https://s3-us-west-2.amazonaws.com/omsdk...https://s3-us-west-2.amazonaws.com/omsdk-files/compliance-js/omid-validation-verification-script-v1.js]]>"
				}, {
					"VerificationParameters": "<![CDATA[iabtechlab]]>"
				}
			]
		}
	],
	"adID": "90000035",
	"creative": "ed85dfa6e5b74442a2df7d8bfe15bed5",
	"creativeID": null
}