Low-latency HLS in practice: setup, players and the delay you really get

HLS plays everywhere and caches beautifully, but classic HLS runs many seconds behind live. Low-latency HLS (LL-HLS) keeps everything good about HLS and cuts most of that wait. Here is how it works, and what it delivered when measured.

Why ordinary HLS is slow

HLS cuts video into segments, typically 2 to 6 seconds long, and lists them in a playlist. A segment can only be listed once it is finished, and players usually hold two or three segments in hand before starting. Add those up and 6 to 30 seconds of delay is normal.

What LL-HLS changes

• Parts. Each segment is published in small parts, around 200 ms, as soon as each is written. (A playlist says so with PART-TARGET.)
• Blocking reloads. The player asks for the next playlist version before it exists, and the server answers the moment it does (CAN-BLOCK-RELOAD=YES). No polling, no waiting for a timer.
• A small hold-back. The playlist tells the player how close to live it may play (PART-HOLD-BACK).

Measured delay

We stamped a clock into every frame, sent it the way a tuned OBS would, and read it back in a real browser, so each number is the whole delay from camera to screen:

Three traps we hit

1. Aiming too close to live

Letting the player sit right at the playlist's 0.5 s hold-back was faster on most runs, 0.8 to 1.1 seconds. But once it started slowly, settled 2.9 seconds behind and never caught up. Aiming 1 second behind, and jumping forward if it ever falls 3 seconds behind, gave steady results run after run.

2. Apple devices want https

Low-latency HLS is meant to be served over https for Apple devices to handle it properly. Serve the playlist and parts from the same https address as your site.

3. Not every player can do it

Some older built-in players cannot send the authorisation a private stream needs, or do not speak LL-HLS at all. Give them ordinary HLS as a fallback rather than a blank screen.

When to use which

What a low-latency playlist looks like

The low-latency playlist a creekX server served for a live stream (real output, the head and the newest lines):

#EXTM3U
#EXT-X-VERSION:10
#EXT-X-TARGETDURATION:2
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=0.52250,CAN-SKIP-UNTIL=12.00000
#EXT-X-PART-INF:PART-TARGET=0.20900
...
#EXTINF:1.25000,
0973fb73d039_video1_seg12.mp4
#EXT-X-PART:DURATION=0.20900,URI="0973fb73d039_video1_part42.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.20800,URI="0973fb73d039_video1_part43.mp4"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="0973fb73d039_video1_part44.mp4"

PART-TARGET is the part length, CAN-BLOCK-RELOAD lets the player wait on the server, PART-HOLD-BACK is how close to live it may play, and PRELOAD-HINT names the next part before it exists.