Closed Bug 2083226 Opened 28 days ago Closed 25 days ago

[Linux][Vulkan Video] Decoded video is green with direct-export on GPUs that report a distinct DPB

Categories

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

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
160 Branch
Tracking Flags:
Tracking Status
firefox160 --- fixed

People

(Reporter: tboiko, Assigned: tboiko)

References

(Blocks 2 open bugs)

Details

Attachments

(3 external files, 1 obsolete file)

Direct export maps the Vulkan decode image to a dma-buf and the compositor samples it. FFmpegVideoDecoder::ChooseVulkanPixelFormatFromContext always adds VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR to that image.

Seen on AMD Radeon RX 9070 GRE (RADV GFX1201, radeonsi). vkCreateImage reports VUID-VkImageCreateInfo-pNext-06811 for an image with VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT, flags 0, and usage TRANSFER_SRC | TRANSFER_DST | VIDEO_DECODE_DST | VIDEO_DECODE_DPB.

Steps to reproduce:
Linux, a GPU whose Vulkan decode caps include VK_VIDEO_DECODE_CAPABILITY_DPB_AND_OUTPUT_DISTINCT_BIT_KHR (AMD Radeon RX 9000 series + RADV does, RX 7600 and higher may be an option to).
Set media.hardware-video-decoding-vulkan.enabled, media.hardware-video-decoding-vulkan.force-enabled and media.hardware-video-decoding-vulkan.direct-export.enabled to true.
Play any video.
Actual: a green frame.
Expected: the picture.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Direct export was forcing VIDEO_DECODE_DPB onto every decode image. Drivers that report DPB_AND_OUTPUT_DISTINCT keep references on a second image; that extra usage made the compositor sample a DPB surface. Keep the bit only when get_hw_frames_parameters already set it.

Attachment #9663789 - Attachment is obsolete: true

Direct export was forcing VIDEO_DECODE_DPB onto every decode image. Drivers that report DPB_AND_OUTPUT_DISTINCT keep references on a second image; that extra usage made the compositor sample a DPB surface. Keep the bit only when get_hw_frames_parameters already set it.

Assignee: nobody → tboiko
Status: NEW → ASSIGNED

Direct export still doesn't work on my RDNA3 GPU btw. And in last FF versions it is even blocklisted from Vulkan decoding completely, unless I set media.hardware-video-decoding-vulkan.force-enabled.

[:hanabishi], have you tried this patch? - It should fix it, at least for RDNA4

No, can't build Firefox myself / can't test until it lands in nightly.

Pushed by stransky@redhat.com: https://github.com/mozilla-firefox/firefox/commit/3b670edde712 https://hg.mozilla.org/integration/autoland/rev/0e9b59db9d3a [Linux][Vulkan Video] Keep VIDEO_DECODE_DPB off the exported image when the DPB is distinct. r=stransky,media-playback-reviewers

Hi Martin,
Thank you for landing these changes. They are correct for the lavc version in ffvpx, but I will need to make a small change for compatibility with older versions, plus perform some minor refactoring and add a warining log. I will follow-up an additional commit.

The diagnosis in comment 0 is correct. The fix from this bug is on autoland now.

Analysis

With media.hardware-video-decoding-vulkan.direct-export.enabled, FFmpegVideoDecoder::ChooseVulkanPixelFormatFromContext always adds VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR to the decode image (FFmpegVideoDecoder.cpp). FFmpeg keeps that bit off the output image when the driver reports DPB_AND_OUTPUT_DISTINCT (vulkan_decode.c). On RADV with RDNA4, image creation then fails validation, and the frame is green. The bundled ffvpx also gets this path when the pref is on, so the problem is not only with system FFmpeg.

The autoland change adds the bit only when FFmpeg already set it. Drivers that share one image for the DPB and the output, such as NVIDIA and Intel, still get the bit. The follow-up for older lavc versions in comment 8 is still open.

The RDNA3 report in comment 4 can have a different cause. A Nightly build with this fix will show if it does.

This bug blocks bug 2053144 (Vulkan video decoding on Linux) and bug 1766429 (Linux playback). Bug 2077880 is a related direct-export problem on NVIDIA, with a different cause.

To give feedback on this comment, add a thumbs-up or thumbs-down reaction.

Blocks: vulkan-video, linux-playback
Severity: -- → S3
Priority: -- → P2
See Also: → 2077880

Bug 2077880 is a related direct-export problem on NVIDIA, with a different cause.

No, the bug reported by [:media-triaging-bot] in #c9 is not related to this one. The only thing they have in common is the green output.

https://hg.mozilla.org/mozilla-central/rev/0e9b59db9d3a

Status: ASSIGNED → RESOLVED
Closed: 27 days ago
status-firefox160: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 160 Branch

Let's keep this open for a while, I will follow-up and additional patch for the older FFmpeg builds. After that we can close the bug.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Refactor so CheckDecodeCapabilities runs the video-caps query. Use VulkanProbeFormat instead of H264VulkanProbeFormat, preserving previous behavior (bug 2063809: VulkanCanDecodeFormat only applies the FFmpeg < n7.1 COINCIDE-without-SEPARATE_REFERENCE_IMAGES skip). This allows other functions to use the decode caps.

libavcodec before 63.8.101 uses dedicated_dpb = !COINCIDE, so VIDEO_DECODE_DPB is on the output whenever COINCIDE is advertised, including when DISTINCT is also set. From 63.8.101 libavcodec uses dedicated_dpb = DISTINCT. Copy hwfc->usage on new lavc; on older lavc set DPB only if the driver does not report DISTINCT.

(In reply to Tymur Boiko from comment #5)

[:hanabishi], have you tried this patch? - It should fix it, at least for RDNA4

Tested nightly with the patch: no difference for RDNA3, direct export doesn't work.

What exactly are you observing: image artifacts or a fallback to VAAPI? Could you provide logs? What RADV version are you using? Could you try running it with the MOZ_DISABLE_RDD_SANDBOX=1 - does that help?
With the 1st patch only landed you should try AV1 or VP9 (so that it uses ffvpx (make sure media.hardware-video-decoding-vulkan.prefer-system-ffmpeg=false, however it should be false by default), or use latest FFmpeg master for other codecs)

Flags: needinfo?(i.r.e.c.c.a.k.u.n+bugzilla.mozilla.org)

With the 1st patch only landed you should try AV1 or VP9 (so that it uses ffvpx, or use latest FFmpeg master for other codecs)

Oh, that's the culprit. I tested H264 which uses system ffmpeg 9.0.2.
But yeah, direct export works now for VP9/AV1 using built in ffvpx.

Flags: needinfo?(i.r.e.c.c.a.k.u.n+bugzilla.mozilla.org)

(In reply to Tymur Boiko from comment #16)

What exactly are you observing: image artifacts or a fallback to VAAPI?

With Vulkan decode on we don't fallback to VA-API but to SW decode directly.

With Vulkan decode on we don't fallback to VA-API but to SW decode directly.

In the attached patches, I did not change any fallback behavior

Hi Martin, could you please land the rest (your comments were resolved)?

Pushed by stransky@redhat.com: https://github.com/mozilla-firefox/firefox/commit/e54432c53893 https://hg.mozilla.org/integration/autoland/rev/e9aaabf9364a [Linux][Vulkan Video] Split video-caps query out of VulkanCanDecodeFormat. r=stransky,media-playback-reviewers https://github.com/mozilla-firefox/firefox/commit/7f998472474b https://hg.mozilla.org/integration/autoland/rev/e3569715c160 [Linux][Vulkan Video] Strip output DPB usage on pre-63.8.101 libavcodec when the driver reports DISTINCT. r=stransky,media-playback-reviewers

https://hg.mozilla.org/mozilla-central/rev/e9aaabf9364a
https://hg.mozilla.org/mozilla-central/rev/e3569715c160

Status: REOPENED → RESOLVED
Closed: 27 days ago → 25 days ago
status-firefox160: affected → fixed
Resolution: --- → FIXED
See Also: 2077880 →
See Also: → 2085082
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: