What Is SCTE-35 and What Is It Good For?

Nothing is simple. In the digital age, that’s more or less a hard-and-fast rule—everything we interact with in our day-to-day, from cars to phones to the toaster on your kitchen counter, has layers of abstraction and interconnectivity in order to interface with other digital devices. What’s more, since the digital revolution wasn’t done in one fell swoop, there are layers and layers of history behind the design and development of things we take for granted.  

Take for example serving ads on network television. At first glance, this would seem like a simple prospect—just cut the feed from the main broadcast and turn on a recording of a commercial. But the more you think about it, the more questions arise. How do you “just cut the feed” reliably and switch to commercials without introducing a chance for operator error? How do you account for remote broadcasts where the studio providing the main feed doesn’t have every single commercial on file? What about serving local ads when a program is broadcast to multiple networks—how do you do that? Nothing is simple…

Fortunately, there is a system in place to handle all of these issues seamlessly: the SCTE-35 standard, which injects “SCTE markers” into a broadcast feed. Simply put, these cue ad insertion opportunities and other events at specific points in time on a broadcast, adding flexibility and functionality to an otherwise “bare” camera feed. But how did this come about? What can it do to make a broadcast better? To answer that, let’s go over the genesis of SCTE-35 and its predecessors—it’s a more interesting story than you might imagine. Let’s go back to the beginning…


Yes, this is where the story starts. Think about it—before the advent of Internet protocols with packets that could contain any information you need, how did the act of dialing a number cause your line to be connected properly? It’s not as though there was a separate line to transfer that data to a switching center—a telephone connection is just a single pair of wires.  

The answer is in-line signaling. Through an encoder built into every landline phone, dialing (either literally, in the case of rotary phones, or by pressing buttons on a keypad) a number causes a series of tones to be sent along the phone line in the same way voice is transmitted. This signal is sent to a telephone exchange, where it is automatically processed into commands to establish a connection from the sender to the receiver. In some cases, this even involved physical connections being established by motorized shuttles, though most systems involve simple electrical or electromechanical relays.

A vintage panel switch once used to route hundreds of calls using the methods we’re discussing. Isn’t it great that old technology gets preserved?
I hope our target audience is old enough to remember Touch-Tone phones, but at this point… who can be sure?

At first, the signal standard used for this system was pulse dialing, which generated a simple series of on-off pulses by interrupting the connection to the telephone exchange directly. (This is how rotary phones work, and the specificity of the pulse rate is why all rotary phone dials turn at about the same speed.) However, this system was significantly limited in the speed at which you could dial, and the requirement to physically “cut” the connection intermittently meant the distance a phone could be from the switching station was limited.

To resolve this, Bell developed an alternative in the early 1960s called dual-tone multi-frequency signaling, or DTMF. Instead of interrupting the connection to the telephone switching system directly, DTMF sent a pair of tones (hence the name) whenever a button was pressed on a phone’s keypad. This system, which is more well-known as Touch-Tone, introduced push-button phones to the general public and allowed for increased performance of telephone systems. Signals from a phone could be sent faster, to an exchange any distance away, with a much lower chance for distortion—and the dual-tone system allowed for more characters to be encoded on the same system than just numbers. (This is when the star (*) and pound (#) sign were introduced!) This system is still the groundwork for how conventional phones operate today.


What does this have to do with ad insertion? We’re getting there. Recall that telephone exchanges process the audio signal a phone sends them and can convert that into an action like flipping a relay or starting a motor. (You may already see where this is going.) In the late 20th century, it became clear that this system could be utilized elsewhere to embed commands into an audio signal that was designed to support voice frequencies. To send credit card information, pay phones embedded strings of DTMF tones into their signal. VHS tapes sometimes use DTMF to encode information about the program duration and type. And, in 2001, the Society of Cable Telecommunications Engineers released the first version of the SCTE-35 standard, which embedded DTMF tones into television audio channels for signaling.

A broadcast-quality DVCPRO tape player. Contrary to popular belief, tapes are still alive and well in the realm of TV and data backup!

This initial implementation was fairly simple. Essentially, an audible DTMF tone was assigned to a small number of events, namely the start and end of approved ad blocks. A studio would play these tones directly into the audio feed of their broadcast “on its way out,” as it were, to be processed by networks downstream. These DTMF signals would start and stop videotape players built into the broadcast architecture to insert advertisements—either wholesale to supplant the source studio’s advertisement injection capability, or partially, to include local ads in a larger commercial block. Being based on a proven standard and utilizing very little new hardware (in most cases, a DTMF decoder and interface was all that was needed, as studios would already have equipment to play taped commercials) meant that adoption was fairly effortless and soon became widespread. 

Of course, the injection of tones into the audio channel being fed to consumers wasn’t a perfect solution, though it added a great deal of flexibility. If the timing of the broadcast systems wasn’t completely correct, the signaling tones would play in full before the tape of the injected advertisement began to play—as you can imagine, this wasn’t an ideal experience for the end user. (You may recall this happening when watching TV in the early 2000s, often accompanied with a black or flashing screen before a commercial began.) Additionally, though the base 16 DTMF tones were more than enough for controlling a telephone exchange, it limited the potential for SCTE-35 to expand its capabilities with more information and signaling. A change was needed to improve performance and pave the way for the future…


The very first broadcast TV station started service in 1928, setting a global standard for analog television systems. Analog TV is, to put it lightly, dead simple. It consists of two separate signals (usually) pushed over radio, one each for video and audio. As the standards for analog TV in the United States were established in 1941, you can imagine they’re fairly limited in capability. For decades, TV audiences had to make do with 480i resolution for the majority of broadcasts—and as cameras, computers, and home video media grew more capable of handling higher resolutions, this 480i standard became more and more restrictive. In order to support higher (and multiple) resolutions, markets worldwide transitioned to digital TV starting in the early 2000s, with the digital “flip” in the United States taking place in mid-2009.

A map of the global digital television transition. Countries in red have completely switched over, while those in orange, yellow, and green have varying degrees of implementation.

A digital TV signal can carry dramatically more information than its analog predecessor as a result of improved bandwidth, and the SCTE-35 standards were updated to take advantage of this. Though the standard retained support for DTMF signals for compatibility with older hardware (and indeed still does today), the main functionality of the standard was overhauled with an all-digital system. Now, advertisements are indicated in a video stream using “SCTE-35 markers,” which are brief code segments added to a video data stream as metadata. No longer are commands relayed down the line using audible signals—SCTE markers are “silent” additions to a broadcast, only “noticed” and interpreted by equipment designed to process the relevant data. Moreover, the new SCTE-35 standard is compatible with the modern Internet streaming protocols HLS and MPEG-DASH (see an earlier blog post for a breakdown on those!) which adds compatibility with online streaming and broadcasting services, greatly improving reach. 

Despite these improvements, however, the basic operation is quite similar from a broad perspective. Broadcasting hardware injects SCTE markers into a transport stream to indicate the start and end of advertising opportunities—though instead of playing a tone at the proper times, each marker is simply a timestamp to denote when a downstream ad provider can insert their own commercials. Depending on the stream format, this can occur as a pair of commands reading essentially “start at this timestamp and end at this timestamp” or “start at this timestamp and play for (value) seconds and frames”. Having support for both opens up compatibility for new hardware and software and improves accessibility for more studios.

How a SCTE marker looks when it’s actually injected into an MPEG-DASH stream in raw code.

As the system is fairly open-ended, modern SCTE-35 markers can also be used for more purposes, including denoting chapter or segment breaks in broadcast shows and movies to allow for greater content control all the way down to local broadcasters. For example, if a particular segment in a broadcast movie was considered objectionable in one region, local broadcasters could use SCTE-35 markers to automatically black out that segment and replace it with local programming. In fact, SCTE markers could be used for signaling nearly anything, limited only to what equipment downstream can interpret. Studios large and small can utilize SCTE-35 to control broadcasts with terrific precision and ease—including our studio here in Boulder.


BCC Live is a relatively small company, but we leverage our mastery of broadcast technology to put on world-class shows to a global audience. A major part of that is our usage of SCTE markers to interface with our downstream partners. For most shows, we have a single staff member running the broadcast—coordinating cameras, switching signals, communicating with our onsite hosts, and setting up commercial breaks. Though this sounds daunting, it’s perfectly manageable with the right hardware!

When it comes time to insert an ad break, our team member signals the hosts with a countdown to cut. While the hosts wrap up their comments, we prepare for the cut—though it doesn’t take much! All it takes is cutting to black and pressing a key on our control deck to insert a SCTE marker. In our case, this is actually a SCTE-104 marker, which requests the insertion of a SCTE-35 marker in the final broadcast stream. From there, the video feed with embedded markers is pushed to the cloud services of Amagi Media Labs, which converts the SCTE-104 markers to SCTE-35 and pushes our stream out to broadcast TV and online platforms, depending on what our clients require. The rest is self-evident based on what’s been relayed above—advertisements can be inserted with ease wherever they’re needed, by local TV networks using digital recordings or even old analog tape decks, by streaming services pushing content over the Internet, or indeed anywhere they’re needed!

Here’s the TriCaster at our home studio, resting up before the next big broadcast. Thanks for all the control you give us, little buddy!

While it seems almost anticlimactic to describe our production pipeline so concisely after an extensive history, it’s the bulk power of that history which makes our workflow so easy. The genesis of remote hardware control in telephone exchanges has caused the basic operation to be, quite literally, as easy as dialing a phone number! The whole system is straightforward to grasp from both a theoretical and operational perspective, thanks in no small part to the way it’s connected to other systems that we easily understand. SCTE-35 markers are a massive multiplier to a studio’s capability to operate effectively in the digital age, and we’re lucky to be able to utilize them in every broadcast we run.

And yes, thanks to the simplicity and backward-compatibility of the system, you could insert ad breaks by dialing an old Touch-Tone phone connected to your broadcast hardware. There’s no reason to, when a normal control deck works so well… but how much fun would that be?

I’m not saying you SHOULD. I’m not saying WE will. But imagine…

MPEG-DASH and You

Logitech MEVO Camera at IRONMAN 70.3 Victoria Finish Line

MPEG-DASH is a standardized protocol for streaming video and audio over the Internet which is part of a new wave of streaming standards. Whereas older systems, such as RTMP, were often improvised and rudimentary, building off of the “figure it out as you go” nature of the early Internet, DASH was carefully planned from the start for effective and error-resistant streaming. More and more streaming services are introducing modern streaming protocols into their system, so those of us running livestreams and broadcasts suddenly have a reason to change our methods. In particular, Vimeo has been rolling out MPEG-DASH streaming to Enterprise customers through Livestream Studio, and so we here at BCC Live have been learning the strengths and intricacies of a new protocol. 

But what was so wrong with the old way? What does a streaming protocol actually do in the pipeline from camera to screen? And is there actually a good reason to switch? Let’s dig into the details. 

It’s easy to think of a livestream as a literal “river” of data flowing from a server to a client, or a client to a server, as an unbroken “stream.” However, this simply isn’t how the Internet works. Since its inception, the Internet has relied upon the concept of packet switching—the separation of data into discrete “packets” (imagine!) which can be routed along any connection to the end user and reassembled into a video, a Web page, or anything else you may be sending. If a file is split into, say, twenty packets, each one of those could be sent along one of twenty routes to the client and arrive completely out of order, and yet, because of proper packet categorization and redundancy, the client wouldn’t know that anything was amiss. 

A simple diagram showing how packet switching works—your data is transmitted in discrete pieces that are reassembled at the recipient to recreate the original file.

In effect, a video streaming protocol operates in this way. A video stream is broken up into discrete “chunks” of anywhere from a few frames to several seconds of video and transmitted to where it needs to go. It’s where the specifics come in that we find the strengths and weaknesses of each protocol. 


Ahh, the good old days of Flash. Well, they weren’t really that good, but they WERE fun.

For years, the game to beat in Internet livestreaming was the Real-Time Messaging Protocol, or RTMP. This has been used for streaming from clients to servers to clients for years and, in the specific use case we’re talking about, is used end-to-end for streaming on Vimeo for most users.  

An interesting fact is the genesis of RTMP: the protocol was developed by Macromedia for the Flash Player, that classic mainstay of the early “Web 2.0” days. Flash has been completely discontinued as of the end of 2020, but RTMP is still in use and is now controlled by Macromedia’s successor, Adobe. As you can imagine, this makes RTMP a “legacy” product which could be discontinued at any time. 

While the possibility of the protocol becoming unavailable is troublesome enough, there are other issues to contend with. For one, RTMP has limited support for video and audio file formats, which requires a resource-intensive format change depending on your inputs. For another, the network protocol RTMP uses is more or less proprietary and doesn’t share much with other protocols, so servers have to have specific configurations to accept RTMP streams. Fortunately, the ubiquity of RTMP has meant that it’s widely supported across platforms and servers, but it’s still a limitation that can prove troublesome.  

The largest limitation, however, is a lack of support for adaptive-bitrate streaming. Adaptive-bitrate streaming is, fortunately, exactly what it sounds like: a method to dynamically scale up and down the bitrate (think, “number of packets”) of a video stream based on the speed of a connection, to ensure video playback isn’t interrupted while also providing the highest-quality video possible. This requires the video to be encoded in multiple bitrates at once and essentially simulcast to the server or client, so that the correct “channel” of video quality can be selected at any given moment. This, unfortunately, is not possible with RTMP as designed. With greater demand for high-quality video over a wide range of connection types, from gigabit fiber to cellular data, support for adaptive-bitrate streaming becomes more and more crucial as the years go on. 

Sometimes all you’ve got to watch video on is an outdated phone. And there’s nothing wrong with that! Technically.

In comes the solution. MPEG-DASH builds off of the widely-accepted standards for today’s Internet to provide greater flexibility, reliability, and performance. Unlike RTMP’s proprietary server connection, DASH embeds its video “chunks” into HTTP, the Internet protocol that runs the entirety of the World Wide Web. (That’s what the “http://” at the start of Web addresses is: the protocol by which you’re sending and receiving data through the Internet!) Since the video data is enclosed within HTTP just like any Web page, any Web server could send or receive MPEG-DASH streams without special configuration, and any client can, in theory, send and receive the stream without any concerns about running into firewalls. That’s already a great incentive to switch, but it gets better. 

MPEG-DASH is, in effect, a new international standard for video streaming, which means it’s easily accessible to any user or company which wishes to implement it in their systems. As a part of this, DASH was designed to function regardless of the video and audio formats sent via the protocol, which opens up more possibilities for hardware and software compatibility. (This is one of the issues with the other popular modern streaming protocol, HLS: it was designed as a “closed system” with support for only H.264 video and AAC audio.) Of course, being a publicly-available standard also means it’s unlikely to become unavailable at short notice, which certainly helps DASH have a leg up over proprietary systems. 

While this doesn’t necessarily look interesting, having an official ISO standard for a streaming protocol is really quite cool.

Finally, support for adaptive-bitrate streaming is baked into DASH from the ground up. Have you been wondering what “DASH” stands for? It’s “Dynamic Adaptive Streaming over HTTP.” It’s in the name! Naturally, this support means video streaming can be provided at higher quality, and with better support for slow or inconsistent connections to boot. So, what you get is a foundation for more-accessible streams, with better quality, and all at a better fit for today’s networking architecture. But, well, RTMP works well enough for most cases. Is it really worth changing for us? 


Here’s where the clincher comes in. Vimeo has been rolling out MPEG-DASH support to business clients over the last several years in what it refers to as “Fail-Safe Streaming.” In effect, this relies on DASH’s adaptive bitrate support to receive a stream from your sources with the lowest likelihood of interruptions. Additionally, DASH’s HTTP packeting means video “chunks” are easier to process serverside and push out to local data centers to serve to clients. As a result, on the stream producer’s side, there are much fewer headaches about connection quality and even service interruptions—it’s much easier for the system to compensate for connection issues while still serving video to customers. 

Sometimes you need to livestream from somewhere with a less-consistent internet connection than a cozy studio—like, say, a lakeside park in British Columbia.

If you know anything about what we do, you know that this is a big deal for us. At BCC Live, we’ve livestreamed events from all sorts of strange places—from beaches to the center of bridges to the tops of mountains, from the bustling heart of Washington D.C. to the backcountry of Kona, we’ve been there and served video. While we’ve built a robust system of Internet devices to facilitate streaming from anywhere, sometimes a fast or stable Internet connection is simply not in the cards. With RTMP streaming, this would require us to manually reduce the output resolution of our stream (thus reducing the picture quality to our clients), or have to deal with interruptions and “blackouts” of the stream. With DASH, our stream output is automatically scaled based on the best possible connection to keep peak quality. What’s more, Vimeo’s implementation of DASH introduces extra buffer time to the stream. While this means a stream is a little further back from “real time” than before, it allows for greater resistance to interruptions in the connection. 

Simply put, MPEG-DASH is the perfect upgrade for a team like ours. It gives us greater leeway with the hardware and software we can utilize, provides significantly better performance in the face of network issues, and stands every chance of remaining a useful tool for years to come. We’re excited to roll it out in upcoming events to make our livestreams even better than before. Do you think it’d be right for you as well? Give it a try—or give us a call, and we’ll livestream it for you!