Low‑Latency HLS (LHLS) Solutions and Optimizations for Live Streaming

With the arrival of 5G, network speeds have increased and users demand lower latency for live streaming. In response, the Youku technology team proposed two Low‑Latency HLS (LHLS) solutions based on the mainstream HLS architecture and has applied them to Youku’s live‑streaming services.

The article first compares the current mainstream low‑latency live‑streaming protocols:

RTMP (Real‑Time Messaging Protocol) – advantages: designed for streaming, good Flash support, low latency (1‑3 s); disadvantages: uses TCP on non‑standard port 1935 (firewall issues), proprietary Adobe protocol.

HTTP‑FLV – advantages: uses port 80 (firewall‑friendly), supports 302 redirects and HTTPS; disadvantages: caches media locally (privacy concerns) and cannot switch bitrate smoothly.

HLS (HTTP Live Streaming) – advantages: widely supported, port 80 friendly, smooth bitrate switching, CDN‑friendly; disadvantages: higher latency (typically >10 s) and reducing GOP size may increase bitrate.

RTP (Real‑time Transport Protocol) – advantages: low latency (<1 s), UDP‑based high efficiency; disadvantages: mainly used for video conferencing, limited support for high‑bitrate live content.

Because HLS offers the best overall compatibility, Youku chose the LHLS approach.

The article then explains why latency occurs in HLS:

HLS consists of a master playlist (m3u8) and media segments (ts, CMAF, fMP4, etc.). Clients poll the playlist and download new segments, which introduces delay.

Playlist refresh timing (EXT‑X‑TARGETDURATION) determines how often new segments become available; each poll adds round‑trip time (RTT) latency.

CDN edge nodes cache previous playlist versions; TTL expiration can add extra delay.

Network conditions (packet loss, bandwidth) further increase latency.

Based on Apple’s LHLS draft, Youku proposes six protocol‑level optimizations to reduce end‑to‑end latency to below 2 seconds:

Reduce segment publishing latency – introduce EXT‑X‑PART and EXT‑X‑PART‑INF tags so that parts of a segment are published before the whole TS file is completed.

Optimize segment discovery – use blocking m3u8 loading ( EXT‑X‑SERVER‑CONTROL:CAN‑BLOCK‑RELOAD=YES ) and request specific parts with URLs such as GET https://example.com/live.m3u8?_HLS_msn=1803 or GET https://example.com/live.m3u8?_HLS_msn=1803&_HLS_part=0&_HLS_push=1 .

Eliminate segment request time – leverage HTTP/2 server push ( _HLS_push ) so that the server can push the part data together with the playlist request, removing an extra RTT.

Incremental m3u8 updates – use EXT‑X‑SERVER‑CONTROL:CAN‑SKIP‑UNTIL=36.0 and the _HLS_skip=YES parameter to send only the delta of the playlist, reducing bandwidth.

Accelerate bitrate switching – add EXT‑X‑RENDITION‑REPORT to the master playlist so the client knows the current segment numbers of other renditions and can switch without a new request.

Dynamic start‑up strategy based on network scoring – compute a network score from signal strength, bandwidth, packet loss, etc., and start playback from a later part (e.g., from the 3rd last part for a good network) to balance latency and buffering.

The article also describes a community‑driven LHLS scheme that uses HTTP/1.1 chunked transfer coding. By broadcasting upcoming segment URLs early and delivering segment data via chunked encoding, the scheme avoids playlist polling and CDN TTL delays.

Finally, a comparison of the standard Apple‑based LHLS and the community chunked‑transfer LHLS is presented:

Standard LHLS – follows Apple’s specification, supports flexible extensions, provides good overseas acceptance, but requires HTTP/2 support on CDN.

Community LHLS – relies on HTTP chunked encoding, easier to implement, but its overseas recognition is uncertain.

The Youku team plans to continue optimizing live‑streaming technology, aiming to improve user experience while driving industry‑wide innovation.