Back to Blog
The Architecture of Adaptive Bitrate Streaming: How HLS and MPEG-DASH Function
Dilip NayakMay 13, 202617 min readStreaming Architecture

Public media guide

The Architecture of Adaptive Bitrate Streaming: How HLS and MPEG-DASH Function

Deep dive into adaptive bitrate streaming protocols: HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (MPEG-DASH). Master manifest files, chunked delivery, CMAF, and CDN caching.

In the early days of web video, media delivery relied on stateful protocols like RTMP (Real-Time Messaging Protocol) or simple progressive HTTP downloads. Both architectures suffered catastrophic scalability limitations: RTMP required specialized media servers that broke through enterprise firewalls, while progressive downloads forced users to buffer entire files regardless of network volatility.

The modern streaming revolution was unlocked by Adaptive Bitrate (ABR) streaming over standard stateless HTTP infrastructure. Today, Apple HTTP Live Streaming (HLS) and the international ISO standard MPEG-DASH (Dynamic Adaptive Streaming over HTTP) power global services including Netflix, Disney+, YouTube, and live sports broadcasts.

ABR protocols break continuous video streams into small, indexed segments (typically 2 to 6 seconds in duration), pre-encoded across a ladder of varying resolutions and bitrates.

This architectural analysis dissects how playlist manifests coordinate playback, how client heuristics switch rungs dynamically, and how Common Media Application Format (CMAF) achieves sub-second broadcast latency.

1. The Master Manifest & Media Playlists

When a video player requests a stream, it first downloads a Master Manifest. This document lists all available rendition streams, including bandwidth requirements, codecs, resolutions, and alternative audio/subtitle tracks.

  • HLS Master Manifest (.m3u8): Uses tags like #EXT-X-STREAM-INF to declare bandwidth rungs pointing to child playlists.
  • Child Media Playlist: Lists sequence segments (.ts or .m4s) with duration tags (#EXTINF) for the player to fetch sequentially.
  • MPEG-DASH MPD: Uses hierarchical XML structure with Periods, AdaptationSets (video, audio, text), and Representations (different bitrates).

2. Client-Side ABR Decision Heuristics

The media player, not the server, decides which quality tier to download next. Player algorithms evaluate several real-time network variables before requesting each segment.

  • Throughput Rule: Measures download duration of the preceding segment to calculate immediate connection speed.
  • Buffer Occupancy Rule: Monitors forward buffer health (in seconds). If the buffer drops below a safe threshold, the player steps down to avoid a playback freeze.
  • Hybrid BBA (Buffer-Based Adaptation): Modern players (like Shaka Player and Hls.js) combine buffer velocity and throughput moving averages for smooth, tear-free switching.

3. CMAF and Low-Latency Chunked Streaming

Historically, HLS relied on MPEG-2 Transport Streams (.ts) while DASH utilized fragmented MP4 (.m4s), forcing publishers to transcode and store duplicate libraries. In 2017, Apple and Microsoft standardized the Common Media Application Format (CMAF / ISO/IEC 23000-19).

  • Unified Storage: A single set of fMP4 media segments can be referenced by both HLS (.m3u8) and DASH (.mpd) manifests.
  • Chunked Transfer Encoding: Segments are subdivided into sub-second chunks, allowing players to start decoding a segment while the encoder is still writing the remaining frames.

Format & Use Table

Protocol / FormatDeveloping BodyManifest FormatSegment FormatEcosystem Support
HLS (HTTP Live Streaming)Apple.m3u8 (Extended M3U text)fMP4 (.m4s) or MPEG-TS (.ts)Universal (Mandatory on iOS/macOS)
MPEG-DASHISO/IEC MPEG.mpd (XML Schema)fMP4 (.m4s)Android, Smart TVs, Web Browsers
CMAF (Common Media App Format)ISO/IEC 23000-19Dual (.m3u8 + .mpd)Fragmented MP4 (fMP4)All modern player engines
Low-Latency HLS (LL-HLS)Apple.m3u8 (Part tags)Chunked fMP4Modern Apple devices + Hls.js

Step-by-Step Workflow

01

Generate multi-bitrate HLS ladder with FFmpeg: ffmpeg -i input.mov -filter_complex "[0:v]split=3[v1][v2][v3]; [v1]scale=w=1920:h=1080[v1out]; [v2]scale=w=1280:h=720[v2out]; [v3]scale=w=854:h=480[v3out]" -map "[v1out]" -c:v:0 libx264 -b:v:0 5000k -maxrate:v:0 5350k -bufsize:v:0 7500k -map "[v2out]" -c:v:1 libx264 -b:v:1 2800k -maxrate:v:1 2996k -bufsize:v:1 4200k -map "[v3out]" -c:v:2 libx264 -b:v:2 1400k -maxrate:v:2 1498k -bufsize:v:2 2100k -map a:0 -c:a aac -b:a 128k -f hls -hls_time 4 -hls_playlist_type vod -master_pl_name master.m3u8 -var_stream_map "v:0,a:0 v:1,a:0 v:2,a:0" stream_%v.m3u8

02

Verify segment duration consistency across all streams.

03

Configure CDN edge caching headers for manifests (Cache-Control: max-age=2) vs media segments (Cache-Control: max-age=31536000, immutable).

Frequently Asked Questions

Why should HLS media segments be cached indefinitely on CDNs?

Video segments (.m4s or .ts) are static, immutable media files. Once written, their byte contents never change. Caching them for 1 year at the CDN edge offloads traffic completely from origin servers.

Can modern browsers play HLS natively without JavaScript?

Safari (on iOS and macOS) supports native HLS in the HTML5 <video> element. Google Chrome, Firefox, and Edge require lightweight JavaScript MSE libraries such as Hls.js to unpack and render HLS streams.

#streaming protocols#HLS#MPEG-DASH#CMAF#adaptive bitrate#CDN caching#video infrastructure