Verify that VP8 HW encoding/decoding is really working on Linux

Question

I have the "Beebox" from "ASRock". The processor of this machine is an Intel Celeron N3150 which supports hardware encoding and decoding of VP8 video streams. I would like to use this feature in Google Chrome (on Debian Linux) for making WebRTC calls. But I'm not sure how to proove that Chrome is really using HW encoding/decoding.

My findings so far

Unfortunately the situation on Linux is very confusing. Apart from the different acceleration APIs (VAAPI, VDPAU, etc.), of which I don't know which of them Chrome is really using, Chrome adds additional confusion by saying:

Video Decode: Software only, hardware acceleration unavailable

Video Encode: Hardware accelerated

on the "chrome://gpu" page.

Encoding: Even though ist says that encoding is accelerated, I have a CPU load of 60-70% when encoding HD Video as a VP8 stream. This doesn't look like HW encoding to me.

Decoding: As far as I read on the web, HW decoding does not seem to be supported at all on Chrome under Linux. There is a Chrome switch called --ignore-gpu-blacklist which indeed turns the "Video Decode" line from "Software only ..." to "Hardware accelerated", but this does not change anything. I also did some research with different media players like Kodi and VLC. These players show a CPU load of approx 25-30% when playing VP8 which indeed could be HW decoding, but surprisingly enough there is no change at all when I turn off HW encoding in these players. Which in turn makes me believe that even these do not decode in HW.

Tools: I found some tools, even from Intel, but most of them refer to the GPU load (which means 3D acceleration). I also tried glxinfo from mesa-utils which says: "direct rendering: Yes" and according to this thread confirms that HW decoding (?) is supported. But this just tells that support is available, but not whether currently any application is really using it.

Question

Is there a way to clearly verify whether or not the hardware enoder and/or decoder is working when a VP8 video stream is encoded or decoded on Linux?

I'd appreciate your help very much!

Answer 1

1) There's a more specific flag that matters here. In Chrome://gpu, you should see VPx Video Decode:

Does it say hardware or software?

2) Relatedly, something to try: Go to YouTube in Chrome, play any video. Right-click on the video while it's playing and choose Stats for Nerds from the context menu.

That will tell you if YouTube is giving you VP8, VP9, or H.264. This can be a helpful clue, especially if you're getting H.264. (It would be more helpful on a laptop, because if Chrome is like MS Edge, it will stop advertising VPx support when the laptop is on battery power, forcing YouTube to give it H.264, because VPx consumes a lot more battery than H.264 even when it's hardware decoded. H.264 is a much less taxing codec, and its hardware decoding is more efficient than VPx hardware decoding. Kaby Lake might finally close the gap.)

3) There are a few other issues. The Chrome software rendering list has some interesting entries that suggest that Chrome might be ignoring even fairly new Intel GPUs, including your Braswell chip. Check it out here. Notice that one entry says: "VPx decoding is too slow on Intel Broadwell, Skylake, and CherryView".

If you follow the breadcrumb trail, you see that means every gpu with some specific PCIID mask (N3150 should be 0x22b1 for example). That's Windows only though, and moreover it may as well be a remnant of an old bug already fixed.

Keep also note of other possible entries, some of which mention specific Intel driver versions, as well as specific Linux kernel versions.

4) Make sure that your Chrome://flags page actually indicates that the software rendering list is overriden (it's the very first flag). You mentioned the command-line syntax, with the old "blacklist" term, but this flag has had some bugs in recent years, basically not working for some people and other issues. I would just double-check that however you set this flag, it actually shows up with the right setting in the flags page. If not, obviously set it properly in that page. Note that there's a bug, which may or may not be tied to your issues – overriding the software rendering list flips the VPx Video Decode flag in chrome://gpu to Hardware Accelerated even on PCs that have no VPx hardware acceleration, like the Ivy Bridge laptop I'm on now with an Intel HD 4000. I don't know if this is just a presentational bug, and Chrome is not actually attempting to use hardware acceleration, or if Chrome is actually doing so (which would seem to have to crash or something, but it doesn't).

The Chrome flags are a mess of confusion and colliding word choices. The flag says Override software rendering list. This flag needs to be enabled, not disabled. But if it's enabled, you won't see the word Enabled or any kind of status indicator. You'll see the word Disable, as an invitation to change the setting. Just so you know... maybe this is all old hat to you.

5) Last ditch, but very powerful resource to see what's going on with VP8 on your system is the Intel Media SDK. If it's not free by default, it's free as part of the student version of Intel's IDEs/C++ compilers, and the free trial editions of the paid IDE editions. There's a lot you can do there to see what's up. I was struck by this passage in page 24 of their Developer's Guide:

Hardware acceleration can be added to FFmpeg with a simple compile step. For applications written to use FFmpeg command line or libav* APIs they can then be hardware enabled by changing the codec name – for example from libx264 to h264_qsv.

I would play around with that method for the VP8 codecs in ffmpeg to see if you can trigger hardware acceleration on your system at all, outside of Chrome.

6) Also note that the term "hardware acceleration" when it comes to video codecs is used inconsistently across the industry, and I'm not sure what exactly Chrome means by it (in the flags). Decode can be accelerated by a GPU, or it can be performed fully in hardware by a fixed-function unit which also happens to be on the GPU (but does not use GPU shaders). Both of these are called hardware acceleration, but they're not the same thing. Sometimes "fully in hardware" or "fixed function" will be used to differentiate that scenario from general GPU acceleration (which is sometimes called partial acceleration or hybrid acceleration).

The official docs are quite confusing, but Braswell (just like its predecessor and Broadwell) should have full fixed function decoding for VP8. While encoding and VP9 (just like in Skylake, which may have the same QSV module) are provided via an hybrid solution. I think they are using some kind of GPU acceleration (with the shaders, maybe using OpenGL or OpenCL or something but I don't know the details). This distinction can matter especially when you are with a device on battery (let alone HEVC would be leaps and bounds more efficient as per quality). And I guess like this may justify the Chrome dev team's decisions on how to use your Braswell model. Unfortunately, all of this is poorly documented...