SCTE-35, SCTE-104 and SCTE-224: The Complete Guide to Broadcast Ad Signalling Standards

Every broadcaster running ad-supported content has encountered SCTE-35. It's the standard that tells a downstream system — a set-top box, a server-side ad splicer, a CDN — exactly when to swap out the main programme feed for a commercial break. But mention SCTE-104 in the same conversation and the room often goes quiet. And SCTE-224 is rarer still — yet it is increasingly the standard that determines who is allowed to see what content, and when. The three standards are closely related, frequently confused, and almost always used together. Understanding the difference is not just academic: choosing the wrong approach for your playout architecture can mean missed ad breaks, failed splice points, and revenue walking out the door.

What SCTE-35 Actually Does

SCTE-35 is a digital programme insertion (DPI) standard defined by the Society of Cable Telecommunications Engineers. It operates inside an MPEG transport stream, embedding cueing messages that signal the start and end of splice opportunities — the moments when a downstream device is permitted to insert alternative content. A SCTE-35 message contains several key components: the Splice Info Section, a Splice Insert command, and a Time Signal providing precise PCR-based timing. Beyond advertising, SCTE-35 is also used for programme segmentation, blackout enforcement, and rights management. In HLS and DASH delivery, SCTE-35 cues are often translated into manifest-level ad markers consumed by SSAI systems and adaptive streaming players.

What SCTE-104 Does Differently

SCTE-104 operates upstream of the encoder, in the baseband or SDI domain. Where SCTE-35 is a message embedded in a transport stream, SCTE-104 is a command sent between systems — from a broadcast automation platform or a Production Control Room operator to a video router or encoder. A useful way to think about the relationship is this: SCTE-104 is the request; SCTE-35 is the fulfilment. SCTE-104 messages can travel as VANC data in an SDI signal, as TCP/IP packets, or — in modern IP-based facilities using SMPTE ST 2110 — as ancillary data within the ST 2110-40 stream.

SCTE-224: The Standard That Controls Who Sees What

SCTE-224 — the Event Scheduling and Notification Interface (ESNI) — answers a different question entirely: who is allowed to see this content, and under what conditions? It is an out-of-band metadata standard that defines content availability windows, audience groupings, and viewing policies, delivered as an XML/API-based metadata feed over HTTP/REST to downstream distribution systems. When a SCTE-35 cue fires, a downstream SSAI system consults SCTE-224 to decide the action: insert an ad, show a blackout slate, switch to an alternate feed, or pass through main content. Only if the action is ad insertion does the SSAI then call the Ad Decision Server — passing user profile ID, geolocation, and other metadata — to select the actual creative. At the CDN, SCTE-224 enforces regional blackouts before content reaches the player. At the player or app layer, it enforces entitlement-based access control.

The Broadcast Chain: Where Each Standard Lives

The diagram below shows two architectures side by side.

Download hi-res diagram (PNG)

Hardware-Based On-Premise Broadcast Chain

In a traditional SDI facility, SCTE-104 travels alongside the SDI signal as VANC data or over TCP/IP from Master Control Automation to the Contribution Encoder — and optionally to the Live Encoder / Packager. The Contribution Encoder converts SCTE-104 instructions into SCTE-35 splice points embedded in the outgoing MPEG-TS. From that point, SCTE-35 — or manifest-level ad markers in HLS/DASH — travels inside the compressed stream all the way to the viewer.

IP On-Premise to Cloud Broadcast Chain

In a modern IP-based facility, cameras output video over SMPTE ST 2110. SCTE-104 cue messages travel as ancillary data within the ST 2110-40 stream through the Contribution Router. From the Contribution Router, the compressed stream is pushed to the cloud over SRT or RTMP (compressed) or JPEG XS (near-lossless). The Cloud Playout Engine generates SCTE-35 markers directly from schedule metadata — or from cue triggers sent by a Production Control Room operator — without requiring a SCTE-104 message from an upstream SDI system.

Which Standards Does Your Playout Need?

You need SCTE-35 if you are delivering content to any downstream system that performs ad insertion. You need SCTE-104 if your playout system is receiving cue instructions from an external automation system, a PCR operator, or a broadcast router over SDI, TCP/IP, or ST 2110-40. You need SCTE-224 if you are distributing content across multiple regions or audience segments with different rights, blackout rules, or ad targeting requirements. If you are running a fully cloud-native playout workflow with no SDI infrastructure, you may never need SCTE-104 at all — your playout platform should generate SCTE-35 markers directly from schedule data or PCR operator triggers.

Getting It Right

Ad signalling errors are one of the most common causes of missed revenue in broadcast operations. A splice point that fires two seconds late, a SCTE-35 message with an incorrect duration, a SCTE-224 policy that has not been propagated to the CDN edge, or a cloud playout system that does not pass through cue tones correctly can all result in ad breaks that never happen — or happen for the wrong audience. For broadcasters evaluating cloud playout, it is worth asking vendors specifically how they handle SCTE-35 generation from schedule metadata and PCR operator triggers, whether they support SCTE-104 over TCP/IP and ST 2110-40 for live event integration, and whether the platform supports SCTE-224 metadata delivery for content rights and audience policy enforcement.

Learn more about how Evrideo handles ad signalling and dynamic ad insertion across linear and OTT delivery.