Only available in Google Ad Manager 360.

MPEG-DASH integration (Beta)

Similar to HLS, Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH, is an adaptive bitrate video streaming standard that enables high quality streaming of video content over the internet. DASH provides support for Digital Right Management (DRM), which allows you to deliver premium streaming content with protections against unauthorized access or theft.

Ad Manager supports DASH for both video on demand and live linear streams, including the following features under the ISO standard:

  • ISO-BMFF On Demand profile and ISO-BMFF Live profile
  • Support for Widevine and Playready through MPEG-DASH Common Encryption (CENC)
  • Subtitle support for WebVTT and TTML (in-band and out-of-band in MPD)
  • Closed caption support with "CEA608/708"

Learn more about these features in the ISO DASH standard.

  Video on demand encoding

Media Presentation Description (MPD) requirements

  • HTTPS must be used for the entirety of the DASH content referenced in the same MPD.
  • The On Demand content MPD must be declared as type="static".
  • Each Period in the MPD must specify a duration attribute.
  • The On Demand profile must adhere to the ISO-BMFF On Demand profile of the DASH standard.

Media requirements

If you need to serve mid-roll ads in your content, the video segments must be pre-conditioned into multiple periods. Learn how to manage mid-roll ad insertion for DAI.

  Live linear encoding

Media Presentation Description (MPD) requirements

  • HTTPS must be used for the entirety of the DASH content referenced in the same MPD.
  • The Live content MPD must be declared as type="dynamic".
  • Each period in the MPD must specify a valid start attribute.
  • The Live profile must adhere to the ISO-BMFF Live profile of the DASH standard.
  • Addressing schemes are restricted to templates with number and time-based addressing.

MPD updates

  • New periods can be added to the MPD at the end.
  • Old periods from the top of the MPD can be removed.
  • Only the last period in the MPD can be updated. No other periods in the MPD should be modified.
    • Updates should only be for adding new segments to the last period.
    • Segments cannot be removed from the last period.

Media requirements

  • The ISO-BMFF Live profile must adhere to the segment format constraints of the DASH standard.
  • DASH content must follow all the rules specified in the Service Offering Requirements and Guidelines of the DASH-IF Interoperability Points.

Content requirements

The content should be pre-conditioned based on the following:

  • Media presentation must be broken into multiple periods with each mid-roll CUE-OUT and CUE-IN falling on a period boundary.
  • Content segments at the beginning and end of each period must be prepared so that every frame in the segment is included in the period.

    • Cue points must align with a keyframe/IDR frame and it must be at the beginning of the period. This may require ending periods with a short segment when the cue point does not fall on a natural boundary.

Ad break signaling

  • All content related to a single ad break, must be included in exactly one single period. That period must only contain the content segments to be replaced.
  • The ad break period must signal CUE-OUT based on the formats specified in these examples.

The duration of the ad break specified in the CUE-OUT event should be equal to the total duration of all the segments in the period, and can not be less than the actual duration of the period.

See examples

Ad break CUE-OUT indicators should be signaled in the MPD manifest via one of the following options:

Example 1

  • SCTE-35 EventStream elements
  • schemeIdUri="urn:scte:scte35:2014:xml+bin"
  • Defined in the DASH standard.

<MPD>

<Period start="PT0S" id="1">
   <!-- Content Period -->

   ...

</Period>

<Period start="PT32S" id="2">
    <!-- Ad Break Period -->
    <!-- The first segment of this period is the start of the ad break
    and the ad break ends with the last segment -->

    <EventStream timescale="90000"
    schemeIdUri="urn:scte:scte35:2014:xml+bin">

     <Event duration="2520000" id="1">
     <!-- The duration specified in this event should match the actual
     duration of the period as close as possible -->

       <Signal xmlns="urn:scte:scte35:2013:xml">
         <Binary>
           /DAlAAAAAAAAAP/wFAUAAAAEf+/+kybGyP4BSvaQAAEBAQAArky/3g==
         <Binary>
       </Signal>

      </Event>
    </EventStream> 
</Period>

<Period start="PT60S" id="3"> 
   <!-- Content Period -->

   ...

   </Period>

</MPD>

Example 2

  • SCTE-35 EventStream elements
  • schemeIdUri="urn:scte:scte35:2013:xml"
  • Defined in the DASH standard.

<MPD>

<Period start="PT0S" id="1">
   <!-- Content Period -->

   ...

</Period>

<Period start="PT32S" id="2">
    <!-- Ad Break Period -->
    <!-- The first segment of this period is the start of the ad break
    and the ad break ends with the last segment -->

   <EventStream timescale="90000"
   schemeIdUri="urn:scte:scte35:2013:xml">

     <Event duration="2520000" id="1">
     <!-- The duration specified in this event should match the actual
       duration of the period as close as possible -->

       <SpliceInfoSection xmlns="urn:scte:scte35:2013:xml">
          <SpliceInsert outOfNetworkIndicator="true" 
          spliceImmediateFlag="true">
            <BreakDuration autoReturn="true"
            duration="2520000"/>
            </SpliceInsert>
        </SpliceInfoSection>

      </Event>
    </EventStream> 
</Period>

<Period start="PT60S" id="3"> 
    <!-- Content Period -->

    ...

</Period>

</MPD>

Supported ad markers

SCTE35 XML Splice Insert

In DASH, CUE markups are accompanied by XML Period element boundaries. CUE markups are provided as Events within EventStream elements inside a Period. This additional boundary sufficiently functions to identify and the markup. Additionally, since ad breaks are marked by Period boundaries, an explicit CUE-IN marker is not required.

SCTE targeting data is not supported for this format.

This example shows an XML-based SCTE35 markup for DASH. This is similar to SCTE35 Binary Splice Insert, except that the data is parsed and presented as XML instead of binary.

<Period>

  <EventStream timescale="90000" schemeIdUri="urn:scte:scte35:2013:xml">

     <Event duration="2520000" id="1">

       <scte35:SpliceInfoSection>

          <scte35:SpliceInsert outOfNetworkIndicator="true" spliceImmediateFlag="true">

          <scte35:BreakDuration autoReturn="true" duration="2520000"/>

          </scte35:SpliceInsert>

        </scte35:SpliceInfoSection>

      </Event>

    </EventStream>

</Period>

See additional information and an example under ad break signaling.

SCTE35 Binary Splice Insert

In DASH, CUE markups are accompanied by XML Period element boundaries. CUE markups are provided as Events within EventStream elements inside a Period. This additional boundary sufficiently functions to identify the markup. Additionally, since ad breaks are marked by Period boundaries, an explicit CUE-IN marker is not required.

This example shows a binary SCTE35 markup for DASH.

<Period>

    <EventStream schemeIdUri="urn:scte:scte35:2014:xml+bin">

      <Event duration="2520000" id="1">

       <scte35:Signal>

         <scte35:Binary>

           /DAlAAAAAAAAAP/wFAUAAAAEf+/+kybGyP4BSvaQAAEBAQAArky/3g==

         </scte35:Binary>

       </scte35:Signal>

      </Event>

    </EventStream>

 ...

<Period>

See additional information and an example under ad break signaling.

SCTE35 Binary Time Signal: Provider Ad Start/End

SCTE-35 binary (base64 encoded) data has to be decoded and parsed in order to determine if it contains valid CUE-OUT/CUE-IN, along with any break targeting information.

For example, the following binary data contains a valid CUE-OUT signal:

#EXT-OATCLS-SCTE35:/DBcAAAAAAAAAP/wBQb//ciI8QBGAh1DVUVJXQk9EX+fAQ5FUDAxODAzODQwMDY2NiEEZAIZQ1VFSV0JPRF/3wABLit7AQVDMTQ2NDABAQEKQ1VFSQCAMTUwKnPhdcU=

Once decoded, the message contains the following fields:

  • splice_command_type set to a value of 6 indicates this is a time signal
  • segmentation_type_id indicates the type of time signal

The following segmentation_type_id value is recognized as a valid CUE-OUT time signal:

48 : Provider Advertisement Start

If the break duration is provided in both EXT-X-CUE-OUT:DURATION and SCTE segment_duration fields, DAI will use the value from EXT-X-CUE-OUT.

The following segmentation_type_id value (when splice_command_type = 6) is recognized as a valid CUE-IN time signal:

49 : Provider Advertisement End

SCTE35 Binary Time Signal: Provider Placement Opportunity

SCTE-35 binary (base64 encoded) data has to be decoded and parsed in order to determine if it contains valid CUE-OUT/CUE-IN, along with any break targeting information.

For example, the following binary data contains a valid CUE-OUT signal:

#EXT-OATCLS-SCTE35:/DBcAAAAAAAAAP/wBQb//ciI8QBGAh1DVUVJXQk9EX+fAQ5FUDAxODAzODQwMDY2NiEEZAIZQ1VFSV0JPRF/3wABLit7AQVDMTQ2NDABAQEKQ1VFSQCAMTUwKnPhdcU=

Once decoded, the message contains the following fields:

  • splice_command_type set to a value of 6 indicates this is a time signal
  • segmentation_type_id indicates the type of time signal

The following segmentation_type_id value is recognized as a valid CUE-OUT time signal:

52 : Provider Placement Opportunity Start

If the break duration is provided in both EXT-X-CUE-OUT:DURATION and SCTE segment_duration fields, DAI will use the value from EXT-X-CUE-OUT.

The following segmentation_type_id value (when splice_command_type = 6) is recognized as a valid CUE-IN time signal:

53 : Provider Placement Opportunity End

Macros for SCTE-35 markup

If your feed includes EXT-OATCLS-SCTE35 markup, the metadata is automatically extracted and made available through custom key-values. You need to set up the custom key-values, and insert them as macros when you generate ad tags.

When you set up the new custom key-values for the SCTE-35 fields, use a custom key (for example, "scte35") and set the value to the macro(s) that correspond to which type of field is available in your feed:

  • %%SPLICE_INSERT_EVENT_ID%%
  • %%SPLICE_INSERT_UPID%%
  • %%TIME_SIGNAL_EVENT_ID%%
  • %%TIME_SIGNAL_UPID%%
  • %%AFMM_CBC%%

The first three macros, which are unsigned integers in the SCTE35 message, are converted to strings as decimal numbers. %%TIME_SIGNAL_UPID%% is rendered as lowercase hexadecimal, with no 0x prefix. %%AFMM_CBC%% extracts the commercial break code from the splice info (required for the French AF2M specification).

Digital Right Management (DRM)

If DRM is enabled, the MPD must contain the <ContentProtection> element and follow the syntax defined in the DASH spec. Optimally, the PSSH (parallel-SSH) box content should be present in the manifest.

See an example

Widevine example

<ContentProtection
  schemeIdUri="urn:uuid:EDEF8BA9-79D6-4ACE-A3C8-27DCD51D21ED">
  <cenc:pssh>BASE64_PSSH</cenc:pssh>
</ContentProtection>

Supported platforms, packagers, and players

Platforms

Devices/browsers

Version

DRM

Chrome Browser

66+

Widevine

Firefox Browser

60+

Widevine

Microsoft Edge

18

PlayReady

Android

4.4+

Widevine

Chromecast

Gen2, Ultra (CAF API)

Widevine

Roku

3, 4 (firmware 8.1)

PlayReady

 

Packagers

Shaka

2.1.0

Multi-period Support

Bitmovin

1.47.3

Multi-period Support

Unified Streaming

Pending

 

Players

Shaka

2.4.2

Recommended for testing

Bitmovin

v7

 

Exo-Player

2.8.2

 

Dash.js

2.0

 
 

For any issues related to DAI troubleshooting or outages, contact publisher support.

Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue

Search
Clear search
Close search
Google apps
Main menu
Search Help Center
true
148
false