Today, we will be discussing the concept of SCTE-35. Suppose you have ever watched a live television show. In that case, you may have noticed a sudden interruption in the program, followed by a change of content, a commercial, or a promotional video. These interruptions are usually coordinated by a technology known as SCTE-35, which can insert and signal specific events within a video stream, such as ad breaks, content promotions, and program start/stop times.
Nowadays, SCTE35 is more relevant than ever. It has existed for a long time in the video space. Still, with advertising dollars moving from traditional TV networks to OTT streaming platforms – SCTE35 is critical in ensuring TV stays dynamic in this new Internet territory.
In this post, we will take a closer look at what SCTE-35 is, how it works, how it has transformed the landscape of the pay-tv industry, and, to finish, what kind of applications it enables with modern streaming platforms.
What is the SCTE-35 Standard?
SCTE 35 (ANSI/SCTE 35 2013) is an ANSI and Society of Cable and Telecommunications Engineers standard that specifies guidelines for inline cue tone insertion in streams. The standard name is “Digital Program Insertion Cueing Message for Cable.”
These signals, also known as markers or tags, are event-signaling messages into the MPEG transport stream of a live video. They indicate where content distributors can insert, replace, or splice content into a stream.
These messages can trigger various events, such as ad insertion, content replacement, and blackout management. For example, suppose you want to replace ads with a live stream; SCTE-35 can signal the start and end times of specific ad breaks. Then down the line, you can use the markers to replace and deliver ads to different regions or demographics based on their preferences or interests.
For instance, viewers in one region may see an ad for a local restaurant, while viewers in another area may see an advertisement for a different product that is more relevant to them. This allows advertisers to maximize their impact while minimizing waste and gives viewers a more personalized and engaging ad experience.
Where does it come from?
SCTE 35 was built originally to insert local content in the transport streams.
The fact to splice content in streams is almost as old as the traditional broadcast networks used in the Pay TV industry.
Initially, it was done using DTMF (Dual tone multi-frequency) cue tones in analog audio channels, but it was replaced by SCTE 35 data signaling in DPI (digital program insertion) PIDs.
It is considered the first standardization workaround started by SMPTE ST 312M Television – Splice Points for MPEG-2 Transport Streams. SMPTE 312M has later moved to SCTE, the base for SCTE35.
It is also broadly used for Over-The-Top Streams, delivered using Adaptive Bitrate Streaming protocols (ABR) such as HLS or DASH.
Historically explicitly designed for ad insertions, SCTE35 offers excellent flexibility and can be used in other cases, such as, among others, rights management or programming.
Structure of SCTE-35
First, it is crucial to understand that SCTE35 is an in-band standard: SCTE-35 packets are multiplexed with video and audio packets in the transport stream.
SCTE-35 consists of a header and a payload. The header contains information about the event message, while the payload contains the actual event data.
The header includes fields for time, duration, and other event-specific information.
The payload syntax is called splice_info_section() and signals different commands. You can consider that the most important commands are splice_insert() and time_signal().
Splice_insert
Splice_insert signals a splice event, such as an ad placement opportunity.
Out_of_network_indicator equals “1” signals to switch from the network program to an advertisement. When it is back to out_of_network_indicator = 0, it signals to switch back to the network program.
The timing of the splice event is specified in terms of the Presentation Time Stamp (PTS). If you are unfamiliar with it, it is a timing value used to synchronize the playback of audio and video frames. PTS values are typically expressed in units of 90 kHz clock ticks, which correspond to the clock rate used in MPEG-2.
Time_signal
To help with program segmentation, SCTE35 relied on a combination of time_signal command and segmentation_descriptor. The time_signal command signals a timestamp of the segmentation when segmentation_descriptors carry the details.
The segmentation_descriptor objects can be Networks, Programs, Chapters, Breaks, etc… in a nutshell, any notifiable event within a linear channel. It also notifies of restrictions for the delivery (think Blackout, for example).
Time_signal permits to manage more use cases than Splice_insert and slowly starts to be the new reference for SCTE35 implementation.
Here is how you can signal SCTE35 in ABR streaming formats:
HLS
In HLS, SCTE 35 tags are visible in the .m3u8 manifests. Three main types of tags are used in HLS to signal ad opportunities in a manifest.
The main difference between the three is how they handle timing: for example EXT-X-DATERANGE relies on UTC, and EXT-X-CUE-IN/OUT depends on the position in the playlist.
- EXT-X-DATERANGE tag
The reference standard for ad markers in HLS manifest files is EXT-X-DATERANGE in the HLS RFC:
https://tools.ietf.org/html/rfc8216#section-4.3.2.7
EXT-OATCLS-SCTE35tag
OATCLS-SCTE35 is containing the base64 encoded raw bytes of the original SCTE-35 advertising available message.
- EXT-X-CUE-OUT and EXT-X-CUE-IN tags
EXT-X-CUE-OUT/IN are proprietary but widely used markers in the advertising industry.
#EXT-X-CUE-OUT:<duration>,[<scte35-out>]
#CUE-IN:[<scte35-in>]The start of an ad insertion or splicing event is indicated by the #EXT-X-CUE-OUT tag, which also usually contains the length of the event (the exception being blackout which is not specifying the duration).
The event’s SCTE 35 binary splice data is included in the optional <scte35-out> argument.
Similarly, the optional <scte35-in> component, which holds the SCTE 35 binary splice information for the event, is included in the #EXT-X-CUE-IN tag, which marks the conclusion of an ad insertion or splice event.
DASH
The MP4 media segments in DASH contain SCTE 35 tags inserted as Event messages.
An SCTE 35 tag in DASH has the following syntax:
<Event presentation_time="PT0S" duration="duration" event_id="event_id" message data="base64-encoded-scte35-message">The SCTE 35 tag’s presentation time element indicates the time of the segment’s beginning.
The duration attribute represents the splice event’s duration.
This attribute identifies the event’s id.
The event’s SCTE 35 binary splice data is base64-encoded in the message data property.
‼ Note that the exact syntax of SCTE 35 tags in HLS and DASH may vary depending on the implementation and the specific use case. ‼
Use Cases for SCTE-35 Standard
The SCTE-35 can be used for various use cases, including ad insertion, regionalization of national feeds, replacing content, or managing blackouts. In a nutshell, SCTE35 is all about segmenting the live feeds. It indicates where and when you can replace content from a source. That gives much control to video distributors over the content they show.
Here are a few examples:
- Ad replacement: one of the most common use cases where the markers can provide more granular control over when and where ads are inserted. It can also tailor ads to specific audiences, increasing engagement and ROI.
- Linear Parity: a subset case of Ad Insertion focusing on the insertion of regional ads. In that case, the schedule is directly programmed by CCMS, indicating which national ads need to be replaced by local ads using the SCTE35 to trigger the replacement.
- Content replacement: another use case. For example, suppose a broadcaster needs to replace a piece of content due to licensing issues. In that case, they can use the markers (in complement of another standard, SCTE-224 – that we have described here) to trigger the end of the replacement in real time, minimizing the impact on the viewer experience. This is the typical “blackout” use case.
- Ads replacement in delinearized TV:
- In catch-up tv or personal video recording (PVR), viewers can watch previously aired TV content on-demand. These recorded programs often include ads as they did when the program originally aired.
- Using SCTE 35 cues, the delinearized TV provider can identify the specific points in the video stream where the ads were initially inserted during the live broadcast. It can then be used to insert the same ads into the catch-up TV program at the appropriate points. This helps to maintain the intended viewing experience and ensure that the ads are displayed in the same context as the live broadcast.
- Other miscellaneous cases are, in theory, possible, but we did not see them deployed on a large scale yet:
- Delimiting programs for DVR recording or creating VOD content from Linear channels
- EPG is typically used for that case today.
- Enforcing DRM restrictions on specific programs and regions
- We have not seen demands for this kind of case yet.
- Delimiting programs for DVR recording or creating VOD content from Linear channels
Implementation of SCTE-35 Standard
To enable all these use cases, we need to ensure that SCTE35 messages appear in the source and ensure they are still there after the different steps of the OTT video chain (encoding, packaging) up to the Video Stitcher (also called Manifest Manipulator).
Here is an example of workflow on how some programmers make sure the SCTE35 appear in the feed.
- They have their original SDI linear video feed going through an inserter (this can also be done on some encoders), which will be responsible for adding SCTE-104 markers in the SDI feed (in the VANC using SMPTE-2010 to be exact). SCTE104 are baseband markers decorating the video feeds.
- An automation system should control the inserter, triggered by a Scheduling system or Public Schedules via SMPTE BXF.
- Now the feed is ready to be compressed! The SDI with SCTE-104-markers gets into an encoder which will generate a compressed TS stream, with SCTE35 markers, based on the SCTE104 ones.
- They now have a compressed TS linear feed with SCTE35, which distributors can use for transcoding/packaging/distribution.
Most OTT distributors (virtual and non-virtual MPVDs, aggregators, etc…) are typically getting involved at that step – ingesting the feeds via SRT or another kind of contribution protocol. Here is what generally is happening there:
- Verification that the input video contains SCTE-35 markers. We have seen distributors not receiving the markers because they were lost during contribution. In that case, a re-insertion of the markers is necessary, sometimes via Automatic Ad Detection.
- The feed will go to the transcoder to create multiple levels of quality used by Adaptive Bitrate protocols. After that, it will pass through a packager to create HLS and DASH versions of the feeds. It is critical at that stage to enable SCTE-35 passthrough in the transcoding and packaging settings.
- Test your output streams to verify that they contain SCTE-35 markers. You can directly see it in the manifest files (“.m3u8” and “.mpd”) with the above syntax.
At this stage, the HLS/DASH feeds are ready for manipulation! A Video Stitcher solution, such as broadpeak.io, can then take over and make the manipulations needed for the different business cases. The Video Stitcher will be controlled by third-party systems such as Scheduler for Content Replacement (typically using SCTE224) or Ad Server for DAI (using VAST or VMAP).
Overall, implementing and exploiting SCTE35 signaling requires coordination between the different components of your video delivery chain, between video encoding, ad decision, and delivery systems. You may need to work with your vendors or consult with experts in SCTE35 to ensure that you follow best practices and standards.
!! I purposely did not discuss ESAM and POIS for this piece’s simplicity. Distributors typically use these for signal and manifest conditioning. I will get into this in a different blog post. !!
Conclusion
SCTE-35 markers provide a standardized method for triggering events in live OTT video streams. It leads to the automatic and accurate event starting. That helps to control the addition and replacement of content in a safe and interoperable way.
At broadpeak.io, we use SCTE35 daily to trigger replacements of ads and content. We are grateful for this standard to exist as it helps simplify the integration of our customers’ projects.
Also, SCTE35 is highly complementary to SCTE224, another standard we support and promote. Together, these standards enable content providers and service providers to manage their programming more efficiently, reducing complexity and operations while providing viewers with a smoother experience.
Suppose you need more practical details on how to enable/use SCTE35; two solutions: you can review the recommended practices in [SCTE 67] “Recommended Practice for Digital Program Insertion for Cable” or contact us!
