SSAI (server-side ad insertion)
SSAI (server-side ad insertion) stitches video ads into a stream on the server, so the player receives content and ads as one continuous stream. A manifest manipulator reads break markers such as SCTE-35, asks an ad decision server which ads each viewer should get, and rewrites that viewer's playlist to point at ad segments encoded to match the content. Because ads arrive from the same source as the show, transitions are smooth and ad blockers have little to remove. Tracking moves to the server.
How does SSAI work?
SSAI runs as a service between the player and the origin. When a viewer requests a stream, the SSAI service fetches the content manifest and finds the breaks, marked with SCTE-35 for live and linear streams or with cue points for on-demand titles. For each break, it sends an ad request with the viewer's context to the ad decision server, which replies in VAST with the chosen ads.
The ads must look like the content to the player. The SSAI service transcodes each new ad into the same codecs, resolutions and segment lengths as the content ladder, a step called ad conditioning, and caches the result. It then writes a manifest for that session. In live and linear streams the ad segments replace the content segments under the break; in on-demand titles they are inserted at each cue point. Discontinuity tags are added at the joins so the player resets its timestamps and decoder. As the ads play, the service fires the tracking beacons the advertiser bills against.
SSAI vs. CSAI
Client-side ad insertion (CSAI) puts the ad logic in the player. At a break the player pauses the content, requests VAST itself, loads the ad from the ad server's CDN and plays it, often in a second video element. That gives rich, clickable formats and direct measurement from the device, but each break is a second startup, ads may be encoded at very different bitrates, and ad blockers can intercept the requests.
SSAI moves that work to the server. The player sees one stream, so there is no second startup and the ad plays at the same quality as the content. Ad blockers have no separate request to block. The trade-offs are cost and complexity: every viewer gets a personalised manifest, ads must be conditioned before they can play, and click-through and viewability are harder to measure. Connected TVs and live sports lean on SSAI; web apps that need interactive ads keep CSAI.
What does SSAI need from the content stream?
SSAI is only as clean as the stream it works on. Break markers must be accurate: SCTE-35 cues carry the break's start and duration, and a cue that arrives late or with the wrong duration produces a clipped ad or a few seconds of the content the ad was meant to cover.
The encoder must cooperate too. Each splice point needs a keyframe, a frame decodable on its own, and segment boundaries should line up with the break so the SSAI service can cut cleanly between segments. Audio loudness should be normalised so an ad is not louder than the programme.
When content is protected with DRM, ads are usually clear, so the manifest switches between encrypted and clear segments at each discontinuity, and players must handle that change without a stall. Testing the full break path on each target device before launch catches most of these problems.
How is SSAI ad tracking measured?
In client-side ads, the player calls each tracking URL as the ad plays. In SSAI, the player may not know an ad is playing at all, so tracking needs a different design.
Server-side beaconing has the SSAI service fire impression and quartile beacons as it serves ad segments. It is simple, but it counts segments delivered, not seconds watched, so a viewer who closes the app mid-ad can still be counted. Client-side tracking in SSAI fixes that by sending ad timing to the player as timed metadata in the stream, or through a side channel the player polls, so the player fires beacons from what it actually renders. Many ad buyers require that for connected TV.
Personalised manifests also change caching. Ad and content segments stay cacheable at the CDN, but each session's manifest is unique, so manifest requests reach the SSAI service and must scale with concurrent viewers.
How does FastPix handle SSAI?
FastPix's part in SSAI is narrow: Cloud Playout channels support SCTE-35 markers. Ad decisioning, ad conditioning and stitching come from your SSAI partner; FastPix does not stitch ads into streams.
Cloud Playout turns your FastPix library and live inputs into a 24/7 linear channel: you program content by time slot, mix VOD and live inputs in one rundown, and cut to live and back automatically. A fallback item plays if a slot is empty, and a browser-based control room lets you preview what is on air and change the rundown mid-air. SCTE-35 is the cue format an SSAI service reads to find each break; confirm with your partner how it takes in the channel's output.
Video Data reports per-channel concurrent viewers, watch time, startup time, rebuffering and errors, so viewer-side problems on a channel, including any that cluster around breaks, show up in the data. Event-level export to your warehouse lets you line those sessions up with your ad partner's impression reports.
Cloud Playout costs $99 per channel a month, with a 14-day trial. It schedules against your full FastPix library with no storage bands, so the channel fee stays flat per channel. Your SSAI partner bills separately for its work. Start the 14-day trial, build a channel from your library and send its SCTE-35 markers to your ad partner for a test.
