Evaluating Intel A380 QSV Encoding

Let’s examine how Intel encodes on modern graphics cards.

My previous experience was entirely unimpressive, starting from building the source code and preparing for encoding in general. An embarrassingly large amount of time was spent on what seemed like a simple task. We even had to involve system programmers just to even get MFX working.

A recent test with the N100 platform showed a slightly better picture. Getting QSV working with FFMPEG build and encode adequately failed (the inadequacy was in uncontrollable bitrate). However, the encoding utility from the SDK delivered stable results. And I managed to evaluate the H.264 video compression quality.

The current situation with a discrete card and new code pleasantly surprised me twice and once “did not disappoint” (in quotes, because I still couldn’t get the HEVC codec to run). So, let’s look at the pleasant part, H.264 and AV1.

Before moving to the graphs, I want to note the set of test videos differs from what the graphic card manufacturers use. It’s done deliberately to show how the codecs perform under certain conditions, on “difficult” scenes. In the companies’ promotional materials, you may likely find a greater spread in quality when comparing to competitors.

You can find the exact test fragments chosen here: https://www.vmetrix.tech/methodology/. Encode parameters here: https://www.vmetrix.tech/encode-parameters/.

Aggregated BDBR metrics: https://vmetrix.tech:3000/d/ads7nhh/bd-br-aggregated

RD Curves: https://vmetrix.tech:3000/d/adrgpg7/rd-curves

H.264

Comparison with itself. I’ll use average BDBR VMAF values across all videos (reminder: negative BDBR is good, positive is bad).

Presets veryslow vs veryfast. Yes, there is a gain. At best, about 1% bitrate savings – for the smallest 144p videos. For others, the difference is even smaller.

Don’t try to encode at low bitrates since the codec will ramp it up anyway. Usual pattern is shown in the next graph. For a target bitrate of 461K for 1080p, the output was 1.5 times higher.

Although this pattern appears with almost all hardware codecs.

Let’s compare with the “reference,” libx264, preset slow.

Basically, nothing unexpected. A bitrate deficit within 7% – 11% for main frame sizes. Which is not bad overall.

What about NVENC?

The veryslow preset is slightly worse than H.264 NVENC p4, i.e., around 2% – 5% for main frame sizes. However, for 4K there is even a small gain.

The gain would be around 22% – 25% comparing to the fastest preset.

Compared to the highest quality p7 – a deficit of up to 10%. But for “common” frame sizes, up to 7%. Which is not bad overall.

AV1

First, let’s see how much better it is than its own H.264 implementation.

And here are the promised 50% savings – but only for 4K. The biggest gain, an impressive 83%, you’ll get on such a “heavy” scene with many moving objects.

And what about NVENC?

I’d to clarify the results were obtained using NVENC 9th gen, i.e., NVidia Blackwell GPU. The 8th gen (Ada) seems slightly worse. I’ll examine the difference in the future.

Comparing best quality presets, QSV will need about 9% – 13% more bitrate to support the same quality as NVENC.

And the final chord – a comparison with H.264 RK3588 (don’t blame them, there’s no b-frames), sorry…

What’s left out the box – is a comparison to software AV1 codecs like SVT-AV1 and libaom. As well as a comparison of encoding speed and power consumption. I hope to add it soon…