Firefox Vulkan Video Decoding Still Needs a Manual Pref

Firefox 153 shipped Vulkan Video decoding on July 21, 2026, and left the switch off. Linux still decodes through VA-API unless you flip two prefs in about:config.

NVIDIA engineer Tymur Boiko wrote the path so Arm boxes and NVIDIA cards could skip VA-API. Two releases later the code is in the tree, and the default is still no.

Firefox 153 Shipped the Decoder Off by Default

The binaries went out on July 21. HDR playback on Windows, built-in Containers, PDF merge, and JPEG XL in Labs all made the Firefox 153 notes Mozilla published. Vulkan Video did not.

That omission matches how the feature actually ships. The decoder lives behind media.hardware-video-decoding-vulkan.enabled and media.hardware-video-decoding-vulkan.direct-export.enabled. Restart after both are true, then play something your GPU can handle. H.264 is the safe test.

The June merge of Vulkan Video decoding closed Boiko’s implementation bug for the 153 branch. Coverage treated that merge as the end of the NVIDIA workaround. It was the start of a gated FFmpeg path.

Public posts peaked around the July 21 upload, then went quiet. The live argument moved into Bugzilla, where the default-on ticket is still open.

An NVIDIA Engineer Opened the Arm Bug

Bug 2021722 is not an NVIDIA feature request. Boiko filed it against Firefox 150 because a video on Aarch64 Linux never touched the GPU. The expected result was simple: use a hardware decoder when the chip has one.

Linux Firefox had spent years on VA-API. Mesa’s Intel and AMD drivers speak it. NVIDIA’s proprietary driver does not, which is why people glue NVDEC to VA-API through a third-party module. Smaller Arm and embedded drivers often never grew a VA-API stack at all. Vulkan Video is the vendor-neutral way around that gap.

Boiko’s patches added a Vulkan Video path in FFmpegVideoDecoder, vendored Khronos headers from vulkan-sdk-1.4.341.0, and hooked DMA-BUF export into the compositor. He told Red Hat’s Martin Stransky the change should work on other GPUs if the Vulkan SDK and FFmpeg 6.1.1 are present, and that he had checked NVIDIA and Intel.

Stransky would not land the first blob as-is. He asked for a split series so the existing VA-API path would not break, and he said it was fine to make NVIDIA work first so long as other arches stayed intact. AMD’s early dmabuf export failed to become an EGLImage on his box. The review frame was “don’t break Intel and AMD,” not “flip this on for everyone.”

Two Prefs and a Sandbox That Missed 153

Decode runs in Firefox’s RDD process, a sandboxed helper. Vulkan Video still needs EGL to reach the display server so it can export dmabuf images. The first sandbox policy did not allow those sockets. With the sandbox on, decode failed or fell back to the CPU. With MOZ_DISABLE_RDD_SANDBOX=1, the same build worked. That is the same environment variable the NVIDIA VA-API wrapper has demanded for years.

With the RDD sandbox enabled, Vulkan hw video decode fails or is unreliable (fallbacks to CPU). With MOZ_DISABLE_RDD_SANDBOX=1, the same build works.

Tymur Boiko, NVIDIA engineer, Bug 2046954

Boiko wanted that sandbox fix in 153 by July 21. The patch landed, got backed out for browser_sandbox_test.js failures, then relanded for the 155 branch. Firefox 154, which became release the following week, was marked wontfix. Stransky tested the decoder on an AMD RX 6600 with Mesa 26.1.3 on Fedora 44 and Wayland, and it worked with only the main pref, with or without the sandbox patch. NVIDIA was the setup that needed the extra hole.

THE VULKAN VIDEO PATH IN FIREFOX

1. Early June 2026: Bug 2021722 is marked fixed for the 153 branch after Boiko and Stransky land the FFmpeg Vulkan path, GTK prefs, and compositor hooks.
2. July 21, 2026: Firefox 153 ships with both Vulkan prefs off. The RDD sandbox still blocks NVIDIA decode unless MOZ_DISABLE_RDD_SANDBOX=1 is set.
3. August 18, 2026: Firefox 154 ships 28 days later. The sandbox bug stays wontfix on that branch.
4. September 1, 2026: Firefox 155 ships 14 days after 154, the first twice-monthly release, with the RDD sandbox policy that lets EGL connect for dmabuf export.

Six weeks after 153, the decoder could finally run inside the sandbox it was supposed to use. The prefs did not flip with that fix.

Which GPUs Can Use Vulkan Video?

Khronos already defined H.264, H.265, AV1 and VP9 decode as Vulkan Video extensions, so the GPU API is no longer the missing piece. Firefox still only uses the codecs a given driver exposes, and H.264 is the clip testers are told to start with. There is no public compatibility list. The browser probes Vulkan the first time the pref is on.

LINUX DECODE PATHS IN FIREFOX 155

Early how-tos and a Linux Mint tester on nvidia-driver-595-open both pointed at NVIDIA 595.x as the floor. That Mint box listed VK_KHR_video_decode_h264, h265, av1, vp9, and the decode queue. After the two prefs, about:support showed hardware decode. nvtop and nvidia-smi still showed no decoder load on the videos that were playing.

A dual-GPU laptop can wake the discrete NVIDIA chip during playback and hitch when workspaces change. Boiko also told testers to set nvidia-drm modeset to Y. The path is real on Stransky’s RX 6600. It is still a trial on a lot of NVIDIA desktops.

Seven Open Bugs Block a Default Switch

Mozilla engineer Paul Adenot opened a meta bug to enable Vulkan video decoding by default on Linux desktops. The ticket is still NEW. Bugzilla lists seven open bugs in front of it. Adenot named the same two prefs Boiko shipped. Direct export, he wrote, is worth taking if it works.

Stransky wants that direct-export pref folded into the same HW_DECODED_VIDEO_ZERO_COPY feature VA-API already uses, so Vulkan does not keep a private switch. Dependent tickets have kept landing through September, including compositor, sandbox, and zero-copy follow-ups. The meta bug was still taking those links in the second week of September.

Mozilla has not named a release that will flip the pref. When it does, the plan is to gate on GPU and driver combos that have actually been shown to work, not to force every Linux profile onto Vulkan.

The Old Wrapper Still Wins on NVIDIA

The community VA-API wrapper for NVIDIA still documents Firefox prefs, a direct backend, and environment variables. That page exists because the browser path is not the default. One NVIDIA user on Ubuntu 26.04 wrote that Vulkan decode fell back to software after a rhythmic stutter. Turning the Vulkan pref on also disabled the VA-API driver, so a broken experiment took away the setup that had been playing video.

That is the second-order cost the June headlines skipped. VA-API remains the path that Intel and AMD users already have. Vulkan is a second stack that can steal the first if someone turns it on for a card that then stutters. Until Adenot’s meta bug closes, the wrapper is still the reliable NVIDIA option, and Arm machines that never had VA-API still need a driver that actually advertises the Vulkan video extensions.

WHAT STILL HAS TO BE TRUE

• The build: Firefox 155 or newer, so the RDD sandbox lets EGL talk to the display server without MOZ_DISABLE_RDD_SANDBOX=1.
• The prefs: media.hardware-video-decoding-vulkan.enabled and media.hardware-video-decoding-vulkan.direct-export.enabled both set to true, then a restart.
• The driver: NVIDIA 595 or newer with nvidia-drm modeset, or Mesa with the Vulkan video decode extensions, plus a clip the GPU can actually decode.
• The fallback: If playback stutters or about:support lies, turn the Vulkan prefs back off so VA-API can take the session again.

Firefox 155 put the decoder on speaking terms with its own sandbox. The meta bug to make that the Linux default is still open, with seven open bugs in front of it. NVIDIA users who want GPU decode without a fight still install the wrapper.