Why This Matters

Plain HLS is a magnificent CDN-friendly delivery format and a terrible interactive medium. A six-second segment plus a three-segment playback buffer is eighteen seconds of latency before the encoder, the network, and the player buffer have spoken; production deployments routinely measure twenty-five to thirty seconds glass-to-glass. That is fine for a movie and a disaster for sports betting, live auctions, classroom-with-Q&A, surveillance review, telemedicine, and any product where a viewer's reaction is supposed to land in the same conversation as the event. LL-HLS is the protocol you ship when you want HLS's CDN economics and Apple-ecosystem compatibility, and you also want a viewer who tweets about a goal during the match, not after the replay. The mechanisms are subtle, the failure modes are non-obvious, and the wrong configuration produces buffering rather than low latency. The point of this article is to make every line of an LL-HLS playlist readable to you, and to make the trade-offs visible before they cost a season's worth of CDN bill.

What LL-HLS is, in one paragraph

LL-HLS is regular HLS plus five tags and one HTTP behaviour. A producer encodes the live video in the same way as for plain HLS, but instead of waiting six seconds to publish a complete segment, the packager cuts each segment into ten to thirty partial segments (or parts) of 200–500 ms each and publishes each part as it becomes ready. The media playlist now lists not only the complete segments at the top of the file but also the parts of the segment currently being produced at the bottom. A new tag, #EXT-X-PART, marks each part with its duration and URI; another, #EXT-X-PRELOAD-HINT, tells the player where the next part will be once it exists. The player uses a long-poll request — playlist.m3u8?_HLS_msn=42&_HLS_part=7 — to ask the server "send me the playlist when part 7 of segment 42 exists", and the server holds that request open until the part is ready. Then it returns immediately. The player pipelines the next long-poll before parsing the response. The net effect is a continuous trickle of media instead of a stop-and-fetch rhythm, and glass-to-glass latency drops from twenty-five seconds to two-to-five.

The protocol was introduced by Apple at WWDC 2019 as the Apple Low-Latency HLS extension to the existing HLS specification. The original 2019 design relied on HTTP/2 server push to deliver parts; this was widely criticised because few commercial CDNs supported it well in production, and Apple removed the HTTP/2-push requirement in the September 2023 revision of the HLS Authoring Specification, replacing it with the preload-hint mechanism described in this article. The spec is now part of the same Internet-Draft that tracks the rest of HLS — draft-pantos-hls-rfc8216bis-22, published 1 May 2026 — and is normatively required on top of that for content shipping on Apple devices by the HLS Authoring Specification revision 2025-09.

The latency budget, before and after

The cleanest way to understand what LL-HLS is doing is to lay out the latency budget side by side with plain HLS and watch each segment of the bar collapse.

A typical plain-HLS live stream has three latency contributors. The encoder produces six-second segments; before the first byte of segment 42 reaches the origin, six seconds of real time have already passed. The playlist refresh is one round-trip every target-duration period, so on average half a target-duration of wait between a new segment existing and the player learning about it — three seconds for a six-second target. The playback buffer is conventionally three target-durations deep so the player can absorb network jitter without rebuffering, which adds eighteen seconds. Add about one second of HTTP overhead and you arrive at twenty-eight seconds glass-to-glass. Production deployments typically measure twenty to thirty.

LL-HLS rewrites every line.

Latency contributorPlain HLS (6 s segments)LL-HLS (6 s segments, 200 ms parts)
Encoder6.0 s (one full segment)0.2 s (one part)
Playlist refresh3.0 s (half target-duration)0.0 s (blocking reload returns immediately)
Playback buffer18.0 s (3× target-duration)0.6–1.2 s (3–6 parts)
HTTP overhead1.0 s0.4 s (pipelined)
Total glass-to-glass~28 s~2.2–3.0 s
The encoder line drops from six seconds to two hundred milliseconds because the packager publishes a part as soon as it has one, not after a full segment. The playlist-refresh line drops to zero because the server holds the long-poll open until the part exists and returns the moment it does — there is no polling round-trip to pay. The playback buffer shrinks from three target-durations to three to six parts because the smallest unit the player can buffer is now a part, not a segment. The HTTP overhead halves because requests are pipelined. The math is concrete: 0.2 + 0.0 + 0.6 + 0.4 = 1.2 s of protocol-level latency, plus 1–2 s for encoder pipeline and decoder pre-roll, lands LL-HLS at the two-to-three-second band that the Apple-ecosystem deployments measure in production. Glass-to-glass latency budget comparison between plain HLS and LL-HLS, with each contributor (encoder, playlist refresh, playback buffer, HTTP overhead) drawn as a horizontal stacked bar segment Figure 1. The glass-to-glass latency budget for plain HLS (top bar) vs LL-HLS (bottom bar). Each segment is annotated with its contributor; LL-HLS collapses every line by an order of magnitude.

The five mechanisms, one at a time

LL-HLS is not one new thing — it is five new things that only deliver their full benefit together. Skipping any one of them gives you a slower version of LL-HLS that still calls itself LL-HLS in the configuration file. Treat each mechanism as a separate machine and the combined system becomes legible.

Mechanism 1 — Partial segments (#EXT-X-PART)

A partial segment, or part, is a 200–500 ms slice of an in-progress segment, addressable as its own HTTP resource. While the encoder is still producing segment 42, the packager is already cutting and publishing parts 1, 2, 3 — each a separately requestable file (or byte-range of the in-progress segment file). The media playlist lists each finished part with a new tag:

#EXT-X-PART:DURATION=0.20000,URI="seg42-p1.m4s",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.20000,URI="seg42-p2.m4s"
#EXT-X-PART:DURATION=0.20000,URI="seg42-p3.m4s"

DURATION is the part's playable length, expressed as a decimal number of seconds. The spec requires the durations of all parts in a segment to add up exactly to the segment's #EXTINF duration once the segment is closed. URI points at the part — relative to the playlist, just like a segment URI. The optional INDEPENDENT=YES attribute marks a part that begins with an I-frame, which is the only kind of part a player can use as an ABR-switch point or as the first frame after a seek; the spec requires at least one independent part per segment, and the Apple Authoring Specification recommends one independent part every second of real time.

A second new tag declares the publisher's part policy at the top of the media playlist:

#EXT-X-PART-INF:PART-TARGET=0.2

PART-TARGET is the target part duration in seconds. A player uses it to pre-size its buffer; the value must be at least the longest part listed in the playlist. Apple's authoring spec requires PART-TARGET ≤ 0.33 (333 ms) for ultra-low-latency mode and PART-TARGET ≤ 1.0 for the relaxed low-latency mode. Two hundred milliseconds is the safe default; three hundred milliseconds is the safe ceiling.

The choice of PART-TARGET is the single most important latency knob in LL-HLS. Smaller parts mean lower latency and more requests; larger parts mean higher latency and fewer requests. The arithmetic is direct: a six-second segment with 200 ms parts is thirty parts, so a five-rendition multivariant stream produces 150 part-requests per six seconds (twenty-five per second) instead of five segment-requests every six seconds (less than one per second). Origin and CDN cache key design has to keep up.

Mechanism 2 — Preload hints (#EXT-X-PRELOAD-HINT)

Once the player has fetched every part in the current playlist, it still does not know where the next part will live until the playlist refreshes. The preload hint tells it ahead of time:

#EXT-X-PRELOAD-HINT:TYPE=PART,URI="seg42-p4.m4s"

TYPE=PART declares that the next thing the player should fetch is a part. The player issues a normal HTTP GET on that URI immediately. The server holds the request open — the file does not exist yet — and as soon as the encoder publishes the part, the server streams the bytes back over the already-open connection using HTTP/1.1 chunked transfer encoding, HTTP/2 stream framing, or HTTP/3 stream framing. From the player's perspective, it asked for the next part and the next part arrived. The round-trip cost of "check the playlist, find the URI, request the part, wait for response" collapses into one already-open connection.

Preload hints replaced HTTP/2 server push, which was the original 2019 design. HTTP/2 push proved hard to deploy at CDN scale because pushed responses bypassed every commercial CDN's cache logic; Apple removed the requirement in the September 2023 revision of the HLS Authoring Specification. The September 2025 revision keeps preload hints as the single normative mechanism for getting the next part to the player before its URI lands in a refreshed playlist. Articles that still describe LL-HLS as requiring HTTP/2 push predate that change and are out of date.

TYPE=MAP is the second form, used to preload the next CMAF initialisation segment when the encoder rotates encoding parameters between segments. In practice this rarely fires in a steady-state stream and is mostly relevant at ABR-switch boundaries.

Mechanism 3 — Blocking playlist reload

The player asks for the media playlist not by polling on a fixed schedule but by long-polling with the part it wants the server to wait for:

GET /720p/playlist.m3u8?_HLS_msn=42&_HLS_part=7 HTTP/1.1
Host: edge.example.com

The two reserved query parameters — _HLS_msn (the media sequence number the player wants to see in the response) and _HLS_part (the part index within that segment) — are delivery directives defined in the spec. The server reads them and behaves as follows: if a media playlist that already includes segment 42's part 7 exists, return it immediately; if not, hold the request open until that part is published, then return the playlist; if the wait would exceed three times the target duration, return what's available with a hint that more is coming.

Two preconditions activate this behaviour. The first is that the multivariant playlist (or the media playlist itself in older deployments) advertises the server's willingness to block:

#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=0.7,HOLD-BACK=6

CAN-BLOCK-RELOAD=YES is the unambiguous signal that long-poll requests with _HLS_msn are honoured. PART-HOLD-BACK is the minimum distance, in seconds, from the live edge at which the player should start playback — typically three times PART-TARGET. HOLD-BACK is the segment-level fallback for clients that don't support parts; six seconds is the spec's recommended floor.

The second precondition is that the server actually implements the long-poll. This is where commercial deployments quietly fall over: many origins return immediately with whatever playlist is currently on disk, ignoring _HLS_msn, and rely on the player to retry. The result is a polling loop dressed up as LL-HLS, and the latency budget collapses back into plain HLS. The Apple Authoring Specification requires servers advertising CAN-BLOCK-RELOAD=YES to actually block. Validate end-to-end with mediastreamvalidator and Apple's hlsreport tool before declaring a deployment compliant.

Mechanism 4 — Rendition reports (#EXT-X-RENDITION-REPORT)

A player that wants to switch from 720p to 1080p in the middle of a live stream cannot use the 720p playlist's blocking-reload state to know where 1080p currently is. Without help, it would have to issue a fresh GET against the 1080p media playlist, parse it to find the latest sequence and part number, and then issue the long-poll. That round-trip costs hundreds of milliseconds and frequently produces a one-segment rebuffer at the switch boundary.

Rendition reports prevent this by piggy-backing the current state of every sibling rendition onto every media playlist:

#EXT-X-RENDITION-REPORT:URI="../1080p/playlist.m3u8",LAST-MSN=42,LAST-PART=8
#EXT-X-RENDITION-REPORT:URI="../480p/playlist.m3u8",LAST-MSN=42,LAST-PART=8
#EXT-X-RENDITION-REPORT:URI="../360p/playlist.m3u8",LAST-MSN=42,LAST-PART=8

Each report lists the URI of a sibling media playlist and the latest sequence number and part index it carries. A player picking up 1080p reads the 1080p rendition report from the 720p playlist it already has, then issues playlist.m3u8?_HLS_msn=42&_HLS_part=9 against 1080p directly — no probe round-trip, no rebuffer.

The Apple Authoring Specification requires every LL-HLS rendition to advertise rendition reports for every sibling rendition, audio rendition, and subtitle rendition in the same variant group. In a multivariant stream with five video renditions, three audio renditions, and two subtitle tracks, every media playlist carries nine rendition-report lines. That is bandwidth the player pays once per playlist instead of nine extra long-polls per switch.

Mechanism 5 — Playlist delta updates (CAN-SKIP-UNTIL + #EXT-X-SKIP)

The fifth mechanism is what stops the playlist itself from growing without bound. Plain HLS playlists for live deployments are typically held to a sliding window of a few hundred seconds — past that, segments fall off the bottom of the file and the file stays small. LL-HLS makes the playlist much chattier because every refresh now also publishes parts at the bottom, and the sliding window has to be longer if the player is going to seek backward or recover from a longer rebuffer. Without intervention, an LL-HLS media playlist would grow to tens of kilobytes per refresh, and at twenty-five refreshes per second per rendition the bandwidth bill becomes serious.

Delta updates solve this. The server advertises a skip boundary — the oldest segment the player is allowed to skip — in #EXT-X-SERVER-CONTROL:

#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,CAN-SKIP-UNTIL=36.0,PART-HOLD-BACK=0.7

CAN-SKIP-UNTIL=36.0 says the server can omit any segment older than thirty-six seconds back from the live edge. The Apple Authoring Specification requires CAN-SKIP-UNTIL to be at least six times the target duration; for a six-second target that floor is thirty-six seconds. The player opts in by adding _HLS_skip=YES to its long-poll URL:

GET /720p/playlist.m3u8?_HLS_msn=42&_HLS_part=7&_HLS_skip=YES HTTP/1.1

The server returns a playlist with a new tag in place of the omitted segments:

#EXT-X-SKIP:SKIPPED-SEGMENTS=80

This says "I've left out the next eighty segments — you already had them on your previous fetch". The player splices the skipped range out of the response and into its existing playlist representation, and the wire payload shrinks by an order of magnitude. The semantics are equivalent to the full playlist; only the bytes on the wire change.

CMAF and EXT-X-MAP initialisation segments are never skipped, because the player may need them at any time. Discontinuities and date-ranges that fall inside the skipped window are not skipped either; the server is required to keep them in the response. Implementations sometimes get the discontinuity handling wrong — there's an open hls.js issue from 2025 documenting a regression where delta updates dropped a discontinuity that the player needed for ad-marker reconciliation. Validate with mediastreamvalidator -P and the Apple hlsreport tool whenever the upstream packager changes major version.

Sequence diagram of an LL-HLS request loop with long-poll: player issues GET with _HLS_msn and _HLS_part query parameters, server holds the request open until the part is published, then returns the playlist; the player issues the next long-poll before parsing the response Figure 2. The blocking-reload long-poll loop. The player asks for "the playlist when part 7 of segment 42 exists", the server holds the request, the encoder publishes part 7, the server returns immediately, and the player pipelines the next long-poll before parsing the response.

A live LL-HLS media playlist, line by line

Here is a realistic LL-HLS media playlist for one variant, mid-stream, with one segment fully published and the next segment in progress.

#EXTM3U
#EXT-X-VERSION:9
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:41
#EXT-X-PART-INF:PART-TARGET=0.2
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,CAN-SKIP-UNTIL=36.0,PART-HOLD-BACK=0.7,HOLD-BACK=6
#EXT-X-MAP:URI="init.mp4"

#EXTINF:6.000,
seg41.m4s

#EXT-X-PART:DURATION=0.20000,URI="seg42-p1.m4s",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.20000,URI="seg42-p2.m4s"
#EXT-X-PART:DURATION=0.20000,URI="seg42-p3.m4s"
#EXT-X-PART:DURATION=0.20000,URI="seg42-p4.m4s"
#EXT-X-PART:DURATION=0.20000,URI="seg42-p5.m4s"
#EXT-X-PART:DURATION=0.20000,URI="seg42-p6.m4s"
#EXT-X-PART:DURATION=0.20000,URI="seg42-p7.m4s"

#EXT-X-PRELOAD-HINT:TYPE=PART,URI="seg42-p8.m4s"

#EXT-X-RENDITION-REPORT:URI="../1080p/playlist.m3u8",LAST-MSN=42,LAST-PART=7
#EXT-X-RENDITION-REPORT:URI="../480p/playlist.m3u8",LAST-MSN=42,LAST-PART=7
#EXT-X-RENDITION-REPORT:URI="../360p/playlist.m3u8",LAST-MSN=42,LAST-PART=7

Read it from the top. #EXTM3U declares HLS. #EXT-X-VERSION:9 is the minimum HLS protocol version the player must support — version 9 is the first that includes the full LL-HLS tag set including CAN-SKIP-UNTIL and #EXT-X-SKIP; version 6 is enough for the original 2019 LL-HLS without delta updates. #EXT-X-TARGETDURATION:6 says no segment exceeds six seconds. #EXT-X-MEDIA-SEQUENCE:41 says segment 41 is the first complete segment in this view of the playlist. #EXT-X-PART-INF:PART-TARGET=0.2 declares the target part duration. #EXT-X-SERVER-CONTROL advertises the long-poll capability, the skip boundary, the part-level hold-back, and the segment-level hold-back. #EXT-X-MAP points at the CMAF initialisation segment.

Then the closed segment: #EXTINF:6.000, followed by seg41.m4s. Then seven parts of the in-progress segment 42, each two hundred milliseconds long, each with its own URI. Part 1 carries INDEPENDENT=YES because it starts with an I-frame; the others are P-frame parts that the player can only decode after part 1.

Then the preload hint: TYPE=PART and the URI where part 8 will live once it exists. The player issues an HTTP GET on that URI now; the server holds the response until part 8 is published.

Finally, three rendition reports for the sibling 1080p, 480p, and 360p variants. Each lists the latest sequence number and part index that variant has reached, so an ABR switch can long-poll the new variant directly without a probe round-trip.

When the playlist refreshes, segment 42 is closed (#EXTINF:6.000, + seg42.m4s), segment 43's first parts appear at the bottom, the preload hint moves to point at part 1 of segment 43, and the rendition reports advance. Older segments fall off the bottom of the file as the sliding window slides. With _HLS_skip=YES, the server returns the new state minus an #EXT-X-SKIP:SKIPPED-SEGMENTS=N line in place of the segments the player already saw.

Annotated LL-HLS media playlist showing closed segment 41 followed by seven published parts of in-progress segment 42, a preload hint pointing at part 8, and three rendition reports for sibling variants Figure 3. The same playlist, with each tag and its purpose annotated. The line between closed segments and in-progress parts is the live edge.

Chunked transfer, HTTP versions, and what the wire looks like

LL-HLS does its long-poll over plain HTTP. The original 2019 design relied on HTTP/2 server push to ship parts; that requirement is gone. In 2026 the deployed mix is roughly half HTTP/1.1 chunked transfer encoding, a third HTTP/2 stream framing, and the rest HTTP/3 over QUIC, with HTTP/3 growing fastest because it pairs naturally with the same QUIC stack that underpins MoQ.

The wire mechanics differ slightly by HTTP version but the semantics are identical. Over HTTP/1.1, the server holds the long-poll, then begins responding with Transfer-Encoding: chunked and writes each frame of the part as a separate chunk as the encoder produces it. Over HTTP/2 and HTTP/3, the server opens a stream and writes data frames as they appear; both protocols support the same low-latency behaviour because both treat the response body as a sequence of frames rather than a single buffer. The point — the same point in every version — is that the player begins decoding the first byte of the part as soon as it arrives, before the part is complete.

CMAF chunks are the encoding-side counterpart of LL-HLS parts. A CMAF chunk is the smallest independently decodable unit a CMAF encoder can produce; in practice, packagers produce one chunk per part, and "chunk" and "part" are used interchangeably in deployment discussions. The full chain is: encoder produces a CMAF chunk → packager wraps it as an addressable HTTP resource → media playlist publishes #EXT-X-PART pointing at it → server delivers it through chunked transfer or HTTP/2/3 streams → player decodes it the moment the first frame arrives. Modern packagers — Wowza, AWS MediaPackage, Bitmovin Live, Mux Live, Norsk, Unified Streaming, Shaka Packager — all produce LL-HLS as CMAF with one chunk per part out of the box. The CMAF format is defined in ISO/IEC 23000-19:2024; the LL-HLS-over-CMAF guidance is in the Apple Authoring Specification §3 and DASH-IF's Low-Latency Modes For DASH implementation guidelines.

ABR in LL-HLS: how the player switches

Adaptive bitrate switching in plain HLS is straightforward: when the player decides to switch from 720p to 1080p, it fetches the new variant's media playlist, finds a segment boundary, downloads the new init segment if it changed, and continues. In LL-HLS the same machinery applies, but two new constraints kick in.

First, the player can only switch at an independent part — one whose #EXT-X-PART line carries INDEPENDENT=YES. Independent parts start with an I-frame and can decode without referring to previous parts. The Apple Authoring Specification recommends one independent part every second of real time; that gives the player a switch opportunity every five parts at a 200 ms PART-TARGET. Non-independent (P-frame) parts cannot be the first part the player decodes on the new variant.

Second, the player uses rendition reports to skip the probe round-trip. With rendition reports in hand, the switch sequence is: the bandwidth estimator decides to move from 720p to 1080p; the player reads the 1080p rendition report from the current 720p playlist (LAST-MSN=42, LAST-PART=7); the player issues a long-poll directly against the 1080p playlist for _HLS_msn=42&_HLS_part=8; when the response arrives the player downloads the 1080p init segment if it's not in the player's cache, then begins fetching parts. No extra probe; no playlist GET that returns "you're already in sync"; no segment-boundary penalty.

The corner case is when 1080p and 720p have drifted in time relative to each other. CMAF specifies time alignment across renditions so a given media-sequence-number maps to the same real-world instant in every rendition. The Apple Authoring Specification §2.10 makes that alignment mandatory for variants in the same multivariant playlist; if the upstream encoder drifts, ABR switches will produce visible glitches. Validate alignment with mediastreamvalidator after any encoder configuration change.

Where the latency floor actually is, in 2026

The Mux, Wowza, Bitmovin, and AWS deployments that ship LL-HLS in production today report a two-to-three-second glass-to-glass floor for in-region viewers on modern devices. Apple's own demonstrations at WWDC 2025 showed sub-two-second latencies in a controlled environment with iPhone 15 / iOS 17 clients and a chunked-CMAF origin behind iCloud's edge network. Production averages drift slightly higher — three to five seconds — because the contributors that LL-HLS doesn't address (encoder pipeline depth, decoder pre-roll, last-mile jitter) don't disappear.

The numbers are concrete. Mux's published 2024 benchmark measures LL-HLS at 4.0 s average glass-to-glass across 35,000 sessions (median 3.2 s; p95 6.1 s; p99 9.4 s), against a 22.0 s average for plain HLS in the same conditions. Wowza's 2025 benchmarks describe a 5–6 s LL-HLS latency for a single iPhone client on Safari. Bitmovin's customer deployments report 3–4 s under normal conditions, with the 1.5 s lower bound reachable only when the encoder pipeline is tuned (B-frames disabled, GOP at one second, segment duration at two seconds with 200 ms parts). Apple's spec-grade implementations on Apple TV / iOS land closer to two seconds when the origin is within one network region of the client.

The reason production averages live above two seconds is that LL-HLS cannot make the encoder faster than its pipeline, the decoder faster than its pre-roll, or the network faster than RTT × jitter. The two seconds LL-HLS shaves off are the playlist-refresh and buffer contributions, which were never bound by physics. The remaining two-to-three seconds are real-world floors: a one-second encoder pipeline (one GOP buffered for B-frame reference + cabac entropy + chunk muxing), 200–400 ms of decoder pre-roll, 100–300 ms of last-mile RTT, and 200–500 ms of CDN/origin overhead. Below two seconds you need WebRTC — and you pay for it by trading the CDN economics that make HLS cheap to ship.

Common pitfalls

The five mechanisms describe what LL-HLS is. The pitfalls describe what goes wrong in practice when one of the mechanisms is misconfigured. Every team that ships LL-HLS hits a subset of these.

Pitfall — origin returns immediately and ignores _HLS_msn. The origin advertises CAN-BLOCK-RELOAD=YES in the playlist but doesn't actually implement long-polling. Player polls; server returns the current playlist; player polls again; latency stays at plain-HLS levels even though the playlist looks LL-HLS-compliant. Validate by issuing a request with _HLS_msn set well ahead of the live edge and timing how long the server holds it. The response should arrive within ±50 ms of when the requested part is published, not within the player's poll interval.
Pitfall — PART-TARGET set too high. Some packagers default to 1000 ms or 500 ms PART-TARGET to reduce origin load. The latency floor moves accordingly: PART-HOLD-BACK is three times PART-TARGET, so a one-second part gives a three-second mandatory minimum hold-back on top of the encoder and decoder floors. Production LL-HLS uses 200 ms parts; treat 500 ms as a regression from the default.
Pitfall — independent parts too sparse. The Apple Authoring Specification recommends one independent part per second of real time. Some encoders default to one per segment (one every six seconds), which forces ABR switches to wait for a segment boundary; latency at the switch becomes a full segment, not a single part. Set the encoder to produce an I-frame every second; check with ffprobe -show_packets after configuration changes.
Pitfall — CDN cache key ignores _HLS_msn / _HLS_part. A CDN that caches the playlist without those query parameters in the cache key serves a stale playlist to every long-poll. The fix is to include _HLS_msn, _HLS_part, and _HLS_skip in the CDN's cache key and to set the playlist's Cache-Control to max-age=1 (or zero) so the CDN re-fetches on each request. Akamai, Cloudflare, Fastly, and AWS CloudFront all support this — but it has to be configured explicitly per-deployment.
Pitfall — discontinuities dropped by delta updates. When the server returns #EXT-X-SKIP:SKIPPED-SEGMENTS=N, any #EXT-X-DISCONTINUITY or #EXT-X-DATERANGE (SCTE-35 ad marker) inside the skipped range must remain in the response. Some packager versions silently drop them. The hls.js issue tracker has an open ticket from late 2025 about this exact regression. Validate with mediastreamvalidator -P after every packager upgrade.
Pitfall — old players probing the playlist with no _HLS_msn. A legacy player that doesn't speak LL-HLS issues a plain GET against the same media playlist URL. The server should still serve a valid HLS playlist — LL-HLS extensions degrade cleanly, and the player simply doesn't see the LL-HLS tags. But many servers wrap the playlist in a CMAF-chunked response that confuses non-LL-HLS players; validate with the Apple mediastreamvalidator tool against both LL-HLS and non-LL-HLS player profiles before shipping.
Pitfall — EXT-X-PART durations don't sum to #EXTINF once the segment is closed. The spec requires the sum of all part durations to equal the segment's #EXTINF value to the nearest microsecond. Encoder drift can produce a 5.9999 vs 6.0000 mismatch that some players accept and some reject; in production, force the encoder to emit exact part durations and verify with mediastreamvalidator.

When LL-HLS is the right choice — and when it isn't

LL-HLS is the right protocol when you want the CDN economics of HLS, you ship to Apple devices, and you can live with two to five seconds of latency. That covers most live OTT use cases above 100,000 concurrent viewers — live sports without betting integration, breaking news, concert streams, live shopping where the chat is the primary interaction, classroom streaming with delayed Q&A, surveillance review.

LL-HLS is the wrong choice in two directions. Upward, when latency below two seconds matters — sports betting, live auctions, real-time gaming, telemedicine consultations with synchronous video, video conferencing — WebRTC delivery and Media over QUIC are the answers, and LL-HLS will leave a visible second of lag between the action and the reaction. Downward, when latency above ten seconds is fine — long-form VOD, replays, podcast video, archive content — plain HLS or plain MPEG-DASH is simpler, cheaper, and cache-friendlier. LL-HLS pays its CDN cost in long-poll request volume; if you don't need the latency, you don't need the cost.

The non-Apple alternative for the same 2-to-5 second band is LL-DASH with chunked CMAF — the same chunked-CMAF segments produced once and packaged once, served as HLS to Apple devices and DASH to everything else. CMAF makes that practical without doubling storage; the cluster-doc-recommended pattern in 2026 is "LL-HLS for iOS / Safari, LL-DASH for Chrome / Edge / Firefox / Android, one set of CMAF chunks underneath both". The protocol family tree lays out where each protocol sits.

Where Fora Soft fits in

We have shipped LL-HLS into live e-learning platforms, OTT services, telemedicine triage systems, and live shopping. Our streaming engineering team treats the five mechanisms above as one system — encoder pipeline, packager output, origin long-poll behaviour, CDN cache keys, and player ABR algorithm tuned together — because the production failure modes are always at the seams between two layers, not inside any one of them. We've also done the inverse: helped clients realise their use case actually requires WebRTC and avoided shipping LL-HLS for a sub-second product. The honest scoping conversation up front saves three months of "why is it still buffering" later.

What to read next

CTA

  • Talk to a streaming engineer — about whether LL-HLS, LL-DASH, WebRTC, or MoQ is the right shape for your latency target and CDN budget.
  • See our case studies — live e-learning, OTT, telemedicine, and live-shopping deployments.
  • Download — LL-HLS Readiness Checklist (2026) — twenty-five items every team should verify before declaring an LL-HLS deployment production-ready.

References

  1. IETF RFC 8216 — Pantos, R., May, W., HTTP Live Streaming, August 2017. https://www.rfc-editor.org/rfc/rfc8216 — Tier 1 (IETF RFC). Base HLS protocol; LL-HLS extends this.
  2. IETF Internet-Draft draft-pantos-hls-rfc8216bis-22 — Pantos, R., HTTP Live Streaming 2nd Edition, 1 May 2026. https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-22 — Tier 1 (IETF Internet-Draft, subject to change). Active draft (version 13 of HLS) that incorporates the LL-HLS tag set including #EXT-X-PART, #EXT-X-PRELOAD-HINT, #EXT-X-SERVER-CONTROL, #EXT-X-RENDITION-REPORT, CAN-SKIP-UNTIL, and #EXT-X-SKIP. Obsoletes RFC 8216 if approved.
  3. Apple HLS Authoring Specification for Apple Devices, revision 2025-09 — September 2025. https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices — Tier 1 (vendor authoring spec, normative for Apple devices). Source for the HTTP/2-push removal (revision 2023-09), PART-TARGET ≤ 0.33 s / 1.0 s requirements, one-independent-part-per-second recommendation, and the CAN-SKIP-UNTIL floor of 6 × target duration.
  4. Apple WWDC 2025 — What's new in HTTP Live Streaming, June 2025. https://developer.apple.com/streaming/Whats-new-HLS.pdf — Tier 3 (first-party engineering session by the spec authors). Source for production-grade latency numbers on iOS 17 / Apple TV and the 2025 chunked-CMAF guidance.
  5. ISO/IEC 23000-19:2024 — Common Media Application Format (CMAF) for segmented media, 2024. https://www.iso.org/standard/85673.html — Tier 1 (ISO/IEC standard, paywalled). CMAF chunk and segment definitions that underpin LL-HLS parts.
  6. DASH-IF — Low-Latency Modes For DASH, Implementation Guidelines v1.2, 2024. https://dashif.org/guidelines/ — Tier 1 (DASH-IF implementation guidelines, normative for DASH but informative for LL-HLS-over-CMAF). Source for the chunked-CMAF guidance that LL-HLS and LL-DASH share.
  7. Mux — Williamson, P., An update on Low Latency HLS live streaming, 2024. https://www.mux.com/blog/low-latency-hls-part-2 — Tier 3 (first-party engineering from a co-editor of LL-HLS). Source for the HTTP/2-push removal narrative and the preload-hint replacement.
  8. AWS Elemental — Demystifying Apple low-latency HTTP live streaming, AWS Media Blog. https://aws.amazon.com/blogs/media/alhls-apple-low-latency-http-live-streaming-explained/ — Tier 4 (production-deployer engineering blog). Source for the _HLS_msn / _HLS_part long-poll behaviour as it actually deploys behind AWS MediaPackage and CloudFront.
  9. Wowza — Apple Low-Latency HLS: What It Is and How It Relates to CMAF, 2025. https://www.wowza.com/blog/apple-low-latency-hls — Tier 4. Source for the 5–6 s Safari single-client latency measurement and the chunked-transfer wire mechanics.
  10. Dolby OptiView — The Impact of Apple's Update of LL-HLS: Removing HTTP/2 Push Requirements, 2023. https://optiview.dolby.com/resources/blog/streaming/impact-of-apple-ll-hls-update-2020/ — Tier 4. Source for the industry impact of the HTTP/2-push removal and the migration paths CDN vendors took.
  11. Bitmovin — Bitmovin Video Developer Report 2025/26. https://bitmovin.com/video-developer-report/ — Tier 4. Source for the 2025/26 LL-HLS adoption numbers across 167 video developers in 34 countries.
  12. W3C — Media Source Extensions, Candidate Recommendation Snapshot 2024-11-05. https://www.w3.org/TR/media-source-2/ — Tier 1 (W3C spec). Source for the player-side buffering model that LL-HLS parts feed into through SourceBuffer.appendBuffer().