Knowledge Base Categories

GNU: VAAPI HW Decoding For Laptops with Integrated Graphics

May 11, 2022

If you're using a laptop, you probably don't have a discrete GPU—not if you care about battery life. But you probably still want to play videos without dropping frames. All laptops ship with some form of integrated graphics on the CPU, and the vast majority of modern (and even not-so-modern) CPUs support some level of hardware decoding. Here's a good place to start to get hardware decoding working: https://wiki.archlinux.org/title/Video_acceleration

Particularly relevant is mpv's section for hardware decoding, which you must enable manually even if hardware decoding is setup system-wide: https://wiki.archlinux.org/title/Mpv#Hardware_video_acceleration

While the mpv manual discourages always setting hardware decoding via mpv.conf for what I'm sure are good reasons, the not so great alternatives are manually setting it via the developer console with every video, using hwdec=auto-safe (which might be deprecated at some point), or setting a keyboard shortcut to enable/disable it.

I'm lazy. I set this in my mpv.conf file:

hwdec=vaapi-copy

If you're wondering why I'm using vaapi-copy instead of vaapi, it's because EasyCrop won't work otherwise.

Another program you may want to enable hardware decoding on is your browser. Here's the section for Firefox: https://wiki.archlinux.org/title/Firefox#Hardware_video_acceleration

I don't recommend playing video in browsers at all if you can avoid it. Install yt-dlp to use mpv as a player for videos on YouTube and hundreds of other sites just by passing the link:

mpv https://www.youtube.com/watch?v=dQw4w9WgXcQ

You will be unable to avoid this if you use streaming services that make use of the anti-feature, web DRM. Some of these services include: Netflix, Amazon Prime, Hulu, Disney+, and Commsec. However, as almost all of these services use Google Widevine, no 32-bit GNU/Linux computers can use these services: https://support.mozilla.org/en-US/kb/enable-drm

For an autopsy of the web following the introduction of Web DRM, see: https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-we-just-lost-web-what-we-learned-it-and-what-we-need-do-next