H.264 (AVC) — the codec that won, and is still winning two decades later

H.264 — also known as AVC, MPEG-4 Part 10, ISO/IEC 14496-10 — is the codec that won the early-2000s codec war and never let go. Standardized in 2003, it's been the dominant video codec on the internet for over two decades. Every device that decodes video supports it. Every encoding pipeline emits it as a baseline. Every CDN serves it. In 2026, it's the codec you don't think about — and that's exactly why it's still load-bearing.

This page is about the engineering reality of H.264 in 2026: why it's still the right answer for the bottom of every ladder, what x264 still does that nothing else does, and where H.264's actual ceiling is.

#What H.264 is

H.264 is the codec that introduced most of the techniques modern video coding still uses, in a form simple enough to be hardware-implementable across two decades of silicon evolution. The mechanics:

• Macroblock-based coding — 16×16 luma blocks (4:2:0 chroma), with intra and inter prediction modes selected per block.
• Intra prediction — 9 angular modes for 4×4 blocks, 4 modes for 16×16. Predicts current block from neighboring decoded samples in the same frame.
• Inter prediction — quarter-pel motion compensation, B-frames (bidirectionally predicted), reference frame buffering. The motion model is translational only (no rotation or zoom — that's HEVC and later).
• Transform — 4×4 integer DCT-like transform. Smaller than HEVC's 32×32, simpler to implement, more uniform.
• Entropy coding — CABAC (context-adaptive binary arithmetic coding) for High profile; CAVLC for Main/Baseline. CABAC gets ~10% bitrate improvement over CAVLC at the cost of decoder complexity.
• Profiles and levels — Baseline (downlevel), Main, High, High 10, High 4:2:2, High 4:4:4 — each adding tools and bit depth/chroma support. Streaming uses High; HDR-adjacent content uses High 10.
• Deblocking filter — in-loop, applied to all reconstructed blocks. Reduces visible block boundaries.

Compared to MPEG-2 (its predecessor), H.264 was a 50% bitrate reduction at the same quality. Compared to HEVC, H.264 needs 40-50% more bitrate. The compression-efficiency math is what made HEVC and AV1 worth pursuing — but H.264's ubiquity is its own competitive advantage.

#x264 in production

x264 is the open-source H.264 encoder maintained primarily by Loren Merritt and Jason Garrett-Glaser (ex-Google, ex-Mozilla, ex-Two Sigma). It is the H.264 encoder. There are commercial encoders — MainConcept, Beamr, Intel SDK — that out-perform x264 at specific operating points, but x264's quality at the same compute budget is the floor every other encoder is measured against.

The presets:

• ultrafast, superfast, veryfast — live, low-latency. Quality drops noticeably below veryfast.
• faster, fast — live with quality budget. fast is the default for live workflows where ~1.5x the bitrate of medium is acceptable.
• medium — VOD baseline. The CRF default that everyone benchmarks against.
• slow, slower — premium VOD. ~2-3× slower than medium, ~10-15% bitrate savings at same quality.
• veryslow, placebo — research-grade. Diminishing returns past slower.

The production tuning specifics worth knowing:

• CRF defaults — CRF 23 is the x264 default. Production VOD typically uses CRF 18-22; live often uses VBV-constrained ABR rather than CRF.
• Tune options — --tune zerolatency for live (disables B-frames, look-ahead), --tune film for cinema-grade content (more deblocking, larger transforms), --tune animation for cartoon-style content.
• Profile/level — High profile + level 4.0 covers most streaming. Going to High 4.1+ unlocks 1080p60. Baseline profile is essentially deprecated outside very specific embedded/legacy targets.
• Reference frames — --ref 4 is a good default. More than 6 rarely helps; some downlevel decoders cap at 4 references for buffer-size reasons.

x264's medium preset has been calibrated and re-calibrated over 18 years. The tuning is so well-known that benchmark papers across video research routinely use "x264 medium" as a baseline operating point. When you see "Bjontegaard delta rate vs x264 medium" in a paper, that's why.

#Hardware encode/decode

H.264 has the most-deployed hardware decoder in computing history. Every device that has ever decoded video in hardware decodes H.264:

• Mobile — every phone, period. Including pre-smartphone feature phones from the 2008+ era.
• Desktop — every Intel CPU since Sandy Bridge (2011) has Quick Sync H.264. Every NVIDIA GPU since Fermi (2010), every AMD GPU since VCE-capable cards (2012).
• TVs and set-top boxes — every smart TV, every cable box, every streaming stick (Roku, Fire TV, Apple TV).
• Browsers — every browser supports H.264 decode. No exceptions.

Hardware encode quality has plateaued — modern NVENC H.264 is roughly equivalent to x264 fast, sometimes worse. The gap between hardware H.264 and software x264 is meaningful for VOD; for live, hardware is the right answer because wall time matters. Most streaming services encode VOD with x264 software and live with hardware NVENC/Quick Sync.

#When H.264 is the right answer in 2026

For the bottom tier of every consumer streaming ladder, H.264 is still the default. Specifically:

• Downlevel devices — anything pre-2017 likely decodes H.264 in hardware and HEVC in software (battery-killing) or not at all. The long tail of older smart TVs, basic Android phones in developing markets, and embedded devices.
• Embedded targets — set-top boxes, security cameras, in-vehicle infotainment, drones. Hardware H.264 encoders and decoders are ubiquitous and battery-efficient. HEVC is more compute-expensive at low power; AV1 even more so.
• Web-first floor tiers — the lowest rung of an ABR ladder is almost always H.264 because no client can fail to play it.
• WebRTC media — H.264 is the most-supported codec across WebRTC implementations. Some endpoints support VP8 (better) or VP9/AV1 (rare); H.264 is the lowest-common-denominator answer.
• Internal/non-streaming use — preview transcodes, intermediate proxies, editorial workflows. Speed matters more than compression.

#When to skip H.264

• Premium-only streaming — if your audience is overwhelmingly Apple devices and modern Android, you can skip H.264 entirely and serve HEVC + AV1. Saves storage and bandwidth at moderate operational complexity.
• Storage-bound archive — if you're storing master-quality content for years, H.264 is wasteful. HEVC or AV1 is the answer.
• Low-latency live where you control the player — you can use HEVC or AV1 if your delivery pipeline reaches only known-capable clients. Most live systems still serve H.264 in addition because you can't predict the audience.

#The patent situation (briefly)

H.264 has patent licensing — MPEG LA's AVC license — but it's stable, well-understood, and at this point essentially priced into industry economics. Per-stream costs for streaming services are nontrivial at scale but not catastrophic. The major patent holders are companies that also license HEVC, so most large streamers have H.264 + HEVC bundled licenses.

For internal/non-commercial use, the pragmatic reality is the same as any old codec: nobody's coming after the local development setup. For commercial deployment at any meaningful scale, you license. The H.264 license is one of the easier MPEG licenses to negotiate because it's been around long enough that everyone knows the rate structure.

#H.264 vs HEVC vs AV1

The position H.264 occupies in 2026 isn't "this is the best codec." It's "this is the codec that always works." The role of H.264 in a modern ladder:

The floor tier is where H.264 lives, and where it'll continue to live. The audience reaching the floor tier is shrinking but won't disappear. H.264 is the codec that buys you "yes, the video plays" coverage for the long tail of devices that don't get codec upgrades.

#A note on x264 vs alternatives

x264's continued dominance is worth understanding because it's not obvious. MainConcept and Beamr produce closed-source H.264 encoders that beat x264 at very specific operating points, particularly at high bitrates and specialty content like film grain. NVIDIA's NVENC H.264 produces stream output suitable for live in real-time. Intel's Quick Sync H.264 has improved meaningfully across CPU generations. Yet x264 remains the encoder pipelines default to for VOD because its general-purpose quality at general-purpose bitrates is excellent, and the well-known preset behavior makes it predictable to integrate. The encoder you understand operationally is more valuable than the encoder that wins by 1-2% on a benchmark you don't fully trust.

#What MpegFlow does with H.264

Default ladder templates include H.264 floor tiers because that's the production reality. x264 is the default software encoder; hardware H.264 (NVENC, Quick Sync) is configurable for live workflows or throughput-bound VOD. Per-rung preset configuration is exposed in the workflow YAML, so customers can choose x264 medium for VOD versus x264 fast for live without rewriting their pipeline.

MpegFlow's DAG runtime expresses each ladder rung as a parallel FfmpegExecutor stage. The partitioner persists each rendition stage to job_stages with explicit dependency tracking; per-stage retry handles transient failures; sibling cancellation propagates fatal failures so dependents don't waste compute; rendition-level partial-success reporting surfaces granular per-stage state. The KEDA-driven autoscaler sizes the worker pool to the queued workload, so adding cheap H.264 floor rungs adds parallel work without queueing behind heavier HEVC/AV1 stages — the "fast and cheap" reality compounds because H.264 stages run on commodity CPU workers and the autoscaler scales them horizontally.

If you're sizing a ladder and not sure how deep to go on H.264 (just one rung? three?), we run that conversation regularly. The answer depends on your audience mix — but the rule of thumb is at least one H.264 rung at 720p, and a second at 480p if your audience is mobile-heavy.