Where ordinary live delay comes from
A live encoder must produce media, the packager closes segments, the playlist is published, the client reloads it and the player builds a safety buffer. Several segment durations can accumulate between the camera and the screen even when every request is fast.
Partial segments expose media sooner
LL-HLS divides a regular segment into smaller parts that become available before the full segment is complete. A capable client can begin requesting those parts and keep closer to the live edge.
Playlist delivery becomes more interactive
- Blocking reload lets a request wait until specified new media is available
- Delta updates avoid repeatedly transferring the unchanged playlist history
- Preload hints tell the client where the next partial segment is expected
- Rendition reports help the client switch variants near a consistent live position
Low latency requires an end-to-end implementation
Adding a low-latency tag to a static manifest is not enough. Encoder cadence, packaging, atomic playlist updates, origin behaviour, cache configuration and player support must cooperate. A CDN that waits for complete objects or caches a stale playlist can erase the latency benefit.
Less buffer means less room for network variation
Playback close to the live edge has a smaller safety margin. Packet loss, request delay, overloaded origins and inaccurate publication timing become more visible. The right target balances interactivity against rebuffering rather than chasing the smallest possible number.