SD System Design In Depth
0%
lesson system-designmediaworkflows

Video transcoding pipeline

Module 5.2: Media Processing & CDN Distribution Updated Sep 18, 2026
📄 Cheat Sheet
How NETFLIX onboards new content: Video Processing at scale 🎥
Gaurav Sen How NETFLIX onboards new content: Video Processing at scale 🎥 Watch on YouTube ↗

A clear, focused explanation of the split, parallel-encode, and assemble pipeline with multiple resolutions and codecs, exactly this unit's architecture.

0:00 / --:--

Transcoding at Scale (Netflix & YouTube Pattern)

Most consumer camera uploads are already compressed, while professional workflows may supply higher-bitrate mezzanine masters. The video transcoding pipeline validates and decodes those varied inputs, then produces multiple resolutions (1080p, 720p, 480p, 360p), bitrates, and codecs (H.264, H.265/HEVC, AV1, VP9) for playback across TVs, laptops, and mobile devices.

Distributed Pipeline Architecture

flowchart TD Raw["Raw Master in S3"] --> Splitter["Video Splitter Worker"] Splitter --> Chunks["Split into keyframe-aligned segments of a few 2-second GOPs"] Chunks --> Queue["Kafka / SQS Transcode Tasks"] Queue --> W1["Worker: 1080p Chunk 1"] Queue --> W2["Worker: 720p Chunk 1"] Queue --> W3["Worker: 480p Chunk 1"] W1 & W2 & W3 --> Merger["Video Stitcher & Manifest Generator"] Merger --> HLS["HLS / DASH Manifest + TS/M4S Chunks"] HLS --> CDN[("CDN Delivery")]

Split-and-Stitch Parallelism

Rather than encoding a 2-hour movie linearly on a single machine (taking hours), modern pipelines split the video at Keyframe (I-frame) boundaries into 5-to-10-second segments. Hundreds of ephemeral worker instances transcode segments concurrently in parallel. Every rendition must use the same keyframe and segment boundaries so players can switch cleanly. The completed segments are stitched together with an index manifest file (.m3u8 for HLS or .mpd for DASH).

Worked example: one hour of 1080p

Assumptions: a 60 minute 1080p30 upload, a 5-rung H.264 ladder, and each worker encoding one rendition at about 0.5x real time (2 seconds of work per second of video).

  • Serial: 5 renditions x 60 minutes x 2 = 10 hours of encoding.
  • Chunked: split into 6 second segments at keyframes: 600 segments x 5 renditions = 3,000 tasks, each about 12 seconds of work. With 300 workers the wall-clock time is about 2 minutes plus queueing, probing and packaging.
  • Cost is unchanged (still about 10 CPU-hours); parallelism buys latency, not efficiency. Per-title or per-shot encoding reduces cost and bitrate for simple content.

Example bitrate ladder

RenditionResolutionVideo bitrate (H.264)
1080p1920 x 1080about 5 Mbit/s
720p1280 x 720about 3 Mbit/s
480p854 x 480about 1.2 Mbit/s
360p640 x 360about 0.7 Mbit/s
240p426 x 240about 0.4 Mbit/s

Codec trade-offs

CodecCompression versus H.264Encode costPlayback support
H.264 / AVCBaselineLowUniversal
H.265 / HEVCRoughly 25 to 50 percent smallerHigherApple devices and many TVs; licensing complexity
VP9Similar to HEVCHigherChrome, Android, many TVs
AV1Roughly 30 percent smaller than VP9Much higherGrowing hardware decode support

Platforms commonly encode H.264 for everyone and add AV1 or HEVC only for popular titles, where bandwidth savings repay the encode cost.

Pipeline and failure handling

flowchart LR U["Upload complete event"] --> PR["Probe and validate"] PR --> SP["Split at keyframes"] SP --> Q["Task queue keyed by video, rendition, segment"] Q --> W["Encode workers"] W --> CK["Completion tracker"] CK --> PK["Package HLS and DASH manifests"] PK --> PUB["Mark video playable"]
  • Poison inputs: after N failed attempts, move the task to a dead-letter queue and mark the video failed with a reason, instead of retrying forever.
  • Audio is encoded once per language and bitrate, separately from video, and muxed or referenced in manifests.
  • YouTube has reported receiving over 500 hours of video per minute, which is why these pipelines are built as elastic, queue-driven worker fleets.
Check yourself Question 1 of 3
Aligned keyframes recall
From: Split-and-Stitch Parallelism

Why must every rendition in a transcoding ladder use the same keyframe and segment boundaries?

Adaptive Bitrate: throughput vs buffer-based

Both players fetch the same 120 s of network, one segment at a time, from a 10-rung ladder (235k to 5.8M). The throughput player picks the highest rung under 85% of its recent measured throughput; the BBA-0 player ignores throughput and maps its buffer level (5 s reservoir, 20 s cushion) to a rung. Click or drag on the top chart to redraw the bandwidth.

Key Takeaways

Split videos into short keyframe-aligned segments (each made of one or more closed GOPs) to transcode massively in parallel across worker pools.
Encode into multiple bitrates and resolutions to support Adaptive Bitrate Streaming (ABR).
Store output segments in object storage fronted by an Anycast CDN.
Was this lesson helpful? Spot an issue or have a suggestion? Let us know on GitHub.
Report an issue