We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
3 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Web Content Delivery
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Web Content Delivery
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Raw video from a camera sensor is enormous. A single frame of 1080p uncompressed video is about 6 MB. At 30 frames per second, that is 180 MB per second, or roughly 10.8 GB per minute. Nobody can stream that. Nobody can store it economically. Video encoding exists to solve exactly this: compress raw frames into something a user can stream over a 5 Mbps connection without visible quality loss.
Netflix spends more on encoding infrastructure than most startups spend on their entire stack. They encode every title into over 100 different bitrate/resolution combinations using a technology called per-title encoding, where each scene's complexity determines how much compression it can tolerate. A static dialogue scene compresses down to almost nothing. An action sequence with fast motion needs 10x the bitrate to look acceptable.
YouTube processes over 500 hours of video uploads per minute. Every one of those videos gets encoded into a dozen renditions within minutes. The encoding pipeline is the bottleneck between "user clicks upload" and "video is watchable," and the codec choice directly determines storage cost, cost, and visual quality.
A codec (coder-decoder) is the algorithm that compresses and decompresses video frames. The container (MP4, WebM, MKV) is just the wrapper that holds the compressed video, audio, and metadata together. Think of the codec as the language and the container as the envelope.
H.264 (AVC). Released in 2003. The universal baseline. Every browser, phone, smart TV, and set-top box supports it. Encoding is fast and cheap. Quality per bit is the worst of the modern codecs, but compatibility is unmatched. If you can only encode one format, pick H.264.
H.265 (HEVC). Released in 2013. About 50% better compression than H.264 at the same visual quality. But patent licensing is a nightmare. Three different patent pools (MPEG LA, HEVC Advance, Velos Media) each want royalties. Apple supports it natively. Many Android devices support it. Browser support is incomplete (Chrome added it only recently). Netflix uses H.265 for iOS and Apple TV devices.
VP9. Google's royalty-free answer to H.265. Similar compression efficiency. YouTube uses VP9 as the default codec for most playback. Chrome and Firefox support it natively. Safari added VP9 support in 2020. Hardware decode support on newer devices. Encoding is slower than H.264 but the savings in pay for it at YouTube's scale.
AV1. The next generation. Developed by the Alliance for Open Media (Google, Netflix, Amazon, Apple, Meta, Microsoft). Royalty-free. About 30% better compression than VP9 and 50% better than H.264. The catch: encoding is extremely slow (10-100x slower than H.264). Hardware encoders are just starting to ship in 2024-2025 chips. Netflix uses AV1 for mobile streams. YouTube is rolling it out gradually. If you are building for the future, AV1 is where the industry is heading.