![\"Article](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/335801-GCore-new-top-image-Spotlight-ORG.png\")
<\/div>\nAbove: 2.0s latency from OBS RTMP to LL-DASH<\/em><\/p>\n Live streaming is evolving, and audiences now expect near-instant playback. We\u2019re excited to introduce our low-latency live streaming solution, leveraging LL-HLS and LL-DASH to achieve a glass-to-glass delay of just 2.0\u20133.0 seconds<\/strong>. Optimized for seamless delivery across industry-standard players such as hls.js<\/strong>, dash.js<\/strong>, and native Safari<\/strong> support, our CDN ensures a superior streaming experience:<\/p>\n LL-HLS and LL-DASH at sub-3-second latency<\/strong><\/p>\n Supporting LL-HLS and LL-DASH at sub-3-second latency required overcoming several key challenges:<\/p>\n Here is an example of how delivery differs in terms of average request rate and average request time on the same number of viewers when switching from regular HLS to LL-HLS:<\/p>\n Above: Increased response_time\u00a0 and request_rate for 1 viewer when switching from regular HLS to LL-HLS<\/em><\/p>\n Typical low-latency implementation involves two principles:<\/p>\n These traditional principles don\u2019t scale well over CDN and can\u2019t meet low-latency demands. New approaches were needed to reduce delay while maintaining stream stability.<\/p>\n We previously achieved \u00b15-second latency, but reducing it further\u2014especially across players like hls.js and Safari\u2014was a major technical challenge. The goal was to achieve 2-second latency without compromising stability.<\/p>\n Ultimately, a traditional and the new low-latency delivery scheme looked like this:<\/p>\n Above: Challenges of low latency LL-DASH and LL-HLS live streams delivery glass-to-glass<\/em><\/p>\n The protocols LL-DASH<\/strong> and LL-HLS<\/strong> use very different delivery and playback schemes. The challenge was to make both protocols work simultaneously within a single delivery system.<\/p>\n A few key points allowed us to synchronize the delivery of both:<\/p>\n DASH (Dynamic Adaptive Streaming over HTTP) is a very flexible protocol, which is both its strength and its challenge. This flexibility requires developers to consider numerous nuances when segmenting content. Here are the most basic principles of MPEG-DASH<\/strong>:<\/p>\n Low-latency streaming aims to play live content as close to the real-time boundary as possible. In LL-DASH<\/strong>, segments are transcoded and distributed simultaneously. The player doesn\u2019t need to wait for the entire file to be recorded\u2014it can start playback based on a specified \u201ctargetLatency \u201cattribute.<\/p>\n Above: Manifest of Chunked CMAF DASH<\/em><\/p>\n However, playback is only possible from a key-frame, which introduces a limitation when determining latency.<\/p>\n On the other hand, you know that playback is only possible from a key-frame. Thus, the key-frame becomes a vital limitation in determining the latency.<\/p>\n Key-frame placement strategy and how it affects latency in LL-DASH:<\/p>\n In LL-DASH<\/strong>, you can balance minimal latency and delivery quality on the last mile. If key-frames are too infrequent, data updates and network issues may lead to buffering.<\/p>\n Low Latency HLS brings a set of new conditions compared to its regular version:<\/p>\n Blocking Playlist Reloads:<\/strong><\/p>\n This is controlled via the directive: #EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES.<\/p>\n It instructs the server to hold the request until the part file becomes fully available. Whereas traditional HLS returns manifests almost instantly (\u00b130 ms), LL-HLS introduces a delay equal to the duration of the next part being prepared\u2014often 500 ms or more.<\/p>\n Tiny Parts and Buffer Length:<\/strong><\/p>\n Tiny files, or “parts,” are generated more frequently than full chunks. Their duration is regulated via the #EXT-X-PART-INF:PART-TARGET directive.<\/p>\n The buffer length is determined by the #EXT-X-SERVER-CONTROL:PART-HOLD-BACK parameter.<\/p>\n This value defines how many seconds the player should buffer before starting playback. It must be at least three times the part target duration.<\/p>\n How Apple Low Latency HLS Works:<\/strong><\/p>\n Latency is affected by the local buffer, the number of already generated tiny files, and again, the key-frame.<\/p>\n Above: Manifest of Low Latency HLS<\/em><\/p>\n Strategies for Key-Frame Placement and Their Impact on Latency in LL-HLS:<\/p>\n Above: In LL-HLS the more frequent the key-frames, the lower the latency<\/em><\/p>\n The length of the whole segment doesn\u2019t affect the latency, but the key-frame placement remains an essential factor.<\/p>\n One crucial feature of LL-HLS<\/strong> is byte-range requests, which can significantly reduce the number of requests, aggregating multiple small files into one larger request. Some players, like Safari, may delay playback to wait for the next key-frame, delivering the specified latency.<\/p>\n To unify the delivery system for both protocols, we used the similarities in their handling of key-frames and streaming.<\/p>\n Here\u2019s an example of how both protocols can be combined into a single system for stream generation for LL-DASH and LL-HLS:<\/p>\n Above: Unified scheme of placing key-frames and downloading streams using LL-HLS and LL-DASH protocols<\/em><\/p>\n This unified approach enabled us to overcome several challenges in ingest, transcode, packager, and CDN delivery systems.<\/p>\n Ingest:<\/strong> Ingesting streams with minimal delay from the origin is a challenge when dealing with the nuances of both protocols.<\/p>\n Transcoding:<\/strong> Passing unfinished parts\/files to JITP required new processing workflows.<\/p>\n Packager:<\/strong> Packing manifests and parts-files on the fly from unfinished transcoding files was a technical challenge.<\/p>\n CDN:<\/strong> The CDN had to support two different data transfer schemes simultaneously:<\/p>\n \u2022 Accelerated downloading of small files (instant download as they appear) The most complex part of the project was handled by the CDN. Our engineers expanded the network to over 200+ Tbps of capacity and reduced average response time to just 30ms globally. At the same time, we tackled several development tasks:<\/p>\n Chunked-Proxy Module Development:<\/strong><\/p>\n We developed a new module from scratch, which we call \u201cchunked-proxy\u201d<\/strong>. It works by downloading bytes from the origin and immediately distributing them to end-users. When a new user connects, they instantly receive the full volume of the already accumulated cache, while continuing to receive other bytes through continuous download simultaneously with all other users.<\/p>\n It\u2019s important to note that the term \u201cChunked transfer\u201d is used here with caution. In the case of an HTTP\/1.1 connection, it would be considered a chunked transfer response<\/strong>, and for HTTP\/2, it would be framed differently.<\/p>\n Key Features of the Chunked-Proxy Module:<\/p>\n \u2022 If the response is found in the cache, the Age header indicates how many seconds ago the response was cached. Chunked Cache and Delivery of LL-DASH over CDN:<\/p>\n Above: The diagram logic of chunked transfer of LL-DASH via the chunked-proxy module.<\/em><\/p>\n The CDN must be capable of holding connections for low-latency manifest files (.m3u8) for extended periods while waiting for a response from the origin. This presents a challenge for tools that monitor “response_time” because the response time will now be approximately equal to the duration of the part-files.<\/p>\n Additionally, we need to correctly handle MISS and EXPIRED statuses, sending these to the origin only on the first request. This process is tricky because default caching mechanisms like Nginx:proxy_cache_lock are not fully suitable, as they only process a portion of the statuses. A full implementation is required.<\/p>\n The CDN must be configured to cache low-latency .m3u8 manifests properly. The caching should be set with a cache-control of 1 second, and it should include query parameters like _HLS_skip, _HLS_msn, and _HLS_part in the cache key.<\/p>\n Handling an increased number of requests:<\/strong><\/p>\n The CDN must be prepared for an increased number of requests for small files, which includes low-latency manifests for each new part, as well as the parts-files. While the file size is small, the number of requests increases significantly. For example, a single segment may contain multiple manifests and parts-files. Consequently, logs can become 2*N times larger. Monitoring and analysis tools had to be optimized to accommodate this increased load.<\/p>\n Above: Sequence diagram of LL-HLS requests for manifests and parts-files<\/em>S<\/p>\n Byte-range requests can significantly reduce the number of requests made to the origin. Instead of making multiple requests for discrete file parts, one request is made for a whole segment. According to the HLS specification<\/a> (Section 6.2.6), \u201cWhen processing a byte range of a URI that includes one or more Partial Segments that are not yet completely sent, the server MUST refrain from transmitting any bytes belonging to a Partial Segment until all bytes of that Partial Segment can be transmitted at full speed to the client.\u201d<\/p>\n This means that the transmission to and from the CDN should be organized through the Chunked Proxy, just as with LL-DASH, but with an explicit logical division into parts.<\/p>\n All new features have been integrated into the standard transcoding and CDN delivery pipeline. As a result, we’ve adapted our usual analysis and monitoring tools to handle the increased load.<\/p>\n Key Components of Observability:<\/p>\n Gcore has achieved exceptional latency performance with the LL-DASH protocol, delivering a latency of approximately \u00b12.0 seconds, and the LL-HLS protocol, with a latency of around \u00b13.0 seconds.<\/p>\n Key technical developments include:<\/p>\n We believe \u00b11\u20132 seconds over HTTP is achievable\u2014and we\u2019re already working toward it. For content providers, that means not just \u201clow latency,\u201d but interactive latency<\/em>\u2014enabling more immersive, real-time audience engagement.<\/p>\n Delivering high-quality, low-latency live streaming at scale requires advanced infrastructure built for performance. Gcore\u2019s CDN is designed to meet these demands with industry-leading capabilities:<\/p>\n Above: Gcore Edge Network<\/em><\/p>\n By combining high-speed edge processing, optimized caching strategies, and real-time monitoring, Gcore\u2019s CDN provides a robust foundation for live streaming services, enabling content providers to deliver ultra-low latency experiences to their audiences.<\/p>\n Find out more about our CDN<\/a> and streaming service<\/a>.<\/p>\n This article is Sponsored Content<\/em><\/p>\nDelivering real-time streaming at scale<\/h2>\n
\n
The challenge: accelerating live video delivery<\/h2>\n
\n
![\"Increased](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/335802-9-ORG.png\")
<\/p>\n\n
![\"Challenges](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/335803-1-ORG.png\")
<\/p>\nVersatility<\/h2>\n
LL-DASH<\/h3>\n
\n
![\"Manifest](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/239687-Picture4-ORG.png\")
<\/p>\n![\"In](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/335804-2-ORG.png\")
<\/p>\nLL-HLS<\/h3>\n
\n
![\"Manifest](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/239689-Picture6-ORG.png\")
<\/p>\n![\"In](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/335808-3-ORG.png\")
<\/p>\nUnification<\/h3>\n
![\"Unified](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/335805-4-ORG.png\")
<\/p>\nThe challenges<\/h2>\n
\u2022 Continuous download of unfinished long files.<\/p>\nPerformance: Delivery via CDN<\/h3>\n
LL-DASH<\/h3>\n
\n
\n
\u2022 If the response is not found in the cache, the Age header is not added.<\/p>\n![\"The](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/335806-5-ORG.png\")
<\/p>\nLL-HLS<\/h3>\n
\n
![\"Sequence](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/335807-6-ORG.png\")
<\/p>\nObservability<\/h3>\n
\n
The results<\/h2>\n
\n
What\u2019s next<\/h2>\n
About Gcore CDN<\/h2>\n
![\"Gcore](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/InlineImages\/239694-Picture11-ORG.png\")
<\/p>\n![\"Streaming](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/SiteImages\/168775-2025-Cover-Images---April-2025-ORG.png\")
\n\n <\/div>\n<\/p><\/div>\n<\/div>\n![](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/ArticleImages\/141123-Alex-Peterson-G-Core-Labs-ORG.jpg\"\/)
![](\"https:\/\/dzceab466r34n.cloudfront.net\/Images\/CompanyImages\/104082-StreamS-Logo-4.png-ORG.png\"\/){kind=logo}