You've built the stream. The encoder is running, the CDN is configured, and viewers are watching — but the latency is 25 seconds. The sports betting platform you're integrating with needs under two seconds. Your client's live auction app is falling apart because bidders are reacting to prices that have already changed. Sound familiar?
Latency is the invisible tax on live streaming, and reducing it isn't just a matter of flipping a switch. It requires understanding where the latency actually comes from, which protocol architecture eliminates it most effectively, and what trade-offs you're accepting when you chase the lowest possible number. The choices you make at the protocol layer — LL-HLS, WebRTC, or CMAF — will define what's achievable at the infrastructure level, long before you start tuning buffers or tweaking CDN configuration.
This post is a developer's guide to making that decision well. We'll break down how each protocol actually works, where the latency budget gets spent, and how to implement low-latency live streaming in production using Mux's API.
Where Latency Actually Comes From
Before comparing protocols, it's worth being precise about what "latency" means in this context. Glass-to-glass latency is the time elapsed between a pixel being captured by a camera and that same pixel being rendered on a viewer's screen. This is the number your users experience. It's different from ingest latency (the delay between your encoder and the origin server), and developers often conflate the two.
The glass-to-glass pipeline looks like this:
- Encoder — captures and compresses frames
- Ingest — transmits the encoded stream to your streaming platform (via RTMP, SRT, or WHIP)
- Transcoding — re-encodes into multiple bitrate renditions
- Segmentation — packages the stream into chunks for delivery
- CDN propagation — distributes segments to edge nodes
- Player buffer — accumulates enough data before playback begins
Traditional HLS was designed for reliability, not speed. It uses 6–10 second segments, and the player buffers three segments before it starts playing — meaning you're looking at 20–45 seconds of glass-to-glass latency before you've even accounted for transcoding time or CDN propagation. Mux's own deep dive on the evolution of low-latency streaming documents how the industry spent years trying to solve this problem with workarounds before proper spec-level solutions arrived.
Each of the three protocols we're covering attacks this latency budget differently. Understanding where they make savings — and what they sacrifice to do it — is the foundation of the whole decision.
LL-HLS: The Right Default for Most Developers
Low-Latency HLS is Apple's formal extension to the HLS spec, designed to bring latency down to the 2–4 second range while preserving full backward compatibility with the HLS ecosystem. It's the right default choice for the vast majority of developer use cases.
How LL-HLS Works
LL-HLS makes three key changes to standard HLS:
Partial segments break the media timeline into smaller "parts" — typically 200–300ms each — that are appended to the playlist before the full segment is complete. A player doesn't need to wait for a 6-second segment to finish; it can start downloading and rendering the first 200ms part as soon as it's available.
Blocking playlist reloads replace the traditional poll-and-wait pattern. Instead of a player repeatedly requesting the manifest and getting a 304 Not Modified response, it issues a request for the next playlist update and the server holds the connection open until new content is available. This eliminates the polling overhead that added hundreds of milliseconds to every segment delivery cycle.
Rendition reports let the player preemptively request the next segment before the current one finishes, removing the gap between segments entirely.
Together, these changes reduce the delivery pipeline from tens of seconds to 2–4 seconds at scale. The trade-off is that LL-HLS requires CDN support for chunked transfer encoding or HTTP/2 server push — not every CDN configuration supports this out of the box.
When to Choose LL-HLS
LL-HLS is the right call when:
- You need 2–5 seconds of latency and are serving more than a few hundred concurrent viewers
- You need iOS native playback — Safari and AVPlayer support LL-HLS natively with no JavaScript player required
- You're operating within the existing HLS ecosystem and want broad device compatibility
- You want managed infrastructure without operating your own signaling or media servers
For most live shopping apps, live news, sports (where betting integration isn't required), and large-scale events, LL-HLS delivers more than enough speed with dramatically simpler infrastructure than the alternatives.
Using Mux to Implement LL-HLS
Mux's live streaming API exposes low-latency mode as a single field. Here's how to create a low-latency live stream:
import Mux from '@mux/mux-node';
const mux = new Mux();
const liveStream = await mux.video.liveStreams.create({
playback_policy: ['public'],
new_asset_settings: {
playback_policy: ['public'],
},
latency_mode: 'low',
});
console.log('Stream Key:', liveStream.stream_key);
console.log('Playback ID:', liveStream.playback_ids[0].id);You can also target reduced or standard latency modes by setting latency_mode to "reduced" or "standard". The "low" mode enables full LL-HLS delivery, targeting 2–4 seconds of glass-to-glass latency under good network conditions.
Encoder configuration matters as much as the API setting. For LL-HLS to reach its latency floor, your encoder needs to emit keyframes at a 2-second interval (a 2-second GOP). With OBS, set your keyframe interval to 2 seconds in the Output settings. With FFmpeg:
ffmpeg -i [input] \
-c:v libx264 \
-g 60 \ # GOP size = framerate × keyframe_interval (30fps × 2s)
-keyint_min 60 \
-sc_threshold 0 \ # Disable scene-change keyframes
-c:a aac \
-f flv rtmp://global-live.mux.com/app/YOUR_STREAM_KEYSetting -sc_threshold 0 is important — without it, FFmpeg inserts extra keyframes on scene changes, which fragments your GOP structure and disrupts the segment alignment that LL-HLS depends on.
Verifying It's Working
Mux Player handles LL-HLS automatically. To confirm your stream is being delivered at low latency, check the stream_latency metric in Mux Data. In the browser, you can also open DevTools and inspect the playlist requests — you should see _HLS_msn and _HLS_part query parameters on manifest requests, which are the blocking reload requests that confirm LL-HLS is active.
You can read more about using Mux Data to measure live stream latency in their post on measuring live stream latency with Mux Data.
WebRTC: Sub-Second Latency at a Real Cost
WebRTC achieves sub-second, often 100–500ms latency, by abandoning the HTTP segmentation model entirely. Instead of packaging media into files and serving them over HTTP, WebRTC negotiates direct peer-to-peer media sessions using SRTP (Secure Real-time Transport Protocol), a UDP-based protocol designed for real-time communication with minimal buffering.
The Mux post WebRTC: From the ground up covers the protocol architecture in depth. For the purposes of the protocol-selection decision, the key architectural differences are:
- WebRTC requires a signaling server to negotiate session parameters between peers
- It requires TURN/STUN infrastructure to traverse NATs and firewalls
- It sends media via UDP rather than TCP, meaning it prioritizes speed over guaranteed delivery
- There is no CDN in the traditional sense — media is relayed through media servers that handle the fan-out
The Scale Problem Nobody Warns You About
Sub-second latency sounds like a universal win until you try to fan out a WebRTC stream to 10,000 concurrent viewers. WebRTC's peer-to-peer model doesn't scale horizontally the way a CDN-backed HLS stream does. To reach large audiences, you need Selective Forwarding Units (SFUs) or MCUs, which receive one stream and retransmit it to each viewer — effectively rebuilding a CDN layer on top of WebRTC with the full operational complexity that comes with it.
CDN-based WebRTC delivery exists (some providers offer it), but it adds significant cost per viewer-hour compared to HLS-based delivery and introduces its own failure modes. The infrastructure complexity of WebRTC at scale is genuinely high: you're operating media servers, signaling infrastructure, and TURN relays, with per-viewer CPU costs that don't exist in HLS delivery. Mux does not offer WebRTC streaming — it's a deliberate product decision. LL-HLS delivers low enough latency for the vast majority of live use cases without the operational burden WebRTC imposes.
When WebRTC Is the Right Call
Use WebRTC when:
- Sub-second latency is a hard requirement — live auctions where bidders react to hammer prices, real-time gaming, or audience interaction where 2 seconds of delay makes the product feel broken
- Concurrent viewer counts are manageable — under a few hundred simultaneous viewers, the infrastructure cost is reasonable
- You need bidirectional communication — WebRTC is the only protocol here that supports sending media back from the viewer, which is what makes it suitable for interactive live video like trivia games or live Q&A
The most common mistake developers make is choosing WebRTC because it's technically the lowest-latency option, then discovering the fan-out problem when their audience grows. If your acceptable latency is 2–4 seconds and your audience is measured in thousands, LL-HLS will serve you better and cost less to operate.
CMAF: The Cross-Protocol Compatibility Layer
CMAF (Common Media Application Format) is a container format that allows the same media segments to be served over both HLS and DASH playlists simultaneously. It was developed jointly by Apple and Microsoft with MPEG standardization, and its primary value is interoperability — one set of encoded segments, two manifests, compatible with both Apple ecosystem HLS players and Android/browser DASH players.
Low-latency CMAF delivers chunked transfer encoding at the segment level: instead of waiting for a complete segment, the server begins sending a CMAF "chunk" (typically 1–2 seconds) as it's being written, so the player can begin decoding it before the full segment is available.
Realistic Latency and Trade-Offs
CMAF achieves roughly 3–6 seconds of glass-to-glass latency — slightly higher than LL-HLS and significantly higher than WebRTC. The reason is that CMAF's low-latency delivery mechanism relies on chunked transfer, which has more overhead than LL-HLS's partial segment model.
Where CMAF wins is cross-platform delivery without maintaining separate encoding pipelines. If you need to support a DASH-based player (common in some Smart TV ecosystems, Android TV apps, or enterprise video deployments) alongside HLS, CMAF means you're encoding once and packaging twice rather than running two completely separate pipelines.
The practical guidance: if you're building primarily for web and iOS with an HLS player, LL-HLS is simpler and faster. If you have a genuine requirement to support DASH-based players at low latency without duplicating your encoding infrastructure, CMAF is the architecture to reach for.
Choosing the Right Protocol: A Decision Framework
Rather than a table (which would oversimplify the nuances), here's how to think through the decision in order:
Step 1: What is your target latency?
If the answer is under 1 second, you're in WebRTC territory — nothing else gets there reliably at scale. If 2–5 seconds is acceptable, LL-HLS is almost certainly the right answer.
Step 2: What is your expected concurrent viewer count?
Above a few hundred simultaneous viewers, WebRTC's infrastructure cost and complexity become significant. LL-HLS scales horizontally via CDN with no additional media server infrastructure. If you need sub-second latency and large concurrent audiences, budget for CDN-based WebRTC delivery or SFU infrastructure — it's the right tool, but it's not cheap.
Step 3: Do you need iOS native playback or DASH compatibility?
LL-HLS is natively supported in Safari and AVPlayer on iOS without a JavaScript player. If DASH player support is a hard requirement alongside HLS, CMAF gives you a single encoding pipeline that satisfies both.
Step 4: Is the interaction bidirectional?
Live Q&A, auctions, gaming, or any use case where the viewer sends media back to the stream requires WebRTC. No other protocol supports that.
For most developers building video platforms — live commerce, sports, events, news — the answer is LL-HLS via Mux with a 2-second GOP and the latency_mode: "low" API setting. You'll get 2–4 seconds of glass-to-glass latency, full iOS support, CDN-scale delivery, and a much simpler operational footprint than WebRTC.
Monitoring Latency in Production
Theoretical latency and real-user latency diverge in production. A viewer on a congested mobile network will experience higher latency than your test setup over fiber, and players will often increase their buffer size adaptively when the network is unstable — which pushes latency higher.
The most important metrics to track are:
- stream_latency — the glass-to-glass latency Mux measures for your stream; your primary SLO metric
- video_startup_time — if this climbs, it's often a sign that players are accumulating larger buffers to compensate for network instability
- rebuffer_ratio — the red flag metric for over-aggressive latency targets; if you've tuned latency down and rebuffering is climbing, you've found the floor for your audience
Mux Data lets you segment these metrics by geography, CDN PoP, and device type, which is where the actionable signal lives. A high stream_latency in a specific region often points to a CDN edge node that doesn't support chunked transfer, or a geographic path with high propagation delay. You can read more in Mux's guide to reducing live stream latency.
The latency-versus-stability trade-off is real: lower target latency means less buffer margin, which means any network hiccup is more likely to cause a rebuffer. The right balance depends on your audience — a professional sports betting integration justifies accepting more rebuffering to hit a 2-second target; a large-scale awards show broadcast probably wants 4–5 seconds with a stable experience for hundreds of thousands of viewers.
Conclusion
Low-latency live streaming is an architecture decision, not a configuration knob. The protocol you choose — LL-HLS, WebRTC, or CMAF — determines your latency floor, your infrastructure footprint, your scaling ceiling, and your operational complexity. No single protocol wins on every dimension.
The practical summary: LL-HLS is the right default for developer teams building live streaming into their products at scale, delivering 2–4 seconds of latency with CDN-grade scalability and native iOS support. WebRTC is the right choice when sub-second latency is a hard requirement and you understand the fan-out infrastructure cost you're accepting. CMAF is the right choice when cross-protocol HLS and DASH delivery from a single encoding pipeline is a genuine requirement.
The biggest latency wins always come from architectural choices made early — protocol selection, encoder GOP configuration, CDN chunked transfer support — not from micro-optimizations made later. Get the architecture right first.
Ready to implement? Start with the Mux live streaming docs, review the latency_mode API reference, and explore Mux's interactive live streaming page for architecture patterns. Note that Mux focuses on LL-HLS and does not offer WebRTC streaming — if your use case requires sub-second latency, you'll need a dedicated WebRTC provider alongside Mux for the rest of your video infrastructure. For a broader conceptual grounding on where these protocols came from, the low-latency video streaming guide covers the history and terminology in depth.