The problem with splicing
The obvious way to put an advert into a live stream is to stop sending the programme and start sending the advert. It is also the way that causes almost every problem operators report. Switching between two independently encoded streams means the timeline the player is tracking breaks: timestamps jump, encoding parameters change mid-flight, and the playlist has to tell the player that what follows is not continuous with what came before.
Well-behaved players handle that. Plenty of players do not. What operators see in practice is a spinner at the top of every break, audio that returns a beat late, or a set-top box that quietly gives up and has to be restarted — and because it happens at the ad rather than in the programme, the complaint arrives attached to the sponsor.
It also shows up in the numbers. A break that causes a proportion of the audience to drop out is not merely a technical fault; it is inventory you were paid for and did not deliver, and it makes the next renewal conversation harder than it needs to be.
One continuous encode
StreamAdsPro does not splice. The programme and the sponsor are combined into a single picture, and that single picture is encoded as one unbroken stream from the moment the channel starts to the moment it stops. An advert is not a different stream that gets switched to — it is a change in what the frames contain. The encoder never stops, the timeline never jumps, and the playlist never has to declare a discontinuity.
For the player, an ad break is not an event at all. It receives the same segments at the same cadence with the same encoding parameters throughout, so there is nothing to resynchronise and nothing to recover from. This is why the format options are the ones they are: an L-shape wrapped around a reduced picture, a lower third, a corner card or a fullscreen hold all work naturally, because each is simply a description of what the frame should contain during that period.
What it takes as input, and what you get back
- 1Your existing stream, unchanged
A standard live HLS URL. Your origin encoder is not reconfigured, your stream is not re-hosted, and your playout routine does not change. RTMP and SDI sources are handled by adding an encode at the front.
- 2Creatives and a schedule
The sponsor artwork or video, and when it should appear — a fixed rhythm through the broadcast day, a festival or event window, or break times signalled by your playout system. Each channel is configured separately.
- 3A standard HLS output
A normal live playlist with normal segments, servable from your CDN exactly as your current output is. Anything that plays your channel today plays the monetised channel with no client-side change.
Channels are configured and supervised one at a time rather than as a single shared process. A fault on one channel stays on that channel and restarts on its own; it does not take a node down with it. That isolation is the difference between one sponsor missing a spot and an operator explaining an outage to all of them.
What to test before you commit
This applies to any vendor, including us, and it is worth doing on your own feed rather than on a demo channel someone else has prepared. All six are observable from outside the system, without being told anything about how it is built.
Fetch the live playlist repeatedly through an ad and read it. Segment numbering should advance normally and nothing should announce a break in continuity. If it does, players will react to it.
Not a laptop. The oldest set-top box and the cheapest smart TV in your actual audience, through a full break and out the other side. That is where splice-based systems fail and where the failure costs you most.
Compare the monetised output against your current output on the same source. Know the figure before you design anything time-sensitive around the channel rather than after.
A pipeline that is healthy for an hour proves very little. Run it across several broadcast days and confirm that memory, disk and segment cleanup are all stable and that recovery after a source drop is automatic.
Record the output and check the sponsor was on screen for the full intended duration at the intended times. Scheduled and delivered are not the same claim, and only one of them is what you invoice against.
Audio problems are more noticeable to viewers than video ones and are reported far less precisely. Confirm there is no gap, no level jump and no drift as the break begins and ends.
Where the constraints actually are
Compositing is per-frame work, and a live channel has no idle moment in which to catch up. Every frame of every hour is touched, which is why this runs on GPU hardware for anything continuous — it is the difference between a channel that costs a fraction of a card and one that occupies a whole server.
How many channels a machine carries depends on your resolution, your frame rate and the card, and it is measured on your source rather than quoted from a table. Higher resolutions and higher frame rates cost more than people expect, and a channel at 1080p50 is a materially different proposition from one at 720p25. That sizing exercise is part of a pilot, and the resulting number is a real one you can plan capacity against.
If the break times are decided upstream by playout automation or by a rights agreement rather than by you, they arrive as cue markers in the feed, and finding out why a marker never reached the far end is its own diagnostic problem — covered on the SCTE-35 page. If you are still deciding whether server-side is the right choice at all, that argument is laid out on the SSAI versus CSAI page. The per-channel commercials are scoped to your feed rather than published, so talk to us for a quote.
Talk to someone who has run it
The useful next step is a pilot on one of your own channels, because everything above is checkable and none of it is worth taking on trust. Send your stream URL, the ad format you want on screen and the rhythm you have in mind, and the answer comes back as monetised output on your own feed rather than as a specification document.
Technical questions get technical answers, from the person who built the pipeline rather than from a sales engineer relaying them. Questions about capacity, failure behaviour and what happens when your source drops at three in the morning are all fair, and are the ones worth asking.
Frequently asked questions
What is HLS ad insertion?+
HLS ad insertion means putting advertising into an HTTP Live Streaming feed so that viewers receive it as part of the broadcast. It can be done in the player, which is client-side insertion, or on the server before the stream is delivered, which is server-side insertion. StreamAdsPro does the second: the sponsor is composited into the video itself, so it reaches every device that can already play your channel.
Will inserting ads make my stream buffer or stutter at the break?+
It should not, and that is the main thing to test when you evaluate any vendor. Many insertion systems splice between two separate streams, which forces a discontinuity into the playlist and gives players a reason to re-buffer, resynchronise audio, or drop out entirely on weaker devices. StreamAdsPro produces one continuous encode instead, so the playlist stays unbroken across an ad and players have nothing to recover from.
Does my source stream have to change?+
No. A standard live HLS source is taken as input and a standard live HLS output is produced, so nothing changes at your origin encoder and the stream does not need to be re-hosted. If your source is RTMP or an SDI feed rather than HLS, an encoding step is added at the front and the rest is unchanged.
What latency does ad insertion add?+
A few seconds, on the order of one segment plus processing, which for most channels is inside the delay their viewers already experience. Live HLS is not a low-latency protocol to begin with. If your channel has a hard latency budget — betting, auctions, interactive formats — raise it early, because that constrains segment sizing and is worth designing around rather than discovering later.
Do I need GPU hardware to run this?+
For anything running around the clock, yes, and that is a deliberate recommendation rather than an upsell. Compositing a sponsor into the picture is per-frame work on every frame of a 24/7 stream. On general-purpose CPU that cost is high enough to change the economics per channel. Running the encode on an NVIDIA GPU is what makes a flat per-channel price possible at all.
How many channels can one machine run?+
It depends on your resolution, your frame rate and the card, so the honest answer is that it is measured rather than quoted. A sizing exercise on your actual source is part of a pilot, and the number that comes out of it is the one that matters — a figure quoted from someone else’s benchmark is worth very little when your feed is 1080p50 and theirs was 720p25.
Keep reading
Why this is done on the server at all, and when the player is the better place for it.
How an upstream feed signals where a break belongs, and how to find where the cue dies.
What this pipeline puts on screen, described for the person buying it.
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.