What is SCTE-35? The ad break, written into the stream itself.

SCTE-35 was written for American cable in the 1990s, when the problem was splicing local car-dealer ads into a national feed at exactly the right frame, thousands of times a day, across systems run by different companies. The solution was to put the cue inside the stream itself: a small binary message riding alongside the video that says a splice point is coming, when, and for how long. Equipment from any vendor could read it, and nobody had to coordinate anything by phone.

Streaming inherited the standard because the problem survived the technology shift intact. Server-side ad insertion needs to know where breaks are. Distributors stitching a channel into their storefront need to know where they may sell. A downstream recorder needs to know where the programme actually starts. All of them read SCTE-35, which has made it the shared vocabulary between a channel and everyone who handles it after playout.

What trips newcomers is that SCTE-35 marks opportunities rather than inserting anything. The cue says "a 120 second break opens here". Something else, an ad server, a splicer, a downstream distributor, decides what fills it. A channel with clean cues and no ad demand shows its slate; a channel with demand and no cues shows nothing, because the machines were never told where the shelf is.

The cue is born in playout, at the boundary the schedule defines: this item ends, a two minute break opens, the next item follows. The engine writes the SCTE-35 message into the transport stream at that frame. From there it has to survive every hop. The encoder must pass it through, and the packager must translate it into terms the delivery format understands, which for HLS means EXT-X-CUE-OUT and EXT-X-CUE-IN tags, or EXT-X-DATERANGE entries carrying the original payload, written into the playlist at the right segment.

Only then does anything commercial happen. A server-side ad inserter reads the manifest markers, runs its auction during the pre-roll the cue provided, and splices the winning spots into each viewer's stream at the cue's timestamp. A FAST distributor does its own version of the same read. Both are trusting the cue completely: its placement is the edit point, its duration is the inventory.

The chain is only as good as its weakest hop, and the classic failure is silent. A transcoder that was never told about the cue PID drops it without an error, and the channel arrives downstream perfectly watchable, with nothing left for anyone to sell. When a distributor bounces a channel for cue problems, this is usually where the cues went.

Everything automated in television advertising keys off these cues. No cues means server-side insertion has nothing to fill, a distributor has nothing to sell against, and your ad strategy is reduced to burning spots into the programme where nobody can replace, target or count them. That is why "emits standards-compliant SCTE-35" appears in every serious carriage spec, and why it is worth checking a playout vendor's answer before signing rather than after: it decides whether a FAST platform deal is a configuration task or a migration.

It is also why the cues belong to playout rather than to the ad stack. The system that runs the schedule is the only one that knows, to the frame, where the break truly is. Ours writes them at that boundary, in both command forms, and they ride the stream from the playout engine all the way to whoever fills them.