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:
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:
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