Skip to main content
Advanced Streaming

An introduction to Low-Latency HLS (LL-HLS)

Traditional HLS is notorious for introducing 20 to 30 seconds of latency during live broadcasts, creating spoilers for sports fans watching on social media alongside the stream. Apple introduced Low-Latency HLS (LL-HLS) to shrink this delay to 2 seconds or less, putting it on par with traditional broadcast television while maintaining the massive scalability of HTTP caching.

Updated September 8, 2026 Maintained by M3U8 Free Player Online 9 minute read

Delivering video over HTTP natively introduces latency because a player must wait for a segment to finish encoding, download it, and buffer a few segments before beginning playback. If you are using 6-second segments and buffering three of them, you are immediately 18 seconds behind live. LL-HLS solves this by fundamentally changing how playlists and segments are delivered without abandoning the underlying HTTP infrastructure.

Core Mechanisms of LL-HLS

LL-HLS achieves sub-2-second latency through a combination of several spec additions. The most critical features are Partial Segments, Blocking Playlist Reloads, Preload Hints, and Delta Playlists.

1. Partial Segments (CMAF Chunks)

Instead of waiting for an entire 6-second segment to encode, LL-HLS breaks the segment down into smaller "Partial Segments"—typically around 200 to 500 milliseconds in length using CMAF (Common Media Application Format) chunking. The player can download and play these partial segments while the rest of the 6-second segment is still being generated by the encoder.

#EXT-X-PART:DURATION=0.200,URI="part_1.m4s"
#EXT-X-PART:DURATION=0.200,URI="part_2.m4s"
#EXT-X-PART:DURATION=0.200,URI="part_3.m4s"

Once enough partial segments are generated to form a full segment, they are replaced in the playlist by the standard #EXTINF tag pointing to the consolidated segment, keeping the playlist tidy and performant for edge caching.

2. Blocking Playlist Reloads

In standard HLS, a player polls the media playlist every few seconds to see if new segments are available. If it polls too soon, it gets the same playlist. If it polls too late, latency increases. LL-HLS fixes this by allowing the player to request the playlist in advance.

The player appends a query parameter to its HTTP request, such as ?_HLS_msn=120&_HLS_part=1. The server holds the request open (HTTP Long Polling) and only sends the playlist response once Media Sequence Number 120, Part 1, is actually ready. This completely eliminates polling jitter.

3. Preload Hints

To squeeze out even more milliseconds, the server can tell the player exactly what the URL of the next upcoming partial segment will be before it's even encoded. This is done using the #EXT-X-PRELOAD-HINT tag.

#EXT-X-PRELOAD-HINT

Allows the player to proactively open an HTTP connection and issue a GET request for the next chunk. As soon as the encoder writes the first bytes of the chunk, the server streams it back to the client.

#EXT-X-PRELOAD-HINT:TYPE=PART,URI="part_4.m4s"

4. Delta Playlists (Playlist Updates)

As live streams progress, media playlists grow larger. Downloading a massive playlist every 500 milliseconds wastes bandwidth. LL-HLS introduces Delta Playlists (#EXT-X-SKIP). The player can request only the changes that occurred since its last request by appending ?_HLS_skip=YES. The server replies with a truncated playlist containing only the newest segments, saving significant overhead.

Rendition Reports

Adaptive bitrate (ABR) streaming requires the player to know the synchronization state of other quality levels so it can switch resolutions seamlessly. In standard HLS, the player might have to fetch the 720p playlist just to see if it's safe to switch to it from 1080p, wasting time.

LL-HLS adds #EXT-X-RENDITION-REPORT tags to the bottom of the active playlist. These tags report the latest segment and part numbers for all alternative bitrates. The player can switch bitrates instantly without guessing.

#EXT-X-RENDITION-REPORT:URI="720p.m3u8",LAST-MSN=120,LAST-PART=3

Infrastructure and Server Configuration

Implementing LL-HLS is not simply a matter of updating an encoder. Your entire delivery chain must support modern HTTP features.

  • HTTP/2 or HTTP/3: Standard HTTP/1.1 cannot multiplex requests efficiently enough to handle downloading dozens of partial segments per second alongside blocking playlist requests. HTTP/2 or higher is mandatory to prevent head-of-line blocking.
  • Edge Support for Long Polling: Your CDN must be configured to support blocking playlist reloads (long polling) without timing out or collapsing connections aggressively.
  • Chunked Transfer Encoding: Origin servers and CDNs must support Chunked Transfer Encoding to stream partial segments down the wire as they are being encoded.
Early drafts of the LL-HLS specification required HTTP/2 Server Push, which caused immense friction for CDN vendors. Apple wisely deprecated the Server Push requirement in 2020 in favor of Preload Hints, making widespread adoption much easier.

Is LL-HLS right for you?

LL-HLS provides broadcast-equivalent latency (1-3 seconds) and scales gracefully using HTTP CDNs, making it superior to older, non-scalable protocols like RTMP. However, it requires tightly coupled encoders, specialized player configurations, and fine-tuned CDNs. If your usecase (like sports betting, auctions, or interactive live streaming) demands low latency and massive scale, LL-HLS is the definitive standard going forward.