How HLS Powers Adaptive Streaming on Hulu & Disney+: A Deep Dive

Adaptive streaming is widely used on Hulu and Disney+ platforms, where video is encoded into multiple bitrate versions and split into independently decodable segments, allowing bitrate switches per segment during playback.

This approach differs from traditional single‑file streaming; the player must know all available streams and where to download each segment, which is described by a unified adaptive streaming protocol.

The most popular protocols are MPEG‑DASH and Apple’s HLS; this article focuses on HLS.

What is HLS?

HLS (HTTP Live Streaming) is Apple’s HTTP‑based streaming protocol that supports both video‑on‑demand (VoD) and live streams. It works with standard web servers and CDNs, and can be played directly in Safari using the <video> tag.

The HLS specification (RFC 8216) was published in August 2017 (version 7) and is being updated to a second edition, which added low‑latency HLS in April 2020.

Basic HLS Architecture

A client first requests a media description file (playlist) that lists all available media. After parsing the playlist, the client selects a suitable variant based on user preferences and adaptive bitrate algorithms, then downloads the referenced segments until playback finishes.

Media Types and Renditions

HLS defines four media types: VIDEO, AUDIO, SUBTITLES, and CLOSED‑CAPTIONS. Each stream of the same content is called a rendition . Renditions with the same rendition group are interchangeable (e.g., different audio languages or video angles). A variant is formed by combining one rendition from each media type; the player can switch between variants adaptively.

Playlists

There are two playlist types:

Media playlist : describes a single rendition and lists URIs of its segments.

Multivariant playlist (formerly master playlist): describes all variants and rendition groups, referencing media playlists.

Playlists are plain‑text files with .m3u8 or .m3u extensions. Each line is either a comment, a URI, or a tag starting with #. Tags beginning with #EXT define playlist information; other lines starting with # are comments.

Key HLS Tags

#EXTM3U

: must be the first line of every playlist. #EXT-X-VERSION: minimum HLS version required. #EXTINF: duration of the following segment. #EXT-X-BYTERANGE: byte range of a segment within an fMP4 file. #EXT-X-KEY: decryption method for subsequent segments. #EXT-X-TARGETDURATION: maximum segment duration. #EXT-X-MEDIA-SEQUENCE: starting sequence number of segments. #EXT-X-PLAYLIST-TYPE: VOD, EVENT, or none (sliding window). #EXT-X-DISCONTINUITY: marks a break between non‑continuous segments. #EXT-X-DISCONTINUITY-SEQUENCE: starting number for discontinuity segments. #EXT-X-MEDIA: defines a rendition group (type, group‑id, name, language, etc.). #EXT-X-STREAM-INF: defines a variant (bandwidth, codecs, resolution, etc.) and points to a video rendition. #EXT-X-PROGRAM-DATE-TIME: timestamp for the first frame of the following segment, used for timeline synchronization.

Server and Client Responsibilities

In VoD, the server prepares all media and playlists; the client downloads the multivariant playlist, selects a variant, parses the corresponding media playlist, and sequentially downloads and plays segments, refreshing playlists if a variant switch occurs.

In live streaming, the server continuously adds new segments to media playlists (according to #EXT-X-PLAYLIST-TYPE) and may remove old segments using a sliding window. The client must periodically refresh the media playlist; if no update occurs within 1.5 × target duration, the client may consider the server faulty.

Timeline Synchronization

All renditions in an HLS stream share a common time base. Synchronization is achieved using #EXT-X-PROGRAM-DATE-TIME timestamps and matching discontinuity segment numbers across renditions. Segment sequence numbers are not used for synchronization because they may differ between renditions.

When multiple discontinuity segments exist, each should contain at least one timestamp tag to maintain a consistent timeline.

Conclusion

This article introduced the HLS adaptive streaming protocol, explained how its media description files organize all media content, and described client‑server interactions for both on‑demand and live scenarios. Future articles will cover the DASH protocol and compare the two.