The one-line version
When SSAI is the right answer
Smart TVs, set-top boxes, Chromecast, an embed on a partner site. You cannot ship an SDK to any of them, but they all play HLS.
There is no separate ad request to intercept. On the burned-in overlay formats there is not even a separate ad element in the DOM.
The ad is the same encode as the programme, so there is no re-buffer at the splice and no black frame while a player fetches a creative.
Configure the channel once at the encoder and every downstream player inherits it. No per-platform ad module to keep alive.
L-shape banners, lower thirds and corner bugs only exist server-side. A player cannot draw into the video frame itself.
Because the overlay is in the picture, screenshots, recordings and cast sessions all carry it. A player-side ad carries none of that.
When CSAI is the right answer
The client knows the user, the session and the consent state. Serving a different creative to a different viewer is trivial there and awkward server-side.
Quartiles, viewability, click-through, mute state. Those are client-side signals; a server can only ever infer them.
Not showing the same person the same spot four times an hour needs per-user state, which lives naturally in the player.
The VAST and VPAID ecosystem was built client-first. If your demand comes from a network, the client is the shortest path to it.
A web page or your own app, where shipping a player update is something you can do this week rather than negotiate with a TV vendor.
CSAI adds no transcoding cost, because nothing is re-encoded. The ad never touches your pipeline.
The honest trade-offs
Most channels should run both
The comparison is usually framed as a choice, and for a single stream it is. Across a whole channel it usually is not. The two approaches monetise different parts of the same audience, and the split that works looks like this:
Run SSAI as the floor. Every viewer on every device gets the burned-in formats — the corner bug, the L-shape rotation, the fullscreen break. Nothing can block it, nothing needs an SDK, and the smart-TV audience you cannot otherwise reach is monetised at the same rate as everyone else.
Then run CSAI as the premium layer on the surfaces you actually control — your website and your own app — where a targeted pre-roll with real quartile reporting is worth several times a generic one, and where you can afford to lose the blocked share because the floor already covered it.
StreamAdsPro ships both halves. The server-side pipeline is described on the SSAI page, the client-side player on the CSAI player page, and the marker that tells either of them where a break belongs on the SCTE-35 page.
Frequently asked questions
What is the difference between SSAI and CSAI?+
SSAI (server-side ad insertion) puts the ad into the video on the server, before the stream reaches the viewer, so the ad arrives as ordinary video frames and segments. CSAI (client-side ad insertion) leaves the stream untouched and has the player fetch and play the ad separately at the right moment. The practical consequence is that SSAI cannot be blocked or skipped and works on any device that can play video, while CSAI can be blocked but knows far more about the individual viewer.
Is SSAI better than CSAI?+
Neither is better in general. SSAI wins when you do not control the playback surface — smart TVs, set-top boxes, casting, embeds on other people sites — and when ad-block resistance matters. CSAI wins when you do control the player, when you need per-viewer targeting and frequency capping, and when you need the click-through, quartile and viewability signals that only a client can report.
Can ad blockers stop SSAI?+
Not in the way they stop CSAI. With SSAI the ad is the same video stream as the programme — the same segments, the same manifest, often the same encode. There is no distinct ad request to block and no separate ad element to hide. StreamAdsPro goes further and burns overlay formats into the frame itself, which removes even the possibility of a player-side skip.
Does SSAI break my player?+
No, and that is the point. Because the output is a normal HLS stream, any player that already plays your channel keeps playing it — hls.js, AVPlayer, ExoPlayer, a smart TV app, a set-top box, a Chromecast session. There is no SDK to integrate and no per-platform ad module to maintain.
Can I use SSAI and CSAI together?+
Yes, and many channels should. A common split is SSAI for the baseline monetisation that must reach every device — a burned-in L-shape banner or a fullscreen break — plus CSAI on your own web and app players, where a targeted pre-roll is worth more than a generic one. The two do not conflict; they monetise different parts of the same audience.
What does SCTE-35 have to do with this?+
SCTE-35 is the marker that says where a break belongs. It is how a broadcast feed signals an ad opportunity to whatever is downstream, and both approaches can act on it: SSAI uses it to decide where to splice, and CSAI uses it to decide when to tell the player to cut away. If your breaks are landing in the wrong place, the cue is usually the thing to inspect first.
Keep reading
How the server-side pipeline stitches ads and overlays into a live HLS stream.
A lightweight HLS player with pre-roll and mid-roll ads, embedded with one script tag.
The cue that tells either approach where a break belongs — and how to find where it dies.
A managed, usage-billed SSAI service compared with a flat-fee, self-hosted one.
Video-technology engineer in Thane, India. Send me one live stream URL and I will run a free test on your own feed. You get my reply within one working day (IST), from the person who builds it, not a sales queue.
Bring us your stream.
Send us one live URL and what you want on it. We will put a demo on your own feed before you commit to anything.