Hardware versus software decoding: why your fan spins up

Two ways to turn a compressed video stream into pictures. They produce the same output, and almost nothing else about them is the same.

What each one is#

Hardware decoding hands the compressed stream to a fixed-function block on your GPU. That block implements one specific codec in silicon. It is not a faster version of the software decoder; it is dedicated circuitry that happens to produce the same frames, using almost no CPU and very little power.

Software decoding runs the decoder as ordinary code on your CPU, across several cores. It works for any codec the software supports, which is nearly all of them, and it costs real CPU time.

The distinction that matters most: hardware support is binary per codec. Your GPU either has a decoder for AV1 or it does not. There is no partial acceleration, no degraded mode, no "mostly hardware". If the block is absent, the work falls entirely to software.

The setting, and what it actually emits#

Three states, mapping to three decoder selections handed to the player with each piece of media:

Auto   avcodec-hw=d3d11va   ask for the Direct3D 11 video decoder
On     avcodec-hw=any       take any hardware decoder available
Off    avcodec-hw=none      software only

Auto is right for almost everyone. Off is a debugging tool: if a channel shows corruption or fails to open, forcing software decode tells you within one attempt whether you are looking at a driver problem or a stream problem.

One structural detail, because it caused a real bug. This is a per-media option, applied every time a piece of media is opened, rather than an instance-level switch set once at startup. That is the right design. It also means each playback path has to remember to apply it.

The bug that hid in exactly that gap#

Until 2026-08-23, live TV honoured the acceleration setting and the on-demand path hard-coded it to off. Every film and every episode was software decoded, regardless of what the setting said, on every machine.

We got this wrong, and nothing about it was visible from the interface. The setting existed, it persisted, it said Auto, and films decoded in software anyway. It surfaced as "films make the fan spin up and live TV does not", a symptom easy to blame on file size or bitrate.

After the fix, the same 4K title played with the GPU video-decode engines at about 11 percent. Same file, same machine, same setting.

The reason to write this down rather than fix it quietly: it is the clearest illustration of why you verify hardware decode is engaged rather than trusting a setting. Open the stream information panel, and check your GPU's video-decode engine in Task Manager while something plays. A 4K stream with the video-decode engine near zero and CPU cores loaded is software decoding, whatever the setting says.

Threads, and a cost you would not predict#

When software decoding does happen, the decoder splits frames across threads. How many it chooses matters for reasons that have nothing to do with CPU time.

Left to choose for itself, the decoder picked 6 threads on the measurement machine. That produced a 40-surface Direct3D 11 output pool at 4K, roughly 500 MB of GPU-visible commit. Against an Xbox budget of about 1 GB, that is half the memory the whole application is allowed, spent on decoder buffers. I did not expect a thread count to be a memory decision.

So the console caps it at 3.

The elegant part of that cap is what it costs, which is nothing on any path that works. Hardware decode does not use those threads at all. The cap applies only to the software fallback, which on the console is where AV1 lands, because the console's player build has no AV1 hardware decoder.

The other lever, which is not a decoder setting#

If decode cost is your problem, resolution is a bigger lever than the decoder choice.

Multiview tiles are capped to 640 by 360 when muted and 1280 by 720 when carrying audio, and that cap is why a 9 tile grid is possible at all. It is less a quality compromise than an acknowledgement that a tile 4 inches wide does not benefit from 1080p.

The same reasoning applies to a channel your machine struggles with. If your provider offers the same channel at a lower rendition, that is often a better answer than any setting, because it reduces the work rather than redistributing it.

How to actually verify it, in 2 minutes#

The setting is not evidence. This is.

Open Task Manager, go to Performance, select your GPU, and change one of the graphs to Video Decode. Then start a channel.

Video Decode busy, CPU cores quiet     hardware decoding
Video Decode flat, several cores busy  software decoding

That is the whole test, and it is definitive in a way the settings screen is not. On the machine in our own verification pass, a 4K title moved that graph to about 11 percent where it had previously sat at zero with the CPU carrying the work.

Two false readings to know about. A machine with 2 GPUs may be decoding on the one you are not looking at, which is common on laptops with switchable graphics. And a very small window can be cheap enough to decode in software without obvious CPU load, so test at a size you would actually watch.

The stream information panel is the other half of the check, because it tells you which codec you are asking the machine to decode. Its protocol and container fields are derived from the URL rather than from the demuxer; the video codec field is the one that answers this question.

The memory cost, which is the surprising part#

Decoding is usually discussed as a CPU-versus-GPU trade. On a memory-constrained device it is a memory decision as much as a processing one, and the numbers are not intuitive.

Frame threading allocates picture buffers. More threads means more buffers in flight, and at 4K each buffer is large. That is the whole story behind the 500 MB pool above, and it is why the cap is 3 rather than a number chosen for CPU reasons. It is also why the cap costs nothing where hardware decode is working: the hardware path does not allocate those buffers at all.

The wider context makes it sharper. Our own profiling of a 12 minute browse session on the desktop ended at 918 MB of working set and peaked at 1,080 MB, against an internal budget of 400 MB, with the managed heap flat at about 62 MB across the same cycles. The growth is native, and decoder buffers are native. On a console with roughly 1 GB usable, a software decode path that wants 500 MB of pools is not a performance problem. It is a termination.

Why "just fall back" is not a design#

A reasonable-sounding suggestion: try hardware, and if it fails, switch to software automatically and silently.

What makes that harder than it sounds is the failure mode of the layer underneath. Handing the player a switch belonging to a module its build does not carry does not produce a recoverable error. It fails the entire player instance, and the failure does not name the option that caused it. The stream does not open.

So the emitted switch set is computed up front, per head, from an allow-list, with tests asserting that every combination of head, role, setting and surface depth emits only permitted switches. The alternative, discovering support by trying things, means a failed attempt costs a whole instance and produces an error that points nowhere.

This is also why capabilities the console cannot support are hidden rather than shown and disabled. There is no partial version to degrade to, and a control that would fail the player if used is worse than no control.

There is a genuine fallback ladder, and it shows what a well-behaved one looks like. The video surface tries 3 configurations in order:

1  R10G10B10A2 + Ignore        preferred, 10-bit
2  R10G10B10A2 + Unspecified   10-bit, different alpha handling
3  B8G8R8A8 + Unspecified      8-bit, identical to the previous behaviour

What makes that ladder safe is the last rung: it is byte-identical to the configuration that shipped before any of this existed, so a machine that cannot compose 10-bit behaves exactly as it always did rather than entering an untested state. A total failure logs and leaves the surface unloaded rather than throwing out of a layout callback, which would take the application down.

A fallback is only a fallback if the bottom rung is known good.

What to check, in order#

Is hardware decode actually engaged? Look at the GPU video-decode engine, not at the setting.

If it is not, is there a hardware decoder for this codec on this machine? H.264, HEVC and AV1 covers where the boundaries sit, and AV1 is where most of them are.

If there is, are your GPU drivers current? Dull advice, and occasionally the whole answer, because decoder support ships in drivers.

And if this machine will never decode this codec in hardware, the options are a lower rendition, a different codec from the provider, or different hardware. No setting substitutes for a circuit that is not there.