{"id":1298,"date":"2026-09-09T09:48:55","date_gmt":"2026-09-09T02:48:55","guid":{"rendered":"https:\/\/liveapi.com\/blog\/low-latency-hls\/"},"modified":"2026-09-09T13:21:33","modified_gmt":"2026-09-09T06:21:33","slug":"low-latency-hls","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/low-latency-hls\/","title":{"rendered":"Low Latency HLS (LL-HLS): How It Works, Latency, and How to Implement It"},"content":{"rendered":"Reading Time: <\/span> 13<\/span> minutes<\/span><\/span>

Standard HLS ships live video with 10 to 30 seconds of delay. That’s fine for a movie. It’s useless for a sports stream where your viewers hear the neighbors cheer before they see the goal.<\/p>\n

Low latency HLS closes that gap to roughly 2 to 5 seconds without asking you to abandon the HLS ecosystem you already run on.<\/p>\n

Apple published the extension in 2019, folded it into the main HLS specification in 2020, and every major player now supports it.<\/p>\n

What Is Low Latency HLS?<\/h2>\n

Low latency HLS (LL-HLS) is an extension to the HTTP Live Streaming protocol that cuts live stream delay to about 2 to 5 seconds by publishing short partial segments before a full segment finishes encoding.<\/p>\n

Standard HLS makes the player wait for a complete segment (typically 2 to 6 seconds of video), then wait again while it polls the playlist to find out that segment exists. Stack up the buffer a player holds before playback and you get double-digit delay.<\/p>\n

LL-HLS attacks both halves of that problem. It splits each segment into parts of 200 to 500 milliseconds that the server publishes as soon as they’re encoded, and it replaces playlist polling with requests the server holds open until new media is ready.<\/p>\n

The extension exists because HLS won on reach and lost on speed. It plays natively on iOS, Android, smart TVs, and every browser, and it rides ordinary HTTP caches.<\/p>\n

Rewriting all of that to chase latency was never realistic, so Apple made HLS itself faster. Critically, LL-HLS playlists stay backward compatible<\/a>. A player that doesn’t understand the new tags ignores them and plays the full segments at normal latency.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Attribute<\/th>\nStandard HLS<\/th>\nLow Latency HLS<\/th>\n<\/tr>\n<\/thead>\n
Typical glass-to-glass latency<\/td>\n10\u201330 seconds<\/td>\n2\u20135 seconds<\/td>\n<\/tr>\n
Smallest unit published<\/td>\nFull segment (2\u20136s)<\/td>\nPartial segment (0.2\u20130.5s)<\/td>\n<\/tr>\n
Playlist discovery<\/td>\nClient polls on a timer<\/td>\nServer holds the request open<\/td>\n<\/tr>\n
Playlist size on long streams<\/td>\nGrows to megabytes<\/td>\nTrimmed by delta updates<\/td>\n<\/tr>\n
Quality switching<\/td>\nFetch each rendition’s playlist<\/td>\nRendition reports in one response<\/td>\n<\/tr>\n
CDN compatibility<\/td>\nAny HTTP cache<\/td>\nAny HTTP cache, cache key must include query strings<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

LL-HLS vs LHLS vs CMAF-CTE vs WebRTC<\/h2>\n

Four low latency approaches share overlapping vocabulary, and the names are close enough to cause real confusion. Here’s what separates them.<\/p>\n

LL-HLS<\/strong> is Apple’s official extension, now part of the HLS specification. It uses partial segments plus blocking playlist requests, and it’s what “low latency HLS” means in 2026.<\/p>\n

LHLS<\/strong> (no hyphen after the second L) was a community approach that predated Apple’s spec, pioneered largely at Periscope. It used HTTP chunked transfer encoding to stream a segment while it was still being written. It never became a standard, and Apple’s LL-HLS effectively replaced it. You’ll still see the term in older documentation.<\/p>\n

CMAF-CTE<\/strong> (Common Media Application Format with chunked transfer encoding, also called LL-DASH on the DASH side) takes the chunked-encoding route inside fragmented MP4 containers. Because CMAF<\/a> segments can serve both HLS and DASH manifests, one encode covers both ecosystems. Our breakdown of CMAF vs HLS<\/a> digs into that tradeoff.<\/p>\n

WebRTC<\/strong> is a different protocol family entirely, built for real-time conversation rather than broadcast. It reaches 100 to 500 milliseconds, but it needs signaling servers, TURN relays, and media servers that scale per viewer. See WebRTC vs HLS<\/a> for where each one wins.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Approach<\/th>\nTypical latency<\/th>\nTransport mechanism<\/th>\nScales on CDN<\/th>\nEcosystem<\/th>\n<\/tr>\n<\/thead>\n
Standard HLS<\/td>\n10\u201330s<\/td>\nFull segment download<\/td>\nYes<\/td>\nUniversal<\/td>\n<\/tr>\n
LL-HLS<\/td>\n2\u20135s<\/td>\nPartial segments + blocking reload<\/td>\nYes<\/td>\nHLS<\/td>\n<\/tr>\n
LHLS (legacy)<\/td>\n3\u20137s<\/td>\nChunked transfer encoding<\/td>\nPartly<\/td>\nHLS, deprecated<\/td>\n<\/tr>\n
CMAF-CTE \/ LL-DASH<\/td>\n3\u20136s<\/td>\nChunked transfer encoding<\/td>\nYes<\/td>\nHLS + DASH<\/td>\n<\/tr>\n
WebRTC<\/td>\n0.1\u20130.5s<\/td>\nUDP peer\/SFU delivery<\/td>\nNo, needs media servers<\/td>\nReal-time apps<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The rest of this guide uses LL-HLS to mean Apple’s specification.<\/p>\n

How Does Low Latency HLS Work?<\/h2>\n

LL-HLS keeps the HLS delivery model: an m3u8 playlist<\/a> pointing at media files over HTTP. What changes is what the server publishes and how the client asks for it.<\/p>\n

    \n
  1. Your encoder pushes a live feed to the origin.<\/strong> Ingest arrives over RTMP<\/a> or SRT<\/a>, with the keyframe interval<\/a> set short, usually 1 to 2 seconds, because segments can’t be shorter than a GOP.<\/li>\n
  2. The packager writes partial segments as they encode.<\/strong> Rather than holding a 4-second segment until it’s complete, the packager emits parts of 200 to 500 milliseconds and appends an EXT-X-PART<\/code> tag for each one.<\/li>\n
  3. The playlist advertises what’s coming next.<\/strong> An EXT-X-PRELOAD-HINT<\/code> tag names the part that hasn’t been produced yet, so the client can request it before it exists.<\/li>\n
  4. The client asks for the future, not the present.<\/strong> Instead of re-downloading the playlist every few seconds hoping something changed, the player appends _HLS_msn<\/code> and _HLS_part<\/code> query parameters naming the part it wants. The server holds that connection open and answers the instant the part is ready.<\/li>\n
  5. The server holds the preload request too.<\/strong> The GET for the hinted part sits open on the origin and starts responding the moment bytes exist, so there’s no request round trip after the playlist update.<\/li>\n
  6. The player starts playback close to the live edge.<\/strong> How close is set by PART-HOLD-BACK<\/code>, the server-recommended distance from the end of the playlist. That single number is the main lever on your latency.<\/li>\n<\/ol>\n

    The shift that matters is from polling to blocking. Standard HLS wastes time asking “is there anything new?” LL-HLS asks “tell me the moment there is,” and that removes most of the delay that isn’t already spoken for by encoding.<\/p>\n

    The Five Mechanisms Behind LL-HLS<\/h2>\n

    Five features do the actual work. Understanding them is the difference between hitting 2 seconds and wondering why you’re stuck at 8.<\/p>\n

    1. Partial Segments<\/h3>\n

    The core idea. Each media segment is subdivided into parts, and each part gets an EXT-X-PART<\/code> tag carrying a URI<\/code> and a DURATION<\/code>. An optional INDEPENDENT=YES<\/code> attribute flags parts that start with an independently decodable frame, which players need for joining and switching.<\/p>\n

    Parts are transient. The spec says EXT-X-PART<\/code> tags should be removed once they’re more than three target durations from the end of the playlist, though clients must still be able to download a part for at least three target durations after its tag disappears. The EXT-X-PART-INF<\/code> tag declares PART-TARGET<\/code>, the part target duration, which every part must respect.<\/p>\n

    2. Blocking Playlist Reload<\/h3>\n

    The client requests a playlist that doesn’t exist yet. It appends _HLS_msn=<media sequence number><\/code> and optionally _HLS_part=<part index><\/code> to the playlist URI, and the server defers its response until that part is available.<\/p>\n

    This is the single biggest win. Polling costs you up to a full poll interval on every update; blocking costs you nothing. The server signals support with CAN-BLOCK-RELOAD=YES<\/code> in EXT-X-SERVER-CONTROL<\/code>. If it can’t satisfy the request after blocking for more than three target durations, it should return a 503 rather than hang forever.<\/p>\n

    3. Preload Hints<\/h3>\n

    EXT-X-PRELOAD-HINT<\/code> names a resource the server hasn’t finished producing. The client issues a GET immediately, the server holds it, and bytes flow as soon as they’re encoded. Optional BYTERANGE-START<\/code> and BYTERANGE-LENGTH<\/code> attributes let a single file host multiple parts by byte range, which cuts down on file count.<\/p>\n

    Combined with blocking reload, preload hints remove the request round trip between learning a part exists and having its data.<\/p>\n

    4. Playlist Delta Updates<\/h3>\n

    A live playlist on a multi-hour stream grows to megabytes, and re-downloading it several times a second is absurd.<\/p>\n

    So the client adds _HLS_skip=YES<\/code>, and the server returns only the recent portion, replacing the older entries with an EXT-X-SKIP<\/code> tag carrying SKIPPED-SEGMENTS<\/code>. The server advertises this with CAN-SKIP-UNTIL<\/code>, which must be at least six times the target duration.<\/p>\n

    This is the one mechanism that affects your playlist version: a playlist containing EXT-X-SKIP<\/code> needs EXT-X-VERSION:9<\/code> or higher, and version 10 if the skip also replaces EXT-X-DATERANGE<\/code> tags. Some guides claim all LL-HLS tags require version 10. They don’t.<\/p>\n

    5. Rendition Reports<\/h3>\n

    When a player switches quality in standard HLS, it fetches the new rendition’s playlist and figures out where the live edge is, which is expensive at low latency. EXT-X-RENDITION-REPORT<\/code> solves it by including each other rendition’s URI<\/code>, LAST-MSN<\/code>, and LAST-PART<\/code> right in the current playlist. The player already knows where to jump in, so adaptive bitrate streaming<\/a> switches stay fast at the live edge.<\/p>\n

    Here’s how it looks in a real playlist:<\/p>\n

    #EXTM3U\r\n#EXT-X-VERSION:9\r\n#EXT-X-TARGETDURATION:4\r\n#EXT-X-PART-INF:PART-TARGET=0.5\r\n#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.5,CAN-SKIP-UNTIL=24.0\r\n#EXT-X-MEDIA-SEQUENCE:412\r\n#EXT-X-SKIP:SKIPPED-SEGMENTS=90\r\n\r\n#EXTINF:4.00000,\r\nsegment412.m4s\r\n\r\n#EXT-X-PART:DURATION=0.50000,URI=\"segment413.0.m4s\",INDEPENDENT=YES\r\n#EXT-X-PART:DURATION=0.50000,URI=\"segment413.1.m4s\"\r\n#EXT-X-PART:DURATION=0.50000,URI=\"segment413.2.m4s\"\r\n#EXT-X-PRELOAD-HINT:TYPE=PART,URI=\"segment413.3.m4s\"\r\n\r\n#EXT-X-RENDITION-REPORT:URI=\"..\/720p\/index.m3u8\",LAST-MSN=413,LAST-PART=2\r\n#EXT-X-RENDITION-REPORT:URI=\"..\/480p\/index.m3u8\",LAST-MSN=413,LAST-PART=2<\/code><\/pre>\n
    Segment 413 is still being encoded. Three of its parts are published, the fourth is hinted, and the player already has a request open for it.<\/p>\n
    One note on history. Apple’s original 2019 draft required HTTP\/2 server push, delivered via an _HLS_push<\/code> directive. CDNs hated it, and it was removed in 2020.<\/p>\n
    The current specification<\/a> defines exactly three delivery directives: _HLS_skip<\/code>, _HLS_msn<\/code>, and _HLS_part<\/code>. If you’re reading a guide that tells you to configure HTTP\/2 push for LL-HLS, it’s out of date.<\/p>\n
    Low Latency HLS Latency: What to Actually Expect<\/h2>\n
    LL-HLS delivers 2 to 5 seconds of glass-to-glass latency in production, with well-tuned deployments landing near 2 seconds. That’s down from 10 to 30 seconds for standard HLS.<\/p>\n
    The number isn’t magic. It’s arithmetic, and PART-HOLD-BACK<\/code> dominates it. The spec requires PART-HOLD-BACK<\/code> to be at least twice the part target duration and recommends at least three times. So your practical floor is roughly:<\/p>\n
    latency \u2248 encoder delay + PART-HOLD-BACK + network transit + player buffer<\/strong><\/p>\n
    Shrink PART-TARGET<\/code> and PART-HOLD-BACK<\/code> together and latency drops. OvenMediaEngine’s measured benchmarks<\/a> show the relationship cleanly:<\/p>\n
    \n\n\n\n\n\n\n\n
    Part target duration<\/th>\nPART-HOLD-BACK<\/th>\nMeasured latency<\/th>\nProfile<\/th>\n<\/tr>\n<\/thead>\n
    1.0s<\/td>\n3.0s<\/td>\n3.73s<\/td>\nStability first<\/td>\n<\/tr>\n
    0.5s<\/td>\n1.5s<\/td>\n1.93s<\/td>\nBalanced<\/td>\n<\/tr>\n
    0.2s<\/td>\n0.6s<\/td>\n1.03s<\/td>\nAggressive<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
    Sub-second latency over HTTP is real. It’s also fragile. A 0.6-second hold-back leaves almost no buffer for a network hiccup, so viewers on unstable connections rebuffer instead.<\/p>\n
    Most teams land on 0.5-second parts with a 1.5-second hold-back, which trades a second of delay for playback that survives real networks.<\/p>\n
    Two other factors set a hard ceiling regardless of your tuning. Your keyframe interval bounds segment length, so a 4-second GOP caps how short parts can usefully be. And ingest matters: pushing over SRT rather than RTMP shaves off contribution delay on lossy links. Our guide to video latency<\/a> breaks down where each millisecond goes.<\/p>\n
    Advantages of Low Latency HLS<\/h2>\n
    It runs on the CDN you already have<\/h3>\n
    LL-HLS is still HTTP. No SFUs, no TURN servers, no per-viewer compute. The same multi-CDN<\/a> setup that serves standard HLS serves LL-HLS, with one caching change we’ll cover below.<\/p>\n
    It scales to millions of concurrent viewers<\/h3>\n
    Because delivery is cacheable HTTP, cost per viewer stays flat as audience grows. WebRTC gets you to 500 milliseconds but every additional viewer consumes media-server resources. That’s the tradeoff behind ultra low latency video streaming<\/a> architectures.<\/p>\n
    Backward compatibility is built in<\/h3>\n
    Old players ignore the new tags and play full segments. You ship one stream and serve everybody: no parallel pipeline, no user-agent sniffing.<\/p>\n
    Native playback on Apple devices<\/h3>\n
    AVPlayer handles LL-HLS natively from iOS 14 onward. No JavaScript player, no third-party SDK, no workaround for Safari’s refusal to play MSE-based streams on iPhone.<\/p>\n
    Adaptive bitrate still works<\/h3>\n
    Rendition reports keep quality switching fast at the live edge, so viewers on bad connections drop a rung instead of stalling. Latency doesn’t cost you ABR.<\/p>\n
    One protocol from live to VOD<\/h3>\n
    The same HLS segments that serve your live stream become your recording. Turning a broadcast into on-demand content is a packaging step, not a re-encode. See live to VOD<\/a> for the workflow.<\/p>\n
    Disadvantages of Low Latency HLS<\/h2>\n
    It can’t reach sub-second latency<\/h3>\n
    Two seconds is a floor you can approach but not break by much. Video calls, auctions, and betting interfaces need WebRTC. If your product depends on genuine conversation, LL-HLS is the wrong tool.<\/p>\n
    Request volume goes up sharply<\/h3>\n
    Publishing 0.5-second parts instead of 4-second segments means eight times the media requests, plus a blocking playlist request per part. Origin and CDN request counts climb, and on usage-based pricing so does your bill. Larger parts and byte-range addressing pull it back down.<\/p>\n
    Your CDN needs configuring<\/h3>\n
    Delivery directives are query strings, so _HLS_msn<\/code> and _HLS_part<\/code> must be part of the cache key or the CDN serves stale playlists to everyone. Your CDN also has to tolerate origin connections held open for seconds. Not every edge configuration does this out of the box, and it’s the most common reason a technically correct LL-HLS deployment delivers standard-HLS latency.<\/p>\n
    Tuning is unforgiving<\/h3>\n
    Get PART-HOLD-BACK<\/code> wrong and you either give up your latency gains or ship a stream that rebuffers constantly. There’s no safe default that works across every audience, so plan on measuring against real viewers rather than a lab.<\/p>\n
    Building the pipeline yourself is a real project<\/h3>\n
    Partial-segment packaging, blocking request handling, delta updates, rendition reports, and per-rendition part alignment across an ABR ladder add up to months of work, none of which ships a user-facing feature. Most teams reach for managed infrastructure instead.<\/p>\n
    Now that you know what LL-HLS is, how it works, and where it strains, here’s the practical side: how to get a low latency HLS stream running, what players and CDNs support it, and whether it fits your project.<\/p>\n
    How to Implement Low Latency HLS<\/h2>\n
    1. Set your keyframe interval first<\/h3>\n
    Segments can’t be shorter than a GOP, so this decision bounds everything downstream. Use a 1- or 2-second keyframe interval with keyframes at fixed positions. Disable scene-change keyframe insertion, because variable GOPs break part alignment across renditions. Your live streaming encoder<\/a> settings matter more here than anywhere else in the chain.<\/p>\n
    2. Choose your ingest protocol<\/h3>\n
    RTMP works and is universally supported by encoders and OBS. SRT handles packet loss better and cuts contribution latency on unreliable networks, which matters when you’re chasing a 2-second total budget. If your source is remote or on cellular, go with SRT.<\/p>\n
    3. Package into CMAF with partial segments<\/h3>\n
    Use fMP4\/CMAF rather than MPEG-TS so the same segments can feed DASH later. Configure your packager to emit parts and the LL-HLS tags. With ffmpeg, the low latency HLS flags look like this:<\/p>\n
    ffmpeg -i srt:\/\/0.0.0.0:9000?mode=listener \\\r\n  -c:v libx264 -preset veryfast -tune zerolatency \\\r\n  -g 48 -keyint_min 48 -sc_threshold 0 \\\r\n  -c:a aac -b:a 128k \\\r\n  -f hls \\\r\n  -hls_time 4 \\\r\n  -hls_segment_type fmp4 \\\r\n  -hls_flags independent_segments+delete_segments \\\r\n  -hls_playlist_type event \\\r\n  -master_pl_name master.m3u8 \\\r\n  stream.m3u8<\/code><\/pre>\n
    That gets you fMP4 segments with a fixed 2-second GOP at 24fps. But ffmpeg’s HLS muxer doesn’t emit EXT-X-PART<\/code> tags on its own. You need a packager or media server that implements the LL-HLS spec for true partial segments.<\/p>\n
    4. Configure server control and hold-back<\/h3>\n
    Set PART-TARGET<\/code> to 0.5 seconds and PART-HOLD-BACK<\/code> to 1.5 seconds as a starting point. Advertise CAN-BLOCK-RELOAD=YES<\/code> and set CAN-SKIP-UNTIL<\/code> to at least six times your target duration. Then measure and tighten. Don’t start aggressive.<\/p>\n
    5. Use a video API instead of building the origin<\/h3>\n
    Partial-segment packaging, blocking request handling, delta updates, and rendition-report generation across an ABR ladder is a serious engineering effort, and keeping it correct as the spec evolves is ongoing work. A live streaming API<\/a> hands you the finished pipeline. LiveAPI takes RTMP or SRT ingest, transcodes to an adaptive bitrate ladder up to 4K, and delivers HLS streaming<\/a> output across Akamai, Cloudflare, and Fastly, so you get low latency delivery and global reach without operating packagers or negotiating CDN contracts. Streams are playable in seconds after ingest, and recordings become VOD automatically.<\/p>\n
    6. Verify the tags are actually there<\/h3>\n
    Fetch your playlist and confirm EXT-X-PART<\/code>, EXT-X-PRELOAD-HINT<\/code>, and EXT-X-SERVER-CONTROL<\/code> are present. Then check that a request with _HLS_msn<\/code> actually blocks instead of returning immediately:<\/p>\n
    curl -s \"https:\/\/your-origin\/live\/index.m3u8\" | grep -E \"EXT-X-(PART|PRELOAD|SERVER)\"\r\n\r\ntime curl -s -o \/dev\/null \"https:\/\/your-origin\/live\/index.m3u8?_HLS_msn=999999&_HLS_part=0\"<\/code><\/pre>\n
    If that second command returns instantly, blocking reload isn’t working and you’re getting standard HLS latency with LL-HLS overhead.<\/p>\n
    7. Measure glass-to-glass, not playlist age<\/h3>\n
    Point a camera at a running millisecond timer, play the stream on the same screen, and photograph both. That difference is the only latency number that means anything to a viewer. Track rebuffer ratio alongside it. Latency you can’t sustain isn’t latency you have.<\/p>\n
    Player and CDN Support for LL-HLS<\/h2>\n
    Support is broad in 2026, but versions matter and the CDN side needs deliberate configuration.<\/p>\n
    Native Apple playback<\/h3>\n
    AVPlayer supports LL-HLS natively from iOS 14 and tvOS 14 onward, and it’s the reference implementation. If your audience skews iOS, this alone justifies choosing LL-HLS over CMAF-CTE.<\/p>\n
    hls.js in the browser<\/h3>\n
    hls.js<\/a> added Apple Low-Latency HLS support in v1.0.0, released April 2021. Enable it with lowLatencyMode: true<\/code> in the config. It’s the default choice for browser playback outside Safari on iOS.<\/p>\n
    Shaka Player and ExoPlayer<\/h3>\n
    Shaka Player<\/a> supports LL-HLS and is actively maintained through its 5.x line, which is the right pick if you serve both HLS and DASH from one player. On Android, ExoPlayer<\/a> handles LL-HLS through Media3.<\/p>\n
    \n\n\n\n\n\n\n\n\n\n
    Player<\/th>\nLL-HLS support<\/th>\nNotes<\/th>\n<\/tr>\n<\/thead>\n
    AVPlayer (iOS\/tvOS)<\/td>\niOS 14+<\/td>\nNative, reference implementation<\/td>\n<\/tr>\n
    hls.js<\/td>\nv1.0.0+ (April 2021)<\/td>\nSet lowLatencyMode: true<\/code><\/td>\n<\/tr>\n
    Shaka Player<\/td>\nv4+, maintained in 5.x<\/td>\nAlso covers DASH<\/td>\n<\/tr>\n
    ExoPlayer \/ Media3<\/td>\nSupported<\/td>\nAndroid native<\/td>\n<\/tr>\n
    Safari desktop<\/td>\nNative<\/td>\nUses the system HLS stack<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
    CDN configuration<\/h3>\n
    Two settings decide whether LL-HLS works at the edge:<\/p>\n