{"id":6406,"date":"2026-05-20T10:28:00","date_gmt":"2026-05-20T10:28:00","guid":{"rendered":"https:\/\/www.5centscdn.net\/blog\/?p=6406"},"modified":"2026-05-20T10:28:06","modified_gmt":"2026-05-20T10:28:06","slug":"low-latency-streaming","status":"publish","type":"post","link":"https:\/\/www.5centscdn.net\/blog\/low-latency-streaming\/","title":{"rendered":"What Is Low Latency Streaming? LL-HLS, WebRTC & CMAF"},"content":{"rendered":"
<\/div>\n

When millions of viewers watched the 2022 World Cup final through streaming platforms, some experienced the winning goal 30 seconds after others saw it on broadcast TV. That gap \u2014 invisible to most viewers until they are spoiled by a notification \u2014 is the latency problem that the streaming industry has spent years trying to solve.<\/p>\n\n\n\n

Low latency streaming is no longer a niche technical concern. With FIFA World Cup 2026 approaching, live sports betting, real-time auctions, interactive commerce, and social live streaming all creating audiences that demand near-real-time delivery, the question of which protocol to use \u2014 and how to architect your live streaming infrastructure<\/a> around it \u2014 has direct business consequences.<\/p>\n\n\n\n

This guide explains what latency is in a streaming context, how it is measured, what causes it, and how the three main low latency protocols \u2014 LL-HLS, WebRTC, and CMAF \u2014 compare across latency, scale, CDN compatibility, and use case fit.<\/p>\n\n\n\n

What Is Latency in Live Streaming?<\/strong><\/h2>\n\n\n\n

In streaming, latency<\/a> refers to the delay between an event happening at the camera and that event appearing on a viewer’s screen. This is commonly called glass-to-glass latency \u2014 the time from the camera lens to the viewer’s display.<\/p>\n\n\n\n

Latency is measured in seconds or milliseconds and falls into four broadly understood tiers:<\/p>\n\n\n\n

Latency Tier<\/strong><\/td>Range<\/strong><\/td>Typical Technology<\/strong><\/td>Suitable For<\/strong><\/td><\/tr>
Real-time<\/td>< 500ms<\/td>WebRTC<\/td>Video calls, interactive gaming, live auctions<\/td><\/tr>
Low Latency<\/td>1\u20133 seconds<\/td>LL-HLS, LL-DASH<\/td>Live sports, live commerce, social streaming<\/td><\/tr>
Reduced Latency<\/td>3\u20135 seconds<\/td>CMAF<\/td>Broadcast OTT, premium live events<\/td><\/tr>
Standard<\/td>6\u201330 seconds<\/td>Traditional HLS\/DASH<\/td>VOD, replay, SVOD premieres<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The right latency tier depends entirely on your use case. Not every platform needs sub-second delivery \u2014 and as we will cover, chasing sub-second latency when your use case only requires 3 seconds creates unnecessary architectural complexity and cost.<\/p>\n\n\n\n

What Causes Latency in a Live Streaming Pipeline?<\/strong><\/h2>\n\n\n\n

Latency does not come from a single source \u2014 it accumulates across every stage of the streaming pipeline. Understanding where it builds up is the only way to reduce it meaningfully.<\/p>\n\n\n\n

\"Live
The Latency Stack \u2014 Where Delay Is Added in Live Streaming<\/strong><\/strong><\/figcaption><\/figure>\n\n\n\n

1. Encode Latency<\/strong><\/h3>\n\n\n\n

The encoder converts raw video from a camera into a compressed digital stream. Modern encoders using H.264 or H.265 introduce 50\u2013500ms of latency depending on configuration. Encoders optimized for low latency use faster preset settings at the expense of some compression efficiency.<\/p>\n\n\n\n

2. Packaging \/ Segmentation Latency<\/strong><\/h3>\n\n\n\n

The packager divides the encoded stream into segments that the CDN and player can request. Traditional HLS uses segments of 6\u201310 seconds \u2014 meaning the packager must wait for a full segment to complete before sending it. This is the single largest contributor to latency in standard HLS setups. LL-HLS and CMAF address this by introducing partial segments of 200\u2013400ms that are transmitted as they are produced.<\/p>\n\n\n\n

3. CDN Propagation Latency<\/strong><\/h3>\n\n\n\n

Content must travel from your origin server to a CDN edge node close to the viewer. This is largely determined by network distance and the CDN’s PoP coverage. A well-configured CDN with an origin shield layer minimizes this to tens of milliseconds for most regions.<\/p>\n\n\n\n

4. Player Buffer<\/strong><\/h3>\n\n\n\n

The video player maintains a buffer \u2014 a small reserve of pre-downloaded segments \u2014 to protect against brief network interruptions. A larger buffer means more stable playback but higher latency. Most players default to 3\u201310 seconds of buffer. For low latency streaming, players like HLS.js and Shaka Player must be explicitly configured to reduce buffer targets, or the latency gains from the protocol are lost at the final step.<\/p>\n\n\n\n

Key point: <\/strong>Glass-to-glass latency is the sum of all four stages. Optimizing only the protocol without tuning the encoder, packager, and player buffer often produces no real-world improvement.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

What Is LL-HLS?<\/strong><\/h2>\n\n\n\n

Low-Latency HLS (LL-HLS) is an extension of Apple’s HTTP Live Streaming<\/a> protocol, standardized in 2019. It reduces the latency of standard HLS from 6\u201330 seconds down to 1\u20133 seconds by addressing the primary cause of HLS latency: large segment sizes.<\/p>\n\n\n\n

Standard HLS requires the packager to finish an entire segment (typically 6 seconds) before delivering it to the CDN and player. LL-HLS introduces two mechanisms that break this constraint:<\/p>\n\n\n\n