Adaptive Bitrate Streaming: HLS, DASH, and CMAF at CDN Edge

Adaptive bitrate streaming is the foundation of modern video delivery, enabling seamless playback across devices ranging from smartphones on congested cellular networks to 4K displays on fiber connections. Rather than forcing every viewer to download the same quality level, ABR dynamically adjusts video quality in real time based on available bandwidth, buffer health, and device capabilities. For CDN infrastructure, ABR transforms video from a single large file into thousands of small, independently cacheable HTTP objects — a pattern that aligns perfectly with CDN caching strategies designed for static content at scale.

This guide examines the three dominant ABR protocols (HLS, DASH, and CMAF), explains how CDN edge servers handle manifest updates and segment caching, covers bitrate ladder design for optimal quality-per-bit, and addresses the engineering challenges of low-latency live streaming at global scale.

How Adaptive Bitrate Streaming Works

ABR streaming splits video into short segments (typically 2–10 seconds) encoded at multiple quality levels. A manifest file describes the available renditions and provides URLs for each segment. The player downloads the manifest, assesses network conditions, selects an appropriate quality level, and begins downloading segments sequentially. Between each segment download, the player re-evaluates conditions and may switch to a higher or lower quality for the next segment.

The critical insight for CDN engineers is that ABR segments are immutable objects addressed by unique URLs. Once encoded, a segment never changes. This makes them ideal cache candidates with aggressive TTLs — a 6-second HLS segment encoded an hour ago will serve identically to every viewer who requests it. The manifest, however, is mutable (especially for live streams) and requires careful TTL management.

HLS: HTTP Live Streaming

Apple created HLS in 2009, and it remains the most widely supported streaming protocol. HLS uses M3U8 playlist files (plain-text manifests) and supports both MPEG-TS and fragmented MP4 (fMP4) segment containers. A typical HLS delivery consists of a master playlist listing available renditions and individual media playlists for each rendition listing segment URLs.

A master playlist structure looks like this:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360,CODECS="avc1.4d401e,mp4a.40.2"
360p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=15000000,RESOLUTION=3840x2160,CODECS="hvc1.1.6.L150.90,mp4a.40.2"
4k/playlist.m3u8

Each media playlist references individual segments with their duration and sequence number. For VOD content, the playlist is static and fully cacheable. For live streams, the playlist updates every segment duration (typically 6 seconds) as new segments become available and old ones fall off the sliding window. This live playlist update frequency directly impacts CDN caching strategy — a 6-second segment duration means the manifest changes every 6 seconds, requiring TTLs of 2–3 seconds or stale-while-revalidate patterns to balance freshness with origin load.

DASH: Dynamic Adaptive Streaming over HTTP

DASH is an ISO/IEC 23009 standard that uses XML-based Media Presentation Description (MPD) manifests. Unlike HLS, DASH was designed as an open standard from the start and uses fMP4 exclusively. DASH manifests are more expressive than HLS playlists, supporting multiple periods (for ad insertion), content protection signaling, and flexible timeline representations.

DASH introduces two timeline modes that affect CDN caching behavior. In SegmentTemplate mode, segment URLs follow a predictable pattern (e.g., segment_$Number$.m4s), allowing CDN edge servers to predict future segment URLs and even pre-warm caches. In SegmentTimeline mode, each segment has an explicit timestamp, providing frame-accurate seeking but requiring the player to parse the full manifest to construct URLs.

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
     type="dynamic" minimumUpdatePeriod="PT6S"
     availabilityStartTime="2026-10-01T00:00:00Z">
  <Period>
    <AdaptationSet mimeType="video/mp4" segmentAlignment="true">
      <Representation id="720p" bandwidth="2500000"
                      width="1280" height="720"
                      codecs="avc1.4d401f">
        <SegmentTemplate media="720p/seg_$Number$.m4s"
                         initialization="720p/init.mp4"
                         duration="6000" timescale="1000"
                         startNumber="1"/>
      </Representation>
      <Representation id="1080p" bandwidth="5000000"
                      width="1920" height="1080"
                      codecs="avc1.640028">
        <SegmentTemplate media="1080p/seg_$Number$.m4s"
                         initialization="1080p/init.mp4"
                         duration="6000" timescale="1000"
                         startNumber="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

For CDN operators, DASH SegmentTemplate mode is preferable because predictable URLs enable cache pre-warming and simplified cache key design. The manifest TTL challenge is similar to HLS: live MPD documents update at the minimumUpdatePeriod interval and need short TTLs.

CMAF: Unifying HLS and DASH

Common Media Application Format (CMAF) solves the most expensive problem in multi-protocol streaming: duplicate storage and encoding. Before CMAF, supporting both HLS and DASH required encoding every video twice — once in MPEG-TS for HLS and once in fMP4 for DASH. CMAF defines a single fMP4 segment format that both HLS (version 7+) and DASH manifests can reference.

For CDN infrastructure, CMAF halves storage requirements and doubles cache hit ratios. Instead of caching separate HLS and DASH segment copies at each edge PoP, a single CMAF segment serves both protocols. The CDN stores one set of segments and two lightweight manifest files. At a global scale with petabytes of video content, this storage reduction translates directly into lower infrastructure costs and faster cache warming on cold PoPs.

Designing an Effective Bitrate Ladder

A bitrate ladder defines the resolution and bitrate combinations offered to viewers. A poorly designed ladder wastes bandwidth encoding quality levels that look identical, while an aggressive ladder creates visible quality jumps during adaptation. The goal is to provide the smoothest possible quality progression using the fewest renditions that cover the full range of viewing conditions.

Per-title encoding represents the state of the art in bitrate ladder design. Instead of using a fixed ladder for all content, per-title encoding analyzes each video individually. A talking-head lecture might achieve reference quality at 720p with only 1.2 Mbps, while an action scene requires 3.5 Mbps at the same resolution. By customizing the ladder per title, encoding farms reduce total storage and bandwidth by 20–50% while maintaining or improving perceived quality.

CDN Caching Architecture for ABR Streams

ABR video caching at CDN edge follows a two-tier model: segments cache with long TTLs (hours to days for VOD, minutes to hours for live DVR windows), while manifests cache with short TTLs (seconds for live, minutes for VOD).

For live streaming events with millions of concurrent viewers, the origin shield pattern is essential. Without origin shield, a popular live stream broadcast to 200 CDN PoPs generates 200 parallel requests to origin for each new segment — every 6 seconds. With origin shield, a single mid-tier cache layer absorbs the fan-out: one request to origin per segment, then distribution to all edge PoPs from the shield layer. This reduces origin load from segments_per_hour × pop_count to just segments_per_hour. For context on this pattern, see the cache hierarchy guide.

# Nginx configuration for ABR caching at CDN edge
# Segments: long cache, immutable
location ~ \.(ts|m4s|m4v|m4a)$ {
    proxy_pass http://origin;
    proxy_cache video_segments;
    proxy_cache_valid 200 24h;
    proxy_cache_key $uri;
    add_header X-Cache-Status $upstream_cache_status;
    add_header Cache-Control "public, max-age=86400, immutable";
}

# HLS manifests: short cache for live, longer for VOD
location ~ \.m3u8$ {
    proxy_pass http://origin;
    proxy_cache video_manifests;
    proxy_cache_valid 200 2s;    # Live: 2 seconds
    proxy_cache_key $uri;
    proxy_cache_use_stale updating;
    add_header Cache-Control "public, max-age=2, stale-while-revalidate=4";
}

# DASH manifests
location ~ \.mpd$ {
    proxy_pass http://origin;
    proxy_cache video_manifests;
    proxy_cache_valid 200 3s;
    proxy_cache_key $uri;
    proxy_cache_use_stale updating;
    add_header Cache-Control "public, max-age=3, stale-while-revalidate=6";
}

Low-Latency Live Streaming at the Edge

Standard ABR live streaming introduces 15–30 seconds of latency: the encoder buffers 2–3 segments before publishing, CDN propagation adds 1–2 seconds, and the player buffers 2–3 segments before playback begins. Low-latency extensions to HLS and DASH reduce this to 2–5 seconds through three complementary techniques.

First, partial segments (LL-HLS) or chunked transfer encoding (LL-DASH) allow CDN edge servers to begin forwarding segment data before the encoder finishes producing the complete segment. A 6-second segment is divided into parts (typically 200–300 milliseconds each), and each part becomes available immediately. The CDN must support HTTP chunked transfer encoding on both the origin-to-edge and edge-to-client connections.

Second, preload hints (LL-HLS) or availabilityTimeOffset (LL-DASH) tell the player where the next partial segment will be before it exists. The player opens an HTTP connection and waits for the data to arrive, eliminating the round-trip delay of discovering the new segment URL from an updated manifest.

Third, manifest delivery optimization reduces the overhead of frequent playlist updates. LL-HLS uses blocking playlist reload — the player requests the manifest with a query parameter specifying the next expected sequence number, and the CDN holds the connection open until that segment is available. This eliminates polling and reduces manifest requests from multiple per segment to exactly one per segment.

Segment Size and Duration Trade-offs

Segment duration directly impacts three competing concerns: encoding efficiency, switching agility, and startup latency. Longer segments (10 seconds) encode more efficiently because the codec has more frames to work with for inter-frame prediction, but the player must wait for a full segment before it can switch quality levels. Shorter segments (2 seconds) enable faster adaptation but reduce compression efficiency by 5–15% and increase manifest size.

The industry has converged on 6-second segments as the default compromise. At 6 seconds, encoding efficiency loss versus 10-second segments is minimal (under 5%), quality switching happens quickly enough that viewers rarely notice buffering during bandwidth drops, and startup time (one segment download plus buffering) stays under 10 seconds even on moderate connections. For low-latency applications, 2-second segments with partial segment delivery provide sub-3-second glass-to-glass latency.

CDN storage implications scale linearly with segment count. A 2-hour movie at 6-second segments generates 1,200 segments per rendition. With 8 renditions in the bitrate ladder, that is 9,600 individual cached objects per title. At 2-second segments, the same movie generates 28,800 objects. Edge PoP cache management must account for this object density when sizing storage and indexing structures.

Multi-Codec Strategy at the Edge

Modern ABR delivery increasingly requires multi-codec support. H.264/AVC remains the universal baseline (works everywhere), but H.265/HEVC delivers 30–50% bitrate savings at equivalent quality (limited browser support, licensing costs), and AV1 achieves similar savings with royalty-free licensing (growing browser support, high encode cost). VP9 occupies a middle ground with good browser support and moderate savings.

CDN edge servers handle multi-codec through content negotiation. The player advertises supported codecs in the initial manifest request (via the Accept header or a codec-specific URL path), and the CDN serves the appropriate manifest variant. Each codec variant points to its own segment set, so CDN cache storage multiplies with each additional codec — supporting H.264 + HEVC + AV1 triples segment storage compared to H.264 alone. The trade-off is worthwhile: serving AV1 to capable devices reduces bandwidth costs by 30–50% for those viewers, and the savings grow as AV1 device support expands. For details on content negotiation patterns, see content negotiation explained.

Measuring ABR Quality at Scale

Effective ABR monitoring requires metrics beyond simple throughput. Video-specific metrics include average bitrate (the mean quality level served across all viewers), rebuffer rate (percentage of playback time spent buffering), startup time (time from play request to first frame rendered), quality switches per minute, and video start failure rate.

CDN-level metrics that correlate with viewer experience include segment download time (95th percentile should stay under half the segment duration), manifest update latency (time for a new live segment to appear in the manifest at edge), cache hit ratio by segment age (new live segments should hit cache within seconds of production), and origin request rate per concurrent viewer (should approach zero for popular content).

Real User Monitoring (RUM) data from the player provides ground truth. Players report actual experienced quality, rebuffer events, and error rates back to an analytics endpoint. Correlating RUM data with CDN edge metrics identifies whether quality issues originate at the encode pipeline, CDN infrastructure, or last-mile network. For comprehensive monitoring approaches, see the CDN monitoring and observability guide.