Closed Bug 2056593 Opened 24 days ago Closed 16 days ago

VulkanvideoMediaPD~oder #5[14584]: segfault error 4 in libvulkan_radeon.so

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 153
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: gabrielelyas, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

coredump
1.73 KB, text/plain
Details
firefox logs
3.90 MB, application/octet-stream
Details
firefox-logs_rdd_sandbox_disabled (=1)
2.66 MB, application/octet-stream
Details
firefox-logs (4 txt log files)
455.79 KB, application/x-xz
Details
firefox-logs(AV1_codec)
264.93 KB, application/octet-stream
Details
Attached file coredump —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

  1. Open Firefox (vulkan video enabled: media.hardware-video-decoding-vulkan.direct-export.enabled, media.hardware-video-decoding-vulkan.enabled = true)
  2. Go to Youtube
  3. The video plays without using the hardware's decoding capabilities
  4. dmesg shows the error: MediaPD~oder #3[11379]: segfault at 48 ip 00007f8bcaa72805 sp 00007f8bcbad0dd0 error 4 in libvulkan_radeon.so[21e805,7f8bca8a3000+6ca000] likely on CPU 10 (core 2, socket 0)

Coredump output attached.

Actual results:

The video plays without using the hardware's decoding capabilities

Expected results:

The video plays using the hardware's decoding capabilities

FIrefox 153 (Flatpak)

System Details Report

Hardware Information:

  • Hardware Model: ASUS TUF GAMING B550M-PLUS
  • Memory: 32.0 GiB
  • Processor: AMD Ryzen™ 7 5800X3D × 16
  • Graphics: AMD Radeon™ RX 6600 XT
  • Disk Capacity: 1.5 TB

Software Information:

  • Firmware Version: 3636
  • OS Name: GNOME OS Nightly
  • OS Build: nightly.20260720.1
  • OS Type: 64-bit
  • GNOME Shell Version: 51.alpha
  • Kernel Version: Linux 7.0.11
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

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

It seems to be an ffmpeg issue that, as far as I know, has already been resolved in the upstream repository (see https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20057).

Blocks: vulkan-video

What FFmpeg/lbavcodec version did you use? You need FFmpeg 9.0 (May 2026 commit) for direct export to work correctly - otherwise set direct export to false (keep only media.hardware-video-decoding-vulkan.enabled). Also please use the most recent release driver for direct export.

Can you please collect and share logs via:

about:config (runtime, no restart):
logging.PlatformDecoderModule = 5
logging.FFmpegVideo = 5
logging.FFmpegLib = 5
logging.Dmabuf = 5
logging.RemoteDecode = 5
logging.config.LOG_FILE = /tmp/firefox-logs
or

cmdline
MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,RemoteDecode:5"
MOZ_LOG_FILE=/tmp/firefox-logs

Try using FFmpeg version that contains the commit that fixes the issue as noted above.
Also try MOZ_DISABLE_RDD_SANDBOX=1

Flags: needinfo?(gabrielelyas)

(In reply to Tymur Boiko from comment #4)

What FFmpeg/lbavcodec version did you use? You need FFmpeg 9.0 (May 2026 commit) for direct export to work correctly - otherwise set direct export to false (keep only media.hardware-video-decoding-vulkan.enabled). Also please use the most recent release driver for direct export.

Since I'm using the Flatpak version, the ffmpeg version included in the fdsdk runtime (25.08) is version 7.1.3.

Can you please collect and share logs via:

about:config (runtime, no restart):
logging.PlatformDecoderModule = 5
logging.FFmpegVideo = 5
logging.FFmpegLib = 5
logging.Dmabuf = 5
logging.RemoteDecode = 5
logging.config.LOG_FILE = /tmp/firefox-logs
or

cmdline
MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,RemoteDecode:5"
MOZ_LOG_FILE=/tmp/firefox-logs

Logs attached.

Try using FFmpeg version that contains the commit that fixes the issue as noted above.
Also try MOZ_DISABLE_RDD_SANDBOX=1

Flags: needinfo?(gabrielelyas)
Attached file firefox logs —

(In reply to Tymur Boiko from comment #4)

What FFmpeg/lbavcodec version did you use? You need FFmpeg 9.0 (May 2026 commit) for direct export to work correctly - otherwise set direct export to false (keep only media.hardware-video-decoding-vulkan.enabled). Also please use the most recent release driver for direct export.

With the “direct export” flag enabled, the segfault errors disappear from the kernel buffer (dmesg). However, the decoding load goes directly to the GPU instead of the card's dedicated decoding hardware. Sometimes I restart Firefox and the decoding works correctly.

Thanks for the logs and for testing this.

Yes, direct export most likely won't work. I checked the FFmpeg git history directly: the fix from issue #20057 you mentioned in comment #3 (hwdec/vulkan: fix invalid number of planes usage in map_to_drm) first landed in the 8.1 release - it's not present in any 7.1.x tag (7.1.2 through 7.1.5) nor in 8.0.x. Since the Flatpak runtime ships ffmpeg 7.1.3, it does not include this fix, which is consistent with the segfault you're seeing.

Also, a sandbox fix for X11 has already been released and should be available in a nightly soon (targeting Firefox 154)

Sorry, typo.
Also, a sandbox fix for X11 has already been landed and should be available in a nightly soon (targeting Firefox 154)

However, the decoding load goes directly to the GPU instead of the card's dedicated decoding hardware. Sometimes I restart Firefox and the decoding works correctly.

I'm not sure that's actually what's happening - with media.hardware-video-decoding-vulkan.enabled, decoding always goes through the Vulkan Video decode queue, i.e. the same dedicated hardware decode block, regardless of the direct-export setting (direct-export only changes how the already-decoded frame is exported (as a DRM/dmabuf buffer for zero-copy compositing), not which hardware does the decoding. Even If Vulkan Video hw decoding is not available - VAAPI will be used.

The attached log (firefox-logs.moz_log) only contains parent-process output. There's no RDD child-process content at all, so it has none of the FFmpegVideo/FFmpegLib decode logging we need — only Dmabuf format probing and a PlatformDecoderModule Broadcast support from 'RDD' line saying the RDD announced H264 SWDEC/HWDEC support.

When MOZ_LOG_FILE is set (e.g. to /tmp/firefox-logs), Firefox should write two files:

firefox-logs.moz_log (parent)
firefox-logs.child-1.moz_log (RDD — this is the one we need)

Could you double check that the child-1 file was generated and attach it too?

Flags: needinfo?(gabrielelyas)

(In reply to Tymur Boiko from comment #12)

However, the decoding load goes directly to the GPU instead of the card's dedicated decoding hardware. Sometimes I restart Firefox and the decoding works correctly.

I'm not sure that's actually what's happening - with media.hardware-video-decoding-vulkan.enabled, decoding always goes through the Vulkan Video decode queue, i.e. the same dedicated hardware decode block, regardless of the direct-export setting (direct-export only changes how the already-decoded frame is exported (as a DRM/dmabuf buffer for zero-copy compositing), not which hardware does the decoding. Even If Vulkan Video hw decoding is not available - VAAPI will be used.

The attached log (firefox-logs.moz_log) only contains parent-process output. There's no RDD child-process content at all, so it has none of the FFmpegVideo/FFmpegLib decode logging we need — only Dmabuf format probing and a PlatformDecoderModule Broadcast support from 'RDD' line saying the RDD announced H264 SWDEC/HWDEC support.

When MOZ_LOG_FILE is set (e.g. to /tmp/firefox-logs), Firefox should write two files:

firefox-logs.moz_log (parent)
firefox-logs.child-1.moz_log (RDD — this is the one we need)

Could you double check that the child-1 file was generated and attach it too?

Sorry, I forgot to send these. They ended up being too big, so I've attached a tar.xz file with the logs.

Flags: needinfo?(gabrielelyas)

You are trying to decode vp9, whose Vulkan Video support was implemented in FFmpeg 8.0, try to find AV1 (or HEVC, H264) video.

(In reply to Tymur Boiko from comment #15)

You are trying to decode vp9, whose Vulkan Video support was implemented in FFmpeg 8.0, try to find AV1 (or HEVC, H264) video.
Ok, new logs attached (AV1 codec).

Ok, new logs attached (AV1 codec).

Ok, new logs attached (AV1 codec).(In reply to Tymur Boiko from comment #15)

You are trying to decode vp9, whose Vulkan Video support was implemented in FFmpeg 8.0, try to find AV1 (or HEVC, H264) video.

Good to know, since the fdsdk 26.08 will include ffmpeg 8..

So, now it is working for you, right?

[RDD 135: MediaSupervisor #3]: D/Dmabuf DMABUFSurfaceImage::~DMABUFSurfaceImage (7fa0d90ddac0) mSurface 7fa0d90fa940 UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf VideoFrameSurface: Releasing dmabuf surface UID 109 FFMPEG ID 0xffffffff aForFrameRecycle true mLib 0x7fa0fe8e84c0 mAVHWFrameContext 0x7fa101072440 mHWAVBuffer 0x7fa0d8d1bc00
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurfaceYUV::ReleaseSurface() UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurfaceYUV::ReleaseTextures() UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurface::ReleaseDMABuf() UID 109
[RDD 135: MediaPDecoder #1]: V/Dmabuf UID 109 Memory YUV [14] mem 43545 KB (- 3110 KB)
[RDD 135: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Frame decode takes 0.11 ms average decode time 2.52 ms frame duration 16.68 average frame duration 16.68 decoded 923 frames

[RDD 135: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: [VULKAN] DRM descriptor: nb_objects=1, nb_layers=1, copy
[RDD 135: MediaPDecoder #1]: D/Dmabuf VideoFrameSurface: Releasing dmabuf surface UID 109 FFMPEG ID 0xffffffff aForFrameRecycle true mLib 0x0 mAVHWFrameContext 0x0 mHWAVBuffer 0x0
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurfaceYUV::ReleaseSurface() UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurfaceYUV::ReleaseTextures() UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurface::ReleaseDMABuf() UID 109
[RDD 135: MediaPDecoder #1]: V/Dmabuf UID 109 Memory YUV [13] mem 40435 KB (- 3110 KB)
[RDD 135: MediaPDecoder #1]: D/Dmabuf Matched DMABufSurface UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf Using vulkan DMABufSurface UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf Used HW surface UID 108 FFMPEG ID 0xffffffff
Flags: needinfo?(gabrielelyas)

(In reply to Tymur Boiko from comment #20)

So, now it is working for you, right?

[RDD 135: MediaSupervisor #3]: D/Dmabuf DMABUFSurfaceImage::~DMABUFSurfaceImage (7fa0d90ddac0) mSurface 7fa0d90fa940 UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf VideoFrameSurface: Releasing dmabuf surface UID 109 FFMPEG ID 0xffffffff aForFrameRecycle true mLib 0x7fa0fe8e84c0 mAVHWFrameContext 0x7fa101072440 mHWAVBuffer 0x7fa0d8d1bc00
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurfaceYUV::ReleaseSurface() UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurfaceYUV::ReleaseTextures() UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurface::ReleaseDMABuf() UID 109
[RDD 135: MediaPDecoder #1]: V/Dmabuf UID 109 Memory YUV [14] mem 43545 KB (- 3110 KB)
[RDD 135: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Frame decode takes 0.11 ms average decode time 2.52 ms frame duration 16.68 average frame duration 16.68 decoded 923 frames

[RDD 135: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: [VULKAN] DRM descriptor: nb_objects=1, nb_layers=1, copy
[RDD 135: MediaPDecoder #1]: D/Dmabuf VideoFrameSurface: Releasing dmabuf surface UID 109 FFMPEG ID 0xffffffff aForFrameRecycle true mLib 0x0 mAVHWFrameContext 0x0 mHWAVBuffer 0x0
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurfaceYUV::ReleaseSurface() UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurfaceYUV::ReleaseTextures() UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf [7fa0d90fa940]: DMABufSurface::ReleaseDMABuf() UID 109
[RDD 135: MediaPDecoder #1]: V/Dmabuf UID 109 Memory YUV [13] mem 40435 KB (- 3110 KB)
[RDD 135: MediaPDecoder #1]: D/Dmabuf Matched DMABufSurface UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf Using vulkan DMABufSurface UID 109
[RDD 135: MediaPDecoder #1]: D/Dmabuf Used HW surface UID 108 FFMPEG ID 0xffffffff

Yeah, it looks like the problem was between the chair and the PC, lol. I didn't know VP9 wasn't supported. Thanks for the help.

Flags: needinfo?(gabrielelyas)
Status: UNCONFIRMED → RESOLVED
Closed: 16 days ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: