HLS, DASH, and Modern CDN Video Delivery: A Technical Guide

Delivering video at scale over the internet requires solving three distinct problems: how to chop a continuous video stream into files the HTTP infrastructure can cache; how to let clients adapt to changing network conditions automatically; and how to distribute those files cheaply and reliably to millions of simultaneous viewers. HLS and DASH solve the first two. CDNs solve the third. Media over QUIC is starting to rethink all three.

This guide covers each layer from the ground up, including the exact structure of manifest and segment files, so you understand not just what to configure but why.

---

HTTP Adaptive Bitrate: The Core Idea

Traditional streaming protocols (RTMP, UDP multicast) send one fixed-quality stream to every viewer and require the transport to keep up. If the viewer’s connection degrades, the experience breaks.

Adaptive Bitrate Streaming (ABR) inverts this. Instead of one stream, you create several versions of the content at different bitrates and resolutions — an “ABR ladder.” The content is cut into short segments (typically 2–10 seconds each). The player downloads segments one at a time over plain HTTP, measures how fast each segment downloads, and automatically switches to a higher or lower quality rendition based on current throughput.

Because each segment is a standalone file downloadable over HTTP, the entire caching infrastructure of the web — CDNs, reverse proxies, browser caches — works for video without modification.

HLS and DASH are the two dominant ABR formats. They share the same fundamental concept but differ in manifest format, segmentation options, and ecosystem support.

---

HLS: HTTP Live Streaming

Origins

HLS was developed by Apple and introduced with the iPhone OS 3.0 in 2009. Apple required it for video playback in Safari on iPhone, which meant any broadcaster targeting iOS had to support HLS. That mandate drove universal adoption. HLS is now supported on essentially every platform: iOS, Android, smart TVs, desktop browsers, and set-top boxes.

In 2022, HLS was published as an IETF standard: RFC 8216, with the updated LL-HLS spec in a subsequent draft.

---

The HLS Manifest File in Detail

HLS uses plain-text M3U8 playlist files (UTF-8 encoded M3U format). There are two types, and understanding both is essential.

Master Playlist (Multivariant Playlist)

The master playlist is the entry point — the URL you give to a player. It describes all available renditions: video at different bitrates/resolutions, audio tracks, subtitle tracks, and closed caption streams. The player downloads this file once and uses it to decide which media playlist to load.

A real-world master playlist looks like this:

#EXTM3U
#EXT-X-VERSION:6

## === VIDEO RENDITIONS ===

#EXT-X-STREAM-INF:BANDWIDTH=400000,AVERAGE-BANDWIDTH=320000,
  RESOLUTION=416x234,FRAME-RATE=29.970,CODECS="avc1.42c01e,mp4a.40.2",
  AUDIO="audio-group",CLOSED-CAPTIONS=NONE
renditions/416x234_400k.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=800000,AVERAGE-BANDWIDTH=700000,
  RESOLUTION=640x360,FRAME-RATE=29.970,CODECS="avc1.42c01f,mp4a.40.2",
  AUDIO="audio-group",CLOSED-CAPTIONS=NONE
renditions/640x360_800k.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=1400000,AVERAGE-BANDWIDTH=1200000,
  RESOLUTION=854x480,FRAME-RATE=29.970,CODECS="avc1.4d401f,mp4a.40.2",
  AUDIO="audio-group",CLOSED-CAPTIONS=NONE
renditions/854x480_1400k.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2800000,AVERAGE-BANDWIDTH=2400000,
  RESOLUTION=1280x720,FRAME-RATE=59.940,CODECS="avc1.4d401f,mp4a.40.2",
  AUDIO="audio-group",CLOSED-CAPTIONS=NONE
renditions/1280x720_2800k.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=5000000,AVERAGE-BANDWIDTH=4500000,
  RESOLUTION=1920x1080,FRAME-RATE=59.940,CODECS="avc1.640028,mp4a.40.2",
  AUDIO="audio-group",CLOSED-CAPTIONS=NONE
renditions/1920x1080_5000k.m3u8

## === AUDIO-ONLY RENDITION (for poor connections) ===

#EXT-X-STREAM-INF:BANDWIDTH=64000,CODECS="mp4a.40.2",AUDIO="audio-group"
renditions/audio_only.m3u8

## === SEPARATE AUDIO TRACKS ===

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-group",NAME="English",
  DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="audio/english.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-group",NAME="Spanish",
  DEFAULT=NO,AUTOSELECT=YES,LANGUAGE="es",URI="audio/spanish.m3u8"

## === SUBTITLES ===

#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English",
  DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="en",URI="subs/en.m3u8"

Key fields to understand:

• BANDWIDTH: Peak bitrate in bits/second. The player uses this to select a rendition that fits current throughput — it will not select a rendition whose BANDWIDTH exceeds its estimated download speed.
• AVERAGE-BANDWIDTH: Average bitrate, used for more accurate buffer modeling.
• RESOLUTION: Pixel dimensions. Some devices use this for display-size matching.
• FRAME-RATE: Declared frame rate — important for devices that need to switch HDMI output refresh rates. Use NTSC rates for US content: 29.970 (SD/most content), 59.940 (high-frame-rate live/sports), 23.976 (cinema). European/PAL content uses 25 and 50 instead.
• CODECS: RFC 6381 codec strings. avc1.640028 means H.264 High Profile level 4.0. mp4a.40.2 means AAC-LC. Players use this to determine hardware decoder compatibility before attempting playback.
• AUDIO group reference: separates audio into its own playlist, allowing independent audio track selection and muxed or demuxed delivery.

Media Playlist

Each rendition has its own media playlist — the sequence of segments that make up the stream. For live content this file updates continuously; for VOD it is written once and never changes.

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:8412
#EXT-X-DISCONTINUITY-SEQUENCE:0

#EXT-X-KEY:METHOD=AES-128,
  URI="https://keys.example.com/key?keyid=k1042",
  IV=0x00000000000000000000000020EC

#EXTINF:6.006,
segments/seg8412.fmp4
#EXTINF:6.006,
segments/seg8413.fmp4
#EXTINF:6.006,
segments/seg8414.fmp4
#EXTINF:5.988,
segments/seg8415.fmp4

Key fields:

• #EXT-X-TARGETDURATION: Maximum segment duration in seconds. Players set their buffer reload timer relative to this. A CDN’s cache TTL for the playlist itself is typically set to TARGETDURATION / 2 to ensure clients get updates.
• #EXT-X-MEDIA-SEQUENCE: The sequence number of the first segment in the list. For live streams this increments as old segments are removed. Players use this to detect gaps if they fall behind.
• #EXTINF: Duration of the next segment in seconds (with millisecond precision). The sum of EXTINF durations across all segments equals total content duration for VOD.
• #EXT-X-KEY: Encryption parameters. AES-128 encrypts each segment with a 16-byte key fetched from the URI. The IV (Initialization Vector) prevents the same key from producing identical ciphertext across segments.
• #EXT-X-ENDLIST: Appears at the end of a VOD playlist or when a live stream ends. Its absence tells the player to reload the playlist periodically.

---

HLS Segment Format

HLS originally used MPEG-2 Transport Stream (.ts) segments — the same container format used in broadcast DVB. A .ts segment contains multiplexed PES (Packetized Elementary Stream) packets for video and audio, all wrapped in 188-byte fixed-length transport stream packets.

Modern HLS (version 7+) supports fragmented MP4 (fmp4) segments — the same container format used by DASH. fmp4 segments consist of:

• ftyp box: File type declaration (appears at the start of initialization segments)
• moov box: Movie header — decoder initialization parameters (codec, dimensions, timescale). For HLS fmp4 this is sent separately as an initialization segment referenced by #EXT-X-MAP.
• moof box: Movie fragment header — timing, sequence number, and per-sample metadata
• mdat box: Actual encoded video/audio data

A CMAF (Common Media Application Format, ISO 23000-19) stream uses fmp4 with specific constraints that allow the same segments to be delivered via both HLS and DASH playlists — eliminating the need to store two copies of every segment.

Segment size tradeoffs:

Segment duration	Latency impact	CDN efficiency	ABR switching speed
2s	Lower latency	More requests, smaller files	Faster adaptation
4-6s	Moderate	Good balance	Good
10s	Higher latency	Fewer requests, better cache hit ratio	Slower adaptation

---

Low-Latency HLS (LL-HLS)

Standard HLS has inherent latency: 2-4 segment durations (10-40s) from encoder to viewer. LL-HLS (introduced by Apple in 2019) reduces this to 1-3 seconds by:

1. Partial segments: Each full segment is divided into smaller “parts” (typically 200-300ms). The media playlist advertises parts as they complete, so the player can start downloading the next segment before it’s fully complete.
2. Playlist delta updates: The server returns only the changes since the last playlist request, reducing playlist transfer size.
3. Blocking playlist requests: The player makes a request that blocks at the server until a new segment part is available (“server-sent update”), eliminating constant polling.

LL-HLS is supported in HLS.js, Video.js, Shaka Player, and natively in Safari. CDNs that support LL-HLS (Cloudflare, Fastly, AWS CloudFront) maintain server-side connections with the origin packager to enable the blocking request model.

---

DASH: Dynamic Adaptive Streaming over HTTP

Origins

DASH (MPEG-DASH, ISO/IEC 23009-1) is the MPEG standard for adaptive HTTP streaming, published in 2012. It is a genuinely vendor-neutral standard developed by committee, as opposed to HLS which remains Apple-controlled (though standardized via IETF). DASH is mandatory for MPEG-CENC DRM interoperability and is widely used in broadcast OTT (the European Broadcasting Union and major TV standards bodies favor DASH), YouTube, and many SVOD services.

DASH does not work natively in iOS Safari (Apple blocks it to protect HLS), which is why most deployments today serve DASH to Android/smart TV/desktop browsers and HLS to iOS. CMAF packaging lets you serve both from one set of media segments.

The MPD File

DASH’s equivalent of the HLS master playlist is the MPD (Media Presentation Description) — an XML document. It is more verbose but also more expressive.

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
     profiles="urn:mpeg:dash:profile:isoff-live:2011"
     type="dynamic"
     availabilityStartTime="2026-06-14T20:00:00Z"
     minimumUpdatePeriod="PT4S"
     minBufferTime="PT2S"
     timeShiftBufferDepth="PT30S">

  <Period id="1" start="PT0S">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.640028"
                   frameRate="30000/1001" startWithSAP="1" segmentAlignment="true">

      <SegmentTemplate timescale="90000"
                       media="video/$RepresentationID$/seg-$Number$.m4s"
                       initialization="video/$RepresentationID$/init.mp4"
                       startNumber="1">
        <SegmentTimeline>
          <S t="0" d="540540" r="99"/>
        </SegmentTimeline>
      </SegmentTemplate>

      <Representation id="1080p" bandwidth="5000000"
                      width="1920" height="1080"/>
      <Representation id="720p"  bandwidth="2800000"
                      width="1280" height="720"/>
      <Representation id="480p"  bandwidth="1400000"
                      width="854"  height="480"/>
      <Representation id="360p"  bandwidth="800000"
                      width="640"  height="360"/>
    </AdaptationSet>

    <AdaptationSet mimeType="audio/mp4" codecs="mp4a.40.2" lang="en">
      <SegmentTemplate timescale="44100"
                       media="audio/en/seg-$Number$.m4s"
                       initialization="audio/en/init.mp4"
                       startNumber="1">
        <SegmentTimeline>
          <S t="0" d="176400" r="99"/>
        </SegmentTimeline>
      </SegmentTemplate>
      <Representation id="audio-en-128k" bandwidth="128000"/>
    </AdaptationSet>
  </Period>
</MPD>

Key concepts:

• AdaptationSet: A group of interchangeable content — all video renditions of the same content, or all audio tracks. Players switch between Representations within an AdaptationSet based on bandwidth.
• Representation: One specific quality level — a single bitrate/resolution pair.
• SegmentTemplate: URL pattern for generating segment URLs, avoiding the need to list every segment URL explicitly (unlike HLS which lists them in the playlist).
• SegmentTimeline: Maps segment sequence numbers to timestamps. The d attribute is duration in timescale units. t="0" d="540540" r="99" means 100 segments (1 base + 99 repeats), each 540540/90000 = 6.006 seconds. The 6.006s duration is not arbitrary — it is the canonical NTSC segment boundary: 180 frames at 29.97fps (30000/1001) = 180 × 1001/30000 = 6.006s exactly. This is why the frameRate="30000/1001" attribute and the d="540540" timescale math are coupled.
• type="dynamic": Live content. The MPD updates and the client polls it. type="static" is used for VOD.
• timeShiftBufferDepth: How far back in a live stream the player can seek (DVR window).

---

Packaging: Push vs. Just-in-Time

Push Packaging

In push packaging (also called origin packaging or static packaging), segments and manifests are generated and written to storage as the live encoder or transcoder produces them. An origin packager (Elemental, Harmonic Electra, Wowza, ffmpeg with hlsenc) receives the encoded bitstreams and continuously writes:

/streams/live/master.m3u8          ← updated every few seconds
/streams/live/1080p/manifest.m3u8  ← updated every few seconds
/streams/live/1080p/seg8412.ts     ← written once, immutable
/streams/live/1080p/seg8413.ts
...

The CDN is configured to point at this origin. When a client requests a segment URL, the CDN fetches it from origin (on cache miss) and caches it. Manifests have short TTLs (usually TARGETDURATION / 2); segments have long TTLs (often hours or days) because once written they never change.

Strengths of push packaging:

• Simple CDN configuration — CDN just caches flat files
• Segments are available immediately on CDN after first request
• Works with any CDN without special packager integration
• Easy to write segments to durable storage (S3, GCS) simultaneously

Weaknesses:

• Must store and manage all segment files (or implement segment deletion for live)
• DRM license key management must be built into the packager
• Format changes (adding DASH, changing bitrate ladder) require re-packaging

Just-in-Time (JIT) Packaging

In JIT packaging, the origin server stores a single mezzanine copy of the content (typically in a high-quality intermediate format or as broadcast-quality TS chunks) and generates HLS/DASH segments and manifests dynamically at request time. JIT packagers sit between storage and the CDN.

CDN request: /streams/vod/movie.m3u8
    → JIT packager reads mezzanine, generates master.m3u8 on the fly

CDN request: /streams/vod/1080p/seg_00042.ts
    → JIT packager reads appropriate bytes from mezzanine, packages and returns segment

AWS Elemental MediaTailor, Unified Streaming (USP), and Wowza Streaming Engine all support JIT packaging. Cloud-native JIT solutions are common for SVOD services.

Strengths of JIT packaging:

• Store content once, serve in any format (HLS, DASH, fmp4, legacy .ts)
• Easy to update the ABR ladder without re-storing content
• DRM key insertion and token-based authentication can be applied uniformly at packaging time
• Dynamic ad insertion (SSAI) can be applied per-viewer at the JIT layer
• No segment file management — storage holds only the mezzanine

Weaknesses:

• JIT packager becomes a compute bottleneck under sudden traffic spikes; needs autoscaling
• Cache warm-up: first viewer of a segment pays the packaging cost plus CDN miss penalty
• More complex architecture — JIT tier must be horizontally scalable
• For very large VOD catalogs, packaging latency on cache miss can affect startup time

Most large SVOD platforms (Netflix, Disney+, Hulu) use JIT packaging combined with pre-warming popular content.

---

CDN Architecture for Video Delivery

A CDN (Content Delivery Network) is a geographically distributed network of cache servers (Points of Presence, or PoPs) that serve content from a location closer to the viewer than the origin server. For HLS/DASH, this means segment and manifest files are cached at PoPs around the world.

How CDN Caching Works for HLS/DASH

1. A viewer in Tokyo requests seg8412.ts from the CDN
2. The CDN routes the request to the nearest Tokyo PoP
3. If the PoP has the segment cached (cache hit): returns it immediately, typically <20ms
4. If not cached (cache miss): the PoP fetches from origin, caches it, returns it to viewer
5. All subsequent requests for seg8412.ts from that PoP are served from cache

Cache hit rate is the critical CDN performance metric for video. A good live stream might achieve 90-98% cache hit rate on segments (since many viewers are watching simultaneously and requesting the same segments). Manifests have lower hit rates because they expire frequently.

Manifest TTL strategy for live HLS:

Segments:          Cache-Control: max-age=3600 (or more) — immutable once written
Media playlists:   Cache-Control: max-age=3, s-maxage=3  — must update frequently
Master playlist:   Cache-Control: max-age=30             — rarely changes

AWS CloudFront

AWS CloudFront is Amazon’s global CDN, deeply integrated with the AWS ecosystem. It is the natural choice when your origin infrastructure runs on AWS (Elemental MediaPackage, MediaStore, S3).

Architecture for live streaming:

Live encoder → MediaConnect (RIST/SRT) → MediaLive (transcode ABR ladder)
    → MediaPackage (HLS/DASH packaging + DVR) → CloudFront → viewers

Key CloudFront features for video:

• Origin Shield: An additional intermediate caching layer that consolidates CloudFront edge requests to origin, dramatically reducing origin load — critical during high-traffic live events where thousands of PoP cache misses might otherwise simultaneously hit the packager
• Real-Time Logs: Per-request delivery metrics streamed to Kinesis
• CloudFront Functions / Lambda@Edge: For token authentication, manifest rewriting, or dynamic URL signing at the edge
• Signed URLs and Signed Cookies: Standard mechanism for protecting content — the CDN validates a cryptographic signature on each request
• LL-HLS support: CloudFront supports LL-HLS chunked transfer for low-latency delivery

Pricing: regional data transfer rates typically $0.0085–$0.085/GB depending on region and volume tier. For large-scale delivery, negotiated committed use pricing applies.

Akamai

Akamai operates the largest CDN by PoP count and is the dominant provider for large broadcasters, sports rights holders, and enterprises with extremely high peak traffic requirements. Major live sports events (Super Bowl, Olympics) often run on Akamai.

Key Akamai features for video:

• Adaptive Media Delivery (AMD): Akamai’s optimized product for HLS/DASH delivery — includes manifest rewriting, token authentication, and ABR-aware caching behaviors
• Stream Packaging: Akamai can perform JIT packaging at the edge (just-in-time at the CDN layer, not just at origin)
• Surge Queue: Traffic shaping during sudden audience spikes — important for live events with unpredictable viewership peaks
• NetStorage: Akamai’s origin storage, tightly integrated with CDN delivery
• mPulse: Real user monitoring for measuring video Quality of Experience (QoE) — buffering ratio, startup time, bitrate switches

Akamai is more expensive than CloudFront or Cloudflare but offers enterprise SLAs and dedicated delivery engineering support.

Cloudflare

Cloudflare has rapidly expanded into video delivery and is now competitive for medium-to-large deployments. Its edge network spans 300+ cities.

Key Cloudflare features for video:

• Cloudflare Stream: Fully managed video platform — upload, transcode, and deliver with one API
• Cache Rules: Granular control over TTL and bypass conditions for manifests vs. segments
• Workers: JavaScript at the edge for manifest manipulation, token auth, or request routing without Lambda@Edge complexity
• R2 Storage: S3-compatible storage with zero egress fees to the Cloudflare network (egress from S3/GCS to CDN is a major cost at scale — Cloudflare’s R2 eliminates it)
• Argo Smart Routing: Routes requests over Cloudflare’s private backbone rather than the public internet for lower latency to origin
• LL-HLS support: Cloudflare supports LL-HLS via Transfer-Encoding: chunked delivery

Cloudflare is often significantly cheaper than Akamai for similar volume, though lacks the deep broadcast-specific tooling.

Fastly

Fastly is a CDN with a strong engineering culture, best known for its real-time purging capability and VCL (Varnish Configuration Language) programmability.

Key Fastly features for video:

• Instant Purge: Fastly can invalidate cached content globally in ~150ms — critical for live manifest updates or emergency content replacement
• Streaming Miss: Fastly can begin serving an origin response to the viewer before it is fully cached, reducing time-to-first-byte on cache misses (important for large segment files)
• Compute@Edge: WebAssembly-based edge computing for custom logic — more powerful than Workers for complex manifest manipulation
• Real-Time Log Streaming: Sub-second delivery of request logs to external analytics systems
• LL-HLS: Fastly has strong LL-HLS support with their streaming miss + partial caching behavior aligning well with partial segment delivery

Fastly is often the CDN of choice for media companies that need fine-grained cache control and fast purging during live events.

---

Media over QUIC (MoQ): The Emerging Layer

What’s Wrong With HLS/DASH for Live Streaming

HLS and DASH were designed around HTTP/1.1 pull semantics: the player polls the manifest, sees new segments, and fetches them. This works well for 6-second segments. It becomes inefficient for sub-second latency because:

• Each segment request is a new HTTP transaction (or reuse of a connection, but with its own overhead)
• Manifest polling is a polling loop, not a push
• The “blocking playlist request” trick in LL-HLS is a workaround, not a clean design
• HTTP/2 server push was attempted but not widely deployed for video
• Latency below ~1 second is very hard to achieve reliably over HTTP ABR

QUIC and HTTP/3

QUIC (RFC 9000) is a new transport protocol built on UDP that replaces TCP for HTTP/3. It solves several TCP problems relevant to video:

• No head-of-line blocking: In HTTP/2 over TCP, one lost packet blocks all multiplexed streams. QUIC multiplexes streams independently — a lost packet only blocks the one stream it belongs to.
• 0-RTT reconnection: QUIC sessions can be re-established in 0 round trips (using cached session state), reducing latency after network changes (e.g., Wi-Fi to cellular handoff).
• Connection migration: QUIC connections survive IP address changes, so a mobile device can move between networks without breaking the connection.
• Built-in encryption: QUIC mandates TLS 1.3.

Media over QUIC Transport (MoQT)

MoQ Transport (MoQT) is an IETF working group protocol (draft-ietf-moq-transport) that defines a new streaming model built directly on QUIC. Instead of HTTP request/response semantics, MoQ defines a publish-subscribe model:

• Publishers (encoders, packagers) send media objects to a relay
• Subscribers (players) express interest in a namespace (e.g., a specific live stream) and receive objects pushed from the relay
• Relays form a distribution tree, similar in topology to a CDN but with native real-time semantics

MoQ Objects and Tracks:

• A Track is a named sequence of objects (analogous to a video rendition or audio track)
• An Object is a media unit — a video GOP, an audio chunk, or a metadata frame
• Objects have a priority so the publisher can signal that the latest keyframe should arrive before older P-frames
• Objects can be delivered in delivery order (arrival order) or subscriber order (inferred by the player) — enabling the player to drop late frames rather than waiting for retransmit

Why MoQ matters:

• Native sub-second latency: objects are pushed as soon as they’re available, no polling
• Congestion-aware: QUIC’s native congestion control operates per stream; the encoder can adjust bitrate in real time
• No segment boundary concept: video is delivered as objects with fine-grained timestamps
• CDN-like relay topology without the HTTP caching assumptions
• Works naturally with CMAF chunks or raw NAL units

Current state (2024-2026): MoQ Transport is still in IETF draft. Meta (Facebook Live), Akamai, Fastly, and Cisco are among the active contributors. Early implementations exist, but production deployments are limited. The expected path is: MoQT stabilizes → CDNs implement relay support → players add MoQ SDKs → OTT platforms use MoQ for ultra-low-latency live events where HLS/DASH latency is too high.

---

Putting It All Together: Choosing Your Stack

Use case	Recommended stack
Live event, <10s latency acceptable	HLS (6s segments) + CloudFront or Cloudflare
Live event, 2-4s latency required	LL-HLS + Fastly or Cloudflare (LL-HLS support)
Live event, <1s latency, pilot/experimental	MoQT (not yet production-ready at scale)
SVOD, large catalog	CMAF segments + JIT packager (MediaPackage or Unified Streaming) + CloudFront
SVOD, small/mid catalog	Push packaging to S3 + CloudFront
Broadcast-quality OTT, enterprise SLA	HLS/DASH + Akamai AMD
High-traffic live sports spike event	Akamai (Surge Queue) or multi-CDN
Cost-sensitive medium scale	Cloudflare Stream or Cloudflare CDN + R2
iOS + Android universal	CMAF (serves both HLS and DASH playlists from shared segments)

The Typical Live Streaming Architecture

Encoder (H.264/HEVC) → RTMP or SRT contribution
    → Transcoder (ABR ladder: 1080p/5M, 720p/2.8M, 480p/1.4M, 360p/800k, 234p/400k)
    → Packager (HLS + DASH, push or JIT) → Origin storage
    → CDN (CloudFront / Akamai / Cloudflare / Fastly)
        → Edge PoP (cache segments, refresh manifests)
            → Player (HLS.js, Shaka Player, Video.js, native browser)
                → Adaptive bitrate selection → viewer

---

Further Reading

• RFC 8216 — HTTP Live Streaming — IETF HLS specification (Apple’s formal submission)
• IETF LL-HLS Draft — Low-Latency HLS extensions specification
• MPEG-DASH ISO/IEC 23009-1 — MPEG-DASH standard (paid)
• IETF MoQ Transport Draft — Media over QUIC Transport specification in progress
• CMAF ISO 23000-19 — Common Media Application Format (shared HLS/DASH segments)
• Apple HLS Authoring Specification — Apple’s official ABR ladder and codec requirements for HLS delivery to Apple devices
• AWS MediaPackage Documentation — AWS managed packaging service documentation