Unified Origin - DAI

Live stream with Dynamic Ad Replacement

Ad replacement for live is built following industry specifications for assured interoperability with global ad vendors and partners. Chosen by major broadcasters, streaming providers and telcos for its ease of integration, playout compatibility and quality of user experience. A proven solution replacing advertisements in live streams watched by millions of viewers everyday.

Key features

Industry standard ad break signaling, uses SCTE 35 markers to signal advertisement opportunities
Supports HLS and MPEG-DASH, without breaking backward compatibility for older formats like Smooth
Frame accurate, cuts and splices at the exact ad break boundaries

Main benefits

Proven compatibility, works with the majority of third-party ad replacement services
No client-side integration, works natively on many players, increasing the size of your potential audience
Increase revenue, target ads per region, user and demographic
Seamless playback, transitions between programs and ad breaks without buffering or artifacts
Advanced ad break signaling, use SCTE 35's 'splice_insert' for simple ad break signaling, or leverage 'time_signal' for your advanced use cases

How it works

As in a regular live workflow an encoder posts a live stream to Origin, which ingests it, creating a live archive on disk. To enable ad replacement the live encoder sends SCTE 35 markers in a separate track, with additional keyframes in the media wherever the start or end of an ad break is signaled.

From the live archive, Unified Origin generates a stream with splice points at the start and end of each ad break. A third-party ad replacement service then manipulates the manifest to replace the existing ads with more relevant ones.

Note

Apart from below, more background about timed metadata in our blog post: How to make your media streams smarter using timed metadata.

Introduction to Timed Metadata / SCTE 35 

In live streaming metadata can be used to 'mark' a certain timestamp in the stream. Such a mark is also called a 'cue'. These markers are pushed to a publishing point as part of a separate track using SCTE 35 messages, which, like the contents of all other tracks, need to be packaged in fMP4 containers.

SCTE 35 messages may contain info about a program or other relevant data, but for the current document it is most important that they can cue splice points that can be used to enable dynamic ad substitution or insertion in a stream.

A splice point is a specific time in a stream that corresponds to an IDR frame that is signaled as a sync-sample. This means that the splice point offers the opportunity to seamlessly switch the livestream to a different clip. Splice points can be used to cue:

(Ad) replacement/insertion opportunities
Start and endpoint of a program (for Live2VOD see Capturing LIVE)

When the timestamp that signals a splice point does not correspond to the start of a media segment in the stream (i.e., it does not correspond to any of the IDR frames that are present in the stream by default), the encoder that pushes the livestream to the publishing point, needs to insert an additional IDR frame in media tracks at the timestamp that the cue signals. If the --splice_media option is enabled, Origin then splices frame accurately and part of the media segment that contains the splice point is merged with either the previous or the next segment so that the number of segments before and after splicing remains the same.

In addition to splicing the media segments, if necessary, Origin will also signal the splice points in the HTTP Live Streaming playlists and MPEG-DASH client manifests. A third party service may then be used to insert a clip into the livestream at such a splice point to create an ad insertion or ad replacement workflow, for example.

Different types of SCTE 35 signals 

Unified Streaming products support the handling of:

splice_info_section()
splice_insert()
time_signal()
segmentation_descriptor()

And are capable of fulfilling the requirements in the following presentation formats:

HLS TS
HLS fMP4
MPEG-DASH (when using a SegmentList or SegmentTemplate)

Product support for SCTE 35 is based upon the following specifications and guidelines:

splice_insert()

A legacy but commonly used command (as described in Section 9.1 of SCTE 35 (2019)) to indicate where a break can occur within a program stream. It is carried in a splice_info_section().
Still widely used in the industry (until all systems support time_signal)
Commands trigger either CUE-OUT (to the ad break) or CUE-IN (from the ad break) or both.
Breaks cannot overlap each other.

Section 9.2 of SCTE 35 (2019) outlines the following requirements for delivery of metadata in advance of the desired presentationTime:

The splice_insert() message shall be sent at least once a minimum of 4 seconds in advance of the desired splice time for a network Out Point condition. It is recommended that, if a return-to-network (an In Point) message is sent, the same minimum 4 second pre- roll be provided.

recommends some of the constraints when using splice_insert marker for signalling an ad break.

time_signal()

The successor command to indicate where a break can occur within a program stream.
Beginning to be adopted more in the industry.
Commands are supplied in pairs with each CUE-OUT/CUE-IN being used to describe a different type of break.
Can be used to describe different types of 'breaks' (program, chapter, etc.) using a segmentation descriptor

Section 10.3.3 of SCTE 35 (2019) outlines the following requirements for delivery of metadata in advance of the desired presentationTime:

The time_signal() or splice_insert() message should be sent at least once a
minimum of 4 seconds in advance of the signaled splice_time() to permit the
insertion device to place the splice_info_section() accurately.

For further information on using 'time_signal()', please see --time_signal below.

Different types of messages 

The processing entity (e.g., Packager or Origin) can receive SCTE 35 messages delivered as an event message track containing:

As SCTE 35 Events stored in an Event Track (ISO/IEC 23001-18) using schemeIdUri urn:scte:scte35:2013:bin
As based on DASH-IF live media ingest DASH-IF Event Track using schemeIdUri urn:scte:scte35:2013:bin.
Cablelabs ESAM stored in an ‘mdat’ box.

Event message Track Details

Track format is Event Track or DASH-IF Event Track using schemeIdUri urn:scte:scte35:2013:bin
Allows the message to be converted DASH Events as defined in ISO/IEC 23009-1
Adopted by companies such as Telestream, Ateme, MediaExcel, others

The format of the track is an ISO Base Media File Format metadata track (specified in ISO/IEC 14496-12).

The fragmented formatting is bears similarity to webvtt in fMP4 as each change in the active set of cues will trigger a sample boundary.

The fragmented event message about track should be segmented in equal duration segments containing one ore more samples.

In case no cue is active during a sample an emeb embe signal can be used signal this (similarly as the vtt empty VTTEmptyCueBox).

each sample nevertheless shall contain all currently active cues.

An example of a set of input events with duration and id :

event_id	event_presentation_time	event_duration
id=2	presentation_time=19	event_duration=14
id=3	presentation_time=39	event_duration=16
id=1	presentation_time=124	event_duration=7
id=0	presentation_time=132	event_duration=0

An example corresponding set of samples in an event message track of a segment from presentation time 0 to 150:

sample_presentation_time	sample_duration	sample_data
0	19	EventMessageEmptyBox
3	14	EventMessageInstanceBox(id=2,presentation_time_delta=0,event_duration=14)
33	6	EventMessageEmptyBox
39	16	EventMessageInstanceBox(id=3,presentation_time_delta=0,event_duration=16)
55	69	EventMessageEmptyBox
124	7	EventMessageInstanceBox(id=1,presentation_time_delta=0,event_duration=7)
131	1	EventMessageEmptyBox
132	1	EventMessageInstanceBox(id=0,presentation_time_delta=0,event_duration=0)
133	17	EventMessageEmptyBox

Events with duration zero, will have a sample with duration 1. The segmented format allows the equal duration segmenting and regular updating of the event message track. The example above illustrates the structuring of samples in the even track accoding to Event Track.

You should check if your encoder vendor supports this format. An example and reference illustrative implementation showing some of the features is available in Event Track Implementation.

SCTE 35 events shall be signalled as specified in SCTE 214 and using SchemeIdUri urn:scte:scte35:2013:bin. A best practice for constraining SCTE 35 and SCTE 214 usage is defined in DVB-TA part 3 and SCTE 214 2022.

The best practice includes using autoreturn=1 for splice_insert and matching the break duration of the marker with the event duration. The event presentation time is leading to identify the splice point, fields in the SCTE 35 markers such as ptsTime or ptsAdjust are not taken into account as they have no meaning in MP4/DASH/HLS. Please see DVB-TA part 3 for recommendations on signalling ad breaks in events using SCTE 35.

When converted to XML a binary SCTE 35 message can take the following form:

<EventStream xmlns="urn:mpeg:dash:schema:mpd:2011"
schemeIdUri="urn:scte:scte35:2013:xml"
value="2" timescale="10000000">
  <!-- 2019-12-19T08:30:21.942400Z -->
  <Event presentationTime="15767442219424000" duration="150000000" id="1576744212">
    <Signal xmlns="http://www.scte.org/schemas/35/2016">
      <SpliceInfoSection>
        <SpliceInsert spliceEventId="1576744212"
          outOfNetworkIndicator="1"
          spliceImmediateFlag="0"
          uniqueProgramId="0"
          availNum="0"
          availsExpected="0">
          <Program>
            <SpliceTime ptsTime="1259272022" />
          </Program>
          <BreakDuration autoReturn="1" duration="1350000" />
        </SpliceInsert>
      </SpliceInfoSection>
    </Signal>
  </Event>
</EventStream>

Cablelabs (ESAM)

Part of Cablelabs ESAM specification OC-SP-ESAM-API
SCTE 35 messages delivered as XML
XML can be extracted directly from the file delivered
Adopted by AWS Elemental (Live, MediaLive)

<?xml version="1.0"?>
<sig:AcquiredSignal xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cond="http://www.cablelabs.com/namespaces/metadata/xsd/conditioning/2"
  xmlns:sig="http://www.cablelabs.com/namespaces/metadata/xsd/signaling/2"
  xmlns="http://www.cablelabs.com/namespaces/metadata/xsd/conditioning/2"
  xsi:schemaLocation="http://www.cablelabs.com/namespaces/metadata/xsd/conditioning/2 ESAM_Signal.xsd">
  <AcquiredSignal acquisitionPointIdentity=""
  acquisitionSignalID="5f7943fd-7ffa-d8aa-feff-fbfff8b69e92">
    <sig:UTCPoint utcPoint="2017-10-05T23:47:43.138Z"/>
    <sig:BinaryData signalType="SCTE35">/DAlAAAAAA4QAP/wFAUAAAACf+/+ABjGMP4ADbugAAEBAQAAbRyXaw==</sig:BinaryData>
    <sig:StreamTimes>
      <sig:StreamTime timeType="HSS" timeValue="15072472620400000"/>
      <sig:StreamTime timeType="SignalID"
      timeValue="NWY3OTQzZmQtN2ZmYS1kOGFhLWZlZmYtZmJmZmY4YjY5ZTky"/>
      <sig:StreamTime timeType="Duration" timeValue="100000000"/>
    </sig:StreamTimes>
  </AcquiredSignal>

Enabling Media Splicing on SCTE 35 Markers 

--timed_metadata 

New in version 1.9.0.

If your USP license includes support for timed metadata, you can enable Origin to pass it through using the --timed_metadata option when creating the server manifest. SCTE 35 messages that Origin ingests are then automatically signaled in the MPEG-DASH and Apple HLS client manifests.

By default Origin uses the SCTE 35 splice_insert() command as markers for ad breaks and period boundaries.

--splice_media 

New in version 1.9.0.

This option requires that your USP license includes support for timed metadata and that the --timed_metadata option is enabled on the publishing point of your livestream. When this is true and your content contains SCTE 35 markers that signal splice points, Origin can be instructed to splice the MPEG-DASH and Apple HLS media segments on these splice points by enabling the --splice_media when creating the Live server manifest.

--time_signal 

New in version 1.10.15.

The SCTE 35 splice_insert() is considered legacy and a better alternative is to use the SCTE 35 time_signal() command to signal splice events.

This option takes a comma separated list of segmentation type ids that mark the ad breaks and period boundaries.

segmentation_type_id	Segmentation Message
0x22 (34)	Break Start
0x23 (35)	Break End
0x30 (48)	Provider Advertisement Start
0x31 (49)	Provider Advertisement End
0x32 (50)	Distributor Advertisement Start
0x33 (51)	Distributor Advertisement End
0x34 (52)	Provider Placement Opportunity Start
0x35 (53)	Provider Placement Opportunity End
0x36 (54)	Distributor Placement Opportunity Start
0x37 (55)	Distributor Placement Opportunity End
0x38 (58)	Distributor Overlay Placement Opportunity Start
0x39 (59)	Distributor Overlay Placement Opportunity End

Note

For HLS output the selected types will be signalled as either SCTE-OUT or SCTE-IN as appropriate. All other types will be SCTE-CMD.

Attention

It's crucial that the archive_length set when creating the publishing point is longer than the longest possible ad break for that particular live stream.

Advanced SCTE 35 configurations 

If you are using other SCTE 35 commands, use segmentation descriptors or require more control over SCTE 35 commands you can use a more advanced configuration.

For example you may wish to use both splice_insert as well as segmentation_descriptors to signal replacement opportunities.

Another example is that you may wish to splice the media on a 'Program Start' boundary so that you can (re-)start playback frame accurately.

Note that using any of these advanced options replaces the default behaviour of using SCTE 35 splice_insert() for opportunities and the --time_signal option).

--splice_insert 

New in version 1.11.24.

Use splice_insert() messages to signal a replacement opportunity. Can be used together with --splice_media to also splice the media segment.

--cue_ids 

New in version 1.11.24.

This option takes a comma separated list of segmentation type ids that signal a replacement opportunity. Can be used together with --splice_media to also splice the media segment.

Origin Ingest Requirements 

Origin supports the ingest of SCTE 35 messages in the form of SCTE-35 event message track.

the following 3 types of event message tracks are currently supported:

As SCTE 35 Events stored in an Event Track (ISO/IEC 23001-18) using schemeIdUri urn:scte:scte35:2013:bin
As based on DASH-IF live media ingest DASH-IF Event Track using schemeIdUri urn:scte:scte35:2013:bin.
Cablelabs ESAM stored in an ‘mdat’ box.

The timing of the presention time of the event must be sample accurate and it is an error to not have an IDR frame (which must be signaled as being a sync-sample) at the time of a cue. In other words, the encoder must ensure that an IDR frame is present at each timestamp that is signaled in a SCTE 35 message. Also, if an additional IDR frame needs to be inserted, the encoder should not shorten or lengthen any of the media segments but keep the original length intact.

In case of audio some small misalignments may occur, but by chosing the right sample rate and segment duration this can be avoided.

SCTE 35 markers must be received by Unified Origin at least 2x ahead of the specified [hls|mpd].minimum_fragment_length. Example:

2 x minimum_fragment_length = latest receive time: 2 x 6s = 12s

Using time_shift to reduce the time required:

2 x minimum_fragment_length - time_shift = latest receive time: 2 x 6s - 8s = 4s

Using smaller minimum_fragment_length:

2 x minimum_fragment_length = latest receive time: 2 x 4s = 8s

To give some context as to why it exists:

The shortest part of any sliced segment needs to be either prepended to the next segment (if the the second 'half' of sliced segment is the shortest) or appended to the segment before (if the the first 'half' of sliced segment is the shortest). As changing the duration of previously announced segment is not allowed, we need to know about any splicing (via the SCTE marker) that needs to be signaled before the segment that precedes the segment within which the splice opportunity occurs.

In addition to the above, the regular ingest requirements should be followed, as documented in Content Preparation.

SCTE 35 cue events 

Note

We follow the guidelines as described in SCTE 67 (2017) Guidelines and DVB-TA part 3.

The SCTE 35 splice_insert() is used to announce an opportunity to either splice out of the network into an ad (a 'cue-out event'), or splice into network, out of an ad.

A cue-out event is indicated by a SCTE 35 splice_insert() message with the out_of_network_indicator field set to 1. The break_duration() must be present and signal the duration of the break and equal the event duration (after timescale conversion).

Early Termination 

An IN cue which is a time_signal with a segmentation end descriptor or a splice_insert with out_of_network_indicator=0 may arrive before a current break is ended.

This is early termination of an ad break and applies in certain use cases such as live sports.

The correlation between the start (out) and end (in) can be made for both splice_insert or time_signal/segmentation_descriptor.

For splice_insert the correlation is made by looking at the currently active splice_insert with out_of_network_indicator=1. It is then assumed the in marker terminates this currently active break.

Note that when using splice_inserts splice_event_id is not used.

This is because according to SCTE 35 each splice_event_id is unique for a splice, and therefore this cannot be used to correlate the in and out splices.

For time_signal with segmentation_descriptor, the segmentation_event_id can be used to correlate the in and out cue's when it arrives early.

IN markers that arrive late and do not correlate to active events are commented out in HLS and passed through in DASH.

Origin Playout 

The events signaled in SCTE 35 messages are passed through to the client manifests when this feature is part of your USP license and you have enabled the --timed_metadata option for the particular publishing point. 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 MPEG-DASH they are signaled in DASH Event Messages.

For HLS, the EXT-X-DATERANGE and EXT-X-CUE-OUT plus EXT-X-CUE-IN tags present different ways of signaling similar information. By adding them both, compatibility with a broader range of third party services that make use of these tags 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 DFP and AWS Elemental MediaTailor).

Because Origin appends or prepends part of the spliced media segment to the previous or next media segment, no new media segments are introduced and discontinuities in the sequence numbering of the segments is avoided. Since we merge a part of the spliced media segment, the duration of the media segments remains between 0.5 and 1.5 times the original segment duration.

Note

For post-rolls, the EXT-X-DATERANGE and EXT-X-CUE-OUT plus EXT-X-CUE-IN tags will precede the last media segment. This is because the HLS specification requires tag decorators to be explicitly declared before a segment. See the AWS Elemental MediaTailor documentation for more information.

HLS signaling of SCTE 35 

In addition to SCTE 35 markers 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.

An example from an actual livestream with SCTE 35 markers is shown below. The example is taken from HLS - Pure live (SCTE 35)`. This livestream contains cue-out markers that are exactly aligned with the media segment boundaries so that no media segments need to be spliced:

#EXTINF:4, no desc
scte35-audio=69000-video=700000-385202370.ts
#EXT-X-DATERANGE:ID="2002",START-DATE="2018-10-29T10:38:00Z",PLANNED-DURATION=24,SCTE35-OUT=0xFC302100000000000000FFF01005000007D27FEF7F7E0020F580C0000000000088B9661D
#EXT-X-CUE-OUT:24
#EXT-X-PROGRAM-DATE-TIME:2018-10-29T10:38:00Z
#EXTINF:4, no desc
scte35-audio=69000-video=700000-385202371.ts
#EXTINF:4, no desc
scte35-audio=69000-video=700000-385202372.ts
#EXTINF:4, no desc
scte35-audio=69000-video=700000-385202373.ts
#EXTINF:4, no desc
scte35-audio=69000-video=700000-385202374.ts
#EXTINF:4, no desc
scte35-audio=69000-video=700000-385202375.ts
#EXTINF:4, no desc
scte35-audio=69000-video=700000-385202376.ts
#EXT-X-CUE-IN
#EXT-X-PROGRAM-DATE-TIME:2018-10-29T10:38:24Z
#EXTINF:4, no desc

Note

As long as a cue-event has not finished, the signaling of the start of the event will remain part of the playlist, even if the start of the event is outside of the specified DVR window.

Early Announcement of Opportunities in HLS 

Since version 1.11.5 Unified Origin is capable of signalling opportunities ahead of the desired presentation time. Previously Unified Origin would only signal these opportunities at the presentation even if they had been received earlier from the upstream encoder.

Now it's possible for a downstream platform to extract information from the EXT-X-DATERANGE tag signalled at the foot of the HLS client manifest to prepare supplementary content for the opportunity ahead of time.

The following example manifest describes how a future opportunity due to occur at 09:56:27 is already announced in the client manifest at 09:56:21. The Unified Origin has received the SCTE 35 opportunity 6seconds ahead of its presentation time. Until the live-edge of the presentation time reaching this time the EXT-X-DATERANGE will continue to be appended with every new media segment announced.

Fri Dec 10 09:56:21 UTC 2021
#EXTM3U
#EXT-X-VERSION:4
## Created with Unified Streaming Platform  (version=1.11.9-25075)
#EXT-X-MEDIA-SEQUENCE:853713625
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-TARGETDURATION:3
#USP-X-TIMESTAMP-MAP:MPEGTS=6768378784,LOCAL=2021-12-10T09:55:58.080000Z
## splice_insert(auto_return)
#EXT-X-DATERANGE:ID="72616-1639130128",START-DATE="2021-12-10T09:55:28.320000Z",PLANNED-DURATION=19.2,SCTE35-OUT=0xFC302100000000000000FFF0100500011BA87FEF7FFE001A5E00C00000000000E4612402
## Auto Return Mode
#EXT-X-PROGRAM-DATE-TIME:2021-12-10T09:55:58.080000Z
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713625.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713626.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713627.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713628.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713629.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713630.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713631.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713632.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713633.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713634.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713635.ts
## splice_insert(auto_return)
#EXT-X-DATERANGE:ID="72617-1639130187",START-DATE="2021-12-10T09:56:27.840000Z",PLANNED-DURATION=19.2,SCTE35-OUT=0xFC302100000000000000FFF0100500011BA97FEF7FFE001A5E00C00000000000E4612## Auto Return Mode

Since the live-edge has now reached the presentation time of the SCTE 35 opportunity the manifest is now conditioned with both the EXT-X-DATERANGE and EXT-X-CUE-OUT at the segment boundary that has been spliced (split and merged).

Fri Dec 10 09:56:32 UTC 2021
#EXTM3U
#EXT-X-VERSION:4
## Created with Unified Streaming Platform  (version=1.11.9-25075)
#EXT-X-MEDIA-SEQUENCE:853713631
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-TARGETDURATION:3
#USP-X-TIMESTAMP-MAP:MPEGTS=6769415584,LOCAL=2021-12-10T09:56:09.600000Z
## splice_insert(auto_return)
#EXT-X-DATERANGE:ID="72616-1639130128",START-DATE="2021-12-10T09:55:28.320000Z",PLANNED-DURATION=19.2,SCTE35-OUT=0xFC302100000000000000FFF0100500011BA87FEF7FFE001A5E00C00000000000E4612402
## Auto Return Mode
#EXT-X-PROGRAM-DATE-TIME:2021-12-10T09:56:09.600000Z
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713631.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713632.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713633.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713634.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713635.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713636.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713637.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713638.ts
#EXTINF:1.92, no desc
scte35-audio_eng=128000-video=1000000-853713639.ts
#EXTINF:0.96, no desc
scte35-audio_eng=128000-video=1000000-853713640.ts
## splice_insert(auto_return)
#EXT-X-DATERANGE:ID="72617-1639130187",START-DATE="2021-12-10T09:56:27.840000Z",PLANNED-DURATION=19.2,SCTE35-OUT=0xFC302100000000000000FFF0100500011BA97FEF7FFE001A5E00C00000000000E4612402
#EXT-X-CUE-OUT:19.2
#EXT-X-PROGRAM-DATE-TIME:2021-12-10T09:56:27.840000Z
#EXTINF:2.88, no desc
scte35-audio_eng=128000-video=1000000-853713641.ts
## Auto Return Mode

SCTE 35 based spliced media in HLS

The below example that is taken from HLS - Pure live (SCTE 35, spliced) shows the signaling of SCTE 35 markers in a livestream when the cue-out markers do not align with the media segment boundaries. In this example, a 10 second segment need to be spliced to fit a 24 second break. (Origin will only splice segments if the --splice_media option is present in the publishing point's server manifest.)

The duration of the SCTE 35 cue-out event in the example below is 24 seconds and the last media segment in this time range is spliced at exactly 4 seconds and appended to the media segment before it to match the duration of 24 seconds (10 + (10 + 4) = 24 seconds). The remaining 6 seconds of the media segment that was spliced then becomes a media segment on its own, right after the cue-in that signals the end of the 24 second break:

#EXTINF:10, no desc
scte35-audio=69000-video=700000-154080970.ts?hls_minimum_fragment_length=10
#EXTINF:10, no desc
scte35-audio=69000-video=700000-154080971.ts?hls_minimum_fragment_length=10
#EXTINF:10, no desc
scte35-audio=69000-video=700000-154080972.ts?hls_minimum_fragment_length=10
#EXT-X-DATERANGE:ID="2004",START-DATE="2018-10-29T10:42:00Z",PLANNED-DURATION=24,SCTE35-OUT=0xFC302100000000000000FFF01005000007D47FEF7F7E0020F580C000000000004F1B1A5F
#EXT-X-CUE-OUT:24
#EXT-X-PROGRAM-DATE-TIME:2018-10-29T10:42:00Z
#EXTINF:10, no desc
scte35-audio=69000-video=700000-154080973.ts?hls_minimum_fragment_length=10
#EXTINF:14, no desc
scte35-audio=69000-video=700000-154080974.ts?hls_minimum_fragment_length=10
#EXT-X-CUE-IN
#EXT-X-PROGRAM-DATE-TIME:2018-10-29T10:42:24Z
#EXTINF:6, no desc
scte35-audio=69000-video=700000-154080975.ts?hls_minimum_fragment_length=10
#EXTINF:10, no desc
scte35-audio=69000-video=700000-154080976.ts?hls_minimum_fragment_length=10

MPEG-DASH signaling of SCTE 35 

For a MPEG-DASH client manifest, Origin does not create a new period for cue-out events, but signals these events in the same period as the main event. 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 devices silently ignores the presence of the EventStream element). The SCTE 35 markers are carried in DASH Event Messages. The @presentationTime is relative to the Period@Start, the value element contains a base64 encoded representation of the splice_info_section.

Each 'Event' will be signaled in an MPD as long as it is relevant. That is, an 'Event' signaling a 'cue-out' message will be present for the complete duration of the break, as signaled in the 'cue-out' message. Furthermore, each 'Event' will have an 'id' that is unique (which in most cases will the same as the 'splice id' signaled in the SCTE 35 'cue-out' message).

The below example is taken from MPEG-DASH - Pure live (SCTE 35)`. In this livestream the cue-out markers are exactly aligned with the media segment boundaries so that no media segments are spliced.

<EventStream
  schemeIdUri="urn:scte:scte35:2014:xml+bin"
  timescale="1">
  <Event
    presentationTime="1540809120"
    duration="24"
    id="1999">
    <Signal xmlns="http://www.scte.org/schemas/35/2016">
      <Binary>/DAhAAAAAAAAAP/wEAUAAAfPf+9/fgAg9YDAAAAAAAA/APOv</Binary>
    </Signal>
  </Event>
  <Event
    presentationTime="1540809240"
    duration="24"
    id="2000">
    <Signal xmlns="http://www.scte.org/schemas/35/2016">
      <Binary>/DAhAAAAAAAAAP/wEAUAAAfQf+9/fgAg9YDAAAAAAAA2Z7lO</Binary>
    </Signal>
  </Event>
</EventStream>

SCTE 35 based spliced media in DASH (index based)

In the example MPEG-DASH - Pure live (SCTE 35, spliced) livestream, the AdaptationSets in the MPD contain media segments with a duration of 8 seconds, because --mpd.minimum_fragment_length=8 is specified (the ingested fragments have a 1 second length and are concatenated into segments that have the 8 seconds duration that is specified using the --mpd.minimum_fragment_length option).

As the cue-out events signaled by the SCTE 35 markers in this stream do not align with the stream's media segment boundaries, the media segments containing the timestamps that represent the start and end of a cue-out event need to be spliced and Origin will append or prepend part of the spliced media segment to the previous or next media segment.

In the example that results in the media segments before and after a splice being between 4 and 12 seconds long, instead of the stream's original segment duration of 8 seconds. However, because the SegmentTemplate does not signal individual segments when $Number$ is used to index the segments, the contents of the SegmentTemplate element are no different than if splicing would not have been enabled in the server manifest of the publishing point. See:

--mpd.segment_template

--[iss|hls|hds|mpd].minimum_fragment_length

Note

This specifically relates to MPEG-DASH - Pure live (SCTE 35, spliced). We advise to use the SegmentTemplate $Time$ timeline alongside --splice_media for best accuracy

Insertion opportunities for MPEG-DASH

When a third party service is used to insert content based on the cue-out events in the MPEG-DASH client manifest that is generated by Origin, this service may create a multi-period presentation based on the original client manifest. When doing so, it should insert a new period inserted both at the time of the start and end of the cue-out event.

The second of the new 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.

Note

When the original livestream contains ads and SCTE 35 markers are inserted to allow for these ads to be replaced, the markers also have a use when the ads are not yet replaced, because a device's player can be configured to use the events signaled in EventStream to fire beacons to gather metrics for the ads in the original livestream.

Note

There is an important concern among broadcasters about the legacy devices impact. It is important to maintain compatibility with the existing device population. By using a single-period manifest the legacy devices can simply ignore the additional ad signaling.