Understanding Video Codecs: Which One Should You Use?

The video codec landscape in 2026 looks like a coalition negotiation that nobody won. H.264, eighteen years old, still dominates uploads to YouTube, TikTok, and broadcast contribution. H.265 is everywhere in hardware but legally nowhere in software for years. AV1 is the technically superior open codec that took half a decade to arrive in shipping silicon. VP9 quietly powers most YouTube playback. ProRes and DNxHR are the unchallenged kings of editing intermediates. And FFV1 is the format that will probably outlive every other entry on this list because it is mathematically lossless and has no licensing complications.

Choosing the right codec is not a question of which is best. It is a question of where the file is going, who decodes it on the other side, what you will do with it later, and what the bill looks like at scale. This guide walks through the decision matrix and the tradeoffs that actually matter when shipping video to humans.

What a codec actually does

A video codec is two things bundled: an encoder that compresses raw pixel data, and a decoder that reverses that compression. The encoder is allowed to make the decoder's life harder because you encode once and decode billions of times. This asymmetry shapes every modern codec design: encoders take seconds to minutes per second of video; decoders run in real time on a phone.

The compression itself works in four stages. First, prediction: estimate each block of pixels from blocks already encoded, either spatially within the same frame (intra prediction) or temporally across frames (motion compensation). Second, transform: convert the prediction error to frequency space using a discrete cosine transform or wavelet so high frequencies can be discarded. Third, quantization: divide transform coefficients by step sizes that get larger for less important visual frequencies. Fourth, entropy coding: pack the resulting integers into bits using techniques like CABAC or arithmetic coding.

Every codec is a different point in the design space of those four stages. H.264 has 4x4 blocks and CABAC. H.265 has 64x64 blocks and improved intra prediction. AV1 has 128x128 blocks and dozens of new tools. The progression is roughly half the bitrate every ten years for the same perceptual quality.

"Compression is a tradeoff between the time and resources spent compressing and the size of the output. There is no free lunch." Brian Kernighan

The fancier the codec, the more the encoder costs in CPU time. Picking AV1 for a live stream might be technically optimal but economically ruinous if your encoders cost ten times as much.

The decision matrix

Codec	Best for	Encoder speed	Decoder support	Royalty status
H.264 (AVC)	Universal compatibility, live streaming	Fast	Universal, hardware in everything since 2008	Royalty-bearing through MPEG LA
H.265 (HEVC)	High-efficiency VOD, 4K broadcast	Medium	Hardware in iPhones, Apple TVs, smart TVs since 2014	Royalty-bearing across multiple pools
AV1	Open, royalty-free streaming	Slow (improving fast)	Hardware in iPhone 15+, Pixel 6+, Intel Arc, RTX 40	Royalty-free (AOMedia patent license)
VP9	YouTube playback, royalty-free 4K	Medium	Hardware in most TVs since 2017, all modern Android	Royalty-free
ProRes 422	Edit intermediates, color grading	Fast	macOS native, Windows via codec install	Apple license, free to use
DNxHR	Avid edit workflows, broadcast	Fast	Cross-platform, free reference implementation	BSD-licensed reference
FFV1	Long-term archival	Slow	Open source via FFmpeg	Public domain
MJPEG	Surveillance, simple capture	Very fast	Universal	Patent-free
ProRes RAW	RAW capture intermediates	Fast	macOS native, Windows via Apple plugin	Apple license

The honest summary: H.264 for "must work everywhere," H.265 or AV1 for "want bandwidth savings," ProRes or DNxHR for editing, FFV1 for archives. Everything else is a special case.

H.264: still the workhorse, still good enough

H.264 is to video what JPEG is to images. Older, surpassed in raw efficiency, but ubiquitous to the point where choosing anything else needs justification. Every browser decodes it, every phone has dedicated hardware for it, every TV plays it without buffering.

A modern x264 encode at preset slow and CRF 18 is visually transparent on most content for most viewers. The codec's 18-year-old design shows only at extreme bitrates: above 4K and 60fps, you can see H.264 spending bits on motion vectors that newer codecs handle with smaller blocks.

# Production-quality H.264 master
ffmpeg -i source.mov \
  -c:v libx264 -preset slow -crf 18 \
  -profile:v high -level 4.1 \
  -pix_fmt yuv420p -movflags +faststart \
  -c:a aac -b:a 192k \
  master.mp4

# Live streaming H.264 with low latency
ffmpeg -i source.mov \
  -c:v libx264 -preset veryfast -tune zerolatency \
  -profile:v main -level 3.1 \
  -b:v 2500k -maxrate 2500k -bufsize 5000k \
  -g 48 -keyint_min 48 \
  -c:a aac -b:a 128k -f flv \
  rtmp://...

The two parameters that matter most are -crf (constant rate factor, lower is higher quality) and -preset (slower presets find better encoding decisions). For VOD masters, CRF 18 to 20 with preset slow or slower. For live, preset veryfast with rate control matched to the network budget.

H.265: the underused middle child

H.265 should have replaced H.264 by 2020. It did not, partly because of patent licensing chaos, partly because Google and Mozilla refused to ship browser decoders for years. By the time the legal dust settled, AV1 had emerged as the open alternative, and H.265 was relegated to "the codec your phone uses internally."

In a closed ecosystem (Apple devices, smart TVs, set-top boxes), H.265 is excellent. It saves roughly 30 to 50 percent bandwidth versus H.264 at equivalent quality. For a streaming service paying CDN bills by the gigabyte, that math is compelling.

ffmpeg -i source.mov \
  -c:v libx265 -preset medium -crf 23 \
  -tag:v hvc1 \
  -pix_fmt yuv420p10le \
  -c:a aac -b:a 192k \
  master_h265.mp4

The -tag:v hvc1 is critical for Apple compatibility. Without it, Safari and QuickTime will refuse to play the file. The yuv420p10le pixel format enables 10-bit encoding, which produces smoother gradients than 8-bit at minimal extra cost.

AV1: the long-awaited future

AV1 is the codec the open-source community spent half a decade waiting for. Royalty-free, designed by a consortium that includes Google, Mozilla, Microsoft, Netflix, and Apple, and producing 30 to 50 percent better compression than H.264. The catch was encoder speed: early libaom encodes ran at 0.1 frames per second on a fast laptop. By 2026, SVT-AV1 produces production-quality output at 5 to 30 fps depending on settings, and hardware encoders in Intel Arc, RTX 40, and AMD RDNA 3 push live streaming into the realm of possibility.

# SVT-AV1 production preset for VOD
ffmpeg -i source.mov \
  -c:v libsvtav1 -preset 6 -crf 30 \
  -pix_fmt yuv420p10le \
  -svtav1-params tune=0:enable-overlays=1 \
  -c:a libopus -b:a 128k \
  master_av1.webm

For VOD distribution to modern browsers (Chrome, Firefox, Safari 17+) and devices made after 2023, AV1 is the right choice. For live streaming, hardware AV1 in NVENC or QuickSync makes it viable. For contribution to traditional broadcast, H.264 still rules because the upstream chain expects it.

"Worse is better." Richard Gabriel, Lisp: Good News, Bad News, How to Win Big

H.264 is the worse-is-better codec of video. AV1 is the better-but-late codec. The transition will take a decade because compatibility decays slowly.

VP9: the codec you use every day without knowing

VP9 is YouTube's playback codec for high-resolution streams. If you watch 4K on YouTube, you are decoding VP9. It compresses comparably to H.265 with a royalty-free license, which is why Google bet on it. Outside YouTube and a few broadcasters, VP9 sees little adoption because AV1 supersedes it for the same use cases.

For a streaming service that wants royalty-free with broader hardware support than AV1 today, VP9 remains a credible choice. It plays everywhere AV1 plays plus on slightly older hardware (Android 5+, Chromecast 1, some Roku models from 2018).

ffmpeg -i source.mov \
  -c:v libvpx-vp9 -b:v 0 -crf 31 \
  -pix_fmt yuv420p \
  -row-mt 1 -threads 8 \
  -c:a libopus -b:a 128k \
  master_vp9.webm

The -row-mt 1 enables row-based multithreading, which is what makes libvpx-vp9 actually use more than two cores effectively. Without it, encoding times double or worse.

ProRes and DNxHR: the editing intermediates

When you import footage into Premiere, Final Cut, Resolve, or Avid, you do not edit H.264 directly. The NLE either transcodes to ProRes or DNxHR on import, or you do it manually as part of the dailies workflow. The reason: H.264 is asymmetric. Decoding random frames in a long GOP requires walking back to the previous keyframe, which makes scrubbing painful and color grading slow.

ProRes and DNxHR are intra-frame codecs. Every frame stands alone, scrubbing is instant, and the encoder is roughly real-time even at 4K. The bitrate is high (ProRes 422 HQ at 1080p is roughly 220 Mbps), which is the price of cheap decoding.

Intermediate	Bitrate at 1080p30	Use case
ProRes 422 Proxy	45 Mbps	Offline editing, low storage
ProRes 422 LT	102 Mbps	Standard offline edit
ProRes 422	147 Mbps	Online edit, broadcast delivery
ProRes 422 HQ	220 Mbps	Color grade, VFX intermediate
ProRes 4444	330 Mbps	Alpha channel, VFX
ProRes 4444 XQ	500 Mbps	Highest fidelity for grade
DNxHR LB	36 Mbps	Avid offline
DNxHR SQ	145 Mbps	Avid online
DNxHR HQ	220 Mbps	High quality online
DNxHR HQX	220 Mbps	12-bit grade
DNxHR 444	600 Mbps	Mastering

# Transcode camera files to ProRes 422 HQ for editing
ffmpeg -i camera.mov \
  -c:v prores_ks -profile:v 3 -vendor apl0 \
  -pix_fmt yuv422p10le \
  -c:a pcm_s24le \
  edit_master.mov

# Transcode to DNxHR HQ
ffmpeg -i camera.mov \
  -c:v dnxhd -profile:v dnxhr_hq \
  -pix_fmt yuv422p \
  -c:a pcm_s24le \
  edit_master.mxf

The -vendor apl0 tag is required for Final Cut Pro to recognize the file as ProRes; without it, FCP treats the file as some other prores variant and refuses to import.

FFV1: the codec libraries trust

FFV1 is what you use when the file matters more than the bitrate. Mathematically lossless, public domain, embedded in FFmpeg, and recommended by the Library of Congress, the National Archives of Canada, and the Austrian Mediathek for long-term preservation. The output is large (a 1080p hour can run 50 GB) but bit-for-bit reversible to the source.

ffmpeg -i master.mov \
  -c:v ffv1 -level 3 -coder 1 -context 1 -slicecrc 1 \
  -slices 24 -threads 8 \
  -c:a flac \
  archive.mkv

The -slicecrc 1 adds CRC32 to each slice, so a corrupt sector damages only one slice rather than every subsequent frame. This is the kind of detail that matters for media expected to outlive the storage it is on.

The right master, the right deliverable

The single most expensive habit in video production is using the deliverable codec as the master. A creator who edits H.264 files, exports H.264 deliverables, and keeps no intermediate is one client request away from disaster. The right structure:

Stage	Codec	Why
Camera capture	Whatever the camera shoots	You do not get to choose
Edit intermediate	ProRes 422 HQ or DNxHR HQ	Fast scrub, color-grade-friendly
Master	ProRes 4444 or FFV1	Future-proof, format-stable
Web deliverable	H.264 or AV1	Plays in browsers
Mobile deliverable	H.264 main profile	Decoder support
Archive	FFV1 in MKV with PCM audio	Library-grade preservation

A creator who lives by this five-row table will be able to deliver in any future format from a stable master, no matter what the platform of the year demands.

Cross-domain consistency

The codec decision matrix is the same whether you are shipping video for educational explainers at identity-and-photo content like Strange Animals, assessment-prep video at whats-your-iq.com, or local-business explainers at downundercafe.com. The deliverable specs differ, but the master-then-derive pattern is universal.

"All non-trivial abstractions, to some degree, are leaky." Joel Spolsky, The Law of Leaky Abstractions

A codec is an abstraction that hides pixel manipulation behind a number. The leak shows up when the abstraction meets reality: a phone whose hardware decoder lacks support, a browser that refuses a profile, a streaming service that re-encodes everything. Plan for the leak, do not assume the codec is the contract.

Bitrate planning by resolution and codec

A common question is "how much bitrate do I need." The answer depends on resolution, frame rate, content type, and codec. The table below summarizes typical CRF-equivalent bitrates for VOD-quality output across resolutions.

Resolution / fps	H.264 medium	H.265 medium	AV1 medium	Notes
480p / 30	1.0 Mbps	0.6 Mbps	0.5 Mbps	Acceptable for thumbnails and previews
720p / 30	2.5 Mbps	1.5 Mbps	1.2 Mbps	Standard mobile streaming
1080p / 30	5 Mbps	3 Mbps	2.5 Mbps	YouTube recommendation for HD
1080p / 60	8 Mbps	4.5 Mbps	3.5 Mbps	Gaming, sports
1440p / 30	9 Mbps	5.5 Mbps	4.5 Mbps	QHD
2160p / 30	25 Mbps	12 Mbps	9 Mbps	4K VOD
2160p / 60	40 Mbps	18 Mbps	14 Mbps	4K high motion

These numbers are starting points, not absolutes. Animation, screencasts, and other low-motion content needs roughly half these bitrates; high-motion sports and gaming needs roughly 1.5x. Always validate with SSIM or VMAF on representative content.

Encoder tuning for content type

Both libx264 and libx265 expose -tune flags that adjust internal heuristics for specific content types. Most encoders pick the wrong default for non-cinematic content.

# Animation has flat regions and sharp edges
ffmpeg -i animation.mov \
  -c:v libx264 -preset slow -crf 20 -tune animation \
  -c:a aac -b:a 192k animation.mp4

# Screencasts have static content with occasional motion
ffmpeg -i screencast.mov \
  -c:v libx264 -preset slow -crf 22 -tune stillimage \
  -c:a aac -b:a 128k screencast.mp4

# Film with grain that should not be smoothed away
ffmpeg -i film.mov \
  -c:v libx264 -preset slow -crf 18 -tune film \
  -c:a aac -b:a 256k film.mp4

The -tune flag is a one-line change with substantial visible impact at the same CRF. Skipping it leaves quality and size on the table.

Common mistakes that survive years of practice

Three errors recur in codec selection. First, picking a codec because it is newest rather than because it is supported by the audience. Second, encoding masters as deliverables, which compounds quality loss on every re-encode. Third, ignoring 10-bit pixel formats for codecs that benefit from them, which produces visible banding in skies and skin tones at typical streaming bitrates.

A producer who avoids these three mistakes ships video that ages well, reaches its audience reliably, and survives platform changes without panicked re-encoding.

References

1. ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services." International Telecommunication Union, 2021.
2. ITU-T Recommendation H.265, "High efficiency video coding." International Telecommunication Union, 2023.
3. Alliance for Open Media, "AV1 Bitstream and Decoding Process Specification." AOMedia, 2018. Available: https://aomediacodec.github.io/av1-spec/
4. Bankoski, J., Wilkins, P., and Xu, Y., "Technical Overview of VP9." Google, 2013.
5. Apple, "Apple ProRes White Paper." Apple Inc., 2020. Available: https://support.apple.com/en-us/HT202410
6. Niedermayer, M., "FFV1 Video Codec Specification." Internet Engineering Task Force, draft-ietf-cellar-ffv1, 2024.
7. ISO/IEC 23008-2:2020, "Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 2: High efficiency video coding."
8. SMPTE ST 2019-1:2016, "Material Exchange Format - VC-3 Video Compression - Bit Stream." Society of Motion Picture and Television Engineers.