Harness your hardware for smoother streaming
Use your fancy graphics card to decode videos and free up your CPU for your other calculations and compositions.
Since browsing the web constitutes a great deal of most people’s computing time, we thought we’d see if we could find any subtle differences between each distro’s out-of-the-box Firefox configuration. We’ve said before that Firefox can be made smoother by enabling the WebRender backend and activating VA-API for hardwareaccelerated video decoding. But getting this to work in the real world takes a bit of trial and error.
Both distros ship Firefox 93, and if you do a fresh install of Ubuntu this uses Mozilla’s Snap. Users upgrading from previous Ubuntus will get the DEB version from the repos. The first step is getting VA-API working, which on Ubuntu was pretty easy. A simple sudo apt install vainfo pulled in all the required video drivers. Then running vainfo and not getting an error message showed that iHD (the MediaSDK driver for newer Intel graphics) was ready for VA-API processing. On Fedora the process was harder. The package containing vainfo is called libvautils on Fedora, but just installing this (with dnf install libva-utils ) was not enough – no drivers were pulled in. We searched the base repositories for libva and found libva-intel-hybrid-driver , which turned out to be no use – that driver is for older chips and we had a 10th Gen Dell XPS. So a bit of Googling evinced that the required drivers were available in the RPMfusion repositories.
RPMfusion hosts various popular packages that can’t be included in Fedora’s stock offerings. There are two RPMfusion repositories, free and nonfree and they’re really easy to enable nowadays. So easy you don’t even need to type anything: just browse to https://rpmfusion. org/Configuration and click the “RPM Fusion free” link for Fedora 35 (or whatever version you’re running). Firefox on Fedora is already set up to open RPM files with Package Installer, so follow the prompts (don’t worry about the “missing security signature” warning) and the repository will be added. Inside the free repo you’ll find the libva-intel-driver package, which contains the i965 libva-accelerated driver.
Intel Inside, but is it working?
This works for all but the most recent (Icelake and above) Intel chips, but on Gen8 graphics (Broadwell) and above you may want to try the iHD driver. This contains some proprietary bits, and as such can be found in the nonfree RPMfusion repo. Add that in the same way as we added the free one (you can’t enable only RPMfusionnonfree). Then install the iHD driver with a swift sudo dnf install intel-media-driver , and a quick look at vainfo will show if you’re in business. To decode the video you’ll also want the ffmpeg-libs package from RPMfusion-nonfree.
Actually getting VA-API playback enabled in Firefox 93
took a bit of headscratching. Fortunately the same options worked on both distros, so we’ll summarise them here. Open about:config in Firefox and set the following options to true :
gfx.webrender.all media.ffmpeg.vaapi.enabled media.navigator. mediadatadecoder_vpx_ enabled
The last one will speed up VPx-encoded WebRTC traffic, which is what’s used for video chatting.
There are a number of posts online that suggest other options, but this is a fast-moving area, so some of these will be out of date. Some contained bad advice to begin with – in particular, anyone telling you to disable Firefox’s RDD (remote data decoder) process by unsetting media.rdd-process. enabled or via the MOZ_DISABLE_RDD_SANDBOX
environment variable should be ignored. The current situation is that the RDD sandbox blocks VA-API, causing a seccomp sandbox violation error if you start Firefox
from the terminal. But turning it off altogether is a security risk, so don’t do that. Instead, selectively disable it for video decoding by setting media.rdd-ffvpx.enabled and media.rdd-vpx.enabled to false.
You can check if it’s working by starting Firefox with this doozy:
$ MOZ_LOG="PlatformDecoderModule:5,Dmabuf:5” firefox
This generates a huge amount of output to pore over and will probably overrun your terminal’s scrollback buffer in no time. Try pausing the video after a very short time to check you’re not missing some early error messages. If you see messages like VAAPI releasing dmabuf surface among it then this is indicative of success. Different hardware supports different formats, in particular decoding AV1 (denoted AV01 in the Stats for Nerds overlay in the YouTube player) requires very new hardware (newer than our 10th Gen XPS). VP8/9 and h264 (AVC in YouTube) video are more widely supported. For new hardware using the iHD driver it’s currently required to set security.sandbox.content.syscall_ whitelist to 220 and start Firefox with
$ MOZ_SANDBOX_ALLOW_SYSV=1 firefox
in order to let a required syscall out of the sandbox and not upset the iHD driver.
If all that seemed like hard work, rest assured that getting VA-API working with the Firefox Snap (the default browser on Ubuntu) proved much harder. In fact, at the time of writing it seems downright impossible because the Gnome platform Snap is missing those driver libraries we mentioned earlier. A fix is on the way, but if it hasn’t landed yet you can uninstall the Snap and use the version from the repositories without issue. Just use the options we’ve given here, some combination of them will surely work.
There’s another reason you might not want to use the Firefox (or Chromium) Snap in Ubuntu, particularly if you’re a fan of Gnome extensions. Cast your eye at https://bugs.launchpad.net/ubuntu/+source/ chromium-browser/+bug/1741074 and you’ll see that both browsers refuse to load the native host connector plugin. That’s what the website extensions.gnome.org
uses to manage your Gnome extensions, and without it these can’t be managed in the browser. It’s not the end of the world – there’s a desktop tool called Gnome Extensions available in Ubuntu Software. Or install it manually with:
$ sudo apt install gnome-shell-extension-prefs
There, your extensions are yours again, but popular password managers also use native messaging to talk to browser plugins, so if you use those you’ll want to avoid Snap-based browsers for now. Rob Gibbon, product manager at Canonical, assured us that there are plans to fix this in time for the LTS release. And this is a healthy reminder that, while annoying, it’s good that such bugs get visibility through the interim releases. In general, using a Firefox build that comes directly from Mozilla is a good move. One of the main motivations behind Snaps (and Flatpaks) was to enable developers to ship their software independently of distro packagers. It’s a sentiment echoed by Rob: “Mozilla wants to deliver Firefox directly to the user, which is great for everyone involved. From a QA perspective, we worked with Mozilla to ensure its QA processes met our needs for Ubuntu”.
Nvidia and AMD
We tested the libva situation pretty thoroughly on Intel graphics, and thanks to the Mesa drivers the situation should be much the same on AMD hardware, or with the Nouveau driver. The proprietary Nvidia driver has its own Nvdecode and Nvencode API, which is supported on some applications, but not web browsers. There’s another API libvdpau, again lacking support in popular web browsers, but widely supported by media players and AMD and Nvidia hardware. Interestingly, The Gnome web browser (sometimes known as Epiphany) supports all these APIs through Gstreamer. As usual, the Arch Wiki is the best place to get the lowdown on all this, in particular the lovely tables at the end of the video acceleration page at https://wiki.archlinux.org/title/ Hardware_video_acceleration.