HLS Interstitials Explained: Client-Side Ad Splicing Without Segment Re-encoding

Ads in HLS streams have historically been handled in two ways: bake them into the encoded video before delivery (client-side ad insertion with JavaScript hooks, which breaks download), or stitch them into the segment sequence at the CDN before the client ever sees the playlist (server-side ad insertion, SSAI). A newer approach — HLS Interstitials, part of an Apple-driven draft extension sometimes called HLS-I — shifts the decision back toward the client while keeping the ad content physically separate from the main stream.

What an Interstitial Is

An HLS Interstitial is a secondary HLS playlist — a standalone ad or bumper video — that a client is told to play at a specific wall-clock position within the primary stream. The trigger is an X-DATERANGE tag in the primary playlist carrying an interstitial asset URI:

#EXT-X-DATERANGE:ID="ad-break-1",START-DATE="2026-08-05T12:00:00Z",
DURATION=30,X-ASSET-URI="https://ads.example.com/spot-30s.m3u8"

When the player's current position reaches the START-DATE, it pauses the main stream, fetches and plays the interstitial playlist to completion, then resumes the primary stream from where it left off.

X-TIMELINE-OCCUPIES: The Seekbar Problem

A 30-second ad break in a 2-hour film creates a problem for the seekbar. Should scrubbing past the ad position skip 30 seconds of program time, or should the seekbar accurately reflect total viewing time including ads?

The spec addresses this with the X-TIMELINE-OCCUPIES attribute. Setting it to POINTtells the player to treat the interstitial as zero-duration in the primary timeline — the seekbar doesn't grow, and scrubbing past the cue point skips the ad entirely if the viewer chooses to seek. Setting it to RANGEmakes the ad's duration visible and seekable in the timeline.

Streaming services typically use POINT for ads (invisible duration) and RANGE for content bumpers (visible, skippable duration).

How This Differs from SSAI

In server-side ad insertion, the CDN's ad stitcher splices the ad segments directly into the media playlist before the client downloads it. The client sees one continuous stream with no interstitial concept — the ad segments are just segments, numbered sequentially with the program content.

In HLS Interstitials, the primary playlist stays clean. Ad decisions are signaled via metadata tags; the client fetches the ad from a separate origin. This makes ad personalization easier (different clients can receive different ad URIs from the same primary stream) but requires clients to implement the interstitial spec.

What This Means for /convert

The /convert route parses the master playlist, picks the highest-bandwidth variant, downloads its media segments, and muxes them into an MP4. Interstitial tags (X-DATERANGE with asset URIs) are metadata — they add no segments to the media playlist. The muxer never sees or fetches the interstitial playlists.

The result is a clean download of the primary content with no ad segments, regardless of what interstitial ad breaks were scheduled. This is a structural consequence of how HLS Interstitials work: ads that live in a separate playlist are simply not part of the primary segment list being downloaded.

Browser and Player Support

As of mid-2026, HLS Interstitials are an Apple-driven extension supported natively in Safari's built-in HLS player and AVFoundation on iOS/macOS. hls.js support is experimental and opt-in. Most ad-serving infrastructure still uses SSAI for cross-browser compatibility, so interstitial-only streams are relatively uncommon outside the Apple ecosystem.