Standard HLS has 15-30 seconds of latency between the streamer’s action and the viewer seeing it. For a live sports match, that’s an eternity. Viewers checking social media see the goal before they see it on stream. Low-latency HLS and related approaches cut this to 2-5 seconds.

Where the Latency Comes From#

Standard HLS segments are 6-10 seconds long. The viewer’s player buffers 2-3 segments before playing. That’s 12-30 seconds of buffering before a single frame plays.

Reduce segment length to 0.2-2 seconds and you reduce buffering latency. But shorter segments mean more HTTP requests per second from every viewer. A million concurrent viewers each making a request every 2 seconds is 500,000 requests per second to the CDN. That’s manageable. Each making a request every 0.2 seconds is 5 million per second. Less manageable.

Low-Latency HLS#

Apple’s Low-Latency HLS (LL-HLS) addresses the polling problem with two mechanisms.

Partial segments: instead of waiting for a full segment to complete, the server can make partial segments available as they’re being generated. The player requests the next partial segment while the current one is still being produced.

Blocking playlist requests: instead of the player polling the manifest file every N seconds to check for new segments, it sends a blocking request saying “give me the manifest once segment X+1 is available.” The server holds the request until the segment is ready, then responds. This eliminates the polling delay without overwhelming the CDN with requests.

graph TD A[Standard HLS: 6s segments, poll every 6s, 18-30s latency] --> B[Problem: too slow for live events] C[LL-HLS: 0.2-2s partial segments] --> D[Blocking manifest requests: no poll delay] D --> E[2-5s latency achievable] E --> F[Trade-off: more complex player implementation] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#ff0000,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

The Latency-Rebuffer Trade-Off#

Shorter buffers mean lower latency and more rebuffering. A viewer with fluctuating network quality needs buffer headroom to absorb bandwidth dips. With 18 seconds of buffer, a 3-second bandwidth drop is invisible. With 3 seconds of buffer, it causes a rebuffer stall.

Low-latency delivery is only viable for viewers with stable, high-bandwidth connections. Platforms often serve standard-latency HLS to mobile viewers and low-latency to desktop viewers, detecting connection quality and choosing the appropriate manifest.

What Sub-Second Latency Actually Takes#

Below 1 second, standard CDN-based delivery doesn’t work. CDN edge nodes have their own propagation delays. Sub-second latency for truly live events (online auctions, live betting, real-time collaboration) requires WebRTC, which establishes direct peer connections and uses UDP. The trade-off is massive infrastructure complexity and no CDN caching between broadcaster and viewer.

At Oracle#

We had near-real-time dashboards for network KPIs. “Near-real-time” meant different things to different stakeholders. Operations wanted 30-second delay. Management dashboards tolerated 5-minute delay. The push for sub-minute KPI updates doubled our data pipeline infrastructure cost. Sometimes the right answer is to ask “what do you actually do with that information within 30 seconds?” and find that 5 minutes is fine.

What I’m Learning#

Live streaming latency is a product decision more than a technical one. 2-5 seconds satisfies nearly all live streaming use cases. Pushing below that requires a completely different architecture and trades scale for interactivity.

What latency requirements have you encountered that turned out to be less strict than first stated once you dug into the actual use case?