Low-Latency Streaming Explained: LL-HLS, LL-DASH and WebRTC

You are watching a football match online when the neighbours cheer through the wall. Ten seconds later, the goal appears on your screen. That gap is latency, the delay between something happening in front of the camera and viewers seeing it. For films it does not matter. For sports, betting, auctions, live shopping, gaming and any show where the audience talks back, it matters a lot.

This guide explains where streaming latency comes from, and how the three main low-latency approaches, LL-HLS, LL-DASH and WebRTC, reduce it.

Where the delay comes from

End-to-end latency, sometimes called “glass-to-glass”, is the sum of many small delays:

1. Capture and encoding: the camera and encoder need time to capture frames and compress them. Typically 100 ms to 1 second.
2. Ingest: sending the stream to the platform over RTMP, SRT or WebRTC. Tens to hundreds of milliseconds.
3. Transcoding: creating the adaptive bitrate ladder. Usually under a second, more with complex processing.
4. Packaging: cutting the stream into segments. With classic HLS, a segment cannot be published until it is complete, so 6-second segments add up to 6 seconds.
5. CDN delivery: usually small, but playlist and manifest caching can add seconds.
6. Player buffer: the biggest factor. Players traditionally keep several segments buffered before starting, to ride out network hiccups. Three 6-second segments means 18 seconds.

Add it up and classic HLS or DASH typically lands between 15 and 45 seconds.

The latency scale

Step one: tune what you already have

Before adopting new protocols, you can often cut classic HLS latency in half:

• Shorten segments to 2 seconds, with a 2-second keyframe interval.
• Configure the player to start closer to the live edge (for example liveSyncDurationCount in hls.js).
• Reduce playlist caching at the CDN to around one second for live playlists.
• Keep transcoding simple.

That typically gets you to 6 to 10 seconds with no new infrastructure. For many events, that is enough.

LL-HLS: Low-Latency HLS

Apple introduced Low-Latency HLS in 2019, and it is now part of the HLS specification. It keeps everything that makes HLS scale on ordinary CDNs, while cutting latency to roughly 2 to 5 seconds.

Key techniques:

• Partial segments. Each normal segment (say 4 seconds) is split into small parts, often 200 ms to 1 second. The playlist lists parts with #EXT-X-PART as soon as they exist, so players do not wait for complete segments.
• Preload hints. #EXT-X-PRELOAD-HINT tells the player which part will come next, so it can request it before it is ready. The server holds the request open until the part is available.
• Blocking playlist reload. The player asks for “the playlist once it contains part N”, and the server responds as soon as it does, instead of the player polling repeatedly.
• Delta updates. For long live streams, the server can send only the changed end of the playlist, keeping requests small.
• Rendition reports. Let the player switch quality without an extra round trip.

LL-HLS plays natively on Apple devices and in JavaScript players like hls.js, Shaka Player, Video.js with suitable versions, and commercial players. It needs a packager and CDN that support its blocking requests and short cache times. Most major CDNs do.

You can see LL-HLS parts by pasting a live playlist into our M3U8 analyzer. It flags #EXT-X-PART tags.

LL-DASH: Low-Latency DASH with chunked CMAF

LL-DASH achieves similar latency with a different approach:

• The encoder outputs CMAF segments made of small chunks (for example 500 ms each).
• The packager publishes each segment as it is being created, and the CDN delivers it using HTTP chunked transfer encoding, sending each chunk as soon as it is ready.
• The player requests the segment at the moment it starts and receives chunks progressively, so it can start decoding the beginning while the end is still being encoded.
• Players estimate bandwidth differently here, because chunks arrive at the speed they are produced, not the speed of the network. dash.js includes algorithms designed for this.

LL-DASH is popular for Android, smart TVs and browser players, and is used alongside LL-HLS by services that already publish both formats. Test streams in our DASH player.

WebRTC: real-time video

WebRTC is the technology behind browser video calls. It was built for conversation, where more than about 300 ms of delay feels awkward. Used for broadcasting, it delivers video in well under a second.

How it differs:

• It runs over UDP, not HTTP, using RTP/SRTP. Lost packets can be skipped rather than waited for.
• It keeps a very small jitter buffer.
• Connections are set up peer-to-peer or through media servers (SFUs), using signalling and ICE/STUN/TURN for NAT traversal.

For broadcasting to many viewers, you need an SFU-based media server or a WebRTC streaming service that fans the stream out through a network of servers. WHIP (WebRTC-HTTP Ingestion Protocol) and WHEP (WebRTC-HTTP Egress Protocol) have standardised how encoders publish and players watch, and OBS supports WHIP output in recent versions.

Strengths: sub-second latency, true interactivity, broad browser support.

Weaknesses: harder and more expensive to scale than HTTP streaming, because standard CDN caching does not apply; adaptive quality works differently (simulcast or SVC); more complex infrastructure; less mature DRM support.

Comparing the options

Choosing the right approach

Webinars, church services, conferences, classes: tuned HLS at 6 to 10 seconds is usually fine. Chat still feels responsive enough.

Sports and news for large audiences: LL-HLS (and LL-DASH where you already serve DASH) at 2 to 5 seconds. Close enough to broadcast TV that spoilers from social media or neighbours are less of a problem.

Live commerce, auctions, betting and quizzes: WebRTC, because bids and answers need to line up with what viewers see. Some services offer a WebRTC tier for interactive users and LL-HLS for the passive majority.

Two-way interaction with guests: WebRTC for the guests and host, then output to HLS for the wider audience.

Trade-offs to understand

Lower latency always costs something:

• Less buffer means less protection. Viewers on unstable connections may see more stalls or lower quality.
• More requests. Short parts and blocking reloads increase request counts to your CDN and origin.
• Tighter encoding. Short keyframe intervals slightly reduce compression efficiency.
• Synchronisation. When viewers are at different delays, chat and live polls feel out of sync. Low-latency players can adjust playback speed slightly to keep everyone near the same point.

Measuring latency

The simplest method: point your camera at a clock with milliseconds (or burn a timecode into the stream), then watch the stream next to the clock and compare. For ongoing monitoring, use the #EXT-X-PROGRAM-DATE-TIME tag in HLS or the manifest timing in DASH, which let players report how far behind real time they are.

Player settings that control latency

Even with the right protocol, the player decides how close to live it sits.

• hls.js: lowLatencyMode enables LL-HLS features. liveSyncDurationCount or liveSyncDuration sets how far behind the live edge playback starts, and maxLiveSyncPlaybackRate lets the player speed up slightly to catch up.
• dash.js: the liveDelay setting and its low-latency catch-up mechanism control target latency and playback-rate adjustments.
• Shaka Player: liveSync settings allow a target latency with automatic catch-up.
• AVPlayer (iOS): uses Apple’s LL-HLS support automatically when the stream is LL-HLS, with automaticallyPreservesTimeOffsetFromLive and related properties for fine control.

A target of three times the part or chunk duration, plus a small safety margin, is a common starting point. Test on real mobile connections before lowering it further.

A practical path from 30 seconds to 5

Most teams do not jump straight to LL-HLS. A staged approach is safer and shows you where the delay really lives.

Step 1: measure. Burn a clock into the stream or film a stopwatch and record glass-to-glass delay on three devices. Write the numbers down.

Step 2: shorten segments. Move from 6-second to 2-second segments with a 2-second keyframe interval. Check your encoding settings so every rendition still has aligned keyframes. Expect roughly 8 to 12 seconds.

Step 3: tune the player. Reduce how many segments the player waits for before starting. In hls.js that is the live sync setting. Expect a few more seconds off.

Step 4: check the CDN. Make sure live playlists are cached for about a second, not a minute. A long playlist cache quietly adds delay no matter what else you do. Our guide to video CDNs covers the cache rules.

Step 5: switch to LL-HLS or LL-DASH only if you still need to go lower. By now you know your baseline, and you will be able to tell whether the extra complexity paid off.

Throughout, keep an eye on rebuffering. Lower latency is worthless if viewers see more spinners. The bandwidth calculator helps you check that shorter segments do not push request volumes or costs beyond what you planned.

Summary

Classic HTTP streaming is 15 to 45 seconds behind live because of segment lengths and player buffers. Shorter segments and tuned players get you to 6 to 10 seconds. LL-HLS and LL-DASH use partial segments and chunked CMAF to reach 2 to 5 seconds while still scaling on standard CDNs. WebRTC delivers sub-second latency for real interaction, at higher cost and complexity. Choose the lowest latency your use case actually needs, not the lowest that is possible. For the ingest side of the chain, see RTMP vs SRT vs WebRTC.