Where a break can go
An ad can run at three points, and VAST 4.3, the IAB Tech Lab's ad specification, names them: before the content (pre-roll), in the middle of it (mid-roll) and after it (post-roll).
On a recorded video those are just positions on a timeline. A live show has no timeline to plan against, so a mid-roll needs a signal saying "the break starts now". Broadcasters use SCTE-35 cues for this, a standard for marking ad and programme changes in a feed, and HLS has a defined way to carry them in its playlist.
A live pre-roll is a different problem, and this is our reasoning rather than a spec's: it isn't a moment in the show but the moment one viewer arrives. Don't assume a system that handles breaks in the programme also plays an ad to each person joining.
Client-side or server-side: what actually changes
The difference is who fetches the ad, and nearly everything else follows from that. The first three rows come from VAST 4.3. The ad blocker row is our own reading, explained further down.
| Client-side | Server-side | |
|---|---|---|
| Who asks the ad server | The viewer's player | An ad-stitching service, on the viewer's behalf |
| How the ad arrives | The player runs it, which can mean a short buffer when it switches back to your show | Inside one continuous stream with your programme |
| Who reports that it played | The player, traditionally with cookies | The server may do it for the player, and it can't read those cookies |
| Ad blockers | The ad request can be stopped in the browser | No separate ad request from the browser to stop |
VAST 4.3 gives the main reason stitching exists: many players can do little more than play a single stream, and stitching asks nothing more of them. What you give up is sight of what happens next, because the spec warns that a stitching service may have little or no control over the ad once it's in the stream.
What VAST does, and what it leaves to you
VAST is an XML template that carries an ad's details from an ad server to a media player: which files to play and which addresses to notify as it plays. An ad server may answer with the ad itself (an InLine response) or send the request on to another server (a Wrapper). VMAP is the companion format that says where ads go within the content.
So VAST is plumbing. It needs an ad server on one end and someone paying for the ads behind it. Without those you have nothing to insert, and the sponsor route further down will suit you better.
What happens with viewers who block ads?
Stitched ads are more likely to reach them than client-side ones, but neither is certain. With client-side ads, the viewer's own player sends the request, and browser extensions can block network requests by rule. Chrome documents an extension API for exactly that, and blockers' filter rules commonly work the same way, blocking requests to specific URLs.
With server-side insertion the stitching service makes the ad request, and the ad comes down the same stream as your show. An address-based rule then has no separate ad request to match. That's our inference from how the two flows work, and it makes blocking harder, not impossible. At least one major blocker's filter syntax has a modifier meant for removing segments from HLS playlists, limited to trusted filters.
Our reasoning again, not a spec's: if your setup has the player send the tracking calls, a blocker may stop those even when the ad played, so it runs and goes uncounted. And anyone can still mute or leave, so keep your breaks to a length viewers will sit through.
Will your ad buyer accept the numbers?
Ask before you sign, because this is where server-side setups cause arguments. When a stitching server sends tracking for everyone, it all comes from one IP address, and VAST 4.3 says that can look like invalid traffic to the ad server. For now it says stitching providers must send headers naming the real device, X-Device-IP and X-Device-User-Agent, and it recommends moving to a request model based on macros.
The same section quotes measurement guidelines that favour counting which starts from the viewer's device, and it allows that an impression may have to be reported as the ad goes out on the stream. Those are different things to a strict buyer, so agree in writing how an impression is counted on your channel. Cue's own page says your ad server hears the impression, the start, the quarter marks and the finish, once per viewer per ad, whichever quality they watched.
One more check: sending a real device's details, as VAST 4.3 asks, passes each viewer's IP address to an ad server. Make sure your privacy notice covers that. Treat this as a pointer from us, not legal advice.
Pick the route that fits what you have
Start from what you already have.
| You have | Route | On Primcast |
|---|---|---|
| Sponsors you deal with directly, no ad server | Play the spot as part of the show from your encoder, or put it in a station break | Sponsors' spots in the breaks of a 24/7 TV station on any library plan |
| An on-demand library and a VAST ad server | Ads before and during your videos | Listed for Starter, Pro and Platinum libraries |
| A live channel or TV station and a VAST ad server | Ads from your own VAST ad server | Platinum (the plan table also lists server-side ad insertion) |
| Your own server, with SCTE-35 in your feed or a scheduling system | Cue runs the insertion | Cue on a dedicated server |
The sponsor route is the simplest place to start. A spot played from your encoder is simply part of the picture: every viewer gets the same one, and there's no ad request for a blocker to catch, though there's also no per-ad report. The Production tab on paid plans can make 15 or 30 second sponsor spots with your own AI account, and the Live tab's downloadable viewer list, with each viewer's country and player, gives a sponsor something concrete to look at.
A hosted channel suits you if you'd rather not run a server. Primcast's live video plans list VAST ads and server-side ad insertion on Platinum, and the on-demand library page says your live channel and TV station can run ads from your own VAST ad server there.
Cue, our streaming engine, is for when you want your hands on the signalling. On a dedicated streaming server it reads SCTE-35 breaks from an SRT, MPEG-TS or RTMP feed, whether they use splice_insert or time_signal, and marks them in the HLS stream for an outside ad platform. Or it can do the job itself: at each break it asks your ad server over VAST or VMAP what to play, then adds the ads in every quality for HLS and DASH players. With no cue in the feed, your scheduling system can start, end or call off a break through its API.
Before your first paid break
- Get a VAST tag from your ad server and run it through the IAB Tech Lab's tag validator, so a broken tag shows up now and not during your show.
- Settle what triggers a break. On Cue that's a cue in your feed or an API call. On a hosted Platinum channel, ask in live chat how breaks are triggered before you promise a sponsor a schedule, since the plan table lists the feature but not the steps. Ask about an ad as each viewer joins too: the Cue page describes ads at breaks, and only the library page mentions ads before a video.
- Ask advertisers for files that suit stitching. VAST 4.3 says a stitched ad needs a mezzanine file, the raw high-quality source, and a stitching server may reject the ad without one. Alongside it, VAST 4.x expects a UniversalAdId on a linear ad, plus an adaptive ready-to-serve file or at least three quality levels. Any change to an ad should get a new identifier, because stitching services cache by it.
- Allow for a new ad not playing at first. In the flow VAST 4.3 describes, a new ad's mezzanine file is fetched and transcoded on first use, that ad is skipped for the next available one, and error code 407 is reported. The spec says the download may take several hours, so send new ads in well before the show, and check for this before deciding a tag is broken.
- Rehearse on a spare channel. Watch a break on a phone, a browser and a TV player your ads are meant to reach, check that sound and picture return to your show cleanly, then compare your ad server's report with what you saw.
Questions people ask
- Do I need my own ad server?
- For VAST ads, yes: our pages describe ads coming from your own VAST ad server. If you don't have one, sell sponsor spots directly instead, which needs nothing beyond your encoder or a station break.
- Does Primcast put its own ads on my video channel?
- No. The library page says no plan puts our ads in front of your viewers, and the player page says the player shows your stream and its own controls, nothing else. Any ad your viewers see is one you chose to run.
- Can I use stitched ads on a Free, Starter or Pro live channel?
- The plan table on our live video page lists VAST ads and server-side ad insertion on Platinum only. Library plans are listed separately: VAST ads before and during your videos appear on Starter, Pro and Platinum. Check which of the two you actually need.
- Will my ads reach YouTube or Facebook when I restream?
- Ads inserted by a server: our pages don't say they do, so plan as if they won't. A spot played from your encoder is part of the feed you send, but read each platform's own advertising rules before you sell a sponsor that reach.
- Will ads play in my Samsung and LG TV app?
- Don't plan on ads from your VAST ad server there. Our TV app page says viewers get no sign-up, no paywall and no advertising, so leave that audience out of what you sell for those ads. It says nothing about a sponsor spot already in your picture, so if the app matters to your plan, ask us in live chat first.
- How much can a channel earn from ads?
- We can't give you a figure, and you should be wary of anyone who does. It depends on the size of your audience, who they are and what your buyers will pay. Picking server-side insertion changes where an ad can play, not whether someone wants to buy it.