HLS (HTTP Live Streaming)

HLS (HTTP Live Streaming) is Apple's adaptive-bitrate streaming protocol. An encoder cuts the media into short segments. A playlist file lists them. This playlist is the HLS form of a manifest. The player fetches the rendition its connection can sustain over ordinary HTTP. It was published in 2017 as RFC 8216. RFC 8216 is an Informational Independent Submission, not an IETF standards-track protocol. It describes version 7 of the format. The living specification is Apple's HTTP Live Streaming 2nd Edition. It circulates as draft-pantos-hls-rfc8216bis. Revision 22 describes protocol version 13. It obsoletes RFC 8216 if approved.

HLS is a packaging and delivery format. It is not a codec, a player, or a DRM system. It carries video you encoded separately. Apple's authoring rules require H.264/AVC, HEVC/H.265, Dolby Vision or AV1. HLS packages this video inside MPEG-2 transport streams or fragmented MP4. Every playlist and every segment is a plain HTTP resource. So no custom server module is needed. Any web server or CDN can deliver it. Its counterpart is MPEG-DASH (ISO/IEC 23009-1). The two index formats are not interchangeable. But packaging as CMAF lets one set of media files serve both. Apple describes this as sharing the same addressable objects, which lets those objects cache efficiently across platforms.

How it works

A presentation is a set of segments plus two levels of index file. All are fetched with ordinary HTTP GET requests.

1. An encoder and segmenter cut the media into segments. Each segment's duration is less than or equal to a constant target duration. The encoder and segmenter then publish a media playlist. This is a UTF-8 text file that begins with #EXTM3U. It is registered as the media type application/vnd.apple.mpegurl (extension .m3u8). It lists each segment URI in play order. A segment URI may optionally be a byte range of a larger resource.
2. Every segment states its own duration in an EXTINF tag. EXT-X-TARGETDURATION declares the maximum for the whole playlist. RFC 8216 warns that longer segments can trigger playback stalls or other errors. Apple's authoring rules allow at most 0.5 seconds of overshoot. Nothing in the protocol skips an oversized segment.
3. One media playlist describes one rendition. The second-level index lists the variants. RFC 8216 calls it the master playlist. The 2nd Edition renamed it the multivariant playlist. Each variant appears in an EXT-X-STREAM-INF tag. Its mandatory BANDWIDTH attribute gives that variant's peak segment bit rate in bits per second.
4. The client loads the multivariant playlist. It picks a variant its connection can sustain. It loads that variant's media playlist. It requests its segments in order. It switches variants as network conditions change.
5. Live is the default state of a playlist. The server must publish a new version with at least one new segment. It must do this no earlier than half a target duration and no later than 1.5 target durations after the previous version. It may remove old segment URIs. Clients must reload the playlist to see them. But clients must not reload faster than once per target duration. After a reload shows no change, clients must not reload faster than once per half target duration.
6. Completion is signalled by tags, not by a different file format. EXT-X-ENDLIST says no more segments will be added. EXT-X-PLAYLIST-TYPE:VOD says the playlist will never change at all. Apple requires this tag for static content.
7. Segments may be encrypted. An EXT-X-KEY tag carries a key URI. This key applies until the next EXT-X-KEY tag with the same key format. So keys can rotate within a playlist. With METHOD=AES-128, the segment is encrypted in full using AES with a 128-bit key, CBC and PKCS7 padding. The key file itself is 16 octets, fetched from that URI.

Low-Latency HLS (LL-HLS) adds a parallel channel at the live edge instead of replacing any of this. The server publishes EXT-X-PART partial segments. Apple's example is a 200-millisecond part against a 6-second segment. Apple recommends a part target of one second. The server advertises the next part with EXT-X-PRELOAD-HINT. A playlist request can carry the _HLS_msn and _HLS_part delivery directives. The server can hold that request until the requested part exists. Apple describes this as eliminating playlist polling. Apple states the mode lowers latency over public networks into the range of standard television broadcasts.

Why it matters for a CDN

RFC 8216 lists among the protocol's goals that it "offers compatibility with large-scale HTTP caching infrastructure to support delivery to large audiences". That property is what made HLS displace streaming-specific protocols: there is nothing to cache except HTTP responses.

• Segments are independent HTTP objects. Their bytes do not change once published. So one copy at the edge serves every viewer of that rendition.
• The media playlist is the one object that keeps changing during a broadcast. It is small. Every player fetches it on a cadence set by the target duration. Its TTL therefore decides how far behind live the audience runs and how much load reaches the origin.
• Object volume is arithmetic on the target duration. At Apple's recommended six seconds, each rendition publishes ten segments a minute. A five-rendition live ladder creates roughly 50 new cacheable objects a minute. Each rendition also gets a rewritten playlist on the same cadence.
• LL-HLS moves requirements into the edge itself. The Low-Latency Server Configuration Profile in the 2nd Edition sets three requirements for caches. Caches must recognise blocking requests whose cache fill is already pending and hold the duplicates (request coalescing). Any HTTP cache in the path must set the Age response header, so a client can tell how stale the playlist it received is. Playlists and segments must be served over HTTP/2 or HTTP/3. A low-latency stream is therefore a CDN capability, not something the packager can deliver on its own.

What CDNs do

Every CDN can serve ordinary HLS, because ordinary HLS is just HTTP. What differs is the handling of the live edge. Each vendor documents its own configuration.

• Cloudflare Stream takes a live input over RTMPS or SRT. It encodes that input at multiple resolutions. It delivers the result to any player that supports HLS or DASH. The broadcaster gets a Stream Key, rather than packaging and origin infrastructure to run.
• Amazon CloudFront in front of AWS Elemental MediaPackage or MediaStore is configured with two cache behaviours per endpoint. One behaviour matches the manifests (*.m3u8). The other matches the segments (*.ts). Each has a minimum TTL of five seconds or less. For LL-HLS, AWS instructs you to add _HLS_msn and _HLS_part to the query strings of the cache key policy used by the manifest behaviour. That is what makes blocking playlist requests work.
• Akamai Adaptive Media Delivery supports LL-HLS from a third-party origin. Set Segmented Media Delivery Mode to Live with ULL streaming on. Enable HLS while disabling HDS, DASH and Smooth. Add _HLS to the cache key parameter list with exact matching off, so every delivery directive is captured. Akamai also has you add the HTTP/2 behaviour and serve over HTTPS. Akamai states that the LL-HLS specification requires HTTP/2. The current profile in the 2nd Edition accepts HTTP/2 or HTTP/3. Akamai notes its own guidance tracks a specification that is still evolving.
• Fastly Streaming Delivery lists HLS and LL-HLS among its supported protocols. It pulls each manifest or segment from origin once, then serves subsequent requests from its POPs. It collapses simultaneous requests for the same uncached object into a single origin fetch. It offers origin shielding, which is not enabled by default.

Watch out for

• Classic live latency is designed in. A client playing normally should not choose a segment that starts less than three target durations from the end of the playlist. So a six-second target puts playback roughly 18 seconds behind the live edge. That holdback is the buffer that protects against rebuffering. So cutting it means adopting the LL-HLS edge requirements, not simply shortening segments.
• Neither cache a live playlist for a long time nor bypass the cache for it. The 2nd Edition profile recommends caching a successful non-blocking playlist response for half the target duration. It recommends six target durations for a successful blocking response and four for a 404. The origin declares the lifetime through Cache-Control.
• AES-128 encryption is not DRM. The key is a bare 16-octet file, fetched from the URI in the playlist, with no licence exchange or device robustness rules. RFC 8216 only says key delivery should be secured by a mechanism such as HTTP over TLS, together with a secure realm or session token. Apple's own answer for content protection is FairPlay Streaming. FairPlay Streaming requires METHOD=SAMPLE-AES and the key format com.apple.streamingkeydelivery.
• Per-viewer segment URLs and cache efficiency pull in opposite directions. Apple's authoring rules say segment URLs should not be completely static. They should be issued per device, or changed over time. That is exactly the shape a shared cache cannot collapse. So any token that varies per viewer has to be kept out of the cache key.
• An inaccurate BANDWIDTH attribute is a real failure mode, not a cosmetic one. RFC 8216 states that it can cause playback stalls, or prevent clients from playing the variant at all. This happens because the client sizes its rendition choice from that number.
• Old clients are a container problem, not a bitrate problem. Fragmented MP4 segments only entered the specification in September 2016. Apple warns that clients based on earlier revisions will likely not handle CMAF content. On Apple's own hardware, the floor is iOS 10.0, macOS 10.12 and tvOS 10.0.

Best practice

• Use Apple's durations: a six-second target duration with nominally six-second segments. This is also the recommended target in the low-latency profile. RFC 8216 calls a ten-second target typical, so expect to meet that older default in existing streams.
• Package as CMAF fragmented MP4. A single set of segments then feeds both HLS and DASH manifests from the same cached objects.
• Give segments a long max-age. Give the live playlist a lifetime matched to the target duration. Keep the _HLS_ delivery directives in the cache key for manifest requests. Both CloudFront and Akamai require exactly that. Let the edge collapse duplicate fetches. Put a shield in front of the packager, rather than exposing it to every POP.
• Deliver playlists, segments and keys over TLS. Apple specifies this as a should for all three. Move to FairPlay Streaming with SAMPLE-AES when the content genuinely needs protection, not obscurity.
• Size LL-HLS to your network, not to a brochure figure. The part target duration must be at least the P95 round-trip time to the server. One second is the recommended value. PART-HOLD-BACK must be at least three times the part target.