What Is Low-Latency HLS (LL-HLS) and When to Use It

Low-Latency HLS (LL-HLS) is Apple's extension to HTTP Live Streaming that cuts live delay from the usual 20 seconds or more to about 2 to 5 seconds. It splits each segment into small parts, so your player can fetch fresh video before a full segment even exists.

TL;DR:

• Classic HLS players start at least three segment durations behind the live edge, which puts glass-to-glass latency at roughly 20 to 45 seconds with common segment lengths.
• LL-HLS, announced by Apple in 2019, adds partial segments, preload hints, blocking playlist reloads and delta updates, so the player can start a few parts behind the edge instead.
• Real deployments land around 2 to 5 seconds, not WebRTC's sub-second range.
• The cost sits at the origin and CDN, which must hold requests open until new parts exist.
• Pick LL-HLS when viewers interact with the stream but you still want HLS's reach and caching.

Updated Oct 19, 2026: replaced the outdated "live streaming not available" line with AIOZ Stream's shipped live path and Low Latency Mode (Beta), and added sections on what causes HLS latency, HLS vs LL-HLS and LHLS vs Apple LL-HLS, plus a latency table, a diagram and References.

What causes HLS latency?

HLS delivers video as a series of files over plain HTTP. A live encoder cuts the stream into segments, usually 2 to 10 seconds each, and keeps a playlist of the most recent ones. Your player can't use a segment until it has been fully encoded, written and pushed to the CDN edge.

The bigger delay comes from where the player starts. RFC 8216, section 6.3.3 says a client should not start on a segment less than three target durations from the end of a live playlist, since starting closer can cause stalls. With 6-second segments that's 18 seconds before encoding and CDN time even count. Mux puts traditional HLS at 20 to 45 seconds glass-to-glass with 6 to 10 second segments.

That gap is fine for a rebroadcast, but it hurts anything with live chat, betting odds or a call-in segment, because viewers start reacting to events in different orders. Our glass-to-glass latency guide breaks the full delay into seven stages if you want to see where each second goes.

How LL-HLS works

Apple presented LL-HLS at WWDC 2019 as an extension to HLS rather than a new protocol. It's now part of the HLS second edition draft and Apple's HLS Authoring Specification, and it changes delivery in four ways:

• Partial segments. The EXT-X-PART tag lists small parts of the segment that's still being produced. Apple's authoring spec recommends a part target duration of one second, and at least three times the round-trip time most of your clients see.
• Preload hints. The EXT-X-PRELOAD-HINT tag gives the URL of the next part before it exists. Your player's request is already waiting when the data lands.
• Blocking playlist reload. Instead of polling, the player adds _HLS_msn and _HLS_part to ask for a future update. The server holds the request until that part exists, and advertises this with EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES.
• Delta updates. With _HLS_skip=YES, the server sends only the changed tail of the playlist and marks the skipped part with an EXT-X-SKIP tag.

The start rule changes as well: the server sets PART-HOLD-BACK, and Apple's spec says it must be at least three times the part target duration. With one-second parts, your player can start about 3 seconds behind the live edge instead of 18.

None of this changes how your video is encoded. LL-HLS is a playlist and delivery layer on top of standard segments, so a player without LL-HLS support can still play the same stream at normal HLS latency.

HLS vs LL-HLS: what is the difference?

Both use the same segments, codecs and playlists, so the difference is how close to the live edge your player may start and what the server must do to make that safe. Here's how they compare with WebRTC, using the ranges Mux and Fora Soft publish:

If your viewers only watch, classic HLS is the simpler and cheaper choice. If they chat, bid or vote, the 2 to 5 seconds of LL-HLS usually hides the seam while you keep HTTP delivery.

LHLS vs Apple LL-HLS

Apple's version wasn't the first low-latency HLS. As Mux describes, the community approach called LHLS grew out of a Periscope blog post from mid-2017. LHLS lists a segment in the playlist before it's finished and sends it with HTTP/1.1 chunked transfer encoding as the encoder produces it. Mux noted that chunked transfer works on the large majority of CDNs.

Apple's 2019 design took a different route, with separately addressable parts and blocking playlist requests, and its first draft required HTTP/2 push to deliver those parts. According to Mux's follow-up, Apple dropped that requirement and added EXT-X-PRELOAD-HINT instead, which made CDN support far easier. Apple's version is the one in the HLS spec today, so when a vendor says "low-latency HLS" now, they almost always mean it.

What LL-HLS costs you

Blocking reloads mean your origin, or a CDN feature built for this, has to hold requests open and answer only when data exists. That's a different load profile from serving whatever is cached, and a slow origin under LL-HLS leaves connections waiting for the length of a part instead of answering at once.

Your player also asks for the playlist far more often, which is why delta updates matter. Each part is a separate request too, so a one-second part target means about one media request per second for every viewer. None of this is exotic in 2026, but it's more than plain HLS asks of your stack.

When should you use LL-HLS?

The answer depends on how "live" your content needs to feel:

• Plain HLS fits pre-recorded video and live content where a 20-second delay doesn't hurt, like conference streams and background broadcasts. It's the simplest to run and the easiest to cache.
• LL-HLS earns its extra work when viewers interact in ways that expose the delay: live chat, auctions, betting odds or watch parties.
• WebRTC is for cases where even 2 seconds is too slow, such as two-way calls, cloud gaming or remote control. You give up HTTP caching and some device reach for that speed.

A quick test: if the goal is "viewers shouldn't feel behind chat," reach for LL-HLS. If it's "the other person is waiting for my reply," reach for WebRTC. Our HLS vs WebRTC guide goes through that decision in more detail.

How AIOZ Stream handles it

Live streaming on AIOZ Stream is documented and available: you broadcast from OBS Studio or PRISM Live Studio over RTMP, and each session returns an HLS playback URL, a player link and an embed code. For interactive broadcasts, the dashboard player view has a Low Latency Mode (Beta) toggle. The Viewing and Sharing docs say it reduces the delay between you and your audience.

What the docs don't cover yet: whether Low Latency Mode uses LL-HLS parts or another mechanism, and what latency either mode reaches. Measure your own stream before you promise viewers a number. You can watch stream health while you test, because the livestream statistic endpoint returns frame rate and bitrate in and out, updated every 5 to 30 seconds:

curl --location --request GET 'https://api.aiozstream.network/api/live_streams/statistic/stream_media_id' \
  --header 'stream-public-key: your_public_key_here' \
  --header 'stream-secret-key: your_secret_key_here'

The documented response includes fps_in, fps_out, bitrate_in, bitrate_out and data_transferred. Next step: create your Stream Key with the Create Livestream guide.

FAQ

Is LL-HLS a different protocol from HLS?
No. It adds playlist tags and request parameters to the same HLS specification, and a player that doesn't support them plays the stream at regular HLS latency.

Does every player support LL-HLS?
Not every one. Safari supports it natively since it's Apple's extension, and web players such as hls.js added support over time, while a player without support ignores the low-latency tags instead of failing.

Is LL-HLS the same as CMAF low latency?
They're related but different. CMAF is a container format that both LL-HLS and low-latency DASH can use, so one set of segments serves both, and LL-HLS is Apple's playlist and request mechanism on top.

Why not just make HLS segments shorter?
Shorter segments help a little, but they multiply the files your encoder writes and your CDN serves. You still wait for each full segment and then request it, while LL-HLS parts and preload hints remove that wait directly.

How short should LL-HLS parts be?
Apple's authoring spec recommends a one-second part target, at least three times the round-trip time 95% of your clients see. Shorter parts lower latency, but they add requests to your origin and CDN.

Does AIOZ Stream support LL-HLS?
AIOZ Stream's docs describe a Low Latency Mode (Beta) for live streams but don't name the mechanism behind it; the documented live output is HLS.

Related reading

• Glass-to-Glass Latency: What It Is and How to Measure It
• HLS vs WebRTC: when sub-second delivery is worth the infrastructure
• Live Streaming on AIOZ Stream: The Complete Guide: stream keys, sessions and Low Latency Mode (Beta)
• How to Start a Livestream on AIOZ Stream: the go-live path step by step
• Best OBS Encoder Settings for 1080p and 720p: encoder settings that affect latency
• How video segmentation and M3U8 manifests work: the segment and playlist basics LL-HLS builds on
• WebRTC Mesh vs SFU vs MCU: the SFU-plus-LL-HLS pattern large broadcasts use
• HLS vs MPEG-DASH on the AIOZ Stream player: how the player switches renditions

References

• RFC 8216, HTTP Live Streaming: section 6.3.3, the three-target-duration start rule
• HTTP Live Streaming 2nd Edition (draft-pantos-hls-rfc8216bis): partial segments, PART-HOLD-BACK, blocking reload and delta updates
• Apple, HLS Authoring Specification for Apple Devices: the one-second part target and PART-HOLD-BACK rule
• Mux, Low-Latency Live Streaming for Developers: latency ranges for HLS, LL-HLS and WebRTC
• Mux, The community gave us low-latency live streaming and Low-Latency HLS part 2: LHLS and the removal of HTTP/2 push
• Fora Soft, Latency Glass-to-Glass Explained: the 2 to 5 second low-latency tier
• AIOZ Stream docs, Viewing and Sharing: Low Latency Mode (Beta)