LL-HLS (low-latency HLS)
LL-HLS (low-latency HLS) is an extension of Apple's HTTP Live Streaming protocol that cuts live stream delay to around 2 to 5 seconds. It splits each segment into smaller parts that the player can download before the full segment is finished. The server can also hold a playlist request open until new content is ready, so the player does not waste time asking repeatedly.
Why it matters
Live delay shapes the whole viewer experience. A fan who hears neighbors cheer before the goal appears, or a buyer who misses a flash deal, may leave. LL-HLS cuts delay to about 2 to 5 seconds while keeping the CDN-based delivery that lets HLS reach very large audiences. A live sports or shopping app gets that lower delay on FastPix without assembling the pipeline itself, because every live stream is delivered as LL-HLS and recorded automatically for replay.
How it works
- The encoder splits each normal segment into much smaller partial segments, often a fraction of a second long.
- The server lists each partial segment in the playlist as soon as it is ready, before the full segment ends.
- The player asks for the next playlist update and the server holds that request until new content exists.
- Preload hints tell the player which partial segment comes next, so it can request it in advance.
- Older players that do not understand the new tags simply play the stream as regular HLS.
How low is LL-HLS latency?
LL-HLS usually delivers live video about 2 to 5 seconds behind real time, compared with roughly 10 to 30 seconds for standard HLS. The exact figure depends on partial segment length, encoder settings, CDN support and how far behind the live edge the player chooses to sit. It does not reach the under-one-second delay of WebRTC, which is built for two-way conversation.
LL-HLS vs WebRTC: which should I use?
Use LL-HLS for large audiences watching live events, and WebRTC for real-time conversation. LL-HLS works through standard CDNs, so it scales to big crowds at predictable cost with a few seconds of delay. WebRTC gets delay under one second, but it needs specialized media servers and gets harder to scale. Live sports and shopping usually choose LL-HLS, while video calls and live auctions choose WebRTC.
Does LL-HLS work on all devices?
LL-HLS works on Apple devices with recent operating systems and in other browsers through players like hls.js that support it. Because the format is backward compatible, older players simply ignore the low-latency tags and play the stream as regular HLS with normal delay. That means nobody is locked out, but viewers on older apps will sit further behind live.
Where it's used
Live sports streamers use LL-HLS so fans see key plays before social media spoils them, and live shopping apps use it so buyers can act on limited drops while the item is still on screen.
Where it usually goes wrong, and how FastPix handles it
Low-latency HLS needs encoders, packagers, origin servers and CDNs that all support partial segments and blocking playlist requests. Teams often get one piece wrong and quietly fall back to regular HLS delay.
Every FastPix live stream goes out as LL-HLS, with ingest over RTMPS or SRT. Each live stream is recorded automatically for on-demand playback, and Video Data reports live stream latency for every view. You can confirm viewers are really close to live, and offer the replay afterwards without a second workflow.
By the numbers
- Apple's documentation gives an example where regular media segments are 6 seconds long while each partial segment is only 200 milliseconds. (Enabling Low-Latency HTTP Live Streaming (HLS), Apple Developer)
- Apple added its first document describing Low-Latency HLS on June 3, 2019, according to the page's revision history. (Enabling Low-Latency HTTP Live Streaming (HLS), Apple Developer)
