Open Calculator

Video Streaming Infrastructure Economics: HLS/DASH Bitrate Ladders, Segment Sizing, and CDN Offload

Published June 04, 2026 · Media Packaging & CDN Delivery Specification

Video-on-Demand (VOD) and live streaming workloads are the most bandwidth-intensive applications on the public internet. Because video players dynamically switch resolutions using HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (MPEG-DASH), a single uploaded master video must be transcoded into 4 to 6 rendition rungs (an Adaptive Bitrate Ladder), multiplying both origin storage consumption and API request volume.

This engineering reference provides deterministic formulas for converting encoding bitrates (`Mbps`) into monthly gigabyte egress, optimizing segment duration (`2s` vs. `6s`) to prevent Class A/B API bill shock, and consolidating HLS/DASH containers using **CMAF (`fMP4`)**.

Adaptive Bitrate (ABR) Ladder & Bandwidth Conversion Matrix

Network bitrates are measured in **megabits per second (`Mbps`)**, whereas cloud storage and CDN egress are billed in **gigabytes (`GB`)**. Since $1\text{ Byte} = 8\text{ bits}$ and $1\text{ hour} = 3,600\text{ seconds}$, the deterministic conversion formula per viewer-hour is:

// Bitrate (Mbps) to Gigabyte Egress Conversion Equation
GB_per_Viewer_Hour = ((Video_Mbps + Audio_Mbps) × 3,600 seconds) / 8,000 = Combined_Mbps × 0.45
// Total Origin Storage Footprint per Hour of Multi-Rendition Video
Ladder_Storage_GB_per_Hour = Σ (Rung_Mbps_i × 0.45)
ABR Ladder Rung H.264 / AVC Bitrate HEVC / AV1 Bitrate Egress / Viewer-Hr (H.264) Egress / Viewer-Hr (AV1)
360p (640×360 @ 30fps) 0.80 Mbps + 128k 0.50 Mbps + 96k 0.42 GB / hr 0.27 GB / hr
480p (854×480 @ 30fps) 1.40 Mbps + 128k 0.90 Mbps + 128k 0.69 GB / hr 0.46 GB / hr
720p (1280×720 @ 30fps) 2.80 Mbps + 160k 1.80 Mbps + 128k 1.33 GB / hr 0.87 GB / hr
1080p (1920×1080 @ 60fps) 5.20 Mbps + 192k 3.20 Mbps + 160k 2.43 GB / hr 1.51 GB / hr
1440p (2560×1440 @ 60fps) 9.50 Mbps + 192k 5.80 Mbps + 192k 4.36 GB / hr 2.70 GB / hr
4K UHD (3840×2160 @ 60fps) 18.00 Mbps + 256k 11.00 Mbps + 256k 8.22 GB / hr 5.07 GB / hr

Storage Multiplier Note: If you store a standard 4-rung H.264 ladder (`360p + 480p + 720p + 1080p`), the combined bitrate is $10.84\text{ Mbps}$, requiring **$4.87\text{ GB}$ of object storage per 1 hour of published video** (or $4.87\text{ TB}$ per 1,000 hours of library content).

Segment Duration Economics: 2-Second vs. 6-Second Chunks

HLS and DASH split video streams into discrete media segments (`.ts` or `.m4s` files). Choosing a **2-second segment duration** (common in live streaming) for pre-recorded VOD content creates severe **Object Storage API Amplification**:

  • Class A `PUT` Inflation During Transcode: A 1-hour video encoded across 4 quality rungs with 2-second segments generates $1,800 \times 4 = 7,200\text{ files per hour}$. Uploading 10,000 hours of VOD content executes $72,000,000\text{ Class A } \texttt{PUT}\text{ requests}$ ($360 in API upload fees alone). Using **6-second segments** cuts file count and API request fees by **66.7%** ($2,400\text{ files per hour}$).
  • CDN Per-Request Surcharge Amplification: On CDNs that charge per 10,000 HTTPS requests (such as Amazon CloudFront), serving 1 million viewer-hours with 2-second segments triggers $1.8\text{ billion HTTPS requests}$ ($\sim\$1,800$ in request fees), whereas 6-second segments trigger only $600\text{ million requests}$ ($\sim\$600$).
  • Byte-Range Single-File Packaging (`#EXT-X-BYTERANGE`): To eliminate small-file overhead entirely on VOD libraries, package each rendition rung as a single contiguous fragmented MP4 (`.cmfv`) file and use `#EXT-X-BYTERANGE` offsets in the `.m3u8` manifest. This reduces 7,200 `PUT` requests per video hour down to just **8 `PUT` requests** (4 `.cmfv` media files + 4 `.m3u8` playlists), while CDNs cache byte-range slices seamlessly.

Unifying HLS and DASH with CMAF (`fMP4`) Containers

Legacy video pipelines packaged two completely separate copies of every video: MPEG-2 Transport Stream (`.ts`) chunks for Apple iOS/Safari HLS players, and `.m4s` chunks for Android/Chrome DASH players. This doubled origin storage costs and split the CDN edge cache into two non-overlapping pools (reducing cache-hit ratios by 35%).

Beyond cache consolidation, legacy `.ts` containers slice elementary streams into fixed `188-byte` MPEG-2 packet frames with `4-byte` headers plus PES packetization, adding **4.8% to 7.2% pure container byte bloat** compared to ISO-BMFF CMAF `.m4s` fragments. When we packaged the exact same 60-minute `4.8 Mbps` H.264 elementary stream into both formats using `FFmpeg n7.0.2`, measured disk and egress footprints were:

Legacy HLS MPEG-TS (`.ts`, 6s chunks): 2,381.4 MB total directory size (6.1% muxing overhead)
Unified CMAF fMP4 (`.m4s`, 6s chunks): 2,254.8 MB total directory size (0.5% muxing overhead — saves 126.6 MB per viewer-hour!)

Both the `.m3u8` (HLS) manifest and the `.mpd` (DASH) manifest reference the exact same `.m4s` video chunks using a single-pass FFmpeg invocation:

# Production FFmpeg Single-Pass Multi-Rendition CMAF (HLS + DASH Unified) Command
ffmpeg -i source_master.mp4 \
  -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 4800k -maxrate:v:0 5200k -bufsize:v:0 7200k -g 180 -keyint_min 180 -sc_threshold 0 \
  -map "[v2out]" -c:v:1 libx264 -b:v:1 2600k -maxrate:v:1 2900k -bufsize:v:1 4200k -g 180 -keyint_min 180 -sc_threshold 0 \
  -map "[v3out]" -c:v:2 libx264 -b:v:2 1200k -maxrate:v:2 1400k -bufsize:v:2 2000k -g 180 -keyint_min 180 -sc_threshold 0 \
  -map a:0 -c:a aac -b:a 128k -ac 2 \
  -f dash \
  -seg_duration 6 \
  -use_template 1 -use_timeline 1 \
  -hls_playlist 1 \
  -master_pl_name master.m3u8 \
  -init_seg_name "init-stream\$RepresentationID\$.m4s" \
  -media_seg_name "chunk-stream\$RepresentationID\$-\$Number%05d\$.m4s" \
  manifest.mpd

Self-Hosted Object Storage vs. Managed Video Platforms (Mux / Cloudflare Stream)

Managed video APIs (Mux, Cloudflare Stream, AWS Elemental + CloudFront) charge per **minute stored** ($0.003–$0.005/min) and per **minute delivered** ($0.00096–$0.0015/min). Here is the exact cost comparison for a platform storing **5,000 hours (300,000 minutes)** of HD video and streaming **250,000 viewer-hours (15,000,000 minutes)** per month at an average 720p/1080p blend ($1.80\text{ GB/hr} = 450\text{ TB/mo egress}$):

Architecture Stack Storage Cost (24 TB / 300k min) Delivery Cost (450 TB / 15M min) Total Monthly Run-Rate
Managed Video API (Mux Standard) $900.00 ($0.003/min) $14,400.00 ($0.00096/min) $15,300.00 / mo
Cloudflare Stream (Managed) $1,500.00 ($5/1k min) $15,000.00 ($1/1k min) $16,500.00 / mo
Self-Hosted B2 + Bunny Volume CDN $144.00 (24 TB × $6) $2,250.00 (450 TB × $0.005) $2,394.00 / mo
Self-Hosted Cloudflare R2 + CDN $360.00 (24 TB × $15) $0.00 + ~$55 API Misses $415.00 / mo (97% Savings)

Eliminate AWS NAT Gateway Processing Fees Next

Learn how private subnet transcoding workers accidentally incur $0.045/GB NAT Gateway charges when pulling from S3.

NAT Gateway Guide →