LL-HLS (Low-Latency HLS)

Standard HLS has a latency floor of about 20-30 seconds because the player needs to buffer several complete segments before starting playback, and each segment takes time to encode, upload, and propagate through the CDN. LL-HLS (introduced by Apple in 2019) brings this down to 2-4 seconds using three key techniques: partial segments, preload hints, and blocking playlist reloads.

Partial segments (EXT-X-PART) are sub-second chunks of a segment that get published to the CDN before the full parent segment is complete. A 6-second segment might be split into twelve 0.5-second parts. The player can start downloading and rendering these parts immediately, without waiting for the full segment. Once the complete segment is available, the parts are no longer needed and the playlist references the full segment instead.

Preload hints (EXT-X-PRELOAD-HINT) tell the player the URL of the next partial segment before it even exists. The player opens an HTTP request to that URL, and the server holds the connection open until the data is ready. This eliminates the round-trip delay of polling for updates. Blocking playlist reload works similarly: the player requests the playlist with a query parameter indicating it already has content up to a certain point, and the server holds the response until new content is available (like long polling).

LL-HLS requires HTTP/2 because the player needs to maintain multiple concurrent connections efficiently: one for the playlist, one or more for partial segments, and one for the preload hint. Without HTTP/2 multiplexing, the connection overhead would eat into the latency gains.

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.5
#EXT-X-PART-INF:PART-TARGET=0.5

#EXTINF:6.0,
segment100.m4s
#EXT-X-PART:DURATION=0.5,URI="segment101.0.m4s"
#EXT-X-PART:DURATION=0.5,URI="segment101.1.m4s"
#EXT-X-PART:DURATION=0.5,URI="segment101.2.m4s"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="segment101.3.m4s"