Dynamic Adaptive Streaming over HTTP (DASH)

Live stream ad break encoding (DASH)

bookmarkJump to: Manifest & content requirements | Packages, platforms, and players

Multi-period versus single-period manifests

Ad Manager supports ingesting both multi-period manifests and single-period manifests for DASH.

With single period manifests, publishers provide a DASH stream with a single period that contains all content and ad break opportunities, rather than multiple periods differentiating them. DAI supports single-period manifests by converting them to multi-period on every fetch.

You can select whether the manifest is provided as a single or multi-period when you set up a live stream in Google Ad Manager and select "DASH" as the streaming format.

The DASH manifest type selector in the Ad Manager interface.

Use this guide to see the expectations for multi-period manifests and single-period manifests. Additionally, if you are using a single-period manifest, the appendix demonstrates how DAI converts a single-period manifest to a multi-period manifest.

Google's Dynamic Ad Insertion doesn't support splitting segments. This article only describes support for conditioning the manifest.

Manifest and content requirements

For multi-period manifests

Expectations for a multi-period MPEG-DASH manifest

Google DAI performs the following validations on the raw MPD:

MPD element validations

  • Type is set to dynamic
  • Profile is set to urn:mpeg:dash:profile:isoff-live:2011
  • availabilityStartTime must be non-zero and its value must not change between successive polls of the MPD
  • PublishTime must be non-zero and its value should either increment or remain the same between successive polls. However, the publishTime attribute should be set to the current time at each update.
  • HTTPS must be used for the entirety of the DASH content referenced in the same MPD

Example

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" type="dynamic"
profiles="urn:mpeg:dash:profile:isoff-live:2011"
availabilityStartTime="2022-01-01T10:00:00Z"
publishTime="2022-01-01T10:00:00Z"
minimumUpdatePeriod="PT25S" timeShiftBufferDepth="PTM0S" maxSegmentDuration="PT2S"
minBufferTime="PT2S">
<Period ...>
...
</Period>
...
</MPD>

Period element validations

  • Start must be greater than or equal to zero

    This allows for support of ISO-8601 durations that may optionally include an integer day field. For example, P3DT3H1M30S would represent 3 days, 3 hours, 1 minute, and 30 seconds.

    The ISO-8601 Year, Month, and Week duration designators are currently not supported.

  • Period has at least one AdaptationSet element
  • Audio and video adaption sets have to be consistent across periods
  • Addressing schemes are restricted to templates with number and time-based addressing

Example

<Period start="PT0S">
<AdaptationSet ...>
...
</AdaptationSet>
<AdaptationSet ...>
...
</AdaptationSet>
</Period>

Between successive polls of the MPD:

  • Period elements can only be removed from the top of the MPD
  • Period elements can only be appended to the bottom of the MPD
  • Only the first and last periods in the MPD can be updated. No other periods in the MPD should be modified. Updates should only be for:
    • Removing segments or events from the top of the first period
    • Adding new segments or events to the bottom of the last period

AdaptationSet element validations

  • AdaptationSet has at least one Representation element
  • If present, ContentProtection elements in an AdaptationSet and sub-elements must not change between successive polls of the MPD

Example

<AdaptationSet mimeType="video/mp4" startWithSAP="1"
contentType="video" par="16:9"
minWidth="640" maxWidth="640" minHeight="360" maxHeight="360"
maxFrameRate="60/2"
segmentAlignment="true">
<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"></Role>
<ContentComponent id="0" contentType="video" />
<Representation ...>
...
</Representation>
<Representation ...>
...
</Representation>
</AdaptationSet>

Representation element validations

  • Id must be non-empty
  • There must be no SegmentBase or SegmentList elements

Example

<Representation width="640" height="360" sar="1:1" frameRate="60/2"
codecs="avc1.64001e" id="V300" bandwidth="300000">
...
</Representation>

SegmentTemplate with time validations

  • SegmentTimeline S elements may contain the t attribute–used for media URLs
    • If not provided, the value is assumed to be 0 for the first S element and for subsequent S elements, the value is assumed to be the sum of the previous S element's earliest presentation time and contiguous duration—the value of [ t + d ×ばつ (r + 1) ] of the previous S element).
    • $Time$ and $Number$ are both supported for multi-period manifests
    • StartNumber of the SegmentTemplate is not used
  • Between successive polls of the MPD:
    • Segments can only be removed from the top of the SegmentTimeline when they move out of the DVR window snapshots
    • Segments can only be appended to the bottom of the SegmentTimeline

Example

<SegmentTemplate timescale="90000" initialization="$RepresentationID$/init.mp4"
media="$RepresentationID$/$Time$.m4s">
<SegmentTimeline>
<S t="0" d="270000" r="20" />
</SegmentTimeline>
</SegmentTimeline>

Time component validations

Google DAI supports the time component part of the ISO-8601 duration and supports the optional integer day component: P0Y0M[n]DT[n]H[n]M[n]S. The days component is converted to a duration by considering 1 day = 24 hours and is added to the time component. Nanosecond is the lowest granularity that is recognized.

Valid time format examples
  • P0Y0M
  • P0Y0M2D
  • P2D
  • PT3H
  • PT0H3M
  • P0Y0M0DT0H0M1.000S
  • P0Y0M1DT2H4M10S
  • PT0.000000001S
Invalid time format examples
  • P
  • PT
  • 2007年03月01日
  • P5Y0M1DT2H4M1.000S
  • P0Y1.5M1DT2H4M1.000S
  • P0YiM1DT2H4M1.000S
  • P0Y0M.3DT0H0M1.000S
  • 3h
  • PT100,000H

Expectations for cue-out and cue-in message events

Google DAI performs the following validations on cue-out and cue-in message events. The content should be preconditioned 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.
  • A keyframe/IDR frame should follow a cue point and 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 one or more consecutive periods. Those periods must only contain the content segments to be replaced.

  • Ad break CUE-OUT indicators should be signaled in the MPD manifest as shown in one of the following examples:

    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="http://www.scte.org/schemas/35/2016"

    <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>

  • 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 ad break periods.

Supported ad markers

SCTE35 XML Splice Insert

In DASH, CUE markups are accompanied by XML Period element boundaries. CUE markups are provided as Event elements 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 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.

Example

<Period>

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

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

<SpliceInfoSection xmlns="urn:scte:scte35:2013:xml">

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

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

</SpliceInsert>

</SpliceInfoSection>

</Event>

</EventStream>

</Period>

SCTE35 XML Time Signal

In DASH, CUE markups are accompanied by XML Period element boundaries. CUE markups are provided as Event elements 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 an XML-based SCTE35 markup for DASH. This is similar to SCTE35 Binary Time Signal, except that the data is parsed and presented as XML instead of binary.

Example

<Period>

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

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

<SpliceInfoSection xmlns="urn:scte:scte35:2013:xml">

<TimeSignal outOfNetworkIndicator="true" spliceImmediateFlag="true">

<SpliceTime ptsTime="123123"/>

</TimeSignal>

<SegmentationDescriptor segmentationEventId="123123" segmentationEventCancelIndicator="false" segmentationDuration="123123">

<DeliveryRestrictions webDeliveryAllowedFlag="false" noRegionalBlackoutFlag="true" archiveAllowedFlag="false" deviceRestrictions="3"/>

<SegmentationUpid segmentationUpidType="14" segmentationTypeId="52" >11111</SegmentationUpid>

</SegmentationDescriptor>

</SpliceInfoSection>

</Event>

</EventStream>

</Period>

SegmentationTypeId indicates the type of time signal.

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

34 : Break Start
48 : Provider Advertisement Start
52 : Provider Placement Opportunity Start

The following SegmentationTypeId value is recognized as a valid CUE-IN time signal:

35 : Break End
49 : Provider Advertisement End
53 : Provider Placement Opportunity End

SCTE35 Binary Splice Insert

In DASH, CUE markups are accompanied by XML Period element boundaries. CUE markups are provided as Event elements 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.

Example

<Period>

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

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

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>

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

</Binary>

</Signal>

</Event>

</EventStream>

...

<Period>

SCTE35 Binary Time Signal: Break 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:

Example

<Period>

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

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

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>

/DAsAAAAAyiYAP/wBQb/PVbrDQAWAhRDVUVJB48zWH//AAEuGvsAACIAAdRJqiI=

</Binary>

</Signal>

</Event>

</EventStream>

...

<Period>

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:

34: Break Start

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

35: Break End

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:

Example

<Period>

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

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

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>

/DBcAAAAAAAAAP/wBQb//ciI8QBGAh1DVUVJXQk9EX+fAQ5FUDAxODAzODQwMDY2NiEEZAIZQ1VFSV0JPRF/3wABLit7AQVDMTQ2NDABAQEKQ1VFSQCAMTUwKnPhdcU=

</Binary>

</Signal>

</Event>

</EventStream>

...

<Period>

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

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:

Example

<Period>

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

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

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>

/DA0AAAAAAAA///wBQb+cr0AUAAeAhxDVUVJSAAAjn/PAAGlmbAICAAAAAAsoKGKNAIAmsnRfg==

</Binary>

</Signal>

</Event>

</EventStream>

...

<Period>

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

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, or EXT-X-DATERANGE 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:

Macro Description
%%SPLICE_INSERT_EVENT_ID%% Unsigned integers in the SCTE35 message, are converted to strings as decimal numbers.
%%SPLICE_INSERT_UPID%%
%%TIME_SIGNAL_EVENT_ID%%
%%TIME_SIGNAL_UPID%% Rendered as lowercase hexadecimal, with no 0x prefix.
%%TIME_SIGNAL_UPID_RAW%% Inserts raw bytes from the SCTE message (the initial string must be a valid UTF-8 encoded string).
%%AFMM_CBC%% Extracts the commercial break code from the splice info (this is a requirement for the French AF2M specification).
DASH content must follow all the rules specified in the Service Offering Requirements and Guidelines of the DASH-IF Interoperability Points.
For single-period manifests

Expectations for a single-period MPEG-DASH manifest

Google DAI performs the following validations on the raw MPD:

MPD element validations

  • Type is set to dynamic
  • Profiles is set to urn:mpeg:dash:profile:isoff-live:2011
  • AvailabilityStartTime must be non-zero and its value must not change between successive polls of the MPD
  • PublishTime must be non-zero and its value should either increment or remain the same between successive polls
  • MPD has exactly one Period element
  • HTTPS must be used for the entirety of the DASH content referenced in the same MPD

Example

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" type="dynamic"
profiles="urn:mpeg:dash:profile:isoff-live:2011"
availabilityStartTime="2022-01-01T10:00:00Z"
publishTime="2022-01-01T10:00:00Z"
minimumUpdatePeriod="PT25S" timeShiftBufferDepth="PTM0S" maxSegmentDuration="PT2S"
minBufferTime="PT2S">
<Period ...>
...
</Period>
...
</MPD>

Period element validations

  • Start must be greater than or equal to zero
  • Period has at least one AdaptationSet element

Example

<Period start="PT0S">
<AdaptationSet ...>
...
</AdaptationSet>
<AdaptationSet ...>
...
</AdaptationSet>
</Period>

EventStream element validations

Between successive polls of the MPD:

  • Event elements can only be removed from the top of an EventStream
  • Event elements can only be appended to the bottom of an EventStream

AdaptationSet element validations

  • AdaptationSet has at least one Representation element
  • If present, ContentProtection elements in an AdaptationSet and sub-elements must not change between successive polls of the MPD

Example

<AdaptationSet mimeType="video/mp4" startWithSAP="1"
contentType="video" par="16:9"
minWidth="640" maxWidth="640" minHeight="360" maxHeight="360"
maxFrameRate="60/2"
segmentAlignment="true">
<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"></Role>
<ContentComponent id="0" contentType="video" />
<Representation ...>
...
</Representation>
<Representation ...>
...
</Representation>
</AdaptationSet>

Representation element validations

  • Id must be non-empty
  • There must be no SegmentBase or SegmentList elements

Example

<Representation width="640" height="360" sar="1:1" frameRate="60/2"
codecs="avc1.64001e" id="V300" bandwidth="300000">
...
</Representation>

SegmentTemplate with $Time$ validations

  • SegmentTimeline S elements may contain the t attribute–used for media URLs
    • If not provided, the value is assumed to be 0 for the first S element and for subsequent S elements, the value is assumed to be the sum of the previous S element's earliest presentation time and contiguous duration—the value of [ t + d ×ばつ (r + 1) ] of the previous S element).
    • $Time$ is supported for single-period manifests; $Number$ is not yet supported
    • StartNumber of the SegmentTemplate is not used
  • Between successive polls of the MPD:
    • Segments can only be removed from the top of the SegmentTimeline when they move out of the DVR window snapshots
    • Segments can only be appended to the bottom of the SegmentTimeline

Example

<SegmentTemplate timescale="90000" initialization="$RepresentationID$/init.mp4"
media="$RepresentationID$/$Time$.m4s">
<SegmentTimeline>
<S t="0" d="270000" r="20" />
</SegmentTimeline>
</SegmentTimeline>

Time component validations

Google DAI supports the time component part of the ISO-8601 duration and supports the optional integer day component: P0Y0M[n]DT[n]H[n]M[n]S. The days component is converted to a duration by considering 1 day = 24 hours and is added to the time component. Nanosecond is the lowest granularity that is recognized.

Valid time format examples
  • P0Y0M
  • P0Y0M2D
  • P2D
  • PT3H
  • PT0H3M
  • P0Y0M0DT0H0M1.000S
  • P0Y0M1DT2H4M10S
  • PT0.000000001S
Invalid time format examples
  • P
  • PT
  • 2007年03月01日
  • P5Y0M1DT2H4M1.000S
  • P0Y1.5M1DT2H4M1.000S
  • P0YiM1DT2H4M1.000S
  • P0Y0M.3DT0H0M1.000S
  • 3h
  • PT100,000H

Expectations for the input SCTE-35 markers

Google DAI performs the following validations on input SCTE-35 markers:

Splice point validations

Google DAI only recognizes splice points as SCTE-35 markers carried in DASH MPD Event elements if they pass the following validations:

  • Base64 encoded SCTE-35 data must be contained in the Binary element of an event's Signal element
    • Splice_insert is supported
    • Time_signal with segmentation_descriptor commands are supported
  • EventStream elements containing events with SCTE-35 markers must have schemeIdUri set to urn:scte:scte35:2014:xml+bin
  • The Signal namespace must be set to http://www.scte.org/schemas/35/2016
  • For cue-outs, the presentationTime in the Event must be set
  • For cue-ins, the presentationTime in the Event must be set and duration must not be set
  • Event elements in the EventStream must be in sorted order by the presentationTime
Splice points provide opportunities to switch from one stream source to another. A splice point can be a cue out, which is an opportunity to switch to an ad break, or a cue-in, which is an opportunity to return from an ad break.

In this context, the splice points are used to split the Period into separate content and break Period elements based on the presentation times and/or durations of the splice points. These splice points are provided by Event elements with SCTE-35 markers.

splice_insert validations

  • A cue-out is a splice_insert with out_of_network_indicator set to 1
  • A cue-in is a splice_insert with out_of_network_indicator set to 0
  • Cue-ins are optional if and only if the Event containing the cue-out is a splice_insert and has a non-zero value set for duration
    • Google DAI interprets an implicit splice_insert cue-in with a presentation time of the cue-out's presentationTime + duration
    • An explicit cue-in event can end a cue-out before the end of its duration. This is how an early return can be triggered.

time_signal validations

  • A cue-out is a time_signal with segmentation_descriptor with segmentation_type_id matching:
    • 34 - Break Start
    • 48 - Provider Advertisement Start
    • 52 - Provider Placement Opportunity Start
  • A cue-in is a time_signal with segmentation_descriptor with segmentation_type_id matching:
    • 35 - Break End
    • 49 - Provider Advertisement End
    • 53 - Provider Placement Opportunity End
  • All other segmentation_type_ids are not supported
  • Time_signal does not support automatically returning from an ad break with an explicit cue-in

Presentation time validations

Google DAI does not support splitting segments and therefore only allows a 100ms tolerance for how far a splice point's presentation time can be from the closest segment boundary.

  • A splice point's presentation time is relative to the availabilityStartTime of the MPD by adding the presentationTime of the Event adjusted by the timescale of the EventStream to the start of the Period.

    An implicit cue-in's presentation time can be calculated by adding the duration to the associated cue-out's presentation time. A splice point's duration is calculated with the duration of the Event / timescale of the EventStream.

    In this context, the PTS time and durations provided in the SCTE-35 signal are not used to calculate the presentation time or duration.

  • A cue-out must not be at the same Segment boundary as another cue-out or cue-in
  • One or more cue-ins may be at the same Segment boundary (for example, an early break is triggered at the same time as the breaks' actual end). The duplicate cue-in is effectively ignored.

Periods, cue-out and cue-in message events

New Periods will be inserted both at the time of the start and end of the cue-out event (or start of the cue-out and cue-in events) when creating a multi-period presentation of the single-period manifest.

  • The start of the first new Period is represented by presentation time of the cue-out and the start of the second new Period is the sum of presentationTime and duration of the cue-out or the presentationTime of the cue-in, if provided.
    • If a cue-in is provided for a cue-out that has a duration, the Period will be split using the earlier splice point
  • Google DAI ignores the splice_time, break_duration, auto_return, and splice_immediate_flag fields in the SCTE-35 messages

An Event signaling a cue-out message must be present for the complete break duration.

This doesn't mean that the first Event in the EventStream is always a cue-out message. With a sufficiently long input DVR window, there may be events belonging to previous breaks in the window.

A cue-out message is ended by the next cue-in message.

  • SCTE-35 splice ID (splice_event_id or segmentation_event_id), and the event's id attribute are ignored
  • A splice_insert cue-out message is expected to be ended only by a splice_insert cue-in message, if auto_return isn't set
  • A time_signal cue-out message is expected to be ended only by a time_signal cue-in message with the same segmentation_type_id
A cue-out message immediately following another cue-out message before the end of its duration will close the initial break and start another one (in other words, result in a new Period).

Example

<EventStream schemeIdUri="urn:scte:scte35:2014:xml+bin" timescale="600" presentationTimeOffset="991724821200">

<Event presentationTime="992568282204" duration="18073" id="1615447966">

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>/DAbAAAAAAAAAP/wCgUAAAAAf98AAAAAAAAHeq0Q</Binary>

</Signal>

</Event>

<Event presentationTime="992568300277" id="1085695472">

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>/DAbAAAAAAAAAP/wCgUAAAAAf18AAAAAAAAqqkN1</Binary>

</Signal>

</Event>

</EventStream>

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

1.11.17 Single-period support

Players

Shaka

2.4.2

Recommended for testing

Bitmovin

v7

Exo-Player

2.8.2

Dash.js

2.0

Appendix

If you are using a single-period manifest, these examples demonstrate how DAI converts a single-period manifest to a multi-period manifest.

See a single-period manifest input example

Single-period manifest input example

<?xml version="1.0" encoding="UTF-8"?>

<MPD availabilityStartTime="2017-01-01T10:00:00Z" id="id1" maxSegmentDuration="PT2S" minBufferTime="PT2S" minimumUpdatePeriod="PT25S" profiles="urn:mpeg:dash:profile:isoff-live:2011" publishTime="2017-01-01T10:00:00Z" timeShiftBufferDepth="PT5M" type="dynamic" ns1:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance">

<BaseURL>http://example.com/dash/</BaseURL>

<Period id="1" start="PT0S">

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

<Event duration="2700000" presentationTime="270000" id="1">

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>/DAlAAAAAAAAAP/wFAUAAA+if+/+INAJ0P4AKTLgAAAAAAAA9UTkTA==</Binary>

</Signal>

</Event>

<Event presentationTime="2970000" id="2">

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>/DAgAAAAAAAAAP/wDwUAAA+if0/+IPk8sAAAAAAAAH3XbUE=</Binary>

</Signal>

</Event>

</EventStream>

<AdaptationSet contentType="audio" lang="eng" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1">

<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main" />

<SegmentTemplate timescale="44100" initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/$Number$.m4s">

<SegmentTimeline>

<S t="0" d="132300" r="20" />

</SegmentTimeline>

</SegmentTemplate>

<Representation audioSamplingRate="48000" bandwidth="48000" codecs="mp4a.40.2" id="A48">

<AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2" />

</Representation>

</AdaptationSet>

<AdaptationSet contentType="video" maxFrameRate="60/2" maxHeight="360" maxWidth="640" mimeType="video/mp4" minHeight="360" minWidth="640" par="16:9" segmentAlignment="true" startWithSAP="1">

<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main" />

<SegmentTemplate timescale="90000" initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/$Number$.m4s">

<SegmentTimeline>

<S t="0" d="270000" r="20" />

</SegmentTimeline>

</SegmentTemplate>

<Representation bandwidth="300000" codecs="avc1.64001e" frameRate="60/2" height="360" id="V300" sar="1:1" width="640" />

</AdaptationSet>

</Period>

</MPD>

See a multi-period manifest output example

Multi-period manifest output example

<?xml version="1.0" encoding="UTF-8"?>

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:XMLSchema-instance="http://www.w3.org/2001/XMLSchema-instance" XMLSchema-instance:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" id="id1" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="dynamic" availabilityStartTime="2017-01-01T10:00:00Z" publishTime="2017-01-01T10:00:00Z" minimumUpdatePeriod="PT25S" minBufferTime="PT2S" timeShiftBufferDepth="PT5M0S" maxSegmentDuration="PT2S">

<BaseURL>http://example.com/dash/</BaseURL>

<Period id="0s" start="PT0S">

<AdaptationSet mimeType="audio/mp4" startWithSAP="1" lang="eng" contentType="audio" segmentAlignment="true">

<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"></Role>

<SegmentTemplate timescale="44100" presentationTimeOffset="0" media="$RepresentationID$/$Number$.m4s" initialization="$RepresentationID$/init.mp4">

<SegmentTimeline>

<S d="132300"></S>

</SegmentTimeline>

</SegmentTemplate>

<Representation audioSamplingRate="48000" codecs="mp4a.40.2" id="A48" bandwidth="48000">

<AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"></AudioChannelConfiguration>

</Representation>

</AdaptationSet>

<AdaptationSet mimeType="video/mp4" startWithSAP="1" contentType="video" par="16:9" minWidth="640" maxWidth="640" minHeight="360" maxHeight="360" maxFrameRate="60/2" segmentAlignment="true">

<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"></Role>

<SegmentTemplate timescale="90000" presentationTimeOffset="0" media="$RepresentationID$/$Number$.m4s" initialization="$RepresentationID$/init.mp4">

<SegmentTimeline>

<S d="270000"></S>

</SegmentTimeline>

</SegmentTemplate>

<Representation width="640" height="360" sar="1:1" frameRate="60/2" codecs="avc1.64001e" id="V300" bandwidth="300000"></Representation>

</AdaptationSet>

</Period>

<Period id="3s" start="PT3S">

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

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

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>/DAlAAAAAAAAAP/wFAUAAA+if+/+INAJ0P4AKTLgAAAAAAAA9UTkTA==</Binary>

</Signal>

</Event>

</EventStream>

<AdaptationSet mimeType="audio/mp4" startWithSAP="1" lang="eng" contentType="audio" segmentAlignment="true">

<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"></Role>

<SegmentTemplate timescale="44100" presentationTimeOffset="132300" media="$RepresentationID$/$Number$.m4s" initialization="$RepresentationID$/init.mp4">

<SegmentTimeline>

<S t="132300" d="132300" r="9"></S>

</SegmentTimeline>

</SegmentTemplate>

<Representation audioSamplingRate="48000" codecs="mp4a.40.2" id="A48" bandwidth="48000">

<AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"></AudioChannelConfiguration>

</Representation>

</AdaptationSet>

<AdaptationSet mimeType="video/mp4" startWithSAP="1" contentType="video" par="16:9" minWidth="640" maxWidth="640" minHeight="360" maxHeight="360" maxFrameRate="60/2" segmentAlignment="true">

<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"></Role>

<SegmentTemplate timescale="90000" presentationTimeOffset="270000" media="$RepresentationID$/$Number$.m4s" initialization="$RepresentationID$/init.mp4">

<SegmentTimeline>

<S t="270000" d="270000" r="9"></S>

</SegmentTimeline>

</SegmentTemplate>

<Representation width="640" height="360" sar="1:1" frameRate="60/2" codecs="avc1.64001e" id="V300" bandwidth="300000"></Representation>

</AdaptationSet>

</Period>

<Period id="33s" start="PT33S">

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

<Event id="2">

<Signal xmlns="http://www.scte.org/schemas/35/2016">

<Binary>/DAgAAAAAAAAAP/wDwUAAA+if0/+IPk8sAAAAAAAAH3XbUE=</Binary>

</Signal>

</Event>

</EventStream>

<AdaptationSet mimeType="audio/mp4" startWithSAP="1" lang="eng" contentType="audio" segmentAlignment="true">

<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"></Role>

<SegmentTemplate timescale="44100" presentationTimeOffset="1455300" media="$RepresentationID$/$Number$.m4s" initialization="$RepresentationID$/init.mp4">

<SegmentTimeline>

<S t="1455300" d="132300" r="9"></S>

</SegmentTimeline>

</SegmentTemplate>

<Representation audioSamplingRate="48000" codecs="mp4a.40.2" id="A48" bandwidth="48000">

<AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"></AudioChannelConfiguration>

</Representation>

</AdaptationSet>

<AdaptationSet mimeType="video/mp4" startWithSAP="1" contentType="video" par="16:9" minWidth="640" maxWidth="640" minHeight="360" maxHeight="360" maxFrameRate="60/2" segmentAlignment="true">

<Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"></Role>

<SegmentTemplate timescale="90000" presentationTimeOffset="2970000" media="$RepresentationID$/$Number$.m4s" initialization="$RepresentationID$/init.mp4">

<SegmentTimeline>

<S t="2970000" d="270000" r="9"></S>

</SegmentTimeline>

</SegmentTemplate>

<Representation width="640" height="360" sar="1:1" frameRate="60/2" codecs="avc1.64001e" id="V300" bandwidth="300000"></Representation>

</AdaptationSet>

</Period>

</MPD>

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

Was this helpful?

How can we improve it?
true
Unlock your revenue with personalized tips today!

Visit the Optimization tips for Google Ad Manager page to see personalized suggestions to maximize your revenue.

Unlock now