Why This Matters
If your product shows ads to make money, the choice of where ads are spliced into the stream is the single largest engineering decision your monetisation roadmap will make. SSAI is the default for connected-TV and FAST because it works on devices that cannot run a JavaScript ad SDK — every Smart TV running Tizen, webOS, or Vidaa, every Roku, every Fire TV, every set-top box. It is the only path that survives ad blockers at scale. It also costs three to five times more than client-side insertion to operate, and it makes ad measurement harder, not easier. A product manager reading this article will leave knowing why the FAST channel they want to launch needs SSAI rather than VAST in the browser, why "we'll add ads later" is a six-month engineering project not a sprint, and why the analytics team will spend the first quarter post-launch arguing about impression counts. An engineer will leave with the SCTE-35 splice command set, the HLS EXT-X-DATERANGE syntax, the DASH multi-period MPD structure, the VAST 4.3 exchange, the OM SDK viewability hook, and the four production bugs that block launch the week before launch.
This article is the sixth piece of the nine-article Block 9 (Operations, DRM, Ads, and QoE) inside Fora Soft's Video Streaming Learn corpus. Read DRM 101: why three systems, and why you ship all three for the encryption layer SSAI must coexist with, CSAI and VAST/VPAID/SIMID for the client-side alternative this article positions against, and QoE metrics that every dashboard should show for the measurement framework the ad team will share with the engineering team.
What SSAI Actually Is
Before the pipeline, the definition. Server-Side Ad Insertion is the practice of replacing or interleaving segments of an HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH) presentation with ad segments — at the origin or at a manifest-manipulator service in front of the origin — before the manifest reaches the player. The player sees one media-playlist file or one Media Presentation Description, fetches a continuous sequence of segments, and renders frames as if no ad insertion ever happened. The work that would normally be done by an ad SDK inside the player — calling the ad decision server, downloading the ad creative, scheduling the cut, firing the impression beacons — happens server-side instead.
The contrast with Client-Side Ad Insertion (CSAI), the older approach, is sharp. In CSAI the player holds two sources: a content stream and an ad stream. When the player reaches an ad break, it pauses the content video element, calls an ad decision server, downloads the ad's manifest, plays the ad creative through a second video element (or the same one re-sourced), then resumes content. Every transition is a render-pipeline change the user can feel, every ad request is a network round trip that can fail, and every ad asset travels over a URL the ad blocker can pattern-match. CSAI works wonderfully on the open web, where a JavaScript SDK like Google's Interactive Media Ads SDK can do all this lifting; it works poorly on smart TVs, which cannot run a heavy JavaScript SDK; and it fails entirely against modern ad blockers.
The 2026 numbers explain the priorities. Free ad-supported streaming TV (FAST) reached an estimated 12.23 billion US dollars in global advertising revenue in 2026, up from 10.60 billion in 2025. United-States connected-TV ad spending crossed 37.95 billion in 2026, and Yospace, the largest pure-play SSAI vendor, reported crossing 10 billion monthly ad insertions in April 2026. The entire growth curve sits inside SSAI-only or SSAI-mostly device classes. CSAI has not gone away — it still dominates browser-based ad delivery and short-form video — but the money is in the living room, and the living room runs on SSAI.
Figure 1. The five-stage SSAI pipeline. The cue tone, called an SCTE-35 marker, is the signal that everything downstream uses to decide where to splice. Without a clean cue, SSAI cannot run.
The Five-Stage SSAI Pipeline
Every SSAI deployment, regardless of vendor, follows the same five-stage shape. Knowing the names of the stages is the difference between debugging an integration in an afternoon and debugging it in a week.
Stage 1 — Cue insertion. Somewhere upstream of the packager, a piece of equipment marks the moments where ads are allowed. For broadcast contribution that piece is the master-control automation system; for cloud playout it is the schedule-driven origin; for live sports it is a human operator pressing a cue button during the commercial-break window. The cue is an SCTE-35 message, which we'll dissect in the next section. The packager carries the cue through to its segments and signals it in the manifest.
Stage 2 — Manifest fetch and personalisation. When a viewer's player asks for the manifest, the request hits the SSAI service, not the origin. The SSAI service looks up the viewer's session (or creates a new one), reads the upstream manifest the origin would have served, finds the SCTE-35 cues in it, and decides what to do with each one.
Stage 3 — Ad decision. For every cue that falls inside this viewer's playback window, the SSAI service calls an Ad Decision Server, abbreviated ADS, which speaks the Video Ad Serving Template, abbreviated VAST. The SSAI service sends a VAST request that includes the viewer's IP address, user agent, IFA (the device's advertising identifier), the publisher's ID, the content's metadata, and the slot's duration. The ADS returns one or more VAST 4.x XML documents naming the ad creatives the SSAI service should splice in.
Stage 4 — Ad conditioning. The ad's source files almost never match the content stream's encoding ladder. Real ads come in mezzanine MP4s from agencies; the live stream is CMAF at 1080p, 720p, 540p, 360p with H.264 and AAC. The SSAI service therefore transcodes (or fetches pre-transcoded versions of) each ad creative into segments that match the content's resolutions, bitrates, codec parameters, and segment duration — so the splice is byte-for-byte invisible to the player's adaptive-bitrate logic. AWS Elemental MediaTailor calls this step ad conditioning and offers two modes: dynamic transcoding (the default, slower, more flexible) and bring-your-own-ads via pre-conditioned creative URLs declared in the VAST response (introduced January 2025, faster, requires upstream prep).
Stage 5 — Personalised manifest emission. The SSAI service emits a per-session manifest in which the original content segments and the conditioned ad segments are interleaved at the cue points. For HLS, this means swapping or appending segment URIs and adding #EXT-X-DISCONTINUITY tags around the ad block. For DASH, it means adding a new
The whole loop fires for every viewer, every ad break, every break-position decision. A linear FAST channel with 5,000 concurrent viewers and 14 ad breaks per hour serves roughly 70,000 personalised manifests per hour from the SSAI service, each one signed and cache-keyed to the session.
SCTE-35: The In-Band Cue Language
SCTE-35 — formally "Digital Program Insertion Cueing Message", published by the Society of Cable and Telecommunications Engineers and adopted as ANSI/SCTE 35 — is the single most important standard in the entire ad-insertion stack. Every SSAI vendor reads it; every encoder writes it; every conformance test asks for it. The 2023 revision (ANSI/SCTE 35 2023r1, formally ANSI-approved on 29 February 2024) added nested events, hierarchical sub-events, and the renumbering that split the standard into SCTE 35-1 (legacy splice-based and time-based signaling) and SCTE 35-2 (event-based signaling). When you read "SCTE-35" without a part number in a 2026 blog post, the author usually means SCTE 35-1.
The unit of SCTE-35 is the splice_info_section, an MPEG-2-style binary section that wraps one of three commands and zero or more descriptors. The three commands you will see in practice are:
splice_insert()— the original, frame-accurate splice command. Carries a splice event ID, a flag for out-of-network (the ad break opens) or back-in-network (the ad break closes), an optional pre-roll duration, and an optional break duration. Still the most common command in cable contribution feeds.time_signal()— a lighter command that just carries a timestamp. Almost never used alone; it exists to be carried alongside one or moresegmentation_descriptorpayloads that explain what the timestamp marks.splice_null()— a heartbeat. Indicates "I am SCTE-35 capable and there is no event here right now". Used to keep downstream monitors confident.
The segmentation_descriptor is where modern SCTE-35 lives. It carries a 32-bit segmentation_event_id, a segmentation_duration, a segmentation_type_id that names what the segment is — Provider Advertisement Start (0x30), Provider Advertisement End (0x31), Distributor Advertisement Start (0x32), Distributor Advertisement End (0x33), Provider Placement Opportunity Start (0x34), Network Start, Chapter Start, Break Start, and dozens of others — and a segmentation_upid that uniquely identifies the segment across the supply chain. For an ad break, you typically see a time_signal() followed by a segmentation_descriptor with type 0x34 (placement opportunity start), and a matching pair sixty or a hundred and twenty seconds later with type 0x35 (placement opportunity end).
In an MPEG-2 transport stream, SCTE-35 messages ride in their own elementary stream with stream_type 0x86. In a CMAF segment, they ride in an emsg box. In an HLS media playlist, they ride in an EXT-X-DATERANGE tag. In a DASH MPD, they ride in an EventStream. The four carriers exist because SCTE-35 outlived MPEG-2 transport.
SCTE-35 in HLS
Apple's HLS Authoring Specification documents the only Apple-supported way to carry SCTE-35 in an HLS playlist: an EXT-X-DATERANGE tag whose attributes name the splice command and the original binary payload. Each splice_info_section() becomes one EXT-X-DATERANGE tag with a SCTE35-CMD attribute. A splice_insert() out-of-network event becomes a tag with a SCTE35-OUT attribute; the matching back-in event becomes a tag with a SCTE35-IN attribute and the same ID attribute. A minimal mid-roll cue looks like this:
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:4321
...
#EXT-X-DATERANGE:ID="ad-break-9012",START-DATE="2026-05-26T12:00:00Z",DURATION=60.0,SCTE35-OUT=0xFC302F00000000...
#EXT-X-DISCONTINUITY
#EXTINF:6.0,
ad-segment-0001.m4s
#EXTINF:6.0,
ad-segment-0002.m4s
... (eight more ad segments, sixty seconds total) ...
#EXT-X-DISCONTINUITY
#EXT-X-DATERANGE:ID="ad-break-9012",SCTE35-IN=0xFC302F00000000...
#EXTINF:6.0,
content-segment-4332.m4s
The #EXT-X-DISCONTINUITY tags tell the player to expect a different encode (the ad's PTS timestamps don't match the content's) and to reset its decode pipeline at the boundary. Without them, the player's video-decoder will choke on the timestamp jump and the user will see a stalled frame.
SCTE-35 in DASH
The DASH specification, ISO/IEC 23009-1, carries SCTE-35 in an EventStream element inside a emsg boxes inside segments. The MPD names the SCTE-35 scheme with schemeIdUri="urn:scte:scte35:2014:xml+bin" (binary base64) or urn:scte:scte35:2013:xml (XML form). For mid-roll ads, the more common pattern is a multi-period MPD: the content's Period A ends at the cue boundary, a new Period B opens with the ad's AdaptationSets, and the content's Period C resumes after the break. Each period is a self-contained presentation with its own Representations, which is why SSAI services can swap ads in and out without rewriting timestamps inside the content.
A single mid-roll ad break in DASH looks like this (radically abbreviated):
<MPD type="dynamic" ...>
<Period id="content-pre" start="PT0S" duration="PT45M0S">
<AdaptationSet contentType="video">...</AdaptationSet>
</Period>
<Period id="ad-9012" start="PT45M0S" duration="PT1M0S">
<EventStream schemeIdUri="urn:scte:scte35:2014:xml+bin" timescale="90000">
<Event presentationTime="0" duration="5400000" id="9012">
<scte35:Signal>
<scte35:Binary>/DAvAAAAAAAA...</scte35:Binary>
</scte35:Signal>
</Event>
</EventStream>
<AdaptationSet contentType="video">...</AdaptationSet>
</Period>
<Period id="content-post" start="PT46M0S">
<AdaptationSet contentType="video">...</AdaptationSet>
</Period>
</MPD>
The DASH-IF Implementation Guidelines for Advanced Ad Insertion describe this pattern in detail, including the optional xlink:href resolution mechanism (the ad period's content is fetched from a different URL at runtime) and the remote-period model that hides ad content from the original manifest until late binding.
Figure 2. The SCTE-35 cue lifecycle. A single splice_insert binary travels from the contribution encoder, through the packager's emsg box, through the SSAI service's parser, and out to the player as an EXT-X-DATERANGE attribute (HLS) or a multi-period Period boundary (DASH).
The VAST Exchange and Ad Conditioning
The Video Ad Serving Template, VAST, is the second piece of plumbing every SSAI deployment touches. VAST is an XML schema published by the Interactive Advertising Bureau Tech Lab. VAST 4.0, released in 2016, was the first major version explicitly designed for server-side ad stitching: it added a mezzanine file field for high-quality source masters that SSAI services could transcode, multiple renditions for ABR-aware delivery, universal IDs, and verification-vendor metadata. VAST 4.1, 4.2, and 4.3 (the latest as of 2026) tightened the schema, added the optional
A VAST exchange in an SSAI context goes like this. The SSAI service holds the SCTE-35 cue, decides a viewer is eligible for an ad in this slot, and POSTs a VAST request to the configured Ad Decision Server URL. The request carries the publisher ID, the viewer's IFA, the viewer's IP and user agent, the content metadata, and the slot's duration. The ADS returns a VAST 4.3 XML document. Each
The SSAI service does not pass the VAST document to the player. It reads it, downloads or fetches pre-conditioned versions of the named creatives, and replaces the VAST tracking URLs with its own beacon endpoints. From the player's perspective, the ad is just more segments. From the ad ecosystem's perspective, the impressions and quartile events fire from the SSAI service's IP, not from the device.
Ad conditioning: the transcoding step nobody talks about
The agency hands you a 50-megabit-per-second mezzanine MP4 at 1920×1080, 30 frames per second, H.264 high profile, AAC stereo. Your live stream is CMAF at 6/4/2.5/1.2 megabits per second, four resolutions, two-second segments, H.264 main profile, AAC stereo. The two cannot be concatenated as is — the player will stall the moment the segment boundary changes profile, GOP structure, or codec parameter set.
The SSAI service therefore re-encodes (or fetches pre-encoded) versions of the ad in every rendition the content stream uses, with matching codec profile, matching pixel format, matching colour primaries, matching segment duration, and matching audio sample rate. The result is a parallel set of ad segments that drop into the content's rendition group as if the ad were just more content. AWS Elemental MediaTailor calls this step "ad conditioning"; its transcode mode does the work on demand and caches the result for an hour; its none mode trusts the VAST response to already point at pre-conditioned files. The January 2025 BYOA (bring-your-own-ads) feature lets publishers post HLS or DASH manifest URLs for pre-transcoded creatives directly in the VAST creative file attributes, skipping the dynamic-transcode step entirely. May 2026 added ad-trickplay personalisation (so the scrub-bar thumbnails on a VOD asset show the ad's frames, not the content's, when the viewer scrubs across an ad break) and compact DASH manifests (deduplicated AdaptationSets across ad and content periods, smaller MPDs, faster startup).
The conditioning step is the single largest cost in an SSAI bill. A 60-second ad with five renditions at 30 fps decodes to 9,000 frames, encodes to roughly 30 megabytes of segments, and a busy FAST channel can churn through 200 unique creatives per hour. If your ad-creative cache hits 70 percent the bill is manageable; if creative rotation is high (a fresh ad every viewer, every break) the transcoder bill rises faster than the CDN bill.
SSAI Tracking and Viewability: Where the Hard Problem Lives
In a CSAI deployment, the player's ad SDK fires the impression and quartile beacons directly to the ad server. The IP address on the beacon is the viewer's. The user agent is the viewer's. The viewability vendor's OM SDK runs inside the player and reports actual pixels-on-screen. The ad ecosystem trusts this data because it comes from the device.
In an SSAI deployment, none of that is true by default. The impression beacon fires from the SSAI service. The IP address on the beacon is the SSAI service's egress IP. The user agent on the beacon is whatever the SSAI service decided to forward. The OM SDK does not run on the device because there is no JavaScript SDK between the ad and the player. The result is a measurement gap: the ad server thinks the ad was delivered, but it has no way to know whether the device actually rendered it.
Three mitigations have emerged.
First, the SSAI service forwards device telemetry to the ad server. IAB Tech Lab's VAST 4.1 and later add request headers — X-Device-User-Agent, X-Device-IP, X-Forwarded-For, X-Device-Referer — that the SSAI service is expected to populate from the player's incoming request. As of recent industry data, only about 26 percent of SSAI impressions ship with the full transparent header set; the rest are opaque, which is one reason CTV fraud rates remain elevated.
Second, the player runs a thin tracking SDK that maps ad slots to playback positions. The SSAI service emits a tracking manifest (a JSON document listing the timestamps of every ad's quartile events) alongside the media manifest. The player's SDK watches the playback position, fires the OM SDK's viewability and quartile events at the right times, and reports back to the SSAI service. Yospace's OM SDK integration, Mux's data SDKs, and Innovid's SDK all follow this pattern. The fix only works on devices that can host the SDK.
Third, on smart-TV devices that cannot run a custom SDK, the SSAI service relies on segment-fetch events as a proxy. The impression fires when the first ad segment is requested; the first-quartile fires when the segment covering 15 seconds of a 60-second ad is requested; and so on. The proxy is approximate — a fetched segment is not a rendered frame — but it is the best available measurement on a non-extensible device.
The IAB Open Measurement SDK (OM SDK), v1.5, June 2024, is the industry-standard viewability and ad-verification library. It runs inside the player on devices that can host it, exposes a standard JavaScript or native API for ad-verification vendors (DoubleVerify, IAS, Moat), and reports impression, geometry change, and viewability metrics back through the SDK. In an SSAI deployment, the OM SDK runs in the player wrapper if the player can host it (most browser players, most native iOS and Android players can); on connected-TV devices that cannot, the SSAI service emits a "non-OM verifiable" flag and impressions are reported with reduced confidence.
The practical implication: ad measurement under SSAI is always a step worse than under CSAI, and the gap is one of the structural reasons CSAI continues to coexist on the open web.
Figure 3. CSAI vs SSAI vs SGAI. In CSAI, the player does the ad decision, the ad fetch, and the tracking. In SSAI, the server does all three. In SGAI, the server picks the ad, the player fetches the creative and runs the tracking — the best of both, at the cost of player complexity.
Live SSAI vs VOD SSAI: The Latency Tax
VOD SSAI is the easy case. The content is finished, the cues are pre-encoded into the manifest at packaging time, the ad transcoder has hours to pre-condition creatives, and the SSAI service has no real-time pressure. A viewer's per-session manifest can be assembled in milliseconds and the entire impression flow fires inside the same HTTP request that returns the manifest.
Live SSAI is the hard case. The cue tone arrives in the contribution feed seconds before the ad break opens, the SSAI service must call the ADS, condition the ad, splice it into the manifest, and emit the personalised playlist before the player tries to fetch the next segment — all without breaking the player's adaptive-bitrate logic. Historically, the round trip added 15 to 30 seconds of latency to live SSAI streams over plain LL-HLS or LL-DASH: the ad break needed look-ahead room. In 2026, two architectural moves cut that figure.
The first is edge-resident SSAI, in which the manifest manipulator runs at the CDN's edge rather than centralised in a single data centre. A viewer in São Paulo hits a São Paulo edge that already has the cue, the ad creative, and the personalisation logic local. The round-trip-time component of the latency budget drops from ~150 ms (intercontinental) to ~10 ms (city-local), which removes the need for the look-ahead buffer in many deployments.
The second is pre-conditioned ad pools. The VAST response no longer points at a mezzanine that needs transcoding; it points at pre-transcoded HLS/DASH manifests the SSAI service can splice without further encoding. AWS MediaTailor's BYOA (January 2025) is one implementation of this; Bitmovin, THEO, and Yospace all offer equivalents.
A worked latency budget for a 2026 live SSAI deployment looks like this. Take a 100-millisecond glass-to-glass live event:
Capture to encoder: 30 ms
Encoder to packager: 60 ms
Packager to ingest origin: 50 ms
Origin to SSAI service: 20 ms (same region)
SSAI service ad decision: 80 ms (cached ad)
SSAI service ad conditioning: 10 ms (pre-conditioned BYOA)
SSAI service to CDN edge: 15 ms
CDN edge to viewer: 120 ms
Player decode and render: 40 ms
---------------------------------------
Total glass-to-glass: 425 ms
Same budget without BYOA (dynamic transcoding) and without edge-resident SSAI:
Capture to encoder: 30 ms
Encoder to packager: 60 ms
Packager to ingest origin: 50 ms
Origin to SSAI service: 150 ms (cross-region)
SSAI service ad decision: 180 ms (cold cache)
SSAI service ad conditioning: 800 ms (dynamic transcode)
SSAI service to CDN edge: 150 ms
CDN edge to viewer: 120 ms
Player decode and render: 40 ms
---------------------------------------
Total glass-to-glass: 1,580 ms
The 2026 architecture is roughly four times faster than the 2022 one, and the gap explains why live-sports SSAI deployments have finally stopped looking like the historical 15-second compromise. They still trail pure no-ad live streaming by a beat — the ad-decision and ad-conditioning steps cannot disappear entirely — but the gap is now a third of a second, not eight.
The latency budget also explains why live SSAI demands SCTE-35 pre-roll. The cue is emitted not at the splice point but four to six seconds before, so the SSAI service has time to call the ADS, condition the ad, and rewrite the manifest before the player asks for the segment after the cue. Without pre-roll, live SSAI works only on long-look-ahead VOD-like streams; with it, live and near-live work on the same pipeline.
Figure 4. Live SSAI latency budgets, 2022 vs 2026. Pre-conditioned ads and edge-resident manifest manipulation collapse the largest contributors. The remaining floor is dominated by the same factors that govern any LL-HLS or LL-DASH stream — encoder, packager, network, decoder.
SSAI vs CSAI vs SGAI: The 2026 Decision
The third option in the room is Server-Guided Ad Insertion (SGAI), formalised by IAB Tech Lab in late 2025 as a hybrid that addresses the measurement gap and the personalisation rigidity of pure SSAI. In SGAI, the server still decides which ad goes in which slot — that part is server-side — but the player fetches the ad creative directly and runs the standard OM SDK and VAST tracking inside the player. The server sends a manifest with cue points and a sidecar JSON document describing the ads; the player honours both. The Ad Format Hero initiative the IAB Tech Lab launched alongside the SGAI spec adds support for Pause ads, Squeezebacks, Overlays, and L-shaped ads that pure SSAI cannot express because they require client-side compositing.
The 2026 decision tree for which model to ship looks like this:
| Criterion | CSAI | SSAI | SGAI |
|---|---|---|---|
| Browser playback | strong | possible | strong |
| Connected-TV (Tizen, webOS, Vidaa, Roku) | weak | strong | possible |
| Mobile app playback | strong | strong | strong |
| Ad-blocker resistance | weak | strong | strong |
| Impression measurement fidelity | high | medium | high |
| Live-stream latency overhead | low | medium | low |
| Interactive ad formats (overlays, pause ads) | strong | weak | strong |
| Implementation complexity | low | medium | high |
| Personalisation depth | high | medium-high | high |
| 2026 industry investment | maintenance | active | growing |
Common SSAI pitfalls
The four bugs that block launch the week before launch:
Pitfall — cue without pre-roll. The contribution feed emits asplice_insertat the splice point itself, not four to six seconds ahead. The SSAI service has no time to call the ADS and splice the ad before the player asks for the next segment, so the splice misses the boundary and the player stalls. Fix: configure the encoder or master-control automation to emit cues atsplice_event_id - pre_roll.
Pitfall — discontinuity-free splice in HLS. Engineering forgets the#EXT-X-DISCONTINUITYtag around the ad block. The player's video decoder sees a PTS jump it didn't expect and freezes the frame. Fix: every ad block is wrapped in two#EXT-X-DISCONTINUITYtags, one before the first ad segment, one after the last.
Pitfall — ad-rendition mismatch in DASH. The ad'sAdaptationSetlists video resolutions the content'sAdaptationSetdoes not. The player can't find a matching rendition for its current bitrate selection and stalls or downshifts. Fix: ad conditioning produces every rendition the content uses, not a subset.
Pitfall — opaque tracking beacons. The SSAI service fires impression beacons without theX-Forwarded-FororX-Device-User-Agentheaders. The ad server can't dedupe across devices, viewability vendors can't attribute, fraud rates rise, and CPMs fall. Fix: VAST 4.1+ transparency headers must populate on every beacon — this is the cheapest single bug fix that lifts revenue.
SSAI Cost Economics
The cost stack for SSAI runs on four lines.
Line one — manifest manipulation. Vendors price this per ad request (the SSAI service's billing event), typically at one to four US cents per thousand requests in 2026. A FAST channel serving 5,000 concurrent viewers, 14 ad breaks per hour, with one ad request per break per viewer, fires 70,000 requests per hour. At 2 cents per thousand: 70,000 / 1,000 × $0.02 = $1.40 per hour, or roughly $34 per day per channel. At 100 channels, $3,400 per day.
Line two — ad conditioning (transcoding). Vendors price this per ad-creative variant. A 60-second ad transcoded into five renditions at 5 cents per variant is $0.25 per creative. With a 70 percent cache hit, only 30 percent of creatives need conditioning per hour. A channel rotating 50 unique creatives per hour: 50 × 0.30 × $0.25 = $3.75 per hour. At 100 channels, $9,000 per day.
Line three — egress. The personalised manifest and the ad segments travel out of the SSAI service. Manifest egress is negligible (a 10 kB MPD per viewer per minute). Ad-segment egress is real: a 60-second ad at 6 Mbps (highest rendition) is 45 megabytes, but the CDN absorbs most of this for cached creatives. The marginal egress hitting the SSAI service is more like 5 MB per viewer per ad break. At 5,000 viewers × 14 breaks × 5 MB = 350 GB per hour. At $0.01 per GB egress from a CDN tier-one origin: $3.50 per hour. At 100 channels, $8,400 per day.
Line four — engineering and operations. A two-engineer team to operate the SSAI integration costs roughly $400,000 per year fully loaded in a US market, or $1,100 per day spread across the SSAI footprint.
The total daily cost for a 100-channel FAST deployment, 5,000 concurrent viewers per channel, is roughly $3,400 + $9,000 + $8,400 + $1,100 = $21,900 per day, or $656,700 per month. The same deployment under CSAI would save the manifest-manipulation and conditioning lines (call it $12,400 per day) but would lose perhaps a third of impressions to ad blockers and another tenth to non-compliant smart-TV devices. At a $30 CPM, that lost revenue runs into the seven figures per month — and that is why SSAI dominates CTV and FAST even though the per-impression cost is higher.
Figure 5. The four-line SSAI cost stack at 100-channel scale. Ad conditioning dominates; manifest manipulation is small; egress sits between the two. The horizontal line is the CSAI equivalent — visibly cheaper, but ignores the ad-blocker and CTV revenue lost.
Where Fora Soft Fits In
Fora Soft has built ad-supported video products since the early days of OTT — broadcast-quality FAST channels, live e-sports streams with mid-roll inventory, telemedicine platforms with sponsored content, and e-learning systems with course-level ad inventory. The integrations that ship cleanly are the ones that treat SSAI as a contract between three teams: the encoder team that emits SCTE-35 cues with the right pre-roll, the platform team that runs the manifest manipulator at the edge, and the ad-operations team that owns the VAST exchange and the OM SDK fidelity. We have shipped integrations against AWS Elemental MediaTailor, Yospace, Broadpeak, Wowza, and several custom origins, and the failure mode is almost always at the seams between teams rather than in the protocol itself. The deepest lift in 2026 has been moving FAST clients from pure SSAI to SSAI-on-the-web / SGAI-on-mobile / SSAI-on-CTV split deployments, because the IAB SGAI work has matured enough to make the player-side complexity worth the measurement gain.
What to Read Next
- CSAI and VAST/VPAID/SIMID in depth — the client-side alternative this article positions against.
- QoE metrics every streaming dashboard should show — how ad performance fits into the broader engineering scorecard.
- Cost economics of a streaming product: a worked model — where SSAI fits in the full P&L for an OTT service.
Talk to a streaming engineer · See our work · Download
- Talk to a streaming engineer. Walk through your SSAI architecture with a Fora Soft engineer. We have shipped integrations against every major vendor and several custom origins. Book a 30-minute scoping call.
- See our case studies. Real OTT and FAST deployments where we wired SCTE-35 contribution, MediaTailor or Yospace integration, and the player-side tracking layer. Browse case studies.
- Download the SSAI integration checklist. A single-page A4 reference covering the four pre-launch checks, the cue-handling rules, the VAST exchange fields, and the four bugs that block launch. Download SSAI integration checklist (PDF).
References
- ANSI/SCTE 35 2023r1 — Digital Program Insertion Cueing Message Part 1: Legacy Splice-Based and Time-Based Signaling. ANSI-approved 29 February 2024. The normative source for splice_insert, time_signal, splice_null, and the segmentation_descriptor catalogue used in §3 and §4. The 2023 revision split the standard into Parts 1 (legacy) and 2 (event-based) and added nested events. Tier 1 (official standard). SCTE catalogue.
- IETF RFC 8216 — HTTP Live Streaming. Roger Pantos, William May. August 2017. Section 4.3.2.7 defines
EXT-X-DATERANGE; the SCTE35-CMD/SCTE35-OUT/SCTE35-IN attributes are profiled by Apple in the Authoring Specification (see entry 3). Tier 1. RFC 8216. - Apple HLS Authoring Specification for Apple Devices, revision 2025-09. §2.4 and §4.7 cover SCTE-35 carriage and
EXT-X-DATERANGEprofile attributes; §3.6 coversEXT-X-DISCONTINUITYdiscipline around splice boundaries. Tier 1 (vendor-owned profile of the IETF RFC). Apple Developer documentation. - ISO/IEC 23009-1:2022 — Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats. The normative source for the multi-period MPD structure and the
EventStreamelement used in §4. Tier 1 (paywalled; the article relies on the catalogue page abstract and on DASH-IF's open mirror in entry 5). ISO catalogue. - DASH-IF Implementation Guidelines: Advanced Ad Insertion (current revision, 2026). The open-access implementation profile for DASH ad insertion, including remote-period (xlink) and multi-period patterns, the urn:scte:scte35:2014:xml+bin scheme, and inband emsg carriage. Tier 1 (industry-body open implementation guide that mirrors the paywalled ISO text). DASH-IF guidelines.
- IAB Tech Lab VAST 4.3 Specification (latest VAST 4.x revision as of 2026) and VAST CTV Addendum 2024 (published July 2024). The schema VAST requests and responses in §5 conform to, including the mezzanine file, the
- IAB Tech Lab Open Measurement SDK (OMID API) v1.5, June 2024. The viewability and ad-verification API the player runs to report impression and quartile events back through the ad ecosystem. Tier 1. OMID API v1.5 PDF.
- IAB Tech Lab Server-Guided Ad Insertion (SGAI) specification, late 2025 / 2026 publication. The formal definition of SGAI used in §7 — the server picks the ad, the player fetches and tracks. The associated Ad Format Hero initiative defines the interactive formats (Pause ads, Squeezebacks, Overlays, L-shaped) that pure SSAI cannot express. Tier 1. SVTA SGAI overview PDF.
- AWS Elemental MediaTailor documentation. The reference SSAI implementation cited throughout §3, §5, and §6 for ad conditioning modes, BYOA via VAST responses (January 2025), and the May 2026 compact-DASH and ad-trickplay updates. Tier 4 (vendor reference deployer; useful for "what actually ships" but never overrides the IAB or SCTE specs above). MediaTailor architecture, BYOA announcement, May 2026 update.
- Bitmovin — SCTE-35: The Essential Guide [2025 Update] and SSAI: Server-Side Ad Insertion. Vendor engineering blog references for the §3 splice-command catalogue and the §7 architecture overview. Tier 4. Bitmovin SCTE-35 guide, Bitmovin SSAI overview.
- Yospace — SSAI & SGAI and the April 2026 10-billion monthly ad insertions milestone. Tier 4. Yospace SSAI page, Broadband TV News April 2026 milestone.
- Pixalate — Invalid SSAI: How Pixalate measures OTT/CTV ad fraud. Source for the 26-percent transparent-header SSAI figure referenced in §6. Tier 4 (industry measurement vendor; reporting a measurement, not a spec). Pixalate analysis.
The article followed the spec in every place a spec exists. Two notes: (a) the Apple HLS Authoring Specification revision 2025-09 is the controlling profile for EXT-X-DATERANGE SCTE-35 carriage; readers who consult RFC 8216 alone will see the base tag but not the SCTE35-* attribute discipline, which is added by Apple's profile. (b) The DASH-IF Implementation Guidelines for Advanced Ad Insertion mirror the paywalled ISO/IEC 23009-1 text in the parts the article covers; the catalogue-page abstract and the DASH-IF text agree.
