Player Demo
Client-side ad insertion — point it at any stream and ad video.
CSAI ad player — pre-roll and mid-roll ads for HLS
Client-side ad insertion for live and on-demand HLS. Point it at the stream you already publish, add one script tag, and pre-roll and mid-roll ads start running — no re-encode, no SDK, no change to your encoder or CDN. Configure it on the left and watch the breaks fire below.
What client-side ad insertion is
Client-side ad insertion — CSAI — plays the advertisement on the viewer’s own device, as a separate video alongside your programme. The player pauses the content, plays the ad, and resumes. Nothing is stitched on a server, so your stream is never re-encoded and never moved.
That is the opposite trade from server-side ad insertion, where the ad is spliced into the video before it ever leaves the origin. Both approaches put an ad in front of a viewer; they differ in where the work happens, and everything else — cost, reach, and how well the ad survives contact with an ad blocker — follows from that one choice.
CSAI is the faster of the two to put into production, and for a channel whose audience is mostly on web and mobile browsers it is often all that is needed.
Why channels start here
Nothing about your stream changes
The player points at the HLS URL you already publish. Your encoder settings, your packager, your origin and your CDN all stay exactly as they are. There is no re-encode, no re-host, and no migration window — which is why a channel can go from no ads to running ads inside a day.
One script tag, no build step
It is a drop-in web player, not an SDK integration. You add a script tag and a custom element to the page you already have. There is no npm install, no bundler configuration, and no framework requirement — it works the same on a hand-written HTML page as it does inside a React or WordPress site.
Rendering happens on the viewer’s device
Because the ad is composited in the browser rather than on a server, there is no per-stream encoding cost to carry and nothing heavy for you to host. That is the economic argument for CSAI: the marginal cost of one more concurrent viewer is close to zero for you.
The trade you are making
The ad is a separate video request on the viewer’s device, so an ad blocker can recognise and cancel it, and a smart TV or set-top box that cannot run our player cannot show the break at all. If either of those matters more than deployment speed, the server-side core is the right answer instead.
How the breaks are scheduled
Pre-roll plays once, before the content starts. Mid-roll ads then fire on a fixed interval you choose, with an ad duration you also control — both are on the configuration panel, and changing either one remounts the player so you can watch the new schedule take effect immediately.
Interval scheduling is deliberately simple, and it is the right model for a channel that does not yet have marked ad breaks in its stream. If your feed already carries SCTE-35 cue markers — or you need breaks to land on exact broadcast boundaries rather than on a timer — that is the server-side core’s job, because the markers have to be honoured where the video is assembled.
The player emits a real ad-impression event as each break plays — the event you would wire into your own reporting once the player is on your site.
CSAI or SSAI?
Choose CSAI when speed matters most: your viewers are on browsers, you want ads running without touching your pipeline, and you would rather validate that advertising works at all before investing in infrastructure.
Choose server-side ad insertion when the losses start to show — when enough of your audience runs an ad blocker that the missing impressions are real money, or when smart TVs and set-top boxes are a meaningful share of your viewing and simply cannot run a web player. Those two problems have the same fix, and it is not a better client-side player.
— including why an ad blocker cannot remove a stitched ad.
Common questions
- What is client-side ad insertion?
- Client-side ad insertion (CSAI) plays the advertisement on the viewer’s own device, as a separate video alongside your content. The player pauses the programme, plays the ad, and resumes. Because nothing is stitched on a server, your existing stream is never re-encoded or moved.
- What do I need to change on my stream?
- Nothing. The player takes the HLS URL you already publish. Your encoder, packager, origin and CDN are untouched. You add a script tag to your page and point the player at the stream.
- Does it work with live streams as well as recorded video?
- Yes. It handles live HLS channels and on-demand video, with pre-roll before playback starts and mid-roll ads on an interval you set. You can switch between live and on-demand behaviour on this page to see both.
- Can an ad blocker stop client-side ads?
- Yes, and this is the honest limitation of the approach. The ad is a distinct request from a distinct file, which is exactly the pattern blockers match against. If ad-block loss is material to your revenue, server-side ad insertion is the answer, because there the ad is inside the stream itself.
- Will it play on a smart TV or set-top box?
- Not reliably. CSAI needs our player to run on the device, and TV and set-top platforms generally will not run an arbitrary web player. Those devices are the main reason channels move to the server-side core, where any ordinary HLS player shows the break correctly.
- Should I start with CSAI or SSAI?
- Start with CSAI if your audience is mostly on web and mobile browsers and you want ads running quickly with no change to your pipeline. Choose SSAI if you need ad-block-proof delivery, smart-TV reach, or broadcast-grade breaks driven by SCTE-35 markers.