2077880 - Vulkan Video on NVIDIA with Direct export can produce corrupt image

Status: RESOLVED FIXED

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

Description

[Stephen]

Attachment: mozlog.txt

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

Steps to reproduce

1. Enabled Vulkan Video decoding/Disabled VA-API decoding
2. Played a small H.264 video, 284x160px

Actual results

The video it produced was corrupted.

Expected results

The video should have been decoded properly.

I'm not sure there's much you can do to fix the issue, it might be with FFMpeg or the NVIDIA Vulkan driver itself. In the NVIDIA VA-API driver, this video requires two different set of DRM modifiers, one for the luma plane and one for the chroma plane. Using the luma plane modifier for the chroma plane caused the image to look like the one on the left (the image on the right is the same video decoded directly through NVDEC). However looking at the log output, the DRM descriptor only has one object, which means that only one modifier can be used.

Comment 1

[Stephen]

Attachment: Screenshot_2026-10-04_09-11-51.png

Comment 2

[Stephen]

Attachment: smptebars_h264_176p.mp4

This is the video that was being played back.

Comment 3

[Stephen]

Attachment: smptebars_h264_284x160.mp4

This is the video that was being played.

Comment 4

[media-triaging-bot]

Thank you for the report, the log and the sample videos.

Direct export needs FFmpeg 9.0, or FFmpeg 8.1.2 with the upstream commit 25e187f8 (see bug 2057381).

Could you please tell us the FFmpeg version on this system?

:stransky, could you please take a look at this Vulkan direct export problem on NVIDIA when you have time?

Comment 5

[[:nickname]Mark]

could you please try reproducing using ffmpeg 8.1.3 with these commits merged ,
cee26cb74a , e4240e1087 and 02a4641be4b7

or checkout
https://code.ffmpeg.org/Forgejo_Fairy/FFmpeg/src/branch/fairy/issue23932-bugfix
see https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23932 for details.

I've already upgraded my system to F45 (ffmpeg 9) and can't reproduce the original issue for some reason when I force system to load unpatched ffmpeg 8.1.2 libs.

Comment 6

[Stephen]

I've tried using the supplied git branch, but I'm still seeing the same problem, however I'm not certain it was actually using that library over the one that comes bundled with it. I've attached the output of MOZ_LOG=FFmpegRuntimeLinker:5,PlatformDecoderModule:5 firefox 2>&1.

I did confirm through ffplay -loglevel debug -enable_vulkan -hwaccel vulkan smptebars_h264_284x160.mp4 that the build could play it back successfully, however that pipeline is all Vulkan and it doesn't get exported.

Comment 7

[Stephen]

Attachment: ff.log

Comment 8

[Tymur Boiko]

Preliminary: I can only reproduce this issue at low resolution on YouTube (e.g. only at 144p) and with the attached file.
UPDATE: The above is incorrect. It was FFmpeg's lib mismatch at my side. I am retracting this comment.

Comment 9

[[:nickname]Mark]

I can reproduce with unpatched fmpeg 8.1.x and FF153. Not sure whether FF157 is even enabling direct-export. Need to enable logs.
Switched back to nvidia_libva :) some time ago, because session would freeze quite often like in issue https://bugzilla.mozilla.org/show_bug.cgi?id=2058290

Comment 10

[Tymur Boiko]

Actually, no, I am unable to reproduce this issue on Firefox nightly (neither on Ampere nor Blackwell GPUs, neither on FFmpeg master nor ffvpx, neither on the attached clip nor at 144p Youtube videos) . Please try the Firefox nightly build (and if possible - the FFmpeg master). I am retracting my previous comment.

Comment 11

[Stephen]

I've just retested with Firefox nightly 160.0a1 (2026-10-10) and FFMpeg version N-127276-g8e9db1f152, and I still get the same result.

Comment 12

[Tymur Boiko]

Could you capture a log of one playback of the attached smptebars_h264_284x160.mp4 and attach every file it writes? The decoder runs in a separate process, so there will be more than one file.

In a running Nightly, set these in about:config (they take effect immediately; do not restart, or they are cleared):

logging.PlatformDecoderModule = 5
logging.FFmpegVideo = 5
logging.FFmpegLib = 5
logging.Dmabuf = 5
logging.RemoteDecode = 5
logging.config.LOG_FILE = /tmp/firefox-logs

Play the file once, then quit. Please attach every file matching /tmp/firefox-logs*.moz_log, including the -child- ones.

OR, from a terminal:

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

Same request: one playback of that file, then all of the /tmp/firefox-logs*.moz_log files.

Also, please, provide an output for nvidia-smi command.

Comment 13

[Stephen]

Attachment: mozlogs.tar.gz

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

Comment 14

[Stephen]

Here's the nvidia-smi output:

> nvidia-smi
Sat Oct 10 19:29:05 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 610.57.04              KMD Version: 610.57.04     CUDA UMD Version: 13.3     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 5070        Off |   00000000:09:00.0  On |                  N/A |
|  0%   52C    P1             38W /  250W |    2562MiB /  12227MiB |      7%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A            1461      G   /usr/libexec/Xorg                      1318MiB |
|    0   N/A  N/A            2399      G   xfwm4                                     4MiB |
|    0   N/A  N/A            3829      G   ...rack-uuid=3190708988185955192         15MiB |
|    0   N/A  N/A           37383      G   /usr/bin/ghostty                        224MiB |
|    0   N/A  N/A           38770      G   /usr/lib64/firefox/firefox              344MiB |
|    0   N/A  N/A           38911    C+G   ...r/lib64/firefox/browser 4 rdd        492MiB |
+-----------------------------------------------------------------------------------------+

Comment 15

[Tymur Boiko]

Could you check and let us know if this issue occurs with YouTube videos at 144p resolution?

Comment 16

[Stephen]

Very odd, it only seems to be H.264 videos that are effected.
https://www.youtube.com/watch?v=LXb3EKWsInQ - VP9 - Ok at all resolutions
https://www.youtube.com/watch?v=s5bZgYY72Z0 - AV1 - Ok at all resolutions
https://www.youtube.com/watch?v=vVpO_wakTQQ - H.264 - Broken at all resolutions (144p to 1080p)

I'm not sure what to make of that, it might not be the issue I initially thought it was. This might be a video size vs frame size mismatch. There's a lot of green at the end of that garbled frame and I'm seeing the same on the youtube video, which indicates it's reading 0's for the chroma which can be caused by it running off the end of the buffer. I'm not sure.

Comment 17

[Tymur Boiko]

Could you please try upgrading to the 615 driver?
Preliminary: I am observing this issue on version 610. I will double-check. It is possible the driver isn't the cause.

Comment 18

[Stephen]

Upgrading the NVIDIA driver to 615 seems to have fixed all the problems, even with Fedora's stock Firefox 157 and FFMpeg 8.1.3. I'm seeing a couple of decoding issues on that H.264 Youtube video above, but it's minor and clears after a few seconds. I'll run this for a few days and see if any other issues show up.

Comment 19

[[:nickname]Mark]

@Stephen, pls note that if system has ffmpeg-libs installed from rpmfusion repos, those libs are patched with commit 25e187f8
see https://github.com/rpmfusion/ffmpeg/commit/98f9fa19631c65f3f5f93890679d3f8fa9d1f557

indeed I can reproduce the issue with FF157 with latest 615 drivers when streaming H264 YT video on an nvidia 2060 GPU with unpatched ffmpeg 8.1.3 libs. For some reason not reproducible with VP9 streams, like in FF153.4esr.

Comment 20

[Stephen]

I've been running on 615.78.08, with Fedora 44's ffmpeg-free, and it seems fine. I spotted a couple of instances of some minor corrupted video decoding (like it missed a frame and the frames after it were predicting the wrong bit of the frame) but those were brief and the rest of the video played fine.

Comment 21

[Tymur Boiko]

Attachment: Bug 2077880 [Linux][Vulkan Video] Keep H.264 DRM modifiers with height 1 on Blackwell with NVIDIA driver 610 or older. r?alwu,stransky,#media-playback-reviewers!

When codec is H264, on Blackwell with driver 610 or older, use DRM modifiers with height 1 to avoid corruption.

Comment 22

[Tymur Boiko]

The minor residual image distortions in certain specific H264 videos will be fixed in future driver releases.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7a9e93c429a1
https://hg.mozilla.org/integration/autoland/rev/5b5888c58f3f
[Linux][Vulkan Video] Keep H.264 DRM modifiers with height 1 on Blackwell with NVIDIA driver 610 or older. r=stransky,media-playback-reviewers

Comment 24

[amarc]

https://hg.mozilla.org/mozilla-central/rev/5b5888c58f3f

Comment 25

[Tymur Boiko]

No, the bug number reported by [:media-triaging-bot] in #c24 is not related to this bug.

Comment 26

[Tymur Boiko]

No, the bug number reported above by [:media-triaging-bot] is not related to this bug.