Hardware video decoding working on intel 11th gen CPU/GPU Ubuntu 26.04 firefox snap except for AV1 decoding

[tractor556]

I have a related problem, (happy to open as a new topic if required). I have hardware video decoding working on intel 11th gen CPU/GPU Ubuntu 26.04 firefox snap except for AV1 decoding which only uses software. My hardware can do that AV1 decode and Chrome or Firefox flatpack does do AV1 hardware decoding as seen on intel_gpu_top, just not with firefox snap. The firefox snap reports hardware decode is available. All updated to latest versions.

[marcelstevano]

I believe this is currently a Firefox Snap-specific limitation rather than an Intel AV1 decode issue.

Your hardware is capable of AV1 decoding (11th Gen Intel/Xe supports it properly), and the fact that Chrome or Firefox Flatpak can use AV1 hardware decode already confirms the VAAPI stack itself is working correctly.

I have seen multiple similar reports where:

• H264/VP9 decode works through VAAPI

• AV1 falls back to dav1d/software decoding

• intel_gpu_top shows no Video engine activity only on Firefox Snap

The issue appears to be related to the Snap sandbox and Firefox’s media/RDD pipeline handling for AV1.

You can verify this by checking: vainfo | grep AV1

and also monitoring: intel_gpu_top

during AV1 playback.

A few things worth trying in about:config:

media.ffmpeg.vaapi.enabled = true
media.hardware-video-decoding.force-enabled = true
gfx.webrender.all = true
media.rdd-ffmpeg.enabled = true

Also make sure intel-media-va-driver-non-free is installed.

That said, from my testing and from other reports, the most reliable workaround is simply using Firefox Flatpak or the Mozilla tarball/native build instead of the Snap package.

On Flatpak, AV1 VAAPI decode works correctly on the same Intel hardware where Firefox Snap falls back to software decode.

So at this point I suspect this is not a driver issue, but an unresolved Firefox Snap integration problem affecting AV1 specifically.

[marcelstevano]

I eventually removed the Ubuntu Snap build and switched to the official Mozilla Flatpak from Flathub.

sudo snap remove firefox

sudo apt install flatpak

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

flatpak install flathub org.mozilla.firefox

flatpak run org.mozilla.firefox

Then enable the usual VAAPI settings in about:config

media.ffmpeg.vaapi.enabled = true
media.hardware-video-decoding.force-enabled = true
media.rdd-ffmpeg.enabled = true
gfx.webrender.all = true

You can verify AV1 capability with: vainfo | grep AV1

and monitor actual hardware decode usage with: intel_gpu_top

In my case the Flatpak build immediately started using the Video decode engine during AV1 playback, while the Snap package continued to decode AV1 in software.

At this point I strongly suspect this is a Firefox Snap sandbox/runtime issue affecting the VAAPI AV1 pipeline rather than a problem with Intel Xe media drivers themselves.

[peterwhite23]

@marcelstevano

media.hardware-video-decoding.force-enabled = true

There are usually good reasons for those switches to be off. I did similar things and it did work with the snap version too, when it wasn’t some missing content snap, of course, but I also experienced rather strange issues, like loads of zombie processes; every video left one or more of those behind, which is a memory leak, so could lead to RAM exhaustion. I believe it was the same on the native version and related to Wayland. So it might be best to stick as closely to default as possible, even if it means to forego some features for the time being; there could be good reasons for these things not being on by default in the snap, which is maintained by Mozilla, after all. about:support should be consulted, which has some mentions of blacklist and whatnot to indicate deliberate choices.

[marcelstevano]

That’s why I recommend Firefox Flatpak

[peterwhite23]

How does that prevent issues such as I’ve just described? It only seems to make easier. You still need to override default settings best left alone. When something says force in its name that’s a clear sign that one should have a clear understanding of all the implications and failure modes before. Such settings have a habit to stick around even long after they are no longer necessary, but by then they may have been forgotten all about.

[tractor556]

For the Firefox flatpak to work with harware vidieo decoding I don’t think I needed to change any settings. Using firefox Flatpak is hopefully a temporary fix until the SNAP gets fixed. Hopefully with a few bug reports here there is enough to work on it. Does a bug report need opening somewhere or is one already open?

[Peter0612]

@tractor556

For the Firefox flatpak to work with harware vidieo decoding I don’t think I needed to change any settings.

I can tell the same about Firefox from tarball. The only thing I did is change intel-media-driver from free to non-free. Definitely the problem we discuss here is snap-specific.

[ogra]

This has been discussed before (with more or less successful solutions):

What does it take to get video hardware acceleration?

With Ubuntu Plucky, what does it take (if it’s even possible) to get hardware accelerated video playback in youtube and google meet with the browsers: google chrome upstream deb chromium snap firefox snap On xorg, and wayland. Or is only one possible? I’m still hitting issues with wayland in plucky, but that’s a topic for another post. Last time I had that working was in Oracular, and that was after a lot of messing around with packages and different combinations. And IIRC it only worked in …

Enabling accelerated video decoding in Firefox on Ubuntu 21.04

In this past year there has been work to make Firefox hardware decode video on Linux. Ubuntu 21.04’s switch to wayland luckily makes this feature more accessible and easier to enable. Benefits: Hardware video decoding in Firefox greatly reduces CPU usage when watching video. This saves power, improves thermals and reduces fan noise, all while ensuring computer resources are more free to do other things while watching video. While the feature is not perfect, I have been reliably using it for …

You should definitely open a bug so it can be fixed …

[nteodosio]

Yes, please do file the bug. Meanwhile, you can try sudo snap refresh --candidate mesa-2404.

[peterwhite23]

That also switches to that channel permanently, which may be more than users bargained for. One can also install specific revisions from arbitrary channels:

snap=mesa-2404
revid="$(snap info "$snap" | gawk '$1 ~ /^latest\/candidate:$/ {print gensub(/[()]/, "", "g", $4)}')"
sudo snap refresh --hold "$snap"
sudo snap refresh --revision="$revid" "$snap"

This finds the current revision on the latest/candidate channel, disables automatic refreshes of the snap and then refreshes to the found revision. Holding is required because snapd will otherwise revert to the tracked channel revision.

Once the revision will have trickled down into the stable channel just unhold:

sudo snap refresh --unhold "$snap"

[peterwhite23]

Here’s an alternative about:config setting for folks who just want some HW decoding to work:

media.av1.enabled = false

This way the next best codec should be selected automatically, most probably VP9.

To get some more info on why a particular setup isn’t working, about:support#graphics has a “Decision Log”; here’s what mine says about AV1 HW decode:

AV1_HW_DECODE	default available env blocklisted #BLOCKLIST_FEATURE_FAILURE_VIDEO_DECODING_MISSING Blocklisted; failure code FEATURE_FAILURE_VIDEO_DECODING_MISSING

No surprise there, since this machine has no AV1 decoder. There can however be other reasons, like “Blocklisted by gfxInfo … FEATURE_FAILURE_BROKEN_DRIVER” for other features, so best look closely.

[peterwhite23]

I have found some additional info, which may be of interest to people with rather recent hardware, but I have posted it to the other thread, from which this was split, I believe. TL;DR, the mesa-2404 content snap, as the default gpu-2404 provider, may simply lack support for your hardware, which can most probably be confirmed by the method outlined in my previous post.

So yes, it’s an issue with the Firefox snap, but more by design than by bug.

[tractor556]

Logged the bug here in any case https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2153181

[peterwhite23]

It’s probably a good idea to click Copy text to clipboard in about:support and attach that to the report, as well.

Here’s something I noticed:

[RDD 135856: Main Thread]: D/PlatformDecoderModule FFMPEG: version: 0x80, macro: 60, micro: 102, isFFMpeg: yes
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support unknown for hw decoding
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_VP9 for hw decoding
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_VP8 for hw decoding
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_HEVC for hw decoding
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_H264 for hw decoding
[RDD 135856: Main Thread]: D/PlatformDecoderModule FFMPEG: version: 0x200, macro: 62, micro: 101, isFFMpeg: yes
[RDD 135856: Main Thread]: D/PlatformDecoderModule FFVPX: Link result: Success
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_AV1 for hw decoding
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_VP9 for hw decoding

zoomed/trimmed:

[RDD 135856: Main Thread]: D/PlatformDecoderModule Support unknown for hw decoding
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_VP9 for hw decoding
...
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_AV1 for hw decoding
[RDD 135856: Main Thread]: D/PlatformDecoderModule Support AV_CODEC_ID_VP9 for hw decoding

That Support unknown right in the same place where the later Support AV_CODEC_ID_AV1 for hw decoding with the “other” FFMPEG version is.

[tractor556]

yes I did spot that there appear to be two lists of decoder codecs and one has AV1 listed and the other doesn’t