SSAI: ads stop being another request.
They become the stream.
SSAI (server-side ad insertion) is the practice of stitching ads into the program stream on the server, before the video reaches the player. Point Media Tech's SSAI stitches ads frame by frame into your HLS and DASH streams at the packager; ads share the program's bitrate ladder and its domain, so the player sees one continuous video. There is no separate request for an ad blocker to stop, impressions are reported by server-side beacon for reconciliation, and on one channel each viewer can see a different ad.
Same break,
two viewers, different ads.
Point Media Tech's SSAI stitching console shows the source stream alongside the manifests individual viewers actually receive. The ads are already inside the stream, so the player never makes a second request — which is what the blocker tests on the right are measuring.
Two products, one chain, upstream and downstream.
Ad Insertion decides when to break. SSAI decides whose ad goes in, and how it reaches the stream. The first produces frame-accurate SCTE-35 cues on your linear signal, marking every opportunity. The second reads those cues, calls your decision server, and splices the result into the stream your viewer is already watching.
A channel that already has an SCTE-35 signal source can adopt SSAI alone. A linear or FAST channel starting from zero usually rolls out both together. Learn about SCTE-35 Ad Insertion
- Linear signal
- Ad Insertion
frame-accurate cues - SSAI
read cue, call for ad, stitch - The viewer's stream
With CSAI, the player fetches a separate ad.
With SSAI, the ad was already in the stream.
CSAI and SSAI differ in who stitches the ad: with CSAI the player requests the ad from an ad server, with SSAI the server stitches it into the program stream first. The CSAI ad call is a distinct request, easy for ad blockers to catch and prone to black frames and buffering. Ad blockers work by recognizing and blocking requests the player makes to external ad domains; SSAI's ads live in the same content domain as the program, with no separate, identifiable ad request, so blockers have nothing to block. CSAI still suits cases that need player-side interactive or clickable ads; for linear, FAST and live-stream monetization, SSAI gives more consistent playback and impression counting.
The player fetches the ad — blockers can see it
The player makes a separate request to an ad server to fetch the ad; easy for ad blockers to catch, and prone to black frames and buffering that interrupt playback.
The ad is already in the stream — blockers can't see it
The ad is stitched frame by frame into the program stream on the server, and the player only requests segments from the same content domain — no separate ad request for a blocker to catch.
CSAI · the player fetches the ad separately
- The player issues its own request to an ad server
- That request points at an external ad domain
- A blocker recognises the domain and stops it
- Black frames and buffering are common
SSAI · the ad is already in the stream
- Stitched server-side before the stream reaches the player
- Served from the same content domain as the programme
- There is no separate ad request to identify
- Billable impressions are not lost to blockers
Three layers that stitch ads into
the stream your viewer is already watching.
Point Media Tech's SSAI works in three layers: per-viewer targeting, format and standards compatibility, and adoption at the packager. Each layer can be evaluated on its own, and adopting it into your existing playout chain does not mean starting over.
A personalized manifest for every viewer
The stitching node generates a personalized manifest (HLS m3u8 or DASH MPD) for every viewer session. Program segments are shared by everyone; ad segments are filled in per that viewer's region, device, time slot, and audience segment, based on the VAST / VMAP decision result. To the player it still looks like an ordinary stream, but what runs in each viewer's ad slots can be completely different.
- Personalized HLS m3u8 / DASH MPD
- Shared program segments, independent ad segments
- By region / device / time slot / audience segment
- Filled by the VAST / VMAP decision result
Stream format and ad-standard compatibility
Stream output supports HLS (both TS and CMAF fMP4) and MPEG-DASH; ad decisioning supports VAST 2.0/3.0/4.x and VMAP, and integrates with major SSPs and ad servers. Ad impressions are reported via server-side beacons, and measurement events (impression, quartile, complete) can be emitted to IAB standards.
- HLS (TS / CMAF fMP4) and MPEG-DASH
- VAST 2.0/3.0/4.x and VMAP
- Integrates with major SSPs and ad servers
- IAB-standard measurement event reporting
No need to replace your encoder or CDN
The SSAI stitching node sits between your packager and your CDN, consuming the ABR stream and SCTE-35 signal your existing encoder already outputs, and emitting standard HLS / DASH — transparent to the downstream CDN and player. Your existing encoder, player SDKs, and CDN contracts can generally stay as they are.
- Transparent insertion between packager and CDN
- Keeps your existing ABR stream and encoder
- Output remains standard HLS / DASH
- Player SDKs and CDN contracts mostly unchanged
From signal audit to production traffic ·
four steps to adopt SSAI.
Point Media Tech's SSAI does not replace your existing playout chain; it connects between the packager and the CDN and is adopted in four steps: audit the signal, connect the stitching node, integrate ad decisioning, verify and go live.
- Audit the signal and ad breaksConfirm SCTE-35 cues are present, or pair with Ad Insertion to generate them
- Connect the stitching nodeDeploy between the packager and the CDN, consuming existing ABR stream output
- Integrate ad decisioningConfigure VAST / VMAP, connect an ad server or programmatic SSP
- Verify and go liveVerify stitch seams and impression reporting on real devices, then cut to production
Engineering specifications.
Point Media Tech's SSAI outputs standard HLS / DASH and supports VAST / VMAP; book a technical consultant for a live demo, the full spec sheet and an adoption assessment.
| Deployment | Web console; packager and stitching nodes deployed on Linux / x86 (Docker), on-premise or in the cloud |
|---|---|
| Stream output formats | HLS (TS and CMAF fMP4) · MPEG-DASH |
| Ad decisioning standards | VAST 2.0/3.0/4.x · VMAP; integrates with major SSPs and ad servers |
| Personalized manifest | Personalized HLS m3u8 / DASH MPD generated per viewer session; program segments shared, ad segments filled by region, device, time slot, and audience segment |
| Impression reporting | Server-side beacon reporting; emits IAB-standard measurement events (impression, quartile, complete) |
| Signal source | Reads existing SCTE-35 cues; can pair with Ad Insertion to generate frame-accurate break signaling |
| Placement and compatibility | Stitching node sits between the packager and the CDN; output remains standard HLS / DASH, transparent to the downstream CDN and player; existing encoder, player SDKs, and CDN contracts mostly unchanged |
| Licensing and pricing | Custom quote based on requirements — contact sales for details |
Frequently asked questions.
What is SSAI, and how is it different from client-side ad insertion (CSAI)?
SSAI (server-side ad insertion) is the practice of stitching ads into the program stream on the server, before the video reaches the player. The ad and the program share one stream and one bitrate ladder, so the player sees a single continuous video. With CSAI, the player fetches ads separately from an ad server, which ad blockers can catch and which often shows up as black frames and buffering.
How is SSAI different from SCTE-35 Ad Insertion? Do we need to buy both?
Not necessarily: a channel that already has an SCTE-35 signal source can adopt Point Media Tech's SSAI on its own. Ad Insertion generates frame-accurate SCTE-35 cues on the linear signal and decides when to break; SSAI reads those cues, calls the ad decision server and stitches the result into HLS / DASH, deciding whose ad runs and how. A linear or FAST channel starting from zero usually adopts both.
How does SSAI serve a different ad to every individual viewer?
Point Media Tech's SSAI stitching node generates a personalized manifest (HLS m3u8 or DASH MPD) for every viewer session. Program segments are shared by everyone; ad segments are filled per that viewer's region, device, time slot and audience segment, based on the VAST / VMAP decision. To the player, it is still an ordinary HLS / DASH stream.
Do ad blockers cost us streaming ad revenue, and how does SSAI handle them?
Under CSAI they do; Point Media Tech's SSAI stitches the ad into the program stream, leaving no separate ad request to block. Blockers work by recognizing and blocking the player's requests to external ad domains, while an SSAI player only requests segments from the same content domain. Impressions are reported by server-side beacon, so billable impressions are no longer lost to blockers.
Which stream formats and ad standards does SSAI support?
Point Media Tech's SSAI outputs HLS (TS and CMAF fMP4) and MPEG-DASH, and ad decisioning supports VAST 2.0/3.0/4.x and VMAP. It integrates with major SSPs and ad servers. Impressions are reported by server-side beacon, with IAB-standard measurement events (impression, quartile, complete).
Do we need to replace our existing encoder or CDN to adopt SSAI?
Usually not: Point Media Tech's SSAI stitching node sits between the packager and the CDN, and its output is still standard HLS / DASH. It consumes the ABR stream and SCTE-35 signal your existing encoder already produces, transparent to the downstream CDN and player. Existing encoders, player SDKs and CDN contracts can generally stay as they are.
Ready to make streaming ad impressions
measurable and billable?
Book a demo and see how Point Media Tech's SSAI stitches ads in at the stream layer and reports every impression by server-side beacon.