Closed Bug 2085082 Opened 21 days ago Closed 10 days ago

[Linux][Vulkan Video] Decoded video is green with direct-export on Radeon 680M

Categories

(Core :: Audio/Video: Playback, defect, P3)

Product:
Core
Component:
Audio/Video: Playback
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
161 Branch
Tracking Flags:
Tracking Status
firefox161 --- fixed

People

(Reporter: DaisyTheFoxxo, Assigned: tboiko)

References

(Blocks 2 open bugs)

Details

Attachments

(7 files, 2 external files)

A small video that produces the artifacts
33.43 KB, video/mp4
Details
reproduction.mp4
1.87 MB, video/mp4
Details
about:support
37.33 KB, text/plain
Details
artifacts on the YouTube video
3.49 MB, video/mp4
Details
All YouTube resolutions (144p -> 4K)
7.13 MB, video/mp4
Details
RDNA3-VP9-720p.png
305.21 KB, image/png
Details
2026-10-29 15-54-33.mp4
2.94 MB, video/mp4
Details

This is a clone of https://bugzilla.mozilla.org/show_bug.cgi?id=2083226 because the bug there still happens to me and I don't have the permission to comment on it because it's closed

OS: CachyOS
GPU: Radeon 680M (amdgpu kernel module)

How to reproduce:
Enable media.hardware-video-decoding-vulkan.enabled, media.hardware-video-decoding-vulkan.force-enabled, and media.hardware-video-decoding-vulkan.direct-export.enabled
Play the attached video
Bug happens regardless of if media.hardware-video-decoding-vulkan.prefer-system-ffmpeg is enabled or not

Attached video reproduction.mp4 —

This was originally reported on Ladybird issue #12902, so I'm attaching a recording of the bug for reference here. I suggested reporting it here, since I figured that direct export shipping on all hardware vendors is on the roadmap. From a cursory look, it seems like the failure worked around by forcing Vulkan decoding is simply an NVIDIA whitelist, rather than this and/or other issues being known on AMD GPUs?

Thanks for the sample and the recording.

Analysis

This is a different symptom from bug 2083226. That bug gave a solid green frame. Here, the recording shows green blocks that follow motion, and some regions decode with correct colors. This pattern points to bad H.264 reference pictures, not to a wrong dma-buf layout.

H.264 always uses the system FFmpeg, because the bundled ffvpx has no H.264 decoder. This explains why prefer-system-ffmpeg has no effect. For a libavcodec older than 63.8.101, the direct-export path in FFmpegVideoDecoder.cpp can drop VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR from images that libavcodec still uses as references. This is the probable cause, but code reading alone found it. The Firefox build and the FFmpeg version on your system will show if this path applies.

Tymur, could you please look at this? The question is the direct-export path on RDNA2 with a system libavcodec older than 63.8.101. The follow-up from bug 2083226 changes this path.

This bug blocks bug 2053144 (Vulkan video decoding on Linux) and bug 1766429 (Linux playback).

Next steps

Please capture a profile:

  1. Open about:logging.
  2. On the Logging presets tab, choose the "Media playback" preset.
  3. Under Logging output, select "Logging to the Firefox Profiler".
  4. Click Start Logging.
  5. Reload the page. Then do the steps that show the problem.
  6. Click Stop Logging. The profile opens in the Firefox Profiler.
  7. Click Upload Local Profile. This is the share button.
  8. Copy the share URL. Add it to this bug.

The instruction video shows these steps.

Please also add this information to the bug:

  1. Open about:support, click "Copy text to clipboard", and paste it into a comment.
  2. Run pacman -Q ffmpeg mesa in a terminal, and paste the output.
  3. Set media.hardware-video-decoding-vulkan.direct-export.enabled to false, and play the same video. Tell us if the picture is correct.

If you'd like to provide feedback on this comment, please use the 👍 or 👎 reaction.

Blocks: vulkan-video, linux-playback
Severity: -- → S3
Flags: needinfo?(tboiko)
Flags: needinfo?(DaisyTheFoxxo)
Priority: -- → P3
See Also: → 2083226

What versions of Firefox, FFmpeg, and RADV did you use? Could you try playing a video on YouTube (in this case, AV1/VP9 and ffvpx will be used, for other codecs, the system FFmpeg will be used regardless) and tell us if you see the corruption there - if yes, provide the link to the youtube video)?
Please, also provide the original input video (the one you shared is gray) and the Mozilla logs.

Flags: needinfo?(tboiko)
Flags: needinfo?(DaisyTheFoxxo)
Attached file about:support —

https://share.firefox.dev/47VlQ0d

Version: Nightly from October 21st ("https://ftp.mozilla.org/pub/firefox/nightly/2026/10/2026-10-21-20-53-24-mozilla-central/", file "firefox-160.0a1.en-US.linux-x86_64.tar.xz")

The YouTube video does show the artifacts on 720p60

pacman -Q ffmpeg mesa:

ffmpeg 2:9.0.2-2.1
mesa 3:26.2.4-1```

Setting `media.hardware-video-decoding-vulkan.direct-export.enabled` to `false` does remove the artifacts

Please, also provide the original input video

The original video is a direct download of https://www.youtube.com/watch?v=S6YyVlCW6Vg via youtube-dl
I wont share that directly because I care about the creator's work. Though, the bug happens on almost all YouTube videos at 720p60 specifically

The YouTube video does show the artifacts on 720p60

What about other resolutions? This will help isolate the issue. I suspect this bug is something different, in the referenced bug, there were severe distortions appearing as solid green areas (completely green frames)

What about other resolutions?

From my testing, it only happens on 720p60 on regular videos and whatever resolution YouTube uses for shorts. For me, all shorts I've watched contained the same artifacts

Could you please try 1080p, 1440p, 2160p videos on Youtube, will it work for you? (just to be sure, If I understood correctly, you said that issue affected only 720p resolution, right?)
Also, please set media.hardware-video-decoding-vulkan.prefer-system-ffmpeg.enabled to false

Could you please try 1080p, 1440p, 2160p videos on Youtube, will it work for you?

Here is me testing all resolutions from 144p to 2160p
Seems it also appears on 144p as well. My earlier claim that its 720p60 is half incorrect as 60 fps isn't required

Also, please set media.hardware-video-decoding-vulkan.prefer-system-ffmpeg.enabled to false

I did that just before I sent the video in the comment above. It seems to have no affect on the results for me

Alright, that helps, thank you.
So the issue affects only specific resolutions (e.g. 144p, 720p) on RADV, DISTINCT path specific - there’s likely still some discrepancy. I will take a look at it but probably not this week.

Thanks for the versions, the about:support and the recordings. Tymur plans to look at this bug (comment 13).

Analysis

The probable cause is in ChooseVulkanPixelFormatFromContext in FFmpegVideoDecoder.cpp. For a libavcodec older than 63.8.101, Firefox sets outputIsDpb = !mDriverDistinctDpb. Then it writes hwfc->usage without VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR.

RADV on the Radeon 680M reports both COINCIDE and DISTINCT. In that case, a libavcodec older than 63.8.101 uses the output image as the reference picture. Thus each reference picture is an image without DPB usage. The system FFmpeg 9.0.2 from comment 5 is probably in this version range, because the FFmpeg 9.0.1 in ffvpx is libavcodec 63.1.101.

The recordings match this cause. In attachment 9667298 [details], a green band covers the bottom rows of the picture. The luma in the band is correct, and only the chroma is missing. The top edge of the band has macroblock steps, and green blocks follow the motion. This pattern comes from motion compensation with bad references, not from a wrong export layout.

This behavior started with the part 3 change of bug 2083226, in ChooseVulkanPixelFormatFromContext, which landed on 2026-10-19. Before that change, the same setup showed solid green frames. Thus this is not a regression of a setup that worked. Code reading found this cause, and no log confirms it yet. A run with the Vulkan validation layer can confirm it: the layer should report reference pictures without DPB usage.

H.264 always uses the system FFmpeg, because ffvpx has no H.264 decoder. This explains why prefer-system-ffmpeg has no effect.

The profile in comment 5 uses a newer profile format that our tools cannot read yet. This is a gap in our tools, and the analysis above does not use the profile.

Fix direction

  1. Take outputIsDpb from the hwfc->usage that libavcodec sets, for every libavcodec version.
  2. When the output image has DPB usage and the driver reports DISTINCT, skip direct export.
  3. In that case, use the copy path and log the reason.
  4. Detect ffvpx with FFVPX_VERSION, not with the libavcodec version number.

The last step is necessary because ffvpx reports 63.1.101 but already has the DISTINCT logic.

This bug blocks bug 2053144 (Vulkan video decoding on Linux) and bug 1766429 (Linux playback).

If you'd like to provide feedback on this comment, please use the 👍 or 👎 reaction.

[:media-triaging-bot], the above findings and fix direction are not relevant to this bug. Please read comment #13.

I could not reproduce the corruption locally with the attached sample (“A small video that produces the artifacts”) or either YouTube video (all resolutions were clean, including 144p, 720p):

Environment: Ubuntu 26.04.1, Wayland with GNOME/Mutter, Radeon RX 9070 GRE (RDNA4/GFX1201), local RADV Mesa 26.3.0-devel (b888682cba), also tried system radeonsi Mesa 26.0.8, Firefox checkout efd2d1e6.

[:hanabishi], could you please tell us if you see this kind of corruption at your side?

Attached image RDNA3-VP9-720p.png —

Yes, I see it. Exactly as described, only with direct export on certain resolutions. VP9 is especially nasty here.

Maybe Benjamin could take a look. I don't have the required setup (no repro on RDNA4)

Just for sanity check, ensure that Vulkan is actually enabled. It requires to be force-enabled here.

media.hardware-video-decoding-vulkan.enabled, force-enabled, and direct-export.enabled are all true

Flags: needinfo?(ben)

This should be fixed by https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/b7e835e06913e4374a4567003fe8c75cebfffb98.

The issue is libavcodec is creating the DPB images with a DRM format modifier list which isn't supported by the hardware. This is invalid by spec (since RADV doesn't report VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT for the DPB images. I'll look into a workaround in RADV to ignore the modifier list passed for DPB images in the meanwhile (no promises because it's hacky).

Flags: needinfo?(ben)

Thank you for your answer. Sorry, one more quick question:
I am still curious why I can't reproduce this on RDNA4 with ffvpx (which precedes this commit), and why only specific resolutions (e.g., 144p and 720p - see video example in comment #11) are affected on RDNA2 and RDNA3? Could it be something similar to https://docs.mesa3d.org/relnotes/26.2.1.html#bug-fixes?
Also, in Firefox, this DPB usage flag was removed for GPUs that report distinct usage (which helped fix Bug 2083226), these usages are then passed to libavcodec:
https://github.com/mozilla-firefox/firefox/blob/0f76fed7aea1f77db85afbf5a895754d8ad971d7/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#L487
https://github.com/mozilla-firefox/firefox/blob/0f76fed7aea1f77db85afbf5a895754d8ad971d7/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#L535
https://github.com/mozilla-firefox/firefox/blob/0f76fed7aea1f77db85afbf5a895754d8ad971d7/dom/media/platforms/ffmpeg/FFmpegVulkanVideoDecoder.cpp#L666

Flags: needinfo?(ben)

[:hanabishi], could you try please if the latest FFmpeg master helps you to fix the issue?

Here's the RADV workaround: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45669. It may be worth trying that as well.

(In reply to Tymur Boiko from comment #23)

I am still curious why I can't reproduce this on RDNA4 with ffvpx (which precedes this commit) [...]

VCN5 (the video decoder IP on your RDNA4 card) supports more swizzle modes for the DPB (in fact it can almost support COINCIDE).

and why only specific resolutions (e.g., 144p and 720p - see video example in comment #11) are affected on RDNA2 and RDNA3?

I have not 100% confirmed this but from my observations I believe it is because the modifier requires a larger alignment than the tiling mode that HW wants to use, that can make the chroma plane have a different pitch than what the FW/HW expected. That mis-alignment only happens for certain resolutions as you see.

Could it be something similar to https://docs.mesa3d.org/relnotes/26.2.1.html#bug-fixes?

No those corruptions do not look like this (and it is a firmware issue that would affect both direct-export enabled/disabled).

Flags: needinfo?(ben)

(In reply to Tymur Boiko from comment #24)

[:hanabishi], could you try please if the latest FFmpeg master helps you to fix the issue?

Can't tell, direct export doesn't work with system ffmpeg for me. (Falls back to SW.)

(In reply to Benjamin Cheng from comment #25)

Here's the RADV workaround: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45669. It may be worth trying that as well.

Yes, this patch fixes the problem for me.

Great, thank you. We may also need to backport the above FFmpeg commit to ffvpx.

Backport FFmpeg b7e835e06913: "Drivers needn't support modifier tiling
for DPB-only usage, and radv doesn't, so the pool broke
VUID-VkImageCreateInfo-pNext-06811."

Fixes direct-export video corruption at certain resolutions, including
144p and 720p, on AMD RDNA2 and RDNA3 GPUs.

Assignee: nobody → tboiko
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by stransky@redhat.com: https://github.com/mozilla-firefox/firefox/commit/c6356cadde74 https://hg.mozilla.org/integration/autoland/rev/48d821c7e055 [Linux][Vulkan Video] Keep DRM modifiers off distinct DPB images in ffvpx. r=stransky,media-playback-reviewers

https://hg.mozilla.org/mozilla-central/rev/48d821c7e055

Status: ASSIGNED → RESOLVED
Closed: 15 days ago
status-firefox161: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 161 Branch

I found another instance where the same bug happens. I'm on the October 29th nightly build. While the bug on the original video was fixed, 720p on a livestream (https://www.youtube.com/watch?v=KsCJwkyvw_s) produced the same artifacts.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached video 2026-10-29 15-54-33.mp4 —

Please check "Stats for nerds" on YouTube to see which codec is being used.

On the Firefox side, this issue can only be resolved for FFVPX (AV1 + VP9). Other codecs rely on system FFmpeg, meaning the fix must be applied either in your FFmpeg build (see comment #22) or in RADV (see comment #25), as noted above.

Flags: needinfo?(DaisyTheFoxxo)

Please, check Stats for Nerds on Youtube to see which codec was used

avc1.4D4020 (298) / mp4a.40.2 (140)

Flags: needinfo?(DaisyTheFoxxo)

avc1 is H264, it uses system ffmpeg. It should be fixed in ffmpeg 9.1 release.

That's probably the fault of the stream using H.264 and running on system FFmpeg, which would carry the problematic code. Direct export should probably be blocked when it calls out to the affected versions.

Edit: Commented too late again!

You could try the RADV build from comment #26 to see if it helps, but I noticed the PR was closed unmerged.

Otherwise, I don't think we should disable this across all AMD GPUs for system FFmpeg builds predating the upstream fix - everything works on RDNA4, and only specific resolutions are impacted on RDNA2 and RDNA3. In the end, this isn't a Firefox bug.

We could, however, block the specific resolutions observed to fail (144p, 720p) on pre-RDNA4 GPUs. Technically, though, to avoid the erroneous path altogether, direct export should be disabled on RADV when using FFmpeg builds predating the commit (except for FFVPX, where the fix was backported).

Older system FFmpeg copies output DRM modifiers into its internal DPB
pool, which can cause video corruption on RADV at certain resolutions.
H.264 and HEVC use system FFmpeg and are not covered by the ffvpx backport.

Use the cached AMD vendor ID to block direct export when runtime
libavcodec is older than 63.20.101, the first upstream version bump after
the fix in b7e835e06913. Keep Vulkan decoding through the copy path.
Patched ffvpx and newer system FFmpeg remain eligible for direct export.

Combine this restriction with the existing NVIDIA forced-block-linear
restriction in a local directExportBlocked decision.

Pushed by stransky@redhat.com: https://github.com/mozilla-firefox/firefox/commit/d2184195162a https://hg.mozilla.org/integration/autoland/rev/acec6691b081 [Linux][Vulkan Video] Disable direct export on AMD with older system FFmpeg. r=stransky,media-playback-reviewers

https://hg.mozilla.org/mozilla-central/rev/acec6691b081

Status: REOPENED → RESOLVED
Closed: 15 days ago → 10 days ago
status-firefox161: affected → fixed
Resolution: --- → FIXED
See Also: → 2068257
QA Whiteboard: [qa-triage-done-c162/b161]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: