Video Compression
Every codec, on every platform, is the same three boxes. A camera or renderer hands you raw pixels — enormous, uncompressed, one full picture per frame. An encoder throws away what a viewer will not miss and what the previous frames already said. Out comes a bitstream two orders of magnitude smaller. Everything else — pixel formats, frame types, rate control, latency — is detail hanging off one of those three boxes.
The encode path
click a stage to go deeperRaw frames
Uncompressed pictures, one after another. Nothing is shared between them: frame 300 costs exactly what frame 1 costs, even if the camera never moved.
Encoder
Decides, per frame, how much of it to code from scratch and how much to describe as motion away from frames it already sent. That single decision is the whole trade.
Bitstream
A keyframe now and then, and between them a long list of instructions for changing it. Small, ordered for the decoder rather than for your eyes, and fragile in interesting ways.
numbers are one worked example — 1080p30, 4:2:0, 8-bit, 6 Mbps — not a property of any codec. Swap NV12 for I420 or P010, H.264 for HEVC or AV1: the shape of the diagram does not move.
Where the detail lives
each box opens into its own set of questionsWhy encoders want YUV and not RGB. What the 2 in 4:2:0 means and why halving the chroma is nearly free. How NV12 actually sits in memory — one luma plane, one interleaved chroma plane at half height — and why that layout is what the GPU hands you.
Frame types, GOP structure, reference frames, and why decode order stops matching display order the moment you enable B frames. Covered in the explorer →
NAL units, parameter sets, and what a container adds on top. Which byte you can cut a stream at, and what a lost packet destroys — that answer depends entirely on the frame type it belonged to.