There is an ongoing effort to enable hardware accelerated video playback on Firefox.
Has anybody tried to get this working on NixOS?
It appears that Firefox cannot find the appropriate libva libraries.
[Child 7022: Main Thread]: D/PlThis text will be hiddenatformDecoderModule VA-API support: Missing or old libva-wayland.so.2 library
This is on NixOS 20.03 with the firefox-wayland package from the nixos-20.03 channel , installed via either environment.systemPackages or nix-env as a regular user, but other firefox packages yield the same result.
Did this already… on e.g. Arch Linux or Fedora this is working as expected, on NixOS hardware accelerated video via e.g. mpv or vainfo is also working fine. It’s just Firefox in this case.
Ah, i should have mentioned this in the first post… I don’t know much about Plasma and which compositor library KDE uses, but apparently to the relevant Bugzilla entries, GNOME’s Mutter and also, what i’m using here, sway with wlroots do support zwp_linux_dmabuf, which is necessary for DMABUF on Firefox. This very same setup is working just fine on Arch Linux.
Yes, unfortunately Firefox on NixOS currently doesn’t support VA-API as no one had enough time/interest to update the build expression so far. But firefox-bin already supports it (PR 81917) if that would work for you as well.
[Child 7022: Main Thread]: D/PlThis text will be hiddenatformDecoderModule VA-API support: Missing or old libva-wayland.so.2 library
If Firefox is already looking for the library then the linked PR should be enough, but that change wasn’t backported to 20.03. You could test installing firefox-wayland from nixos-unstable if you want.
You are right, thanks a bunch for the hint.
Firefox indeed seems to find the appropriate libs now and initializes VA-API decoding correctly.
libva info: VA-API version 1.7.0
libva info: User environment variable requested driver 'i965'
libva info: Trying to open /run/opengl-driver/lib/dri/i965_drv_video.so
..
libva info: Found init function __vaDriverInit_1_5
libva info: va_openDriver() returns 0
..
[Child 1494: MediaPDecoder #1]: D/PlatformDecoderModule VA-API FFmpeg init successful
...
[Child 1494: MediaPDecoder #3]: D/PlatformDecoderModule Got one VAAPI frame output with pts=80333 dts=80333 duration=40000 opaque=-9223372036854775808
But, Martin Stransky has this [1] blogpost up about VA-API on Firefox, where it states that Window Protocol should be “wayland/drm” instead of just “wayland”. Obviously, i don’t know about the implications of this, just wondering if other perhaps got different results. I’m on NixOS-20.03 and perhaps mesa 19.3 from release is just to old.
It also has the benefit of making using firefox the same as using the other firefox derivations that respect the same convention. firefox-wayland is the odd-ball now.
I kind of wonder if others were using firefox like me and couldn’t get vaapi working because WR wasn’t actually working right…
I’m on Firefox 77.0.1 with firefox-wayland from nixos-unstable now and it appears that VAAPI is indeed used, where it applies, according to intel_gpu_top measurements.
Waiting for Firefox 78 hitting the shelves now, as there have been important performance fixes [1] gone into this release, especially around stuttering/flickering with UI-elements on-screen.
About the Window Protocol: This is just a guess, but perhaps VAAPI is indeed used to decode the frames, but Firefox still copies the decoded frames from the GPU to the CPU and back again without “wayland/drm”.
Anyhow, @primeos is correct in this context, as FF from unstable has now added libva to the wrapper libs, also, this whole FF hardware acceleration topic is still under heavy development and today still is dependend on many other factors.
@colemickens There have been issues [2] around opengl in firefox lately, which webrender is dependend upon.
So now that the PR are merged we should use firefox instead of firefox-wayland and just enable gfx.webrender.enabled and widget.wayland-dmabuf-vaapi.enabled in about:config and that’s it?
How do you test that it’s working? With the CPU usage? I don’t seem to see much of a difference.
The only difference in firefox-wayland is that it sets MOZ_ENABLE_WAYLAND=1 in the wrapper. (And I guess we put “(Wayland)” into the Application title in the Desktop unit.)
As for confirming, I just repeated these instructions with a fresh profile:
Hopefully this can give you an idea if it’s working or not. Change the nix-build to account for your nixpkgs or NIX_PATH.
Important note: I have MOZ_ENABLE_WAYLAND set desktop-wide. You will need to set it as well, or modify the command below to use the firefox-wayland attribute. In fact, to be safe, I’m going to do that here:
D/PlatformDecoderModule Got one VAAPI frame output with
They are both present.
Note, Firefox Nightly users might not want to aggressively enable all dmabuf/drm options. My stable profile has all related options enabled, and it worked well, but Nightly has even more knobs available and some didn’t work out well with my system (though do note, we have libva, mesa and other related changes coming soon to nixos-unstable that might help too).
Anyone got this to work with X11? I’m trying with two Thinkpad T520s, the other works with Arch Linux. With Arch, if I run with MOZ_LOG="PlatformDecoderModule:5" I can see VAAPI in the messages, when playing a video from Youtube. With NixOS I don’t see it. I use the enhanced-h264ify addon.
Edit: not working on a Slimbook with AMD Ryzen 4800H either.
Here is a summarised version of my configuration.nix:
Required prefs are: media.ffmpeg.vaapi.enabled=true (use hw video decoding), media.ffvpx.enabled=false (use system ffmpeg), gfx.webrender.all=true (use OpenGL rendering)
env vars: MOZ_X11_EGL=1 is correct and required for VAAPI. MOZ_LOG=“PlatformDecoderModule:5” is of course only needed if you want to check the log.
VAAPI is definitely broken in 80 (bug 1656436), technically the first VAAPI on X11 release. It was left broken for Wayland.
Please try Beta 81 or Nightly 82.