Low Latency HLS (LL-HLS): How It Works, Latency, and How to Implement It

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.

Low latency HLS closes that gap to roughly 2 to 5 seconds without asking you to abandon the HLS ecosystem you already run on.

Apple published the extension in 2019, folded it into the main HLS specification in 2020, and every major player now supports it.

What Is Low Latency HLS?

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.

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.

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.

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.

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

LL-HLS vs LHLS vs CMAF-CTE vs WebRTC

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

LL-HLS 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.

LHLS (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.

CMAF-CTE (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 segments can serve both HLS and DASH manifests, one encode covers both ecosystems. Our breakdown of CMAF vs HLS digs into that tradeoff.

WebRTC 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 for where each one wins.

The rest of this guide uses LL-HLS to mean Apple’s specification.

How Does Low Latency HLS Work?

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

1. Your encoder pushes a live feed to the origin. Ingest arrives over RTMP or SRT, with the keyframe interval set short, usually 1 to 2 seconds, because segments can’t be shorter than a GOP.
2. The packager writes partial segments as they encode. 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 tag for each one.
3. The playlist advertises what’s coming next. An EXT-X-PRELOAD-HINT tag names the part that hasn’t been produced yet, so the client can request it before it exists.
4. The client asks for the future, not the present. Instead of re-downloading the playlist every few seconds hoping something changed, the player appends _HLS_msn and _HLS_part query parameters naming the part it wants. The server holds that connection open and answers the instant the part is ready.
5. The server holds the preload request too. 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.
6. The player starts playback close to the live edge. How close is set by PART-HOLD-BACK, the server-recommended distance from the end of the playlist. That single number is the main lever on your latency.

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.

The Five Mechanisms Behind LL-HLS

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

1. Partial Segments

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

Parts are transient. The spec says EXT-X-PART 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 tag declares PART-TARGET, the part target duration, which every part must respect.

2. Blocking Playlist Reload

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

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 in EXT-X-SERVER-CONTROL. If it can’t satisfy the request after blocking for more than three target durations, it should return a 503 rather than hang forever.

3. Preload Hints

EXT-X-PRELOAD-HINT 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 and BYTERANGE-LENGTH attributes let a single file host multiple parts by byte range, which cuts down on file count.

Combined with blocking reload, preload hints remove the request round trip between learning a part exists and having its data.

4. Playlist Delta Updates

A live playlist on a multi-hour stream grows to megabytes, and re-downloading it several times a second is absurd.

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

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

5. Rendition Reports

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 solves it by including each other rendition’s URI, LAST-MSN, and LAST-PART right in the current playlist. The player already knows where to jump in, so adaptive bitrate streaming switches stay fast at the live edge.

Here’s how it looks in a real playlist:

#EXTM3U
#EXT-X-VERSION:9
#EXT-X-TARGETDURATION:4
#EXT-X-PART-INF:PART-TARGET=0.5
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.5,CAN-SKIP-UNTIL=24.0
#EXT-X-MEDIA-SEQUENCE:412
#EXT-X-SKIP:SKIPPED-SEGMENTS=90

#EXTINF:4.00000,
segment412.m4s

#EXT-X-PART:DURATION=0.50000,URI="segment413.0.m4s",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.50000,URI="segment413.1.m4s"
#EXT-X-PART:DURATION=0.50000,URI="segment413.2.m4s"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="segment413.3.m4s"

#EXT-X-RENDITION-REPORT:URI="../720p/index.m3u8",LAST-MSN=413,LAST-PART=2
#EXT-X-RENDITION-REPORT:URI="../480p/index.m3u8",LAST-MSN=413,LAST-PART=2

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.

One note on history. Apple’s original 2019 draft required HTTP/2 server push, delivered via an _HLS_push directive. CDNs hated it, and it was removed in 2020.

The current specification defines exactly three delivery directives: _HLS_skip, _HLS_msn, and _HLS_part. If you’re reading a guide that tells you to configure HTTP/2 push for LL-HLS, it’s out of date.

Low Latency HLS Latency: What to Actually Expect

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.

The number isn’t magic. It’s arithmetic, and PART-HOLD-BACK dominates it. The spec requires PART-HOLD-BACK to be at least twice the part target duration and recommends at least three times. So your practical floor is roughly:

latency ≈ encoder delay + PART-HOLD-BACK + network transit + player buffer

Shrink PART-TARGET and PART-HOLD-BACK together and latency drops. OvenMediaEngine’s measured benchmarks show the relationship cleanly:

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.

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.

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 breaks down where each millisecond goes.

Advantages of Low Latency HLS

It runs on the CDN you already have

LL-HLS is still HTTP. No SFUs, no TURN servers, no per-viewer compute. The same multi-CDN setup that serves standard HLS serves LL-HLS, with one caching change we’ll cover below.

It scales to millions of concurrent viewers

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 architectures.

Backward compatibility is built in

Old players ignore the new tags and play full segments. You ship one stream and serve everybody: no parallel pipeline, no user-agent sniffing.

Native playback on Apple devices

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.

Adaptive bitrate still works

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.

One protocol from live to VOD

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 for the workflow.

Disadvantages of Low Latency HLS

It can’t reach sub-second latency

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.

Request volume goes up sharply

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.

Your CDN needs configuring

Delivery directives are query strings, so _HLS_msn and _HLS_part 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.

Tuning is unforgiving

Get PART-HOLD-BACK 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.

Building the pipeline yourself is a real project

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.

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.

How to Implement Low Latency HLS

1. Set your keyframe interval first

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 settings matter more here than anywhere else in the chain.

2. Choose your ingest protocol

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.

3. Package into CMAF with partial segments

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:

ffmpeg -i srt://0.0.0.0:9000?mode=listener \
  -c:v libx264 -preset veryfast -tune zerolatency \
  -g 48 -keyint_min 48 -sc_threshold 0 \
  -c:a aac -b:a 128k \
  -f hls \
  -hls_time 4 \
  -hls_segment_type fmp4 \
  -hls_flags independent_segments+delete_segments \
  -hls_playlist_type event \
  -master_pl_name master.m3u8 \
  stream.m3u8

That gets you fMP4 segments with a fixed 2-second GOP at 24fps. But ffmpeg’s HLS muxer doesn’t emit EXT-X-PART tags on its own. You need a packager or media server that implements the LL-HLS spec for true partial segments.

4. Configure server control and hold-back

Set PART-TARGET to 0.5 seconds and PART-HOLD-BACK to 1.5 seconds as a starting point. Advertise CAN-BLOCK-RELOAD=YES and set CAN-SKIP-UNTIL to at least six times your target duration. Then measure and tighten. Don’t start aggressive.

5. Use a video API instead of building the origin

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 hands you the finished pipeline. LiveAPI takes RTMP or SRT ingest, transcodes to an adaptive bitrate ladder up to 4K, and delivers HLS streaming 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.

6. Verify the tags are actually there

Fetch your playlist and confirm EXT-X-PART, EXT-X-PRELOAD-HINT, and EXT-X-SERVER-CONTROL are present. Then check that a request with _HLS_msn actually blocks instead of returning immediately:

curl -s "https://your-origin/live/index.m3u8" | grep -E "EXT-X-(PART|PRELOAD|SERVER)"

time curl -s -o /dev/null "https://your-origin/live/index.m3u8?_HLS_msn=999999&_HLS_part=0"

If that second command returns instantly, blocking reload isn’t working and you’re getting standard HLS latency with LL-HLS overhead.

7. Measure glass-to-glass, not playlist age

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.

Player and CDN Support for LL-HLS

Support is broad in 2026, but versions matter and the CDN side needs deliberate configuration.

Native Apple playback

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.

hls.js in the browser

hls.js added Apple Low-Latency HLS support in v1.0.0, released April 2021. Enable it with lowLatencyMode: true in the config. It’s the default choice for browser playback outside Safari on iOS.

Shaka Player and ExoPlayer

Shaka Player 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 handles LL-HLS through Media3.

CDN configuration

Two settings decide whether LL-HLS works at the edge:

• Cache key. Add _HLS_msn, _HLS_part, and _HLS_skip to it. Otherwise the CDN treats every blocking request as the same object and serves stale playlists.
• Connection timeouts. Allow long-held origin connections, because a blocking request can legitimately sit open for seconds.

Most major CDNs support both, but neither is usually the default.

Managed infrastructure

Building and operating the origin, packager, and CDN configuration is where most LL-HLS projects stall: six to nine months of infrastructure work before the first viewer. LiveAPI covers that layer with a video encoding API that transcodes on ingest, an embeddable HTML5 player, HLS URLs that drop into OTT platforms like Roku and Apple TV, and pay-as-you-grow pricing tied to stream minutes. You configure ingest and get a playable stream, and protocol choice becomes a delivery preference rather than an infrastructure decision.

Is Low Latency HLS Right for Your Project?

LL-HLS fits a specific band of the latency spectrum. Here’s how to tell whether you’re in it.

Good fit if:

• Two to five seconds of delay is acceptable for your use case
• You expect thousands to millions of concurrent viewers
• Native iOS and smart TV playback matters
• Your delivery already runs on HTTP CDNs
• You need adaptive bitrate at the live edge
• The same content has to work as VOD afterward

Not a good fit if:

• Your product needs sub-second, two-way interaction
• Viewers number in the dozens and latency beats cost
• You can’t change CDN cache-key configuration
• Your encoder can’t produce fixed short GOPs

If you land in the good-fit column, the remaining question is build versus buy. The protocol is documented and the players support it. The effort is in the origin and the edge, which is exactly the part you can rent.

Low Latency HLS FAQ

What is the delay of low latency HLS?

LL-HLS typically delivers 2 to 5 seconds of glass-to-glass latency, compared with 10 to 30 seconds for standard HLS. Tuned deployments using 0.5-second parts and a 1.5-second PART-HOLD-BACK measure close to 2 seconds. Sub-1.1-second results are documented with 0.2-second parts, at the cost of rebuffer resilience.

Is LL-HLS better than WebRTC?

For broadcast to a large audience, yes. LL-HLS scales on ordinary CDNs at flat cost per viewer. For genuine two-way interaction, no. WebRTC reaches 100 to 500 milliseconds but needs signaling, TURN, and media servers that consume resources per participant.

Does hls.js support low latency HLS?

Yes. hls.js shipped Apple Low-Latency HLS support in version 1.0.0, released in April 2021. Set lowLatencyMode: true in your player config to enable it.

What is PART-HOLD-BACK?

PART-HOLD-BACK is the server-recommended minimum distance from the end of the playlist at which a client should start playing in low-latency mode. The spec requires it to be at least twice the part target duration and recommends at least three times. It’s the primary lever on your latency.

Does LL-HLS still need HTTP/2 push?

No. HTTP/2 server push was in Apple’s original 2019 draft but was removed in 2020 after CDN pushback. The current specification defines only three delivery directives: _HLS_skip, _HLS_msn, and _HLS_part.

What keyframe interval should I use for LL-HLS?

Use a fixed 1- or 2-second keyframe interval with scene-change detection disabled. Segments can’t be shorter than a GOP, and variable GOPs break part alignment across your ABR renditions.

Does Netflix use HLS or DASH?

Netflix primarily uses DASH for its on-demand catalog, though it delivers HLS to Apple devices where native playback requires it. Neither is a low latency deployment. VOD has no live edge to chase.

Can I use low latency HLS with ffmpeg?

Partly. ffmpeg produces fMP4/CMAF segments with the fixed short GOPs LL-HLS needs, but its HLS muxer doesn’t emit EXT-X-PART or EXT-X-PRELOAD-HINT tags. For true partial segments you need a packager or media server that implements the LL-HLS spec.

Is low latency HLS the same as low latency streaming?

No. Low latency streaming is the general category, covering LL-HLS, CMAF-CTE, WebRTC, SRT, and others. LL-HLS is one specific approach within it, targeting the 2-to-5-second range on HTTP delivery.

Bringing It Together

Low latency HLS gives you a 5x latency improvement over standard HLS while keeping everything that made HLS worth using: CDN scale, universal player support, native Apple playback, and adaptive bitrate. Partial segments, blocking playlist reload, preload hints, delta updates, and rendition reports each remove a specific source of delay, and PART-HOLD-BACK is the dial you turn to trade latency against stability.

The protocol side is settled and documented. The hard part is the origin and the edge: packaging parts correctly across an ABR ladder, handling held-open requests, and getting cache keys right on every CDN you use.

Ready to ship low latency live video? LiveAPI handles RTMP and SRT ingest, instant adaptive bitrate encoding up to 4K, HLS delivery across Akamai, Cloudflare, and Fastly, and automatic live-to-VOD recording — launch in days, not months. Get started with LiveAPI.