2057724 - Vulkan decoding won't work

Status: RESOLVED FIXED

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

Description

[Fidon]

Attachment: vulkan decoding.png

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

Steps to reproduce:

Enable vulkan video decoding on firefox 153
Fedora Linux
Wayland
Nvidia RTX3080
Nvidia proprietary driver RPMFUSION 610.43.03
media.hardware-video-decoding-vulkan.direct-export.enabled
media.hardware-video-decoding-vulkan.enabled

Try with H264 video : https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_1MB.mp4
Try with youtube and twitch with vp1 , AV1 video

Check always with nvidia-smi if there is decoding from the GPU

Actual results:

Youtube + twitch : acceleration didn't work
On the H264 video the decoding shows green bars. However, it is definitely running on the GPU because nvidia-smi displays a percentage. (See screenshot.)
This is only temporary because if I close the tab and restart the video, the gpu decoding doesn't start again

Expected results:

For me, this Vulkan decoding offers great hope that I won't have to disable the RDD sandbox to get video decoding on NVIDIA. Unfortunately, I can't get it to work, and I need your help.

Comment 1

[Fidon]

Attachment: about:support

Comment 2

[BugBot [:suhaib / :marco]]

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.

Comment 3

[Tymur Boiko]

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)

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
Also try MOZ_DISABLE_RDD_SANDBOX=1

Comment 4

[Fidon]

Attachment: firefoxlog.tar.gz

Log from firefox when launching videos

Comment 5

[Fidon]

Disabling export successfully fixed the green band issue.
You're right i'm not on a 9.0 version.
ffmpeg -version
ffmpeg version 8.1.2 Copyright (c) 2000-2026 the FFmpeg developers

However, the rest of the problem still persists.

1. I start a Firefox session
2. I open https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_1MB.mp4
3. I see that the video plays fine
4. I close the tab and open a new one with the same video
5. The video is decoded by the cpu

Same problem with YouTube, where it only works intermittently.

For the logging i've done the test with the previous video + launching a twitch video.

Thanks again.

Comment 6

[Fidon]

Comment on attachment 9615934 [details]
firefoxlog.tar.gz

1. Launched https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_1MB.mp4
   GPU decoding ok
2. Close tab
3. reopen same video
4. GPU decoding won't work
5. test with a twitch video : GPU decoding won't work

Comment 7

[Fidon]

Attachment: Enregistrement d'écran_20260725_141112.webm

Video from test

Comment 8

[Fidon]

I forged to answer with RDD sandbox disabled : With MOZ_DISABLE_RDD_SANDBOX=1, it works on the GPU everytime. That was my previous configuration, and the goal of the Vulkan decoding was to be able to re-enable the sandbox. However, I don't know whether, with the RDD sandbox disabled, if it if the new Vulkan that's doing the work or the original VAAPI backend I was using.

Comment 9

[Tymur Boiko]

Thank you for reporting this. The sandbox patch has already been submitted, but it's target is Firefox 154. You can try it if nightly works for you.
https://bugzilla.mozilla.org/show_bug.cgi?id=2046954

Comment 10

[Fidon]

Tested on 155.0a1 (2026-07-24) nightly.

Unfortunately same issue.
I can reproduce the same issue of my video on nightly. Decoding work for the first video and not after.

Comment 11

[Fidon]

Attachment: Enregistrement décran_20260725_224940.mp4

New video with firefox nightly 155.0a1.

Test 1 : sandbox RDD enabled.

1. Open this video : https://lafibre.info/tv-numerique-hd-3d/comparer-h-264-vp9-av1/120/
   GPU decode : ok
2. close the tab and open new tab with the same video :
   GPU decode : fail

Test 2 : sandbox RDD disabled.

1. Open this video : https://lafibre.info/tv-numerique-hd-3d/comparer-h-264-vp9-av1/120/
   GPU decode : ok
2. close the tab and open new tab with the same video :
   GPU decode : ok
3. Again another video :
   GPU decode : ok

Comment 12

[Tymur Boiko]

So, the problem is with the sandbox. In my X11 configuration (Ampere + Ubuntu 24.04), everything seems to work.
If you are using the NVIDIA 610 native driver, you are using Vulkan, not VAAPI.
You can check this with a Vulkan API dump too (you can use vkconfig-gui for this) or collect and share logs as suggested above, but with MOZ_DISABLE_RDD_SANDBOX=1 pre-set.
For a sandbox debugging you can share the separate log with MOZ_SANDBOX_LOGGING=1 (but in that case don't set/unset MOZ_DISABLE_RDD_SANDBOX)

Comment 13

[Tymur Boiko]

That line already proves Vulkan, not VAAPI:
[RDD 29368: MediaPDecoder #2]: D/FFmpegVideo FFMPEG: [VULKAN] DRM descriptor: nb_objects=1, nb_layers=1, copy

You can also use Nsight Systems to profile and check Vulkan API trace.

Just a reminder:

# Reproduce without RDD sandbox (to check if sandbox is the cause)
MOZ_DISABLE_RDD_SANDBOX=1 MOZ_LOG=FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,RemoteDecode:5" ./mach run

# Separate run: sandbox violation log (do NOT set MOZ_DISABLE_RDD_SANDBOX here)
MOZ_SANDBOX_LOGGING=1 ./mach run 2> sandbox.log

Comment 14

[Tymur Boiko]

Sorry, in the command lines above, just change ./mach run to firefox-nightly like in your recording

Comment 15

[Fidon]

The first one give nothing
MOZ_DISABLE_RDD_SANDBOX=1 MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,RemoteDecode:5" firefox-nightly > withoutrdd

Second one :
[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current
[GFX1]: EGLContext#true is owned by/Current on thread#51556 but MakeCurrent requested on thread#51409!
[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current
[GFX1]: EGLContext#true is owned by/Current on thread#51556 but MakeCurrent requested on thread#51557!
[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current
[GFX1]: EGLContext#true is owned by/Current on thread#51556 but MakeCurrent requested on thread#51409!
[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current

I've try with this :
MOZ_DISABLE_RDD_SANDBOX=1 MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,RemoteDecode:5,sync" MOZ_LOG_FILE=rddlog firefox-nightly
I will join the log

Comment 16

[Fidon]

Attachment: withoutrdd.tar.gz

MOZ_DISABLE_RDD_SANDBOX=1 MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,RemoteDecode:5,sync" MOZ_LOG_FILE=rddlog firefox-nightly

1. run video
2. close tab
3. run video again
4. Close logging

Comment 17

[Fidon]

For my configuration :
Ryzen 5600X. Nvidia RTX 3080. Fedora 44. Wayland.
I agree with you. It makes sense that the problem is coming from the sandbox. It works perfectly when it's turned off but it's not the goal. And it only worked with one video when it's turned on. But it's still surprising because, to me, the sandbox was more of an on/off thing.I don't see why it still works on the first one.

Comment 18

[Tymur Boiko]

Sorry, but can you also provide the log from ?
MOZ_SANDBOX_LOGGING=1 firefox-nightly 2> sandbox.log

Comment 19

[Fidon]

Attachment: sandbox.log

Comment 20

[Fidon]

Attachment: sandbox.log

Oups previous one is the wrong file. This one is the good one.
MOZ_SANDBOX_LOGGING=1 firefox-nightly 2> sandbox.log

Comment 21

[Tymur Boiko]

Oh, I see this is Wayland. This may make things different
Thank you for the logs.
I have an idea what is wrong, but I need to check it first.

Comment 22

[Fidon]

Hi, just checking in. Have you been able to try out your idea? Thanks!

Comment 23

[Tymur Boiko]

Attachment: Bug 2057724 - Sandbox - Allow /dev/udmabuf in RDD for Vulkan DMA-BUF export. r?jld,#sandbox-reviewers

NVIDIA EGL/Vulkan on Wayland opens /dev/udmabuf and issues UDMABUF_CREATE
(ioctl type 'u', e.g. 0x40187542) against a sealed memfd, checking its seals
via fcntl(F_GET_SEALS). Without broker + seccomp access for both, the RDD
process is killed and VideoBridge sees AbnormalShutdown; later reinits fail
to create a decoder. X11 typically never hits this path.

Comment 24

[Tymur Boiko]

Hi,
Just submitted a patch. You can try if it works for you

Comment 25

[Tymur Boiko]

Hi, Martin, Paul,
Can you please land this Sandbox patch for Wayland? (D314604)

Comment 26

[Paul Adenot (:padenot)]

Tymur, I just queued it for landing, thanks a lot for the fix (and the decoding backend in the first place, goes without saying). Don't hesitate to ping me directly should you need anything, chat.mozilla.org or [e-mail] (or "Request information from" Bugzilla feature).

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/acf7317ebe39
https://hg.mozilla.org/integration/autoland/rev/f441e5f2918b
Sandbox - Allow /dev/udmabuf in RDD for Vulkan DMA-BUF export. r=jld,sandbox-reviewers

Comment 28

[Serban Stanca [:SerbanS]]

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

Comment 29

[Tymur Boiko]

Hi Fidon,
If I understand correctly, it should be in today nightly.
https://hg-edge.mozilla.org/mozilla-central/pushloghtml
Your browser should show a build date of 2026-07-30 (e.g. 20260730...)
You can try it if it works for you.

Serban, can you please correct me If am wrong.

Comment 30

[Paul Adenot (:padenot)]

Tymur, that's right. If you click on the URL above:

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

you can see the following section near the top:

first release with	
nightly linux64
e27ed214afc8 / 155.0a1 / 20260729213106 / files
nightly mac
e27ed214afc8 / 155.0a1 / 20260729213106 / files
nightly win32
e27ed214afc8 / 155.0a1 / 20260729213106 / files
nightly win64
e27ed214afc8 / 155.0a1 / 20260729213106 / files
last release without	
nightly linux32
75d829afb4b0 / 145.0a1 / 20250916090445 / files
nightly linux64
aea36f7c13ce / 155.0a1 / 20260729095131 / files
nightly mac
aea36f7c13ce / 155.0a1 / 20260729095131 / files
nightly win32
aea36f7c13ce / 155.0a1 / 20260729095131 / files
nightly win64
aea36f7c13ce / 155.0a1 / 20260729095131 / files 

You can decypher 20260729095131, 2026-07-29 09:51:31, meaning "the morning nighlty on the 29th of July 2026" (we do two nigthlies a day these days). about:support has the current buildid.

Comment 31

[Fidon]

Hi
155.0a1-20260730132738 , so the commit should be included. Unfortunately it won't work for me.

Comment 32

[Fidon]

Attachment: newtestafter+commit.webm

New test after patch.

1. Two video on youtube with RDD sandbox enabled. Acceleration KO
2. Two video on youtube with RDD sandbox disabled : Acceleration OK.

dnf list installed firefox-nightly
Paquets installés (available for reinstall, available for upgrade)
firefox-nightly.x86_64 155.0a1-20260730132738 mozilla

Comment 33

[Tymur Boiko]

So, as far as I can see, it doesn't work for you. Can you please share the logs again (without MOZ_DISABLE_RDD_SANBOX)?

Comment 34

[Tymur Boiko]

and MOZ_SANDBOX_LOGGING=1 firefox-nightly 2> sandbox.log

Comment 35

[Tymur Boiko]

[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current
[GFX1]: EGLContext#true is owned by/Current on thread#51556 but MakeCurrent requested on thread#51409!
[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current
[GFX1]: EGLContext#true is owned by/Current on thread#51556 but MakeCurrent requested on thread#51557!
[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current
[GFX1]: EGLContext#true is owned by/Current on thread#51556 but MakeCurrent requested on thread#51409!
[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current

These are most likely a root cause. However previous patch is important.

Comment 36

[Fidon]

Attachment: rddlog..tar.gz

MOZ_DISABLE_RDD_SANDBOX=1 MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,RemoteDecode:5,sync" MOZ_LOG_FILE=rddlog firefox-nightly

1. Opening youtube video

Comment 37

[Fidon]

Attachment: sandboxafterchanges.log

MOZ_SANDBOX_LOGGING=1 firefox-nightly 2> ssandboxafterchanges.log
After new patch

1. Opening youtube video

Comment 38

[Fidon]

(In reply to Tymur Boiko from comment #35)

Please find the logs, i hope you can find something inside. Yes, I think we're making progress. As far as the symptoms go, the videos on YouTube are currently hard to watch because they're choppy. software decoding...

Comment 39

[Fidon]

Same situation with 20260801094916.
@Tymur : Did you have time to check the last logs ? Thanks

Comment 40

[Tymur Boiko]

Thanks for the new logs.

The landed fix is working. RDD's broker policy now includes /dev/udmabuf with the correct permissions, and sandboxafterchanges.log shows zero denials for that device (versus ten in the pre-patch log). RDD also survives the entire session now.

The remaining denials are benign - missing $ORIGIN probes, /proc/self/status reads, nonexistent Vulkan loader directories, and other harmless checks that were already present before.

What stands out is a new pattern: RDD looks stuck in a decoder create/destroy loop. Across that session it rescans the Vulkan loader directories ~147 times and rebuilds the NVIDIA EGL/GL stack ~30 times, at a very regular interval.

rddlog..tar.gz was empty (both .moz_log files were 0 bytes, maybe Firefox was killed rather than exited from the menu?), so I still need a usable MOZ_LOG capture from the broken sandboxed run:

mkdir -p /tmp/rddlog
MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,DMABUFSurface:5,RemoteDecode:5,timestamp,sync"
MOZ_LOG_FILE=/tmp/rddlog/moz.log firefox-nightly
#play a YouTube video, then quit Firefox from the menu (do not kill it)
tar czf rddlog.tar.gz -C /tmp rddlog`
Please attach rddlog.tar.gz and check the files inside are not empty.

Can you also try if it works with X11 display?
GDK_BACKEND=x11 firefox-nightly

PS:
I no longer see the ClaimSnapshotGLContext: Failed to make GLContext current / EGLContext#... is owned by/Current on thread#... errors in the new log — they were only in the earlier sandbox.log from July 25.

Comment 41

[Fidon]

Hi.

1. As for the log, I don't know why, but even when I close Firefox properly, it clears the contents of the files.
   So I played the video, then copied and pasted the files before closing Firefox. I hope that will work. Log below my post.

2. GDK_BACKEND=x11 firefox-nightly
   Everything works. I tried one video first, then a second one. Decoding is working fine. (Just like on your end, since you’re using x11 :)).

Comment 42

[Fidon]

Attachment: rdd.tar.gz

MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,DMABUFSurface:5,RemoteDecode:5,timestamp,sync" MOZ_LOG_FILE=/tmp/rddlog/moz.log firefox-nightly

Without closing firefox at the end because the file is empty if i do it.

Comment 43

[[:nickname]Mark]

Attachment: rddlog_sandbox_enabled.tar.gz

these logs were taken with nightly buildid 20260801211258 on Fedora44 Gnome/mutter 50.3
video plays fine on wayland with RDD_sandbox enabled but hw decoding is not active according to nvtop and nvidia-smi. Top shows the 'RDD Process' as #1 process

errors printed in terminal are

[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current
[GFX1-]: ClaimSnapshotGLContext: Failed to make GLContext current

Comment 44

[[:nickname]Mark]

Attachment: rddlog_sandbox_enabled_x11.tar.gz

HW decoding works with Xwayland

Comment 45

[[:nickname]Mark]

Attachment: rddlog_sandbox_disabled.tar.gz

and with MOZ_DISABLE_RDD_SANDBOX=1

Comment 46

[[:nickname]Mark]

Comment on attachment 9620914 [details]
rddlog_sandbox_disabled.tar.gz

description was wrong

Comment 47

[Tymur Boiko]

Thanks for the three captures — the Wayland / XWayland / sandbox-off split is exactly what was needed.

Your broken run fails the same way as the original report: ClaimSnapshotGLContext: Failed to make GLContext current, then UseDmaBufGL(): Missing GLContext! and [VULKAN] GetVideoFrameSurface failed!. Your three tarballs are MOZ_LOG only though, so they don't include any sandbox denials. On the original reporter's machine, a separate run with MOZ_SANDBOX_LOGGING=1 showed the RDD process denied connect-abstract to /tmp/.X11-unix/X0 during NVIDIA EGL bring-up - that denial is absent when the UI is X11 (the sandbox already grants the X socket) and when the sandbox is off.

Could you redo just the broken case once, with both the decode log and the sandbox denials from the same Firefox session? One command is enough: MOZ_LOG_FILE writes the module logs to files, and 2> captures sandbox denials plus the [GFX1-] lines on stderr:

mkdir -p /tmp/rddlog
MOZ_SANDBOX_LOGGING=1
MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,DMABUFSurface:5,RemoteDecode:5,timestamp,sync"
MOZ_LOG_FILE=/tmp/rddlog/moz.log
firefox-nightly 2> /tmp/rddlog/sandbox.log

Comment 48

[Tymur Boiko]

Thanks for confirming GDK_BACKEND=x11 works, and for the latest MOZ_LOG.

Can you please also collect both synced logs from one Firefox session, as above?

mkdir -p /tmp/rddlog
MOZ_SANDBOX_LOGGING=1
MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,DMABUFSurface:5,RemoteDecode:5,timestamp,sync"
MOZ_LOG_FILE=/tmp/rddlog/moz.log
firefox-nightly 2> /tmp/rddlog/sandbox.log

Broken case only (Wayland + sandbox on). Play until HW decode fails, then copy /tmp/rddlog/ before quitting and attach the directory.

Comment 49

[Fidon]

The following command :
MOZ_SANDBOX_LOGGING=1
MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,DMABUFSurface:5,RemoteDecode:5,timestamp,sync"
MOZ_LOG_FILE=/tmp/rddlog/moz.log
firefox-nightly 2> /tmp/rddlog/sandbox.log

doesn't give me much. just a sandbox.log file with a few uninteresting lines about languages... And no moz.log

I try with this one if it suit you?
MOZ_SANDBOX_LOGGING=1
MOZ_LOG="timestamp,FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,DMABUFSurface:5,RemoteDecode:5,sync"
firefox-nightly > /tmp/rddlog/moz.log 2>&1

Comment 50

[Fidon]

Attachment: moz.log

MOZ_SANDBOX_LOGGING=1
MOZ_LOG="timestamp,FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,DMABUFSurface:5,RemoteDecode:5,sync"
firefox-nightly > /tmp/rddlog/moz.log 2>&1

Comment 51

[[:nickname]Mark]

Attachment: rddlog_wayland_sandbox.tar.gz

Build ID 20260802092052

Comment 52

[[:nickname]Mark]

Attachment: rddlog_wayland_sandbox.tar.gz

this one is complete

Comment 53

[Tymur Boiko]

Attachment: Bug 2057724 - Sandbox - Allow RDD XWayland socket and Xauthority on Wayland for Vulkan Video. r?jld,#sandbox-reviewers

On a GTK Wayland session, AddX11Dependencies() skips the X11 socket because
GdkIsWaylandDisplay() is true, but NVIDIA EGL bring-up in RDD still connects
to /tmp/.X11-unix/X* (XWayland). That connect is denied under the RDD sandbox
and hardware decode fails; with MOZ_DISABLE_RDD_SANDBOX=1, or with
GDK_BACKEND=x11 where the socket is already granted, decode works. Grant
/tmp/.X11-unix/X for the Wayland+DISPLAY case only in GetRDDPolicy() when
Vulkan Video is FEATURE_STATUS_OK.

Comment 54

[Tymur Boiko]

Thank you for the logs. Same session shows RDD denied /tmp/.X11-unix/X0 during EGL bring-up (yes, even on Wayland), then later ClaimSnapshotGLContext / Missing GLContext. That X-socket denial is the only meaningful sandbox denial I see.

There's a sandbox patch for that grant, but it needs verification first (try build / patched Nightly): we need someone to confirm that NVIDIA + Wayland + sandbox-on HW decode recovers before we land it. It would be great if you сould try it

Comment 55

[Fidon]

I try
git diff --stat
python/mozboot/bin/bootstrap.py | 505 ----------------------------------------------
security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp | 7 +
2 files changed, 7 insertions(+), 505 deletions(-)

So the patch is well implemented.
Same issue after running.

New test with :
MOZ_SANDBOX_LOGGING=1
MOZ_LOG="FFmpegVideo:5,FFmpegLib:5,PlatformDecoderModule:5,Dmabuf:5,DMABUFSurface:5,RemoteDecode:5,timestamp,sync"
MOZ_LOG_FILE=/tmp/rddlog/moz.log
./mach run 2> /tmp/rddlog/sandbox.log

Comment 56

[Fidon]

Attachment: testafternewpatch.tar.gz

Comment 57

[[:nickname]Mark]

Attachment: rddlog_D315912_wayland_sandbox.tar.gz

At first, I wasn't sure if I had make a mistake somewhere, since this was my first local firefox build.
Unfortunately, I have to confirm that sandbox still fails on wayland, no issues with xwayland or disabled sandbox.

Comment 58

[Tymur Boiko]

Thank you for testing D315912. Confirmed in the new logs: X11-unix is granted and denials are gone, but NVIDIA driver + Wayland + sandbox-on still fails with Missing GLContext / GetVideoFrameSurface failed after Vulkan briefly initializes (same path as before). So the XWayland connect grant is not sufficient; abandoning it as the fix and looking at ClaimSnapshotGLContext / GL context lifetime next (will amend the patch).

Comment 59

[Tymur Boiko]

However In the same log, RDD still hit:

denied … path=/run/user/1000/.mutter-Xwaylandauth.<suffix>
Authorization required, but no authorization protocol specified

ClaimSnapshotGLContext: Failed to make GLContext current

On GNOME Wayland that path is $XAUTHORITY (Mutter creates $XDG_RUNTIME_DIR/.mutter-Xwaylandauth.* and exports it). Socket-only was incomplete — AddX11Dependencies() on X11 grants socket and cookie; we had only mirrored the socket.

Updated the revision to also AddPath(rdonly, $XAUTHORITY) in the same Wayland+DISPLAY Vulkan RDD block.

Please re-test the updated build on Wayland with RDD sandbox on (no MOZ_DISABLE_RDD_SANDBOX).

Comment 60

[[:nickname]Mark]

Attachment: rddlog_D315912_wayland_sandbox_success.tar.gz

this one works fine.

Comment 61

[Fidon]

Attachment: newtest2.tar.gz

Comment 62

[Fidon]

As for me, I wasn't able to do it/ this is the log I'm getting. I might try recompiling it properly again.

Comment 63

[Fidon]

dec on nvidia-smi dmon stay at 0% on my side. Perhaps i'll wait the proper build if it's ok for Mark.

Comment 64

[Tymur Boiko]

Thanks for testing. Unfortunately your latest run (newtest2.tar.gz) didn't exercise the patch: the string "vulkan" doesn't appear anywhere in the logs. RDD initialized only FFmpeg(FFVPX) with "Hw codec disabled by gfxVars" for every codec and all 74 decoder inits report IsHardwareAccelerated=false, so the whole session was software decode. The "Failed to copy image data" warnings are just noise from the software path, not a failure.
Could you please double check the below settings and if it still works for you with MOZ_DISABLE_RDD_SANDBOX=1?
media.hardware-video-decoding-vulkan.enabled and, optionally (if you have FFmpeg 9.0), .direct-export.enabled

Comment 65

[Fidon]

My bad! I completely forgot to re-enable the vulkan variable after recompiling.

It works! :)

Comment 66

[Tymur Boiko]

Good to hear, thanks for the help with the debugging.

Comment 67

[[:nickname]Mark]

I think there are more pitfalls waiting
when a stream fails for some reason and has to restart then hw decoding remains disabled, with disabled sandbox the stream continues to use hw decoding.

I can force this with a 4K YT stream.

Comment 68

[[:nickname]Mark]

Attachment: stream_restarts_no-hwdec_wayland_sandbox.tar.gz

Comment 69

[[:nickname]Mark]

Attachment: stream_restarts_wayland_sandbox_off.tar.gz

Comment 70

[Tymur Boiko]

With both sandbox on and off you hit 16 late frames, so the HW decoder is torn down and playback falls back to CPU — that part is by design and it happens identically in both logs (same 4K VP9, same decode timing beforehand).

The difference is what follows. With sandbox off the whole audio+video session was restarted (seek/reload — resolution stayed 4K, so not a quality switch), which builds a fresh reader and clears the "HW disabled" flag, so hardware decoding comes back. With sandbox on playback just continued in place, only the video decoder was swapped for a software one, and the flag stays set for the rest of that session. Same code in both, different next event — no sandbox permission is involved.

So the real problem is that 4K hits the slow-decode threshold at all (FFmpeg/Vulkan backend — see https://bugzilla.mozilla.org/show_bug.cgi?id=2058347), and that the SW fallback then latches HW off until the reader is replaced.

Can you confirm whether you did anything different in the sandbox-off run — a seek, replay, or page reload after the slowdown? The logs show a full audio+video restart there and none in the sandbox-on run, so I want to be sure it wasn't the player doing it on its own.

Comment 71

[[:nickname]Mark]

Can you confirm whether you did anything different in the sandbox-off run — a seek, replay, or page reload after the slowdown?

no, nothing different, started the stream (I guess it's one of the endless looping videos ), also reproduced the same behaviour (automatic restart ) with the current official nightly.

I tried to reproduce now again, ( system was suspended s2idle), and now in both cases the stream did not restart but continued with SW decoding. Tried with the x11 backend and could not reproduce the switch to SW decoding at all. HW dec is stable and I see ~ only half of the Decoder % usage compared to the wayland backend.

e.g. on wayland 'nvidia-smi -q -d UTILIZATION -l |grep Decoder' shows values 14-19% , while x11 backend is < 10 %

here is the link to the YT video https://www.youtube.com/watch?v=vXoIaXD-bBE
I close the chat, switch to theater mode 't' , not fullscreen. Two extensions are installed 'block origin' + 'enhanced-h264ify'

So I guess we can ignore that for now.

Comment 72

[Tymur Boiko]

Thank you for the explanation. OK, let's land the second patch D315912.

Comment 73

[[:nickname]Mark]

ok, now I know how to force this. I think this should probably be a new bug report, though.

The automatic reload can be forced, by switching from a lower resolution i.e FHD or QHD to 4k, stream re-starts with 4k, but runs easily into decoder issues and restarts automatically, even with active sandbox. after the second decoder fail inside a few seconds, codec is downgraded from VP9 to AVC (FHD ).

looks like this is only reproducible with wayland backend, GDK_BACKEND=x11 is stable once again.
Any idea why there is the difference in reported Decoder % usage between wayland and x11?

I'm going to install the new Nvidia driver in a moment.

Comment 74

[Tymur Boiko]

Let's separate the above issue from the sandbox issue. Is it also reproducible with MOZ_RDD_DISABLE_SANDBOX=1?
If you see late (slow) frames in the log, this is a known issue with FFmpeg, as noted above.
Otherwise it would be better to provide logs (if it is sandbox related).

Comment 75

[Tymur Boiko]

sorry, typo MOZ_DISABLE_RDD_SANDBOX=1

Comment 76

[[:nickname]Mark]

it's def. not sandbox related.

Comment 77

[Tymur Boiko]

Paul,
Could you please land the second sandbox patch (D315912). It is required for the NVIDIA driver + Wayland to work correctly in a sandbox.

Comment 78

[Paul Adenot (:padenot)]

Tymur, ping me when :jld has reviewed, and I'll do it quickly (or he can do it, as well!), thanks!

Comment 79

[Tymur Boiko]

accepted, please, land it

Comment 80

[Paul Adenot (:padenot)]

Done, thanks!

Comment 81

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/91b0860d83c0
https://hg.mozilla.org/integration/autoland/rev/a1203d2c667b
Sandbox - Allow RDD XWayland socket and Xauthority on Wayland for Vulkan Video. r=jld,sandbox-reviewers

Comment 82

[pstanciu]

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