Windows 10 reached EOS (end of support) on October 14, 2025. If you are on Windows 10, see this article.

Avatar for Username

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More
Open

Hardware Video Decoding (VA-API) Blocked on AMD Stoney + Hainan Dual-GPU System — Arch Linux / Wayland

Firefox Audio and Video
sagenuage81 replied
miglemaya057
miglemaya057

Hello Firefox Support Team/Forum

I am writing to request guidance on a hardware video acceleration issue that I have been unable to resolve despite extensive troubleshooting. Firefox appears to be blocking VA-API hardware decoding on my system even though the VA-API stack is confirmed working at the system level. — SYSTEM SPECIFICATIONS — OS: Arch Linux (rolling), kernel 7.0.13-arch1-1 Desktop: Hyprland 0.55.4 (Wayland, DRM backend) CPU: AMD A9-9425 (2 cores, 3.1GHz, Excavator architecture) RAM: 8GB Firefox: installed via pacman (native, not Flatpak) Mesa: 26.1.3-arch1.2 GPU setup (dual): • card0 / renderD128: AMD Stoney R5 Graphics (iGPU) — VA-API confirmed working here • card1 / renderD129: AMD Hainan R5 M435 (dGPU) — used by Hyprland for display output — CONFIRMED WORKING AT SYSTEM LEVEL — Running ‘vainfo’ on the integrated GPU (renderD128) confirms the following profiles are available: VAProfileH264ConstrainedBaseline, VAProfileH264Main, VAProfileH264High (VLD + EncSlice) VAProfileHEVCMain, VAProfileHEVCMain10 (VLD) VAProfileMPEG2Simple, VAProfileMPEG2Main, VAProfileVC1 (VLD) VAProfileJPEGBaseline (VLD) MPV with ‘–hwdec=vaapi-copy’ successfully hardware-decodes H264 locally, confirmed by ‘nv12’ pixel format output and reduced CPU usage. radeontop monitoring card0 (stoney, bus 00) during Firefox video playback shows: • Graphics pipe: ~53% (compositing activity) • UVD row: absent / 0% (no hardware video decode activity) • Memory clock: near 0.00G This confirms Firefox is NOT using the hardware decoder despite VA-API being functional. — FIREFOX DECISION LOG (from about:support) — HARDWARE_VIDEO_DECODING: default available / user force_enabled H264_HW_DECODE: default available (no blocklist) HEVC_HW_DECODE: default available VP8_HW_DECODE: env blocklisted — FEATURE_FAILURE_VIDEO_DECODING_MISSING VP9_HW_DECODE: env blocklisted — FEATURE_FAILURE_VIDEO_DECODING_MISSING AV1_HW_DECODE: env blocklisted — FEATURE_FAILURE_VIDEO_DECODING_MISSING DMABUF_SURFACE_EXPORT: env blocked — FEATURE_FAILURE_BROKEN_DRIVER WEBRENDER_COMPOSITOR: env blocklisted — FEATURE_FAILURE_WEBRENDER_COMPOSITOR_DISABLED Note: VP8/VP9/AV1 being missing is expected and correct for this GPU generation. The concern is that H264, which IS in the vainfo profile list and shows as ‘available’ in the decision log, is still not being routed to the hardware decoder in practice. — ENVIRONMENT VARIABLES IN USE — MOZ_ENABLE_WAYLAND=1 LIBVA_DRIVER_NAME=radeonsi LIBVA_DRM_DEVICE=/dev/dri/renderD128 MOZ_DISABLE_RDD_SANDBOX=1 — about:config SETTINGS CURRENTLY SET — media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.force-enabled = true media.hardware-video-decoding-vulkan.enabled = false media.rdd-process.enabled = true — WHAT WAS TRIED — 1. Installed full Mesa stack: mesa, libva-mesa-driver, libva-utils, ffmpeg, vulkan-radeon (64-bit and 32-bit variants via multilib). 2. Set LIBVA_DRM_DEVICE=/dev/dri/renderD128 to hardcode VA-API to the stoney iGPU and prevent it from accidentally targeting the hainan dGPU (which fails Firefox’s internal VA-API test with FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED). 3. Enabled media.ffmpeg.vaapi.enabled and media.hardware-video-decoding.force-enabled in about:config. 4. Disabled MOZ_DISABLE_RDD_SANDBOX via both ~/.bash_profile and hl.env() in the Hyprland Lua config to allow Firefox’s RDD process to access /dev/dri/renderD128. 5. Installed enhancedH264ify extension with VP9 and AV1 blocking enabled. YouTube confirms H264 (avc1.64002a) is being served. Despite this, over 1100 frames out of ~4200 are dropped during 1080p60 playback. 6. Verified with radeontop -b 0 (stoney, bus 00) during active 1080p H264 playback: the UVD block shows no activity whatsoever, confirming the CPU is doing all decoding. 7. Tested with and without gfx.webrender.all = true. Enabling it caused severe visual corruption (texture artifacts, split UI elements), so it was reset to default. 8. Did NOT disable media.rdd-process.enabled (correctly kept at true, as RDD is the process Firefox uses for VA-API decoding). 9. Confirmed Firefox is installed via pacman (not Flatpak), so there is no Flatpak sandbox layer involved. — THE CORE QUESTION — Given that: • vainfo confirms H264 hardware decode is available on renderD128 • H264_HW_DECODE shows as ‘default available’ in Firefox’s own decision log with no blocklist entry • media.hardware-video-decoding.force-enabled is set to true • MOZ_DISABLE_RDD_SANDBOX=1 is set • LIBVA_DRM_DEVICE explicitly points to the correct render node • MPV successfully uses vaapi on the same system …why is Firefox’s RDD process still not routing H264 decoding through VA-API, and what additional steps or logs would help identify the specific internal failure point?

Any guidance on enabling verbose VA-API logging within Firefox’s RDD process, or any known issues with AMD Stoney + Hainan dual-GPU setups on Wayland that might explain the DMABUF_SURFACE_EXPORT FEATURE_FAILURE_BROKEN_DRIVER blocklist, would be greatly appreciated.

Thank you.

Hello Firefox Support Team/Forum I am writing to request guidance on a hardware video acceleration issue that I have been unable to resolve despite extensive troubleshooting. Firefox appears to be blocking VA-API hardware decoding on my system even though the VA-API stack is confirmed working at the system level. — SYSTEM SPECIFICATIONS — OS: Arch Linux (rolling), kernel 7.0.13-arch1-1 Desktop: Hyprland 0.55.4 (Wayland, DRM backend) CPU: AMD A9-9425 (2 cores, 3.1GHz, Excavator architecture) RAM: 8GB Firefox: installed via pacman (native, not Flatpak) Mesa: 26.1.3-arch1.2 GPU setup (dual): • card0 / renderD128: AMD Stoney R5 Graphics (iGPU) — VA-API confirmed working here • card1 / renderD129: AMD Hainan R5 M435 (dGPU) — used by Hyprland for display output — CONFIRMED WORKING AT SYSTEM LEVEL — Running ‘vainfo’ on the integrated GPU (renderD128) confirms the following profiles are available: VAProfileH264ConstrainedBaseline, VAProfileH264Main, VAProfileH264High (VLD + EncSlice) VAProfileHEVCMain, VAProfileHEVCMain10 (VLD) VAProfileMPEG2Simple, VAProfileMPEG2Main, VAProfileVC1 (VLD) VAProfileJPEGBaseline (VLD) MPV with ‘–hwdec=vaapi-copy’ successfully hardware-decodes H264 locally, confirmed by ‘nv12’ pixel format output and reduced CPU usage. radeontop monitoring card0 (stoney, bus 00) during Firefox video playback shows: • Graphics pipe: ~53% (compositing activity) • UVD row: absent / 0% (no hardware video decode activity) • Memory clock: near 0.00G This confirms Firefox is NOT using the hardware decoder despite VA-API being functional. — FIREFOX DECISION LOG (from about:support) — HARDWARE_VIDEO_DECODING: default available / user force_enabled H264_HW_DECODE: default available (no blocklist) HEVC_HW_DECODE: default available VP8_HW_DECODE: env blocklisted — FEATURE_FAILURE_VIDEO_DECODING_MISSING VP9_HW_DECODE: env blocklisted — FEATURE_FAILURE_VIDEO_DECODING_MISSING AV1_HW_DECODE: env blocklisted — FEATURE_FAILURE_VIDEO_DECODING_MISSING DMABUF_SURFACE_EXPORT: env blocked — FEATURE_FAILURE_BROKEN_DRIVER WEBRENDER_COMPOSITOR: env blocklisted — FEATURE_FAILURE_WEBRENDER_COMPOSITOR_DISABLED Note: VP8/VP9/AV1 being missing is expected and correct for this GPU generation. The concern is that H264, which IS in the vainfo profile list and shows as ‘available’ in the decision log, is still not being routed to the hardware decoder in practice. — ENVIRONMENT VARIABLES IN USE — MOZ_ENABLE_WAYLAND=1 LIBVA_DRIVER_NAME=radeonsi LIBVA_DRM_DEVICE=/dev/dri/renderD128 MOZ_DISABLE_RDD_SANDBOX=1 — about:config SETTINGS CURRENTLY SET — media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.force-enabled = true media.hardware-video-decoding-vulkan.enabled = false media.rdd-process.enabled = true — WHAT WAS TRIED — 1. Installed full Mesa stack: mesa, libva-mesa-driver, libva-utils, ffmpeg, vulkan-radeon (64-bit and 32-bit variants via multilib). 2. Set LIBVA_DRM_DEVICE=/dev/dri/renderD128 to hardcode VA-API to the stoney iGPU and prevent it from accidentally targeting the hainan dGPU (which fails Firefox’s internal VA-API test with FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED). 3. Enabled media.ffmpeg.vaapi.enabled and media.hardware-video-decoding.force-enabled in about:config. 4. Disabled MOZ_DISABLE_RDD_SANDBOX via both ~/.bash_profile and hl.env() in the Hyprland Lua config to allow Firefox’s RDD process to access /dev/dri/renderD128. 5. Installed enhancedH264ify extension with VP9 and AV1 blocking enabled. YouTube confirms H264 (avc1.64002a) is being served. Despite this, over 1100 frames out of ~4200 are dropped during 1080p60 playback. 6. Verified with radeontop -b 0 (stoney, bus 00) during active 1080p H264 playback: the UVD block shows no activity whatsoever, confirming the CPU is doing all decoding. 7. Tested with and without gfx.webrender.all = true. Enabling it caused severe visual corruption (texture artifacts, split UI elements), so it was reset to default. 8. Did NOT disable media.rdd-process.enabled (correctly kept at true, as RDD is the process Firefox uses for VA-API decoding). 9. Confirmed Firefox is installed via pacman (not Flatpak), so there is no Flatpak sandbox layer involved. — THE CORE QUESTION — Given that: • vainfo confirms H264 hardware decode is available on renderD128 • H264_HW_DECODE shows as ‘default available’ in Firefox’s own decision log with no blocklist entry • media.hardware-video-decoding.force-enabled is set to true • MOZ_DISABLE_RDD_SANDBOX=1 is set • LIBVA_DRM_DEVICE explicitly points to the correct render node • MPV successfully uses vaapi on the same system …why is Firefox’s RDD process still not routing H264 decoding through VA-API, and what additional steps or logs would help identify the specific internal failure point? Any guidance on enabling verbose VA-API logging within Firefox’s RDD process, or any known issues with AMD Stoney + Hainan dual-GPU setups on Wayland that might explain the DMABUF_SURFACE_EXPORT FEATURE_FAILURE_BROKEN_DRIVER blocklist, would be greatly appreciated. Thank you.

All Replies (1)

sagenuage81
sagenuage81

The dual-GPU part is where I would look first. Firefox is stricter than mpv here: mpv can use `vaapi-copy`, but Firefox normally has to pass decoded frames through its compositor path. If decoding is forced to renderD128 while Wayland/display output is on the Hainan GPU, the VA-API test can still fail or get bypassed even though `vainfo` is fine.

A few checks that usually make this clearer:

- start Firefox from a terminal with `MOZ_LOG="PlatformDecoderModule:5,FFmpegVideo:5" firefox` and look for the exact VA-API/FFmpeg reason when playing an H264 video; - in `about:support`, check the “Codec Support Information” section, not only the feature decision log; - test once with Firefox using the same GPU for display and VA-API, if possible, just to remove the cross-GPU/dmabuf variable; - undo `MOZ_DISABLE_RDD_SANDBOX=1` after testing. It is useful as a diagnostic, but I would not leave the media sandbox disabled as the final workaround.

If same-GPU testing works and mixed-GPU testing does not, then it is probably not a Firefox preference problem so much as a dmabuf/cross-device path limitation.

Ask a question

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.