SCTE-35 and Ad Signaling: How Streams Cue Ad Breaks

Why this matters

If you run, or are about to build, an ad-supported streaming service, SCTE-35 is the difference between an ad break that lands cleanly and one that does not happen at all. It is the signal that connects your content to your money: the server-side ad insertion you rely on cannot insert an ad until something in the stream tells it where the break is, how long it runs, and what kind of break it is. Connected-TV advertising in the US is forecast at roughly $37.95 billion in 2026 (eMarketer/industry forecasts, 2026), and the live, linear, and FAST channels driving that growth are built on this one broadcast standard. This article is the builder's guide to the marker itself — what it is, where it is born, what it carries, and how it reaches the player — and the companion to the OTT monetization map, which shows where ad revenue sits among all the ways a platform earns.

The one job: how a stream says "an ad goes here"

Start with the problem SCTE-35 exists to solve. A streaming platform wants to replace or insert advertising at exact moments in a program — between innings, at a chapter break, returning from a national feed to a local one. But the video itself is just a sequence of pictures and sound; it carries no built-in notion of "this is where the commercial goes." Something has to mark the spot, precisely, in a way every downstream machine can read identically.

That marker is SCTE-35 — a signaling standard from the Society of Cable Telecommunications Engineers (SCTE), formally titled Digital Program Insertion Cueing Message, first published in 2001 and most recently revised as ANSI/SCTE 35 2023r1 on 30 November 2023. A SCTE-35 message is a tiny data packet, interleaved with the audio and video, that announces an upcoming splice point: where it is on the timeline, whether the stream is leaving the program or returning to it, and — increasingly — what kind of boundary it is.

Here is the analogy to hold onto. A SCTE-35 cue is the chalk mark a film editor used to scratch onto a reel to say "cut here, drop the commercial in." The film does not know what a commercial is; the chalk mark does the telling, and any editor in any cutting room reads it the same way. SCTE-35 is that chalk mark, except it is a precise digital timestamp that machines — encoders, packagers, ad servers, and stitchers — read automatically and act on without a human in the room. Everything else in this article is detail about how the chalk mark is written, carried, and read.

One thing the cue does not do is contain the ad. SCTE-35 only marks the opportunity; the standard "defines an in-stream messaging mechanism to signal splicing and insertion opportunities" and deliberately says nothing about what gets inserted (ANSI/SCTE 35 2023r1, §1.2). Choosing and delivering the actual ad is a separate job, handled by the ad decision server and the stitcher we meet later.

Figure 1. The signaling chain. An automation system requests a cue over SCTE-104; the encoder writes a SCTE-35 message into the stream; the packager copies it into HLS and DASH manifests; the ad decision server and stitcher turn it into a real ad.

Where the marker is born: SCTE-104 to SCTE-35

The cue does not appear by magic. In a live or linear channel it usually begins life one step upstream, in the automation system — the playout software that runs the channel and knows the schedule. When the schedule reaches an ad break, the automation system sends a request to the encoder asking it to mark a break. That request travels over a companion standard called SCTE-104, which is the messaging interface between an automation system and the compression/encoding equipment.

The division of labour is clean and worth remembering. SCTE-104 is the request — "insert a break here," issued by automation and timed against the broadcast clock (aligned to UTC time, vertical-interval timecode, or a hardware trigger). SCTE-35 is the fulfillment — the encoder receives the SCTE-104 request and writes a SCTE-35 message into the outgoing stream at the right instant, carrying everything a downstream system needs. One is the instruction handed to the encoder; the other is the durable mark the encoder leaves in the stream for everyone after it.

Not every cue starts as SCTE-104. A platform can insert SCTE-35 directly at the packaging stage for video-on-demand assets, or generate cues from an out-of-band schedule (more on that with SCTE 224 below). But the SCTE-104 → SCTE-35 handoff is the canonical live path, and knowing it explains why a missing or mistimed ad break is so often an upstream problem — a fault in the automation request or its timing, not in the player at all.

Anatomy of a SCTE-35 message

A SCTE-35 message is technically a small table called the splice_info_section. You will never write one by hand, but understanding its shape demystifies every ad-signaling problem you will ever debug. Think of it as an envelope with a few labelled fields and one main instruction inside.

The envelope opens with a fixed identifier, table_id, whose value is always 0xFC (ANSI/SCTE 35 2023r1, §9.6.1) — which is why engineers sometimes call SCTE-35 "the 0xFC table." Then come a handful of housekeeping fields: a protocol_version (currently always 0), a 33-bit pts_adjustment used to keep the cue's timing correct if the stream is re-timestamped along the way, and a 12-bit tier value used to route or filter cues. After the housekeeping sits the important part: a splice_command_type that names which instruction this message carries, followed by the command itself, then an optional list of descriptors that add richer meaning, and finally a CRC_32 checksum so a receiver can confirm the message arrived intact.

The standard defines six command types, but only a few matter in practice (ANSI/SCTE 35 2023r1, Table 7):

Hex	Command	Role today
0x00	splice_null	A heartbeat / keep-alive; carries no splice.
0x04	splice_schedule	Schedules future splices in advance; rarely used in streaming.
0x05	splice_insert	The classic "cue out / cue in" ad-break command.
0x06	time_signal	A timestamped point that gains meaning from its descriptors.
0x07	bandwidth_reservation	Reserves bandwidth; used in some satellite paths.
0xFF	private_command	Vendor-defined, non-standard payloads.

Table 1. The SCTE-35 command types. In modern streaming you will almost always be working with splice_insert (0x05) and time_signal (0x06); the rest are legacy or niche.

The two that carry ad breaks — splice_insert and time_signal — deserve their own section, because the difference between them is the single most useful thing to understand about SCTE-35.

Figure 2. Inside the envelope. A splice_info_section carries housekeeping fields, one splice command (splice_insert or time_signal), an optional loop of descriptors that label the break, and a CRC checksum.

The two commands that matter: splice_insert vs time_signal

The older, simpler command is splice_insert. It directly describes an ad break with its own fields. The key one is a single bit called out_of_network_indicator: when it is set to 1, the cue marks an out point — the moment to leave the program and go to an ad (the "cue-out"); when it is 0, the cue marks the in point — the moment to return to the program (the "cue-in") (ANSI/SCTE 35 2023r1, §9.7.3.1). A splice_insert can also carry a break_duration (how long the avail lasts) and a unique_program_id to tie a cue-out and its matching cue-in together. For a plain "leave for 90 seconds of ads, then come back," splice_insert says everything needed.

The newer, richer command is time_signal. On its own, a time_signal carries only a timestamp — a precise point on the timeline and nothing more. Its meaning comes entirely from the descriptors attached to it. The standard is explicit: when a time_signal is used to signal splice events, it "shall carry one or more segmentation descriptors" with the additional information about what to do (ANSI/SCTE 35 2023r1, §9.3). That sounds like a weakness but it is the opposite — it is what lets time_signal express things splice_insert cannot, like "this is the start of a provider placement opportunity for a specific program identified by this ID," or "this is a chapter boundary, not an ad."

The practical guidance the whole industry has converged on: splice_insert is legacy but still widely used for simple breaks; time_signal plus a segmentation descriptor is the modern default because it carries identity and intent, which targeted and audience-specific advertising depends on. A production platform reads both, because real upstream feeds send both.

Figure 3. Two ways to mark a break. splice_insert describes the break in its own fields; time_signal carries only a timestamp and leans on a segmentation descriptor for identity and intent.

Segmentation descriptors: labelling what kind of break it is

A segmentation descriptor is the add-on that turns a bare timestamp into a meaningful event. It is the part of SCTE-35 that says what this boundary is, not just when. It carries three things worth knowing about.

First, a segmentation_type_id — a number that names the kind of boundary. This is where "an ad goes here" gets specific. The ad-relevant values are the ones a streaming team lives with; here are the ones that matter, with a column showing which command can carry each (the support matrix matches how production encoders such as Bitmovin's treat them):

Type ID	Segmentation type	Carried by splice_insert?	Carried by time_signal?
0x10 / 0x11	Program Start / End	Yes	No
0x20 / 0x21	Chapter Start / End	Yes	No
0x22 / 0x23	Break Start / End	Yes	Yes
0x30 / 0x31	Provider Advertisement Start / End	Yes	Yes
0x32 / 0x33	Distributor Advertisement Start / End	Yes	Yes
0x34 / 0x35	Provider Placement Opportunity Start / End	Yes	Yes
0x36 / 0x37	Distributor Placement Opportunity Start / End	Yes	Yes
0x40 / 0x41	Unscheduled Event Start / End	Yes	No

Table 2. The ad-relevant segmentation type IDs (ANSI/SCTE 35 2023r1, Table 23). "Placement Opportunity" (0x34–0x37) is the type most ad decision systems treat as a replaceable ad avail; "Provider" vs "Distributor" says who owns the inventory. The right two columns show which command each type is conventionally carried by — the placement-opportunity and advertisement types travel happily on time_signal, which is why modern targeted advertising uses it.

The single most important distinction in that table is "placement opportunity" versus "advertisement." A placement opportunity (0x34–0x37) is a slot the platform is invited to fill with its own dynamically chosen ad — this is what dynamic ad insertion targets. A plain advertisement marker (0x30–0x33) describes an ad that is already in the feed. And "provider" versus "distributor" answers who owns that inventory: the content provider (the network) or the distributor (you, the platform carrying it).

Second, a segmentation descriptor carries a UPID — a unique program identifier — which says exactly which piece of content or which break this is. The UPID has a type, and the type tells a receiver how to read the bytes. Common UPID types include Ad-ID (0x03, the advertising industry's standard ad identifier), TMS/TID (0x08), EIDR (0x0A, a registry ID for movies and TV), a generic URI (0x0F), and a UUID (0x10). The UPID is how an ad decision server matches a break to a campaign, a blackout rule, or a reporting bucket.

Third, it carries restriction flags — most notably a web_delivery_allowed_flag and a no_regional_blackout_flag — that encode whether this content may be delivered to web/OTT audiences or must be blacked out in certain regions. These are how sports and syndicated rights restrictions ride along with the cue.

The clock and the lead time: showing the math

Two numbers govern whether a break lands where it should, and both are worth working through out loud, because they explain a large share of real-world ad-timing bugs.

The first is the clock. SCTE-35 timestamps are expressed as a pts_time, a 33-bit value that counts ticks of a 90,000-ticks-per-second clock — the same 90 kHz presentation clock MPEG uses for video timing. To convert a wall-clock moment into a pts_time, multiply the seconds by 90,000:

splice point at 1 h 23 min 45.5 s into the stream
seconds      = (1 × 3600) + (23 × 60) + 45.5 = 5,025.5 s
pts_time     = 5,025.5 × 90,000 = 452,295,000 ticks

Because the field is 33 bits, the largest value it can hold is 2³³ − 1, so the clock wraps back to zero roughly every:

2^33 ÷ 90,000 ≈ 8,589,934,592 ÷ 90,000 ≈ 95,443 s ≈ 26.5 hours

That ~26.5-hour wrap is why a 24/7 channel cannot simply trust raw timestamps to keep climbing forever, and why the pts_adjustment field exists to correct timing when streams are re-stamped along the path. Units matter here: a timestamp off by 90,000 ticks is one full second of misalignment — an ad that starts a second into the host's next sentence.

The second number is lead time. A cue is useless if it arrives at the splicer too late to act on. The standard's pre-roll guidance is concrete: a cue "could be sent at 8, 5, 4 and 2 seconds prior to" the splice point, and warns that "any message received with less than 4 seconds of advance notice may not create the desired result" (ANSI/SCTE 35 2023r1, §9.1). The working rule that falls out of this: signal ad breaks at least 4 seconds ahead, and ideally repeat the cue several times during the run-up so a receiver that missed one copy still catches another. Most "the ad break didn't fire" incidents trace back to a cue that arrived inside that 4-second window.

Figure 4. The pre-roll budget. The cue is sent several times before the splice point so a receiver that misses one copy still acts in time; cues arriving with under 4 seconds' notice may not fire.

From transport stream to manifest: SCTE-35 in HLS and DASH

So far the cue lives in an MPEG-2 transport stream — the broadcast-style container used for contribution and live feeds — where it rides on its own dedicated stream identified by a PID (a packet identifier) listed in the program's map table. But a viewer on a phone or smart TV is not watching a transport stream; they are watching segments named by an HLS or MPEG-DASH manifest, the small playlist that tells a player which chunks to download. So the cue has to be translated from the transport stream into the manifest. That translation is the packager's job, and it is where most streaming teams actually encounter SCTE-35.

In HLS (Apple's format, RFC 8216), there are several ways the cue surfaces, from simplest to richest:

#EXTINF:4.0,
segment_18188.ts
#EXT-X-CUE-OUT:90.000        ← leave for a 90-second ad break (cue-out)
#EXTINF:4.0,
ad_segment_0001.ts
...
#EXT-X-CUE-IN                 ← return to the program (cue-in)
#EXTINF:4.0,
segment_18221.ts

The #EXT-X-CUE-OUT / #EXT-X-CUE-IN pair above is the simplest, duration-based form many ad-insertion services accept. For full fidelity, HLS uses the #EXT-X-DATERANGE tag, which can carry the original cue's raw bytes. RFC 8216 specifies that an out/in pair signalled by splice_insert "SHOULD be represented by one or more EXT-X-DATERANGE tags," with the out-point section placed in a SCTE35-OUT attribute and the in-point in SCTE35-IN (RFC 8216, §4.3.2.7.1):

#EXT-X-DATERANGE:ID="ad-break-42",START-DATE="2026-06-17T12:30:00Z",
  DURATION=90.000,SCTE35-OUT=0xFC30200000...

Some encoders also emit #EXT-OATCLS-SCTE35 or #EXT-X-SCTE35 tags carrying the base64- or hex-encoded raw SCTE-35 message, so a downstream system can re-parse the original cue exactly. Which tag you emit depends on what your ad-insertion service documents that it reads.

In MPEG-DASH (ISO/IEC 23009-1), the cue is expressed as an event inside the manifest (the MPD). SCTE 214 — the suite that profiles DASH for these services — defines two carriage paths: out-of-band events placed in the MPD as an EventStream, and in-band events carried in the segments as emsg boxes. The MPD form looks like this:

<Period start="PT32S" id="2">
  <EventStream schemeIdUri="urn:scte:scte35:2014:xml+bin" timescale="90000">
    <Event duration="8100000" id="42">
      <Signal xmlns="urn:scte:scte35:2013:xml">
        <Binary>/DAvAAAAAAAAAP/wBQb+AAAAAAAZAhdDVUVJ...==</Binary>
      </Signal>
    </Event>
  </EventStream>
</Period>

The Binary element holds the same SCTE-35 message, base64-encoded per RFC 4648 (ANSI/SCTE 35 2023r1, §7.4) — proof that HLS and DASH are two envelopes carrying the identical underlying cue. For the mechanics of the manifest formats themselves, see HLS vs DASH in the Video Streaming section; here we care only about how the cue travels inside them. The fact that one transport-stream cue maps cleanly into both manifests is what lets a single signaling pass serve every device — the same principle behind packaging CMAF, HLS, and DASH from one mezzanine.

Figure 5. One cue, two envelopes. The packager renders the same SCTE-35 message as HLS EXT-X-DATERANGE / CUE-OUT tags and as a DASH MPD EventStream, so every device sees the break.

The handshake: how a cue becomes a real ad

The cue is the start of the conversation, not the end of it. Once the marker reaches the ad-insertion layer, four steps turn it into an ad on screen.

The stitcher (in server-side insertion) or the player's ad component (in client-side insertion) detects the cue in the manifest and reads its type and duration. It then calls an ad decision server — the system that chooses which ad to show — using the advertising industry's request standard, VAST (Video Ad Serving Template, from the IAB Tech Lab), often orchestrated across a whole break by VMAP (which describes the full set of ad slots in a piece of content). The ad decision server returns the ad creative. Finally, for server-side insertion, the stitcher conditions that ad to match the content's quality ladder and rewrites the manifest so the ad plays as part of one continuous stream.

Two boundaries keep this article focused. The full VAST/VMAP request-and-response supply chain is its own subject, covered in ad serving, VAST/VMAP, and the ad stack; and the stitching architecture — why server-side insertion beats ad-blockers and keeps breaks smooth — is covered in SSAI vs CSAI. SCTE-35's job ends where those begin: it provides the where, how long, and what kind that the ad decision server needs to act. Without a correct cue, the most sophisticated ad stack in the world has nothing to fire on.

Out-of-band scheduling: SCTE 224 and ESNI

In-stream cues are not the only way to drive ad and content decisions. SCTE 224, the Event Scheduling and Notification Interface (ESNI), is an out-of-band, API-based standard that carries schedules and policy — which programs may run where, when a regional blackout applies, which audiences see which content — as structured data alongside the stream rather than inside it. Where SCTE-35 is the frame-accurate in-stream chalk mark, SCTE 224 is the rulebook delivered separately that tells systems how to interpret and apply those marks across regions and audiences.

The two are complementary, not competing. A live sports workflow commonly uses SCTE-104/35 for the precise in-stream timing of each break and SCTE 224 for the higher-level policy — this game is blacked out in these markets, this break is available for local sale in those. A platform that serves multiple territories or sells local inventory will eventually need both; a single-region AVOD catalog can often start with SCTE-35 alone.

A common mistake: trusting the marker without conditioning the stream

The recurring failure in ad signaling is treating the cue as the whole job. A team wires up SCTE-35 pass-through, sees the markers appear in the manifest, and assumes ads will land cleanly — then discovers breaks that start a beat late, ads that never fire, or breaks that cut a host off mid-word. The root cause is almost always one of three signaling-specific mistakes, none of which the ad stack can fix on its own.

The first is the splice point not landing on a segment boundary. A player can only switch streams at the edge of a segment, so if the cue's pts_time falls in the middle of a chunk, the splice rounds to the nearest boundary and drifts. The fix is to align encoding so a segment boundary (an IDR frame, the kind a player can cut to) sits exactly at the splice point — which is why encoders insert a keyframe at the cue. The second is the late cue: a marker delivered inside the 4-second pre-roll window the standard warns about, which a splicer may simply ignore. The third is dropping the descriptors: a pipeline that preserves a bare time_signal but strips its segmentation descriptor delivers a timestamp with no meaning, so the ad server cannot tell a placement opportunity from a chapter mark. Correct ad signaling is not "are the markers present" — it is "are they accurate, early enough, on a boundary, and complete." That is a quality-control discipline, not a checkbox.

Where Fora Soft fits in

Ad signaling is where broadcast precision meets streaming scale, and the expensive failures are quiet: a break that fires a second late on every viewer, a blackout that leaks because a restriction flag was dropped, or a national feed whose local avails never open because the segmentation descriptor was stripped in packaging. Fora Soft has built video-streaming and OTT/Internet-TV platforms since 2005, across 625+ shipped projects for 400+ clients, which means we have wired SCTE-104-to-SCTE-35 pipelines for live channels, conditioned encodes so splice points land on segment boundaries, carried cues faithfully into HLS and DASH manifests, and connected them to ad decision servers and server-side stitchers that hold up under live load. Our stance is scalability-first and vendor-neutral: we start from the scale and accuracy your channels demand — frame-accurate breaks across every device, correct blackouts across every territory — then build the signaling and ad-insertion path that your live, FAST, and AVOD streams actually require.

What to read next

• Server-Side Ad Insertion (SSAI) vs Client-Side (CSAI)
• Ad serving, VAST/VMAP, and the ad stack
• The OTT monetization map: subscriptions, ads, transactions

For a shorter, product-level overview of streaming monetization, see our video streaming app monetization guide; to commission a build, talk to our streaming team via the link above.

Call to action

• Talk to a streaming engineer — book a 30-minute scoping call to talk through your scte-35 plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the SCTE-35 Ad-Signaling Field & Marker Reference — The SCTE-35 message anatomy, the command and segmentation-type tables, the HLS/DASH carriage cheat sheet, and the pre-roll and QC checklist on one page.

References

1. ANSI/SCTE 35 2023r1 — Digital Program Insertion Cueing Message. Society of Cable Telecommunications Engineers (SCTE). Tier 1. The controlling standard for in-stream ad-break signaling; defines the splice_info_section (table_id 0xFC), the command types (splice_insert 0x05, time_signal 0x06), out_of_network_indicator semantics, segmentation descriptors and their type IDs (Table 23) and UPID types (Table 22), the pre-roll guidance (§9.1), and the base64/XML representation (§7.4). Published 2023-11-30. https://account.scte.org/standards/library/catalog/scte-35-digital-program-insertion-cueing-message/ — accessed 2026-06-17.
2. ANSI/SCTE 104 — Automation System to Compression System Communications API. SCTE. Tier 1. Defines the upstream interface an automation/playout system uses to request that the encoder insert SCTE-35 cues, timed to UTC, VITC, or a hardware trigger; SCTE-35 is the in-stream fulfillment of a SCTE-104 request. https://www.scte.org/standards/library/catalog/scte-104-automation-system-to-compression-system-communications-api/ — accessed 2026-06-17.
3. ANSI/SCTE 224 — Event Scheduling and Notification Interface (ESNI). SCTE. Tier 1. The out-of-band, API-based standard for scheduling and policy (blackouts, audience, alternate content) that complements in-stream SCTE-104/35 signaling. https://www.scte.org/standards/library/catalog/scte-224-event-scheduling-and-notification-interface/ — accessed 2026-06-17.
4. ANSI/SCTE 214-1 / 214-3 — MPEG DASH for IP-Based Cable Services (MPD constraints; ISO BMFF / emsg carriage of SCTE-35). SCTE. Tier 1. Specifies how SCTE-35 events are carried in DASH as out-of-band MPD EventStream events (214-1, §6.7) and as in-band emsg events (214-3, §7.3). https://account.scte.org/standards/library/catalog/scte-214-1-mpeg-dash-for-ip-based-cable-services-part1-mpd-constraints-and-extensions/ — accessed 2026-06-17.
5. HTTP Live Streaming — RFC 8216. IETF. Tier 1. §4.3.2.7.1 specifies how SCTE-35 cues map into HLS via the EXT-X-DATERANGE tag using SCTE35-OUT, SCTE35-IN, and SCTE35-CMD attributes; the rfc8216bis draft tracks current additions. https://www.rfc-editor.org/rfc/rfc8216 — accessed 2026-06-17.
6. Dynamic adaptive streaming over HTTP (DASH) — Part 1, ISO/IEC 23009-1. ISO/IEC. Tier 1. The DASH manifest standard whose EventStream / in-band event mechanism carries SCTE-35 cues into the MPD. https://www.iso.org/standard/83314.html — accessed 2026-06-17.
7. VAST and VMAP — Digital Video Ad Serving Template / Video Multiple Ad Playlist. IAB Tech Lab. Tier 1. The ad-request standards an ad decision server answers once a SCTE-35 cue opens an avail; VMAP describes the full set of ad slots in a piece of content. https://iabtechlab.com/standards/vast/ — accessed 2026-06-17.
8. SCTE-35: The Essential Guide (2025 update). Bitmovin (Andy Francis). Tier 4 (first-party encoder vendor). Used to cross-check the HLS tag set (EXT-X-CUE-OUT/IN, EXT-OATCLS-SCTE35, EXT-X-DATERANGE), the DASH MPD EventStream example, and the segmentation-type-to-command support matrix; not used as the source for any normative spec claim. https://bitmovin.com/blog/scte-35-guide/ — accessed 2026-06-17.
9. Comcast scte35-go / scte35-js — open-source SCTE-35 reference parsers. Comcast. Tier 4 (first-party implementation). Cross-checked the segmentation type-ID and UPID-type enumerations against a widely used implementation. https://github.com/Comcast/scte35-go — accessed 2026-06-17.
10. SCTE-35 signal conditioning and EXT-X-DATERANGE ad markers. AWS Elemental (Live / MediaTailor documentation). Tier 3 (first-party vendor). Documents how a production encoder conditions SCTE-35 and how a packager/stitcher renders the cue into HLS markers. https://docs.aws.amazon.com/elemental-live/latest/ug/scte-35-ad-marker-ext-x-daterange.html — accessed 2026-06-17. Vendor docs — re-check.
11. Connected-TV advertising market forecast, 2026. eMarketer / industry forecast compilations. Tier 5. US CTV ad spend ~$37.95B in 2026; cited for the scale of the ad-supported streaming SCTE-35 underpins. https://www.emarketer.com/ — accessed 2026-06-17. Analyst estimates vary by source.
12. Fora Soft — Video Streaming App Monetisation (overview blog). Fora Soft. Tier 7. Product-level companion on AVOD/FAST/SVOD/TVOD monetization; the commercial-intent counterpart this educational article links to. https://www.forasoft.com/blog/article/video-streaming-app-monetization-strategies — accessed 2026-06-17.

Where sources disagreed, the controlling standard was followed. The command types, table_id, out_of_network_indicator semantics, pre-roll guidance, and base64/XML representation are cited from ANSI/SCTE 35 2023r1 directly; the segmentation type-ID and UPID tables (Tables 23 and 22) are sourced to the spec and cross-checked against the Comcast reference implementation and Bitmovin's published matrix. HLS carriage is cited from RFC 8216 §4.3.2.7, DASH carriage from SCTE 214 and ISO/IEC 23009-1. The popular shorthand that "time_signal is just a newer splice_insert" was overridden in favour of the precise framing — time_signal carries only a timestamp and depends on segmentation descriptors for meaning (§9.3). CTV-spend figures are 2026 analyst estimates, cited as a forecast.