H.264, HEVC and AV1: why the codec decides what plays

Every few years the video industry ships a codec that produces the same picture at roughly half the bitrate of the last one, and charges for it in decoding complexity. For live television that trade has a specific consequence: your provider saves bandwidth, and you find out whether your hardware can keep up.

The three generations#

H.264, standardised in 2003, is the universal one. Every device made this century decodes it in hardware. It is also the least efficient of the three, so an H.264 channel at a given quality uses the most bandwidth.

HEVC, standardised in 2013, is the current default for anything high-resolution. Roughly half the bitrate of H.264 for comparable quality. Hardware support is broad on anything from the last decade, and it is what most 4K IPTV channels use.

AV1, published by the Alliance for Open Media in 2018, is the newest, with the licensing story that made it attractive to large distributors. Roughly half of HEVC again. Hardware decoding is common on recent GPUs and absent on everything older.

codec    standardised   relative bitrate   hardware decode
H.264    2003           baseline           universal
HEVC     2013           about half         broad, last 10 years
AV1      2018           about half again   recent GPUs only

The pattern repeats each time: better compression, more decoding work, narrower hardware support until the world catches up. Which codec is best is never the interesting question. Where your hardware's boundary sits is.

Why a hardware decoder is different in kind#

Everything else follows from this, and it is easy to miss because both look like "playing a video".

A hardware decoder is a fixed-function circuit on your GPU that implements one specific codec. It is not a fast version of the software decoder; it is a different thing that happens to produce the same output. It uses almost no CPU, draws little power, and either exists for your codec or does not.

There is no partial support. A GPU with an AV1 decoder decodes AV1 at 4K without effort. A GPU without one contributes nothing to AV1 at all, and the work falls to the CPU running software.

Software decoding works. It is also expensive in exactly the way you would expect: many cores at high utilisation, a hot laptop, fans, and on a device without headroom, dropped frames.

We have the numbers on the good case, and we have them because we got this wrong ourselves. With hardware decode engaged, a 4K HEVC Main10 title ran with the GPU video-decode engines at around 11 percent. That same path was software-only until 2026-08-23. The decoder selection is a per-media option applied every time something is opened rather than a property of the player, and one on-demand code path had been hard-coding it off regardless of the setting, for months. Same file, same machine, same setting on the screen, and the only visible difference was a fan spinning up. That is the whole reason a wrong decoder goes unnoticed: the picture plays either way. Hardware versus software decoding covers that boundary in detail.

AV1, and the split it creates#

The clearest real-world case of all this in our own apps.

The desktop head can decode AV1 on the GPU where the GPU supports it. The console head cannot, at all: the player build it links carries no AV1 hardware decoder. An AV1 channel on a console falls back to software.

And that fallback has its own ceiling. Decoder frame threads are capped at 3 there, for a measured reason: left to choose for itself the decoder picked 6, which produced a 40-surface output pool at 4K, about 500 MB of GPU-visible commit against roughly 1 GB usable on the console. Hardware decode never touches those threads, so the cap is free on every path that works. It bites precisely where AV1 lands.

What a viewer sees: a channel that plays cleanly on a Windows machine and stutters or fails on the console, with the same account, the same network and the same source. Why a channel works on Windows but not on Xbox is the diagnostic version.

How to find out what a channel uses#

Harder than it should be.

The catalogue does not know. The live channel record carries no codec field, no container field and no transport field, because neither an M3U line nor the panel API provides one. There is nowhere for that information to come from before you open the stream.

The stream information panel will tell you once playback starts, but read it knowing what it is doing. Protocol comes from the URI scheme and container from the file extension on the path, with a not-available literal when the path has none. It derives those from the URL rather than asking the demuxer, so a portal that serves HLS from a path ending .ts is described by its address rather than by its contents.

The video codec field is the one that answers this article's question. Read that one.

Two things people attribute to codecs that are not codecs#

HDR is not a codec property. It travels with HEVC and AV1 in practice because those are what modern high-resolution content uses, but the requirement is a 10-bit surface and a colour space the display accepts. In our case that took an app-owned swapchain, because the stock video control builds an 8-bit buffer and DXGI will not accept an HDR10 colour space on one, so the negotiation could only ever land on sRGB regardless of the stream.

Bitrate is not quality. A channel encoded in HEVC at 8 Mbit/s and one in H.264 at 8 Mbit/s do not look the same, and the HEVC one is not automatically better either: a badly configured encoder wastes any codec's advantage. What the codec buys is a better position on the quality-per-bit curve. Whether your provider spends that on lower bandwidth or a better picture is their decision, not the format's.

Profiles and levels, and why "supports HEVC" is not a complete answer#

A codec name starts the compatibility question rather than ending it. Each standard defines profiles, which say which coding tools are allowed, and levels, which bound resolution and bitrate.

Bit depth matters most for live television. HEVC Main handles 8-bit video; HEVC Main10 handles 10-bit. A decoder can support one and not the other, and 10-bit is what HDR content uses, so "my GPU supports HEVC" and "my GPU decodes this HDR channel" are different statements.

The 4K title in our own verification pass was HEVC Main10 specifically, and that profile is the interesting case precisely because it is where a lot of older hardware stops.

Levels bind the other axis. A decoder rated for a level that covers 1080p60 will not necessarily take 4K60 from the same codec. This is the usual explanation for a provider's HD feed playing while their 4K feed of the same channel does not, on hardware that undeniably "supports" the codec.

What a provider is actually deciding#

The codec on your screen is the output of somebody else's cost calculation.

A provider carrying hundreds of channels pays for bandwidth on every one of them, continuously. Moving a channel from H.264 to HEVC halves that bill for the same picture. Moving it again to AV1 halves what remains.

What they do with the saving is a separate decision, and both choices are common. Some spend it on bandwidth and ship the same picture for less. Some spend it on quality and ship a better picture for the same bitrate. That is why comparing two providers by bitrate alone tells you very little: 6 Mbit/s of well-configured HEVC can look better than 12 Mbit/s of badly configured H.264.

The cost lands on you as decoding work, and hardest on whoever has the oldest hardware. This is why a channel you have watched for a year can suddenly start stuttering with nothing on your side having changed. The provider re-encoded it.

That inverts the usual diagnosis. When one channel degrades and everything else is fine, check its codec before your network.

How this interacts with failure detection#

The playback detector classifies 9 distinct faults, and a decoder that cannot keep up does not have its own class. It shows up as one of the existing ones, which is worth understanding so the diagnosis is not misread.

Software decoding that falls behind presents as a stalled picture or a total freeze while bytes keep arriving. The network is fine, the demuxer is fine, and frames are not reaching the screen fast enough. From the detector's seat that is indistinguishable from a source that stopped producing frames, because the counters look the same.

So the detector does what it does for any freeze: wait out the verdict window, declare, and attempt recovery. Recovery on a decode-bound channel does not help, because restarting the stream does not make the decoder faster. You get a channel that plays for a few seconds, freezes, restarts, and repeats.

That loop is the signature. A stream problem tends to recover or fail; a decode problem cycles. When you see cycling, check the codec. Fixing buffering and stuttering covers the fault classes, and video freezes while audio continues covers why a frozen picture never raises an error.

The lever that is not a codec choice#

You do not control what codec your provider ships. You do control how much of it you ask the machine to decode at once.

Multiview is the clearest case. Tiles are capped at 640 by 360 when muted and 1280 by 720 for the one carrying audio, and that cap is what makes a 9 tile grid possible on ordinary hardware. Nine 640 by 360 decodes is a different proposition from nine full-rate 1080p ones, whatever the codec. The same reasoning applies to a single channel: if your provider offers a lower rendition, taking it reduces the work rather than moving it between the CPU and the GPU.

What to do with this#

If a specific channel fails on one device and works on another, check its video codec first. It takes 30 seconds and it resolves the majority of these.

If you are buying hardware for this, AV1 hardware decode is the thing to check on the spec sheet. H.264 and HEVC are settled questions on anything current.

And if a channel is AV1 and your device cannot decode it in hardware, ask your provider whether the same channel is available in HEVC. Many carry both, and that is a faster fix than any setting.

For the fault classification when a stream does not play at all, fixing buffering and stuttering starts by separating 9 distinct failures.