A video codec is the algorithm that compresses raw frames into a transmittable bitstream and reconstructs them on playback. Treat that choice as a pure quality dial and you will eventually pay for it twice: once in transcoding cost, once in playback failures on devices you never profiled. The codec you pick sets the cost-and-quality envelope for every stream that follows, and the newest, most efficient option is not automatically the right one.

That last point is where most codec discussions go wrong. The intuitive move is to reach for AV1 or HEVC because the compression numbers look better, then assume better compression means a better outcome. It does not — not until you know which devices can actually decode the stream, whether their hardware does the decoding, and what the licensing costs once you multiply across millions of viewers.

How Does a Video Codec Work, and What Does It Mean in Practice?

“Codec” is short for coder-decoder. The encoder takes raw, uncompressed frames — each one a full grid of pixels — and produces a far smaller bitstream; the decoder reverses the process on the viewer’s device. Raw video is enormous, so this compression is not optional. A few seconds of uncompressed 4K would saturate a typical home connection on its own.

Codecs achieve their size reduction by exploiting two kinds of redundancy. Spatial redundancy is the repetition within a single frame — large regions of similar colour, smooth gradients, predictable texture. Temporal redundancy is the repetition between frames — most of the picture barely changes from one frame to the next. Rather than storing every frame in full, the encoder stores occasional complete frames (keyframes) and, between them, only the differences: motion vectors describing how blocks of pixels moved, plus residuals correcting what motion estimation got wrong.

This is why a codec’s efficiency depends so heavily on content. A static news anchor against a fixed backdrop compresses beautifully because temporal redundancy is high. A confetti-filled sports celebration or a noisy concert feed compresses poorly because almost every pixel changes every frame. Any compression-efficiency figure you read is an average over some test set, not a guarantee for your library. Codec efficiency gains depend on content and device mix and are never universal — this is an observed pattern across encoding work, not a fixed ratio you can bank.

The practical consequence: the codec doesn’t just decide how small a file gets. It decides how much compute the encode consumes (newer codecs cost more to encode), what hardware can decode it, and therefore what your per-stream economics look like at scale.

Codec, Container, and Bitstream: What’s the Difference?

These three terms get used interchangeably and they are not the same thing. Confusing them is a common source of “it plays here but not there” bugs.

The bitstream is the compressed sequence of bytes the codec produces — the actual encoded video data. The codec is the algorithm (and its standard) that defines how that bitstream is structured and how to decode it: H.264, HEVC, AV1, VP9. The container is the file format that wraps one or more bitstreams together — video, audio, subtitles, timing metadata — into something playable: MP4, MKV, WebM, the fragmented MP4 segments used by HLS and DASH streaming.

A single container can carry different codecs, and the same codec can live in different containers. An MP4 file usually holds an H.264 or HEVC bitstream; a WebM file usually holds VP9 or AV1. When a device reports a file as unplayable, the failure is almost always at the codec level — the container parsed fine, but the device has no decoder for the bitstream inside it. We see this pattern regularly when teams test on the devices in the office and assume the broader device population behaves the same way.

How Do H.264, HEVC, AV1, and VP9 Compare?

The honest comparison is multi-dimensional. Compression efficiency is one axis; hardware decode support, encode cost, and licensing are the others, and they often pull in opposite directions. The table below is the conceptual shape of the trade-off, not a benchmark for any specific library.

Codec Comparison Matrix (Conceptual)

Codec	Relative compression efficiency	Hardware decode support	Encode cost	Licensing posture
H.264 / AVC	Baseline	Near-universal, including very old devices	Lowest	Mature patent pool, widely licensed
HEVC / H.265	Roughly 30–50% better than H.264 (varies by content)	Broad on modern devices, gaps on older/budget hardware	Higher than H.264	Fragmented patent pools — the cost complication
VP9	Comparable to HEVC	Good in browsers and Android, weaker elsewhere	High	Royalty-free (Google)
AV1	Better than HEVC/VP9	Newest, narrowest hardware-decode base, growing	Highest (heaviest encode)	Royalty-free (Alliance for Open Media)

The efficiency figures here are directional, drawn from the general pattern reported across the encoding community rather than a single named benchmark — treat them as the relative ordering, not a guaranteed number for your content. What the matrix makes visible is the central tension: the codecs with the best compression (AV1, HEVC) carry the heaviest encode cost and the narrowest hardware-decode support, while the codec everything can play (H.264) leaves compression efficiency on the table.

H.264 remains the safe default precisely because near-universal decode support means no playback regressions. HEVC, covered in depth in our explainer on what HEVC/H.265 means for transcoding cost, buys real bandwidth savings but drags a licensing question behind it. AV1 offers the best compression but demands the most encode compute and reaches the smallest installed base of hardware decoders today.

Why Codec Choice Depends on the Viewer Device Mix

Here is the reframe that separates a codec quality dial from a codec economics decision: a codec is only as good as the devices that can decode it, and the decode side matters more than the encode side because there is exactly one encode and there are millions of decodes.

If a device has a hardware decoder for the codec — a dedicated block in the GPU or SoC — playback is fast and power-efficient. If it does not, the device must fall back to software decoding on the CPU, which drains battery, heats the device, can stutter on high resolutions, and on the weakest hardware simply fails. So the question is never “which codec compresses best?” It is “which codec compresses best among the codecs my actual viewers can hardware-decode?”

Answering that requires data you have to measure, not assume: the share of your device population that can hardware-decode each candidate codec, broken out by device class. A streaming service whose audience skews toward recent flagship phones and smart TVs can lean into HEVC or AV1 with confidence. A service with a long tail of older Android devices, budget set-top boxes, or regional hardware will find that the compression win evaporates the moment a meaningful slice of viewers drops to software decode or fails to play at all.

This is the same reasoning that governs the broader video transcoding cost and quality trade-offs at streaming scale — codec selection is one lever inside that larger economics problem, and it is the lever that decides the per-stream cost floor.

How Does Codec Choice Affect Transcoding Cost and GPU Encode Time?

Every codec a streaming service supports is a transcode it has to run. Most platforms encode each title into several codecs and several bitrate ladders to cover their device population, and each additional codec multiplies encode compute.

Encode cost scales sharply with codec complexity. HEVC encoding is meaningfully heavier than H.264, and AV1 software encoding is heavier still — by a large margin in configurations we have seen, though the exact ratio depends on the encoder, the preset, and the content. This is where GPU encode hardware enters the picture. NVIDIA’s NVENC, the encode blocks on data-centre GPUs, and dedicated hardware encoders shift the cost curve by offloading the work from general-purpose CPU cores, but hardware-encoder support for the newest codecs (AV1 in particular) is itself a moving target. A codec your GPUs can hardware-encode costs a fraction of one they have to encode in software.

The bandwidth that codec compression saves trades directly against the encode and storage cost of producing more codec variants — and that tension is fundamentally a cost-versus-value question, not a raw-spend one. The reasoning for treating efficiency, cost, and delivered value as distinct quantities — rather than chasing the lowest unit number — is laid out well in this analysis of cost, efficiency, and value in AI hardware. The same logic applies to a codec ladder: the cheapest encode is not the same as the best-value codec strategy, and the only way to know which one you have is to measure cost-per-stream before and after a migration, segmented by device class.

“Video Codec Not Supported”: What Does It Actually Mean?

When a player shows “video codec not supported,” the container loaded but the device has no decoder for the bitstream inside it. It is almost never a corrupted-file problem and almost always a codec-availability problem.

This error clusters on predictable hardware. Older devices lack decoders for codecs that postdate them — an old smart TV will never play AV1 because the silicon predates the standard. Specific vendors ship inconsistent codec support, so a feed that plays on one phone brand fails on another of the same vintage. Budget and regional hardware often omit the newer hardware decoders to save cost. The pattern is the same in every case: the codec is fine, the device just can’t decode it.

This is exactly why the device-mix data matters before you migrate codecs. A codec selected without profiling the viewer device population can break playback on the very hardware that most needs the bandwidth savings, while a codec chosen against measured device-class data lands the compression gain where it actually pays.

How Do Licensing and Patent-Pool Costs Factor In?

Compression efficiency is the visible cost axis. Licensing is the invisible one, and at streaming scale it can dominate the decision.

H.264 has a mature, well-understood patent pool with predictable licensing. HEVC is the cautionary case: its patents are split across multiple pools with overlapping and sometimes ambiguous terms, which historically slowed HEVC adoption among streaming services wary of unpredictable per-stream or per-device royalties. That licensing fragmentation is a large part of why the royalty-free codecs exist — VP9 from Google and AV1 from the Alliance for Open Media were created specifically to remove the patent-cost question from the equation, which is why large streaming and browser vendors have backed AV1 despite its heavy encode cost.

So the total cost of a codec at streaming scale is not just its compression efficiency. It is encode compute, plus storage for the extra variants, plus the share of viewers who can hardware-decode it, plus whatever the licensing terms cost multiplied across your stream volume. A codec that compresses 40% better but carries an uncertain per-stream royalty may cost more than the one it replaces.

FAQ

How does video codec work, and what does it mean in practice?

A codec (coder-decoder) compresses raw frames into a small bitstream on the encode side and reconstructs them on playback. It does this by removing spatial redundancy within frames and temporal redundancy between frames — storing occasional full keyframes and otherwise only the differences. In practice this means a codec decides not just file size but encode compute cost, decode hardware requirements, and per-stream economics.

What is the difference between a codec, a container, and a bitstream?

The bitstream is the compressed video data the codec produces; the codec is the algorithm and standard defining how that bitstream is structured and decoded (H.264, HEVC, AV1, VP9); the container is the file format wrapping video, audio, and metadata together (MP4, MKV, WebM). The same codec can live in different containers, and one container can hold different codecs — which is why playback failures are usually codec-level, not container-level.

How do the common codecs compare on compression, hardware support, and licensing?

H.264 is the baseline with near-universal hardware decode and mature licensing; HEVC compresses roughly 30–50% better depending on content but carries fragmented patent-pool licensing; VP9 is comparable to HEVC and royalty-free; AV1 compresses best but has the heaviest encode cost and the narrowest hardware-decode base, while being royalty-free. The codecs with the best compression carry the highest encode cost and the least universal decode support.

Why does codec choice depend on the viewer device mix rather than picking the most efficient codec?

A codec is only useful if your viewers’ devices can decode it, ideally in hardware rather than on the CPU. Software decode drains battery, can stutter, and on weak hardware fails outright. The right question is which codec compresses best among the codecs your measured device population can hardware-decode — which requires profiling device-class data, not assuming the newest codec is best.

How does codec selection affect transcoding cost and GPU encode time?

Each supported codec is another transcode to run, and encode cost rises sharply with codec complexity — HEVC is heavier than H.264, and AV1 software encoding is heavier still. GPU hardware encoders such as NVENC shift this cost by offloading the work, but hardware-encode support for newer codecs is itself limited. The bandwidth saved by better compression trades directly against the encode and storage cost of producing more codec variants.

When does a newer, more efficient codec actually pay off?

A newer codec pays off when a large enough share of your device population can hardware-decode it, the encode cost is covered by your GPU encoders, and the licensing terms are predictable — so the bandwidth savings exceed the added encode, storage, and royalty cost. It introduces regressions when it is selected without device-mix data, breaking playback on older hardware or raising cost faster than it saves bandwidth.

What does “video codec not supported” actually mean?

It means the container loaded but the device has no decoder for the bitstream inside it — a codec-availability problem, not a corrupted file. It clusters on older devices that predate the codec, specific vendors with inconsistent codec support, and budget or regional hardware that omits newer hardware decoders to cut cost.

How do licensing and patent-pool costs factor into a codec’s total cost?

Beyond compression efficiency, a codec’s cost at streaming scale includes encode compute, storage for extra variants, the share of viewers who can hardware-decode it, and licensing. HEVC’s fragmented patent pools historically slowed its adoption because per-stream or per-device royalties were unpredictable, which is precisely why royalty-free codecs like VP9 and AV1 were created.

Where This Leaves the Codec Decision

The reframe is simple to state and easy to forget under pressure: codec choice is an economics decision constrained by a real device population, not a quality dial you turn toward “newest.” The compression number on the spec sheet is the start of the analysis, not the answer.

The remaining uncertainty is always empirical and always specific to your audience. What share of your viewers can hardware-decode each candidate codec? What does each codec’s encode cost on your GPU fleet, and what does steady-state encode capacity look like once you add a codec variant across the whole catalogue — a production capacity-planning question as much as an encoding one? What does cost-per-stream do, by device class, after the migration? Those numbers, not the codec’s headline efficiency, decide whether a codec change pays off — and turning them into a profiled encoder-pipeline decision is the work that the broader transcoding-economics methodology in our media and telecom broadcast practice and media-telecom industry page is built to do.