What is SCTE?

The acronym SCTE is short for The Society of Cable and Telecommunications Engineers. SCTE is a non-profit professional organization that creates technical standards and educational resources for the advancement of cable telecommunications engineering and the wider video industry. When talking about it, you may hear people abbreviate SCTE with the shorthand slang “Scutty”. 

SCTE was founded in 1969 as The Society of Cable Television Engineers, but changed its name in 1995 to reflect a broader scope as fiber optics and high-speed data applications began playing a bigger role in the cable tv industry and became the responsibility of its engineers. Currently there are over 19,000 individual SCTE members and nearly 300 technical standards in their catalog, including SCTE-35, which will be the focus of this post.  

What is SCTE-35?

SCTE-35 was first published in 2001 and is the core signaling standard for advertising and program control for content providers and content distributors. It was initially titled “Digital Program Insertion Cueing Message for Cable” but recent revisions have dropped “for Cable” as it has proven useful and versatile enough to be extended to OTT workflows and streaming applications. There have been several revisions and updates published to incorporate member feedback and adapt to advancements in the industry, most recently on Nov, 30 2023.

SCTE-35 signals are used to identify national and local ad breaks as well as program content like intro/outro credits, chapters, blackouts, and extensions when a live program like a sporting event runs long. Initially, these messages were embedded as cue tones that dedicated cable tv hardware or equipment could pick up and enable downstream systems to act on. For modern streaming applications, they are usually included within an MPEG-2 transport stream PID and then converted into metadata that is embedded in HLS and MPEG-DASH manifests. 

SCTE-35 markers and their applications for streaming video

While SCTE-35 markers are primarily used for ad insertion in OTT workflows, they can also signal many other events that allow an automation system to tailor the program output for compliance with local restrictions or to improve the viewing experience. Let’s take a look at some common use cases and benefits of using SCTE-35 markers.

Use cases and benefits of SCTE-35

Ad Insertion – As mentioned above, inserting advertisements into a video stream is the main use case for SCTE-35 markers. They provide seamless splice points for national, local and individually targeted dynamic ad replacement. This allows for increased monetization opportunities for broadcasters and content providers by enabling segmenting of viewers into specific demographics and geographic locations. When ad content can be tailored for a particular audience, advertisers are willing to pay more, leading to higher revenue for content providers and distributors. 

Program boundary markers – Another common use case is to signal a variety of program boundaries. This includes the start and end of programs, chapters, ad breaks and unexpected interruptions or extensions. Many of these become particularly useful in Live-to-VOD scenarios. Ad break start/end markers can be used as edit points in a post-production workflow to automate the removal of ads for viewers with ad-free subscriptions. A program end marker can be used to trigger the next episode in a series for binge viewing sessions if so desired. All of these markers open new possibilities for improving the user experience and keeping your audience happy and engaged.  

Blackouts and alternate content – Another less common, but important use case is to signal blackouts, when a piece of content should be replaced or omitted from a broadcast. This often applies to regional blackouts for sporting events. Respecting blackout restrictions is crucial for avoiding fines and loss of access to future events. Using SCTE-35 allows your automation system to take control and ensure you are compliant.

Types of SCTE-35 markers

SCTE-35 markers are delivered in-band, meaning they are embedded or interleaved with the audio and video signals. There are five different command types defined in the specification. The first 3 are legacy commands: splice_null(), splice_schedule() and splice_insert(), but splice_insert() is still used quite often. The bandwidth_reservation() command may be needed in some satellite transmissions, but the most commonly used command with modern workflows is time_signal(). Let’s take a closer look at the 2 most important command types, splice_insert and time_signal. 

splice_insert commands

Splice_insert commands are used to mark splice events, when some new piece of content like an ad should be inserted in place of the program or a switch from an ad break back into the main program. Presentation time stamps are used to note the exact timing of the splice, enabling seamless, frame accurate switching.  

time_signal commands

Time_signal commands can also be used to insert new content at a splice point, but together with segmentation descriptors, they can handle other use cases like the program boundary markers mentioned above. This enables the segmenting and labeling of content sections for use by downstream systems.

Using SCTE-35 markers in streaming workflows

MPEG-2 transport streams

In MPEG-2 transport streams, SCTE markers are carried in-band on their own PID within the transport stream mux. These streams are usually used as contribution or backhaul feeds and in most cases are not directly played by the consumer. They may be delivered over dedicated satellite or fiber paths or via the public internet through the use of streaming protocols like SRT or proprietary solutions like Zixi.

HLS 

The Bitmovin Live Encoder supports a range of different HLS tags that are written when SCTE-35 triggers are parsed from the MPEG-TS input stream. Multiple marker types can be enabled for each HLS manifest. Which marker types to use depends on the consumer of the HLS manifest. An example consumer would be a Server Side Ad Insertion (SSAI) service. They usually state in their documentation which HLS tags they support for signaling SCTE-35 triggers.

• EXT_X_CUE_OUT_IN: Ad markers will be inserted using #EXT-X-CUE-OUT and #EXT-X-CUE-IN tags.

• EXT_OATCLS_SCTE35: Ad markers will be inserted using #EXT-OATCLS-SCTE35 tags. They contain the base64 encoded raw bytes of the original SCTE-35 trigger.
• EXT_X_SPLICEPOINT_SCTE35: Ad markers will be inserted using #EXT-X-SPLICEPOINT-SCTE35 tags. They contain the base64 encoded raw bytes of the original SCTE-35 trigger.
• EXT_X_SCTE35: Ad markers will be inserted using #EXT-X-SCTE35 tags. They contain the base64 encoded raw bytes of the original SCTE-35 trigger.
• EXT_X_DATERANGE: Ad markers will be inserted using #EXT-X-DATERANGE tags as specified in the HLS specification. They contain the ID, start timestamp, and hex-encoded raw bytes of the original SCTE-35 trigger.

Example HLS manifest with Cue Out, duration and Cue In tags:

#EXTINF:4.0,
2021-07/video/hls/360/seg_18188.ts
#EXT-X-CUE-OUT:120.000
…
#EXTINF:4.0,
2021-07/video/hls/360/seg18218.ts
#EXT-X-CUE-IN

Example HLS manifest using EXT-OATCLS-SCTE35 tag with base64 encoded marker:

#EXTINF:4.0,
2021-07/video/hls/360/seg_18190.ts
#EXT-OATCLS-
SCTE35:/DBcAAAAAAAAAP/wBQb//ciI8QBGAh1DVUVJXQk9EX+fAQ5FUDAxODAzODQwMDY2NiEEZAIZQ1VFSV0JPRF/3wABLit7AQVDMTQ2NDABAQEKQ1VFSQCAMTUwKnPhdcU=

Note: You can copy the base64 encoded marker above, (beginning with the first / after SCTE35: ) and paste it into this payload parser to see the full message structure.

MPEG-DASH 

In MPEG-DASH streams, SCTE-35 defined breaks and segments are added as new periods to the .mpd file.

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

<Period start="PT32S" id="2">
    <!-- Ad Break Period -->
   <EventStream timescale="90000"
    schemeIdUri="urn:scte:scte35:2014:xml+bin">
     <Event duration="2520000" id="1">
       <Signal xmlns="urn:scte:scte35:2013:xml">
         <Binary>      /DAlAAAAAAAAAP/wFAUAAAAEf+/+kybGyP4BSvaQAAEBAQAArky/3g==
         <Binary>
       </Signal>
      </Event>
    </EventStream> 
</Period>

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

With SCTE messages embedded in the stream, various forms of automation can be triggered, whether it’s server or client-side ad insertion, content switching, interactive elements in the application or post-production processing.

Bitmovin Live Encoding SCTE Support

SCTE message pass-through and processing 

Bitmovin supports the parsing of SCTE-35 triggers from MPEG-TS input streams for Live Encodings, the triggers are shown below as splice decisions. The triggers are then mapped to HLS manifest tags.

Splice Decisions

Certain SCTE-35 triggers signal that an advertisement or break (to from the original content starts or ends. The following table describes how the Bitmovin Live Encoder treats SCTE-35 trigger types and SCTE-35 Segmentation Descriptor types as splice decision points, and the compatibility of those types with the different command types, Spice Insert and Time Signal.

✓= Supported

= Not currently supported

Segmentation UPID Type (Start/End)	Descriptor Type Name	SPLICE_INSERT	TIME_SIGNAL
–		✓
0x10, 0x11	PROGRAM	✓
0x20, 0x21	CHAPTER	✓
0x22, 0x23	BREAK	✓	✓
0x30, 0x31	PROVIDER_ADVERTISEMENT	✓	✓
0x32, 0x33	DISTRIBUTOR_ADVERTISEMENT	✓	✓
0x34, 0x35	PROVIDER_PLACEMENT_OPPORTUNITY	✓	✓
0x36, 0x37	DISTRIBUTOR_PLACEMENT_OPPORTUNITY	✓	✓
0x40, 0x41	UNSCHEDULED_EVENT	✓
0x42, 0x43	ALTERNATE_CONTENT_OPPORTUNITY	✓
0x44, 0x45	PROVIDER_AD_BLOCK	✓
0x46, 0x47	DISTRIBUTOR_AD_BLOCK	✓
0x50, 0x51	NETWORK	✓

Live cue point insertion API

In addition to the SCTE-35 pass-through mode, Bitmovin customers can insert new ad break cue points in real-time, using live controls in the user dashboard or via API. These can be inserted independently of existing SCTE-35 markers in the input stream and may be useful for live events when the time between ads is variable depending on breaks in the action. This allows streamers that don’t have SCTE-35 markers embedded in their source to take advantage of the same downstream ad insertion systems for increased monetization.

API Call:

POST /encoding/encodings/{encoding_id}/live/scte-35-cue
    {
      "cueDuration": 60, // duration in seconds between cue tags (ad break length)
    }

The #EXT-X-CUE-OUT tag will be inserted into the HLS playlist, signaling the start and duration of a placement opportunity to the DAI provider. Based on the cueDuration and the segment length, the #EXT-X-CUE-IN tag will be inserted after the configured duration and the ad opportunity will end, continuing the live stream.

HLS manifest with Cue Out, duration and Cue In tags inserted via the API call above:

#EXTINF:4.0,
    2021-07-09-13-18-34/video/hls/360_500/segment_18188.ts
    #EXT-X-CUE-OUT:60.000
    #EXTINF:4.0,
    2021-07-09-13-18-34/video/hls/360_500/segment_18189.ts
    ...
    #EXTINF:4.0,
    2021-07-09-13-18-34/video/hls/360_500/segment_18203.ts
    #EXT-X-CUE-IN
    #EXTINF:4.0,
    2021-07-09-13-18-34/video/hls/360_500/segment_18204.ts

Want to get started using SCTE-35 in your streaming workflow? Get in touch to let us know how we can help.

Resources

Tutorial: Bitmovin Live Encoding with SCTE-35, HLS and SSAI

Guide: Bitmovin Live Encoding and AWS MediaTailor for SSAI

Guide: Bitmovin Live Encoding with Broadpeak.io for SSAI

SCTE website 

SCTE-35 specification

SCTE-35 payload parser

Bitmovin Live Encoding data sheet

The post The Essential Guide to SCTE-35  appeared first on Bitmovin.

In this blog, we will focus on SSAI, how it works, the use cases and challenges for specific workflows and devices, and the different factors that come into play when implementing it.

What is Server-Side Ad Insertion (SSAI)?

To begin exploring the topic, let’s delve into what SSAI is and its benefits. The technology enables ads to be directly delivered within the streaming protocol, seamlessly stitching them into the video stream on the server side just before making it available to viewers. The advantages of this approach include:

• Bypassing ad-blockers – This ensures ads reach viewers
• Smoother integration – Transition from content to ad is more natural
• Improved viewer experience – less buffering and interruptions during playback
• Increased ad revenue – Advertisers are able to stream better-targeted ads to specific user bases
• Flexibility – Ads can be adjusted in real-time, engaging viewers with more personalized ads that meet their interests

A diagram showing how SSAI works

How is it applied to HLS and DASH streams?

As adaptive bitrate (ABR) streaming is the standard for every platform streaming over the internet, SSAI needs to work in the context of two popular video streaming protocols – Dynamic Adaptive Streaming over HTTP (DASH) and HTTP Live Streaming (HLS). While both protocols use fragmented mp4 (ISO BMFF) or transport stream (TS) segments to deliver video content over HTTP to viewers, some protocol differences make the SSAI implementation different for each.

The Dash Implementation

In DASH, SSAI is usually implemented using Media Presentation Description (MPD) Periods. The concept of Periods enables the boundaries between periods in the stream timeline to contain different streaming properties (like codecs, encryption, different adaptations, etc.). When the stream manifest is requested, the ad server in the background resolves ads be delivered within the content and creates MPD Periods at specific advertising time slots. These Periods then contain already chunked ads with their metadata stitched to the original MPD manifest before it is delivered to the viewer’s device.

The HLS Implementation

In HLS, SSAI is often integrated using EXT-X-DISCONTINUITY tags which are present in media playlists. This concept is similar to Periods in DASH, but the main difference is that discontinuities across different playlists (like audio and video) do not have to be aligned. This approach may involve splitting the segmented video stream into smaller segments and splicing them at the appropriate point to insert the ad (the same is valid for DASH). Depending on development expertise and protocol preference, it may require more complex implementations, especially for live scenarios.

A diagram showing the setup of SSAI in DASH and HLS streams

Ads may be injected into both DASH and HLS manifests only into single Periods or playlists without discontinuities, but this approach presents another set of difficulties. The ad segments need to follow the same encoding for adaptation profiles and time synchronization as the main content, which can be challenging when ads need to be inserted in variable time slots or live streams. Also, if the content is encrypted or DRM (Digital Rights Management) protected, the ads must be encrypted using the same encryption schema, which might not be feasible on a large scale. Another problem is client-side tracking requiring specific metadata like EMSG in a container format or Events and Timed Metadata inside the manifest.

Common SSAI use cases and their challenges

SSAI alongside DRM

SSAI is often required to work all along the DRM systems. DRM systems like Widevine, Fairplay, or PlayReady typically use common encryption algorithms to protect the content and require viewers to obtain a license or key to access it. This prevents piracy and other unauthorized access or distribution of the content.

As mentioned above, ads are often delivered separately from the video content and may not be encrypted, so they are placed into separate DASH Periods or HLS discontinuities to be correctly played back on target devices.

A diagram showing SSAI stitched within a DASH stream that is encrypted with DRM

Handling the transition from unprotected to encrypted content may also be challenging on the client side. For example, many steps must be done on MSE and EME API when integrating with javascript clients, like recreating SourceBuffers or waiting for license requests.

In addition to encryption, DRM can also control the distribution and access to ads. This can help prevent unauthorized sharing or reuse of ad content and ensure that the ads are only shown to authorized viewers. By working together, SSAI and DRM can help protect digital video content and ensure it is monetized effectively.

Utilizing SSAI in live streaming

In live streaming, SSAI is a powerful way to deliver targeted and personalized ads to viewers. When implemented, it can reduce latency during the transition between the content and the advertisement during playback. It can also enable dynamic ad scheduling, allowing the platform to change the ads due to inventory or campaign requirements. However, one of the main SSAI challenges is the need to handle segment timestamps carefully to ensure that the ads are inserted at the appropriate point in the video stream. This is because live video streams are constantly changing, and the timing of each segment can vary based on factors such as network latency and processing time.

In order to handle segment timestamps in live streaming, SSAI systems typically use so-called boundary detection. This involves analyzing the incoming video stream to detect critical points or boundaries between segments and then using this information to insert ads at the appropriate moment. In boundary detection, the SSAI system monitors the video stream for changes in the keyframe or scene, which usually indicate the start or end of a segment. The system then uses this information to determine the timing and duration of each segment and to insert ads accordingly. This process requires careful synchronization between the video stream and the ad server to ensure that the ads are inserted at the right time and do not interfere with the viewer’s experience.

A diagram that shows SSAI stitched within a live stream

Due to the considerable complexity of boundary detection, when SSAI is present in the live stream, the main content segments typically have large presentation timestamps (PTS). However, segmented ads present in DASH Periods or HLS discontinuities for dedicated ad slots usually have PTS starting from 0. This may present issues to be handled on the player side as making timestamp continuous is challenging and might introduce some buffering issues.

One last complication to handle in HLS is the effect of splitting the last and first segments of the content stream where the ad is being placed. This often presents issues with the alignment of buffered ranges and may cause playback stalls if not handled correctly.

SSAI in streams viewed on Smart TVs

Delivering SSAI-enabled streams on Smart TVs has its benefits with specific challenges that must be faced, and there are multiple reasons for that. Most smart TV platforms are based on a browser-like environment running JavaScript. LG WebOS, Samsung Tizen, and other smart TV operating systems are exposing native player APIs that are, by their specifications, capable of playing adaptive streams in DASH or HLS. This sounds promising, but unfortunately, streams containing SSAI often do not work, and there is also an absence of proper logs to figure out what is wrong. These native players also do not give much control over how the stream is played back, like managing buffering and controlling ABR algorithms.

The benefit is that most of these platforms also support media source extensions (MSE) and encrypted media extensions (EME) API to manage video streaming using JavaScript, so players supporting SSAI in browsers should work. However, the issue with Smart TVs is the lack of standardization across different platforms. Each Smart TV manufacturer may implement different versions of protocols and specifications of APIs for handling streaming. This often brings various technical limitations to the platform environment, leading to issues supporting different devices. One issue is rollovers in segment timestamps which are common in many live streams, or possible changes in properties of the ad and content segments like encoding parameters, codec, encryption (DRM) transitions, etc. Another issue with SSAI on Smart TVs is the potential for buffering or latency. Smart TVs often have limited processing power and memory, making it difficult to handle ad transitions and provide stable buffering.

Addressing these issues, platforms looking to support these devices and have SSAI-enabled streams playing on them need to put in a lot of effort and perform a lot of black-box testing to figure out the best integration for their streaming workflow. Working closely with Smart TV manufacturers is often required to ensure the ad insertion process is standardized and optimized for their platform. This is why when deploying on different smart TVs and devices in general, it is crucial to consider the unique challenges of supporting them and the steps it takes to optimize the viewing experience for users.

SSAI workflow and third-party providers

Implementing SSAI is usually very complex, which is why many platforms outsource the technical integrations to third-party providers that are running their own SSAI services and are capable of delivering ads into a prepared manifest. There are various providers to choose from like:

• Google Ads Manager DAI (Dynamic ad insertion)
• MediaTailor provided by (Amazon Web Services)
• Yospace
• Broadpeak

The architecture of how SSAI providers integrate with the whole streaming delivery pipeline is a very interesting topic, and we plan to go into further depth on it in a future blog post. In the meantime, we recommend reading our SSAI and Adblocking blog that focuses more on this if you want to learn more.

Playing SSAI-enabled streams with the Bitmovin Player

The Bitmovin Player is designed to work seamlessly with server-side ad insertion solutions. It allows for the dynamic insertion of ads into video streams, ensuring a smooth playback experience for viewers. The Player supports ad stitching, seamlessly blending the ads with the video content during playback. This helps maintain a continuous and uninterrupted viewing experience.

The Bitmovin Player is also pre-integrated with Bitmovin’s Analytics and the Open Measurement Interface Definition (OMID) with its dedicated SDK. This helps give you actionable insights related to your audience and quality of experience metrics while tracking ad events. This data can help you adjust and set where your SSAI ads are utilized since you’ll know your most popular content, where/when viewers are watching it, and how your content and ads perform when streamed, ensuring a smooth viewing experience. Ultimately this will help you optimize your monetization strategy and maximize your business’ potential. To see SSAI in action, check out the Bitmovin player SSAI demo page.

In case there are any device limitations supporting SSAI streams, Bitmovin Player is also compatible with CSAI (Client-side ad insertion) solutions like VAST (Video Ad Serving Template) and VMAP (Video Multiple Ad Playlist) standards produced by IAB (Interactive Advertising Bureau). For more on Bitmovin’s CSAI support, we will be writing up a dedicated blog about it soon, but in the meantime, you can see how it works with our Player by trying our CSAI demo.

Stitching it up

From what we’ve listed above, Server-Side Ad Insertion (SSAI) provides several advantages, including bypassing ad blockers, seamless ad integration, enhanced viewer experience, increased ad revenue, and content security with DRM systems. However, implementing SSAI in streaming workflows for specific devices can be complex due to platform differences and technical limitations. Apart from platforms doing it themselves, Player options like Bitmovin’s can help streamline the process, enabling effective ad monetization and a smooth viewing experience, enhanced with OMID and Analytics integrations for effective workflow optimization. Overall, SSAI remains a potent tool for content providers to monetize their video streaming workflows and maximize revenue potential.

If you’d like to see how Bitmovin’s solution stack can benefit your streaming workflow – sign up for our 30-day free trial.

The post Under the Hood of Server-Side Ad Insertion (SSAI) – The Challenges of Implementing Ad Monetization Technologies appeared first on Bitmovin.