Hardware vs software encoding

Every modern GPU and most CPUs ship a dedicated video encoder: NVIDIA’s NVENC, Intel’s Quick Sync, AMD’s AMF, Apple’s VideoToolbox. They are dramatically faster than encoding in software, and they are not simply better. The trade-off is specific and worth understanding, because picking wrong costs you either hours or megabytes.

What the hardware actually is

A hardware encoder is a fixed-function circuit: silicon laid out to do one job. It does not run code, so it cannot be improved by a software update the way x264 has been improved continuously since 2004. What ships in the chip is what you get for the life of the card.

That constraint buys enormous speed. A GPU encoder can run several 4K streams in real time while barely touching the CPU, because it is not competing for general-purpose compute at all. A software encoder at a slow preset might manage a fraction of real time on the same machine and saturate every core doing it.

Why the files come out bigger

Compression efficiency comes from searching: trying many ways to predict a block and keeping the cheapest. Software encoders can search exhaustively because they are just code, and their slow presets do exactly that. Fixed silicon has a budget of gates and a hard real-time target, so it searches a narrower space, skips expensive tools, and takes the first good-enough answer.

The practical gap, at matched quality: expect a hardware H.264 encode to run roughly 20 to 50 percent larger than x264 -preset slow. The exact figure moves with content and generation, and it has narrowed considerably. Modern hardware encoders gained B-frame support, better rate control and lookahead, and the newest AV1 blocks are genuinely good. But the direction of the gap has never reversed, and on current hardware it will not.

The AV1 hardware landscape

AV1 hardware encoding arrived later than AV1 decoding, and unevenly. Intel’s Arc GPUs shipped a well-regarded AV1 encoder first and remain a strong price-to-quality option; NVIDIA added AV1 encode from the Ada generation (RTX 40 series) onward, and AMD from RDNA 3. Earlier cards that advertise AV1 often mean decode only, which is the trap in a spec sheet: decode support is far more common than encode.

You can check what your own machine exposes to the browser on the browser capability page, and the transcode lab runs on exactly those encoders, which is why its results differ from machine to machine.

Choosing

Use hardware when time is the constraint and the file is transient. Live streaming, video calls, game capture, transcoding a large library on a deadline, any preview render. If it must keep up with real time, this is not a close call.

Use software when the bytes matter more than the minutes. Anything you encode once and serve many times: a video on a landing page, a library master, an archive. Paying an hour of CPU once to save 30 percent on every future delivery is arithmetic that favours software overwhelmingly, and it is the same logic behind choosing a slower preset.

Watch the rate control. Hardware encoders historically defaulted to CBR or plain VBR, which spends bits badly on easy content. Most now expose a constant-quality mode (-cq on NVENC, -global_quality on QSV); using it closes a surprising amount of the gap for free.

Do not benchmark them against each other on speed alone. A hardware encoder at its fastest setting versus x264 at veryslow is a comparison of two different jobs. Match the output size, then look at the frames.