Low-Latency HLS (LL-HLS) is an extension of the HTTP Live Streaming protocol that reduces the delay between a live event and its playback to roughly two to five seconds, compared with the 15 to 30 seconds common in standard HLS. In streaming & broadcasting, it is used for live sports, auctions, betting, interactive shows and any service where viewers must not lag far behind real time.
Apple introduced LL-HLS in 2019 and incorporated it into the HLS specification in 2020. It keeps the core strengths of HLS, namely plain HTTP delivery, CDN caching and adaptive bitrate streaming, while adding partial segments, blocking playlist reloads and preload hints so that players can fetch media almost as soon as it is encoded.
Why standard HLS has high latency
Classic HLS divides a stream into segments of about 2 to 6 seconds and lists them in a playlist. A player usually waits until three segments are available before starting, and a segment can only be published after it is completely encoded. These rules create delay at every stage.
| Stage | Cause of delay | Typical contribution |
|---|---|---|
| Encoding and packaging | Segment must be complete before publishing | One full segment duration |
| Playlist polling | Player checks the playlist at intervals | Up to one target duration |
| Player buffer | Start-up rule of about three segments | Several segment durations |
| CDN propagation | Origin to edge transfer and caching | Fractions of a second to seconds |
Shortening segments to one second reduces latency but multiplies requests and weakens compression, because each segment must begin with a keyframe. LL-HLS solves this differently: it keeps normal segment sizes and publishes smaller pieces of them early.
How Low-Latency HLS works
The core mechanism is the partial segment, a small chunk of media typically lasting 200 to 500 milliseconds. The packager announces each part in the media playlist as soon as it is ready, so the player can download and decode media before the full segment exists. Full segments are still produced for players and CDNs that do not use LL-HLS.
| Feature | Playlist tag or parameter | Purpose |
|---|---|---|
| Partial segments | EXT-X-PART and EXT-X-PART-INF | Deliver media in sub-second pieces |
| Blocking playlist reload | _HLS_msn and _HLS_part query parameters | Server holds the request until the next part exists |
| Preload hints | EXT-X-PRELOAD-HINT | Player requests the next part before it is finished |
| Playlist delta updates | _HLS_skip and EXT-X-SKIP | Send only changes in long playlists |
| Rendition reports | EXT-X-RENDITION-REPORT | Fast switching between bitrate ladders |
| Server control | EXT-X-SERVER-CONTROL | Declares capabilities and target hold-back |
Blocking playlist reload replaces wasteful polling: the player asks for a playlist version that does not yet exist, and the server answers the moment it does. Preload hints go further by letting the player open a request for the next part in advance, so data flows as the encoder writes it.
Media in LL-HLS is normally packaged as fragmented MP4 using CMAF, although MPEG-TS parts are also permitted. Each part does not need to begin with a keyframe; only parts marked as independent can serve as a starting point. This is why the player begins at an independent part near the live edge and then follows the sequence of parts continuously.
LL-HLS compared with other low-latency protocols
Several technologies compete for live delivery. The right choice depends on audience size, required delay, device support and interactivity.
| Protocol | Typical glass-to-glass latency | Scale via CDN | Main strength |
|---|---|---|---|
| Standard HLS | About 15 to 30 seconds | Excellent | Maximum compatibility |
| Low-Latency HLS | About 2 to 5 seconds | Excellent with LL-HLS-aware CDN | Native Apple support |
| Low-latency DASH | About 2 to 5 seconds | Excellent | Chunked CMAF, open standard |
| WebRTC | Under 1 second | Harder and more expensive | Real-time interaction |
| SRT | Sub-second to a few seconds | Not for end viewers | Contribution over the internet |
LL-HLS and low-latency MPEG-DASH can share the same CMAF media chunks, so one packaging pipeline can serve both. WebRTC remains the choice for two-way conversation, but LL-HLS scales to millions of viewers on ordinary HTTP infrastructure.
Deploying LL-HLS
An LL-HLS workflow needs support at every link of the chain: a broadcast encoder or packager that produces partial segments, an origin that supports blocking requests, a CDN that handles held requests and short cache lifetimes correctly, and a player that implements the extension.
| Setting | Common value | Trade-off |
|---|---|---|
| Segment duration | 4 to 6 seconds | Longer improves efficiency and caching |
| Part duration | About 0.33 to 1 second | Shorter lowers delay but adds requests |
| Keyframe interval | Equal to segment length | Must align across all renditions |
| Part hold-back | At least three part durations | Lower values risk rebuffering |
Ingest from the production site usually arrives by RTMP or SRT, after which the cloud packager creates the LL-HLS output. Testing should include congested networks, because aggressive settings that look excellent in a lab can cause frequent stalls on mobile connections.
Monitoring should measure actual end-to-end latency, not only the configured target. A practical method is to burn a clock into the video at the venue and compare it with real time on several viewing devices, which quickly reveals players that drift behind the live edge over long sessions.
Limitations and common pitfalls
- Latency versus stability: a smaller buffer leaves less room to absorb network jitter, so rebuffering becomes more likely.
- Uneven player support: older players and some smart TV platforms fall back to standard HLS latency.
- CDN behavior matters: caching held or partial responses incorrectly can break the low-latency path.
- Higher request rates: many small requests increase load on origin and edge servers.
- Not truly real time: for two-way video calls or sub-second interaction, WebRTC remains necessary.
Explained without jargon
Normal internet live video sends the picture in blocks of several seconds. The viewer’s app waits for a few blocks before it starts. As a result, people online often see a goal half a minute after the crowd in the stadium.
Low-Latency HLS sends much smaller slices of each block as soon as they are ready. The app also asks for the next slice before it is finished. Viewers then stay only a few seconds behind the live action, and the stream still travels over ordinary web servers.
A typical use case
A sports streaming service shows live football and runs an in-app prediction game in which viewers guess the next corner or card. With standard HLS and 6-second segments, viewers were about 25 seconds behind the stadium, and push notifications from news apps spoiled the action before it appeared on screen.
The engineering team keeps 4-second segments but enables LL-HLS with parts of about 0.5 seconds. The packager and CDN are updated to support blocking playlist reloads, and the player uses a target latency of about three seconds. Ingest from the stadium arrives over SRT.
After the change, typical delay falls to about four seconds on good connections. Players on older devices still receive regular HLS. The prediction game becomes fair, and complaints about spoilers drop noticeably during the following season.