videocodecsav1streaming

Video codecs explained: H.264, H.265, VP9 and AV1 without unnecessary jargon

How video compression works: keyframes, inter/intra prediction, why AV1 weighs half of H.264 and which codec to choose for web in 2026.

August 26, 2026·8 min read

One minute of uncompressed Full HD video takes about 9 GB. On YouTube that same minute is 20-40 MB. The 300:1 ratio between those numbers is the silent work of video codecs — and understanding their principles explains why a file "looks bad", why your export takes so long, and what configuration to pick for publishing to the web.

The base idea: 95% of every frame is repetition

Video is an image sequence at 24-60 fps. Compressing each frame like a standalone photo (as JPEG would) wastes the most valuable datum: between consecutive frames almost nothing changes. Modern codecs exploit two redundancies:

  • Spatial (within frame): same as JPEG/WebP.
  • Temporal (between frames): "this block equals the one in the previous frame, shifted 3 pixels".

I-frames, P-frames and B-frames

The typical stream alternates three frame types:

  • I-frame (intra): compressed alone, like a photo. The mandatory starting point.
  • P-frame (predicted): stores only differences from the previous frame — blocks that moved, changed or appeared. A fraction of the I weight.
  • B-frame (bidirectional): predicts from both previous AND next frames. Maximum compression, maximum complexity.

The usual structure (GOP - Group of Pictures): I B B P B B P ... I. I-frames appear every few seconds because P-frames accumulate error and because you need access points: when seeking mid-video, the player must start from an I-frame. That's why seeking in long-GOP videos "snaps" backwards.

Streaming consequence: more I-frames = better seeking + worse compression. Platforms balance per content.

How prediction works (the codec's heart)

For each pixel block in a P-frame:

  1. Motion estimation: find in the reference frame the most similar block — possibly displaced (motion encoded as a vector).
  2. Motion compensation: subtract the found block from the real one; a small residual remains.
  3. Encode vector + residual (which goes through image-style DCT/quantization).

Each codec generation improves this machinery with more block sizes (up to 128×128 in AV1 versus H.264's 16×16), finer angular intra prediction modes, loop filters reconstructing better references, and specialized tools (AV1's film grain synthesis: don't compress the grain, regenerate it synthetically).

The four codecs that matter

H.264/AVC H.265/HEVC VP9 AV1
Year 2003 2013 2013 2018
Relative efficiency base ~+40% ~+35% ~+50%
Licensing Patent pool Expensive, opaque Free Free (royalty-free)
Hardware support Universal Wide (Apple strong) Wide (Google) Growing fast

H.264 remains the universal safe bet: any device from the last decade decodes it in hardware. For maximum compatibility, still the mandatory fallback.

H.265: notably more efficient but historically poisoned by multiple expensive licenses. Dominates Apple ecosystem (iPhone recording, HDR).

VP9: Google's free answer, YouTube's backbone for years. Excellent efficiency/support ratio in browsers.

AV1: the modern open standard backed by a giant consortium (Google, Netflix, Amazon, Apple...). Compresses ~50% better than H.264 — Netflix ships catalog in AV1 saving petabytes. Its historical cost was glacial encoding; SVT-AV1 has accelerated it into daily production. Hardware support already covers most new devices (phones since 2022-2023, recent GPUs).

What to use in 2026

Web publishing with maximum reach: H.264 baseline/high as base + AV1 or VP9 as preferred source via multiple <source> — browser picks the first supported:

<video controls width="1280" height="720">
  <source src="video.av1.webm" type='video/webm; codecs="av01"' />
  <source src="video.vp9.webm" type='video/webm; codecs="vp9"' />
  <source src="video.h264.mp4" type="video/mp4" />
</video>

Reasonable web parameters: CRF/CQ between 28-34 on AV1 (inverted scale: lower = better quality), target bitrate for H.264 by resolution (720p ≈ 4-6 Mbps, 1080p ≈ 8-12 Mbps), Opus audio 96-128k in WebM or AAC 128k in MP4.

Trimming, converting or speed-changing before uploading drastically cuts processing time on the destination platform — our online video editor does those operations locally with ffmpeg/WASM, never uploading your original anywhere.

Why your export takes so long

Encoding well is exhaustive search: testing many motion candidates, many block partitions, many quantization decisions per frame. Encoding speed scales with search complexity — fast presets prune the search (bigger file), slow presets deepen it. An AV1 export at preset 4 can take 5-10× realtime; preset 8 under 1×. Choose based on whether the file encodes once (spend time) or gets served millions of times (spend bytes).

FAQ

Can I recover quality from already-compressed video? No: details discarded by quantization no longer exist. Re-encoding always degrades (generational loss); always start from the best source available.

What bitrate does my video need? Depends on resolution, fps and content complexity (sports ≠ conference). Better quality-based approach (CRF/CQ) than fixed bitrate: you define perceived quality and the codec spends as needed.

HDR and 10-bit? AV1 and HEVC support them natively; H.264 with limitations. For real web HDR today: AV1 or HEVC with Dolby Vision/HDR10 profiles.


Prepare your videos for the web with our video editor, free and right in your browser.

Try it without code

Video Editor

Trim, compress and convert videos.

Open Video Editor

Built by

Miguel Ángel Colorado Marin (MACM)

Full-Stack Developer · Guadalajara, España

I develop web apps, digital tools and full projects — from design to deployment.

Contact me