[upstream] RDD sandbox prevents HW-accelerated video playback
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Unknown
|
|||
firefox (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
• Ubuntu 21.10 (64 bit)
• Firefox 98 installed via apt (cookies & cache have been cleared)
• Kernel 5.13.0-30-generic x86_64
• Tried on both wayland and X11 session → same result
Steps to reproduce:
(1) Visit https:/
(2) Choose one of the video
Actual Result: Video doesn't play
What Expected: Video Play normally
Previously it was normal on Firefox 97 (apt version)
Tried installing Firefox 98 Snap version and it works normally
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #16 |
Some details were provided to Bug 1724385 which also depends on this one.
Run with MOZ_SANDBOX_
Sandbox: Failed errno -2 op stat flags 00 path /tmp/Temp-
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/
Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/
Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/
[GFX1]: Failed to create snapshot GLContext.
Reproduction steps are fairly easy, play a video clip on a page and try to bookmark it or move by D&D.
In Mozilla Bugzilla #1751363, Robert Mader (robert.posteo) wrote : | #17 |
Dupe of bug 1749623?
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #18 |
*** Bug 1749623 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #19 |
Gnome Wayland, Debian Testing, Intel
bug 1752282 comment 16: Since bug 1724385, VAAPI seems to require GL context in RDD, otherwise won't work anymore.
Workaround is MOZ_DISABLE_
Expected: `sudo intel_gpu_top` has hw video decoding workload.
Actual: It doesn't have.
STR (for X11/Xwayland with Mesa >=21 or Wayland):
MOZ_SANDBOX_
> 0:32.28 INFO: b'libva info: va_openDriver() returns 0'
> 0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=0 perms=0 path=/dev/
> 0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 00 path /dev/graphics/fb0'
> 0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evp
> 0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evp
> 0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evp
> 0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evp
> 0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/
> 0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/
> 0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/
> 0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #20 |
*** Bug 1753390 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Aosmond (aosmond) wrote : | #21 |
*** Bug 1755526 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #22 |
*** Bug 1755607 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Release-mgmt-account-bot (release-mgmt-account-bot) wrote : | #23 |
Set release status flags based on info from the regressing bug 1724385
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #24 |
*** Bug 1758431 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #25 |
*** Bug 1758613 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00) wrote : | #26 |
Can confirm this on Manjaro Linux: I believe I was updated to Firefox 98 yesterday, ever since I'm unable to play video on any website, sometimes it works briefly but playback lags and stops to the point where it's unplayable. The issue goes away after disabling "media.
In Mozilla Bugzilla #1751363, Evilpies (evilpies) wrote : | #27 |
*** Bug 1758738 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Evilpies (evilpies) wrote : | #28 |
Workaround: Start Firefox with MOZ_DISABLE_
In Mozilla Bugzilla #1751363, Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00) wrote : | #29 |
I'm using that workaround now: If I start FF with "export MOZ_DISABLE_
In Mozilla Bugzilla #1751363, Mel34 (mel34) wrote : | #30 |
(In reply to Tom Schuster [:evilpie] from comment #13)
> Workaround: Start Firefox with MOZ_DISABLE_
Why not recommend a downgrade to 97.0.2 instead where everything just worked without compromising security?
In Mozilla Bugzilla #1751363, peng shao (shallpion) wrote : | #31 |
(In reply to Mel from comment #15)
> Why not recommend a downgrade to 97.0.2 instead where everything just worked without compromising security?
It asks to create a new profile and it may be inconvenient for some users
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #32 |
Don't downgrade because security bugs have been fixed.
The workaround only disables the sandbox for a process that contains fuzzed media decoders, javascript is still sandboxed in its content process.
Personally I don't use the workaround and just wait for this bug to be fixed.
In Mozilla Bugzilla #1751363, Steindaimar (steindaimar) wrote : | #33 |
> Can confirm this on Manjaro Linux: I believe I was updated to Firefox 98 yesterday, ever since I'm unable to play video on any website, sometimes it works briefly but playback lags and stops to the point where it's unplayable. The issue goes away after disabling "media.
Can confirm this happening, specially with Twitch, as it constantly keeps crashing with Error #3000. Other sites work normally on my experience and disabling `media.
`MOZ_DISABLE_
Using `MOZ_LOG=
`[Child 336: Main Thread]: D/PlatformDecod
But when I try to play a video the logs seem to treat like VA-API is working correctly in the beginning:
```
[RDD 490: MediaPDecoder #2]: D/PlatformDecod
[RDD 490: MediaPDecoder #2]: D/PlatformDecod
[RDD 490: MediaPDecoder #2]: D/PlatformDecod
[Child 410: MediaPDecoder #1]: V/PlatformDecod
[RDD 490: MediaPDecoder #1]: D/PlatformDecod
libva info: VA-API version 1.12.0
libva info: Trying to open /usr/lib/
[Child 410: MediaPDecoder #2]: V/PlatformDecod
libva info: Trying to open /usr/lib/
libva info: Found init function __vaDriverInit_1_12
libva info: va_openDriver() returns 0
```
But I eventually get this error:
`[RDD 490: MediaPDecoder #1]: D/PlatformDecod
Which leads to these messages and after that it falls back to regular FFmpeg decoder:
```
[RDD 490: MediaPDecoder #1]: D/PlatformDecod
[RDD 490: MediaPDecoder #1]: D/PlatformDecod
```
In Mozilla Bugzilla #1751363, Tempel-julian (tempel-julian) wrote : | #34 |
It doesn't even work with MOZ_DISABLE_
description: | updated |
In Mozilla Bugzilla #1751363, Evilpies (evilpies) wrote : | #35 |
*** Bug 1759109 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Ajtbecool (ajtbecool) wrote : | #36 |
What are the exact security implications of the aforementioned workaround? I want a secure browser, but I also don't want my lap to burn while watching YouTube videos xD.
In Mozilla Bugzilla #1751363, Igarcia1089 (igarcia1089) wrote : | #37 |
Can confirm issue on Fedora 35. I just updated to Firefox 98 and VA-API HW acceleration is not working. It was working fine on Firefox 97.
In Mozilla Bugzilla #1751363, Evilpies (evilpies) wrote : | #38 |
Comment 18 (Daimar Stein) and comment 19 (walmartguy) please open new bugs or check if there is an existing similar bug, this bug is *only* about VAAPI not working because of sandboxing.
> What are the exact security implications of the aforementioned workaround? I want a secure browser, but I also don't want my lap to burn while watching YouTube videos xD.
It's hard to quantify. Thanks to VA-API decoding now happening in its own RDD process exploitation gets hard of course. But having no sandbox at all obviously makes it trivial to take over everything if an exploit is found.
Aditya Suseno (aditya-suseno) wrote : | #1 |
Aditya Suseno (aditya-suseno) wrote : | #2 |
Package: firefox
Version: 98.0+build3-
Priority: optional
Section: web
Origin: Ubuntu
Maintainer: Ubuntu Mozilla Team <email address hidden>
Bugs: https:/
Installed-Size: 232 MB
Provides: gnome-www-browser, iceweasel, www-browser
Depends: lsb-release, libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.34), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.10.0), libdbus-1-3 (>= 1.9.14), libdbus-glib-1-2 (>= 0.78), libfontconfig1 (>= 2.12.6), libfreetype6 (>= 2.10.1), libgcc-s1 (>= 3.3), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.42), libgtk-3-0 (>= 3.14), libharfbuzz0b (>= 0.6.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libstdc++6 (>= 11), libx11-6, libx11-xcb1 (>= 2:1.7.2), libxcb-shm0, libxcb1, libxcomposite1 (>= 1:0.4.5), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxi6, libxrandr2 (>= 2:1.4.0), libxrender1, libxtst6
Recommends: xul-ext-ubufox, libcanberra0, libdbusmenu-glib4, libdbusmenu-gtk3-4
Suggests: fonts-lyx
Replaces: kubuntu-
Task: kubuntu-desktop, kubuntu-full, xubuntu-desktop, lubuntu-desktop, ubuntustudio-
Xul-Appid: {ec8030f7-
Download-Size: 62.6 MB
APT-Sources: http://
Description: Safe and easy web browser from Mozilla
Firefox delivers safe, easy web browsing. A familiar user interface,
enhanced security features including protection from online identity theft,
and integrated search let you get the most out of the web.
Aditya Suseno (aditya-suseno) wrote : | #3 |
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #39 |
*** Bug 1759464 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Evilpies (evilpies) wrote : | #40 |
*** Bug 1760514 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, JORGETECH (jorgetech) wrote : | #41 |
I can confirm this issue affects me in Firefox 98.0.1 (Kubuntu 21.10, AMD Ryzen iGPU with Mesa 22.0.0).
Playing a YouTube video makes the browser crash or not load the video and I get this on the console output:
```
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/
libva info: Found init function __vaDriverInit_1_14
ATTENTION: default value of option mesa_glthread overridden by environment.
/usr/share/
```
I had to set the media.rdd-
I'm surprised this change landed in an stable release.
In Mozilla Bugzilla #1751363, Release-mgmt-account-bot (release-mgmt-account-bot) wrote : | #42 |
The severity field for this bug is relatively low, S3. However, the bug has 9 duplicates, 13 votes and 78 CCs.
:gcp, could you consider increasing the bug severity?
For more information, please visit [auto_nag documentation](https:/
In Mozilla Bugzilla #1751363, Gpascutto (gpascutto) wrote : | #43 |
>I'm surprised this change landed in an stable release.
The feature is marked as disabled in Firefox 98.
In Mozilla Bugzilla #1751363, Gpascutto (gpascutto) wrote : | #44 |
>The feature is marked as disabled in Firefox 98.
And indeed it is: https:/
So to answer the question: nothing "landed in a stable release", this configuration was never supported nor released yet because of bugs like this one.
In Mozilla Bugzilla #1751363, Iamtrazy (iamtrazy) wrote : | #45 |
please consider increasing the severity of this bug , this still happens on both amd and intel on firefox 98.0.2 , hardware accelerations worked perfectly fine before 98 update without disabling rdd sandbox.
In Mozilla Bugzilla #1751363, Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00) wrote : | #46 |
I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.
In Mozilla Bugzilla #1751363, Julian Sikorski (belegdol) wrote : | #47 |
(In reply to <email address hidden> from comment #31)
> I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.
Just disable VAAPI and you will be able to watch videos just fine. On my machine (Ryzen 4500U) the difference in CPU load when watching youtube is minimal anyway. Please keep in mind that hardware acceleration was never officially enabled in release builds so please adjust your expectations accordingly.
In Mozilla Bugzilla #1751363, RussianNeuroMancer (russianneuromancer) wrote : | #48 |
> Just disable VAAPI and you will be able to watch videos just fine.
Some hardware cannot handle anything above 480p on YouTube unless hardware acceleration is enabled and works.
In Mozilla Bugzilla #1751363, Jay Chu (escape0707) wrote : | #49 |
(In reply to <email address hidden> from comment #31)
> I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.
For now, set the media.rdd-
In Mozilla Bugzilla #1751363, Mav (basic89) wrote : | #50 |
(In reply to Jay Chu from comment #34)
> (In reply to <email address hidden> from comment #31)
> > I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.
>
> For now, set the media.rdd-
This is helpful, thank you. Nevertheless, most "normal" users will never find this topic, neither the config page. Firefox won't work for everyday use for them (consider the popularity of video streaming) and they will be switching to a browser that works. With AMD and intel GPUs common nowadays, we are talking a significant exodus of firefox users towards alternatives. Current P3 priority absolutely does not cut it.
In Mozilla Bugzilla #1751363, Pmenzel+bugzilla-mozilla-org (pmenzel+bugzilla-mozilla-org) wrote : | #51 |
@EvilMav, nobody disagrees, but it’s unrelated to the bug report. Firefox is FLOSS, so you can fix it or pay somebody. As long as users don’t support Firefox financially (donate or buy commercial GNU/Linux distribution licenses like RHEL desktop) so more developers can be paid to work on Firefox under GNU/Linux in full-time, the current state won’t change. But as written, it’s off-topic.
Olivier Tilloy (osomon) wrote : | #4 |
Aditya, can you check whether libavcodec58 is installed? If it isn't, please install that package, then restart firefox, and let us know whether this fixed the problem.
Changed in firefox (Ubuntu): | |
status: | New → Incomplete |
In Mozilla Bugzilla #1751363, Gpascutto (gpascutto) wrote : | #52 |
I'm updating the flags just to make it clear we are in fact already working on this, see also https:/
Aditya Suseno (aditya-suseno) wrote (last edit ): | #5 |
sudo apt install libavcodec58
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libavcodec58 is already the newest version (7:4.4-6ubuntu5).
libavcodec58 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Seems that it's already installed
What about the behaviour in other machine (on ubuntu that is using apt)?
Aditya Suseno (aditya-suseno) wrote (last edit ): | #6 |
From the debug information, I suspect that the problem is on /usr/lib/
My machine is AMD® Ryzen 5 5600g with integrated radeon graphics by the way
There was an update for Firefox 98.0.2
Haven't tried the apt version for the 98.0.2
Will tried that this night, hopefully the problem disappear on this new update.
Aditya Suseno (aditya-suseno) wrote : | #7 |
Aditya Suseno (aditya-suseno) wrote : | #8 |
- Screenshot from 2022-03-29 11-07-12.png Edit (1.5 MiB, image/png)
But sometimes, what you need is just reloading the page
Olivier Tilloy (osomon) wrote : | #9 |
From the error messages, the problem seems to be with reading /usr/share/
Aditya Suseno (aditya-suseno) wrote : | #10 |
/usr/share/libdrm$ ls -l
-rw-r--r-- 1 root root 10551 Jul 2 2021 amdgpu.ids
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #53 |
*** Bug 1759842 has been marked as a duplicate of this bug. ***
Aditya Suseno (aditya-suseno) wrote : | #11 |
And this is the content of amdgpu.ids
It's just a plain text file
# List of AMDGPU IDs
#
# Syntax:
# device_id, revision_id, product_name <-- single tab after comma
1.0.0
15DD, C3, AMD Radeon(TM) Vega 3 Graphics
15DD, CB, AMD Radeon(TM) Vega 3 Graphics
15DD, CE, AMD Radeon(TM) Vega 3 Graphics
15DD, D8, AMD Radeon(TM) Vega 3 Graphics
15DD, CC, AMD Radeon(TM) Vega 6 Graphics
15DD, D9, AMD Radeon(TM) Vega 6 Graphics
15DD, C2, AMD Radeon(TM) Vega 8 Graphics
15DD, C4, AMD Radeon(TM) Vega 8 Graphics
15DD, C8, AMD Radeon(TM) Vega 8 Graphics
15DD, CA, AMD Radeon(TM) Vega 8 Graphics
15DD, D1, AMD Radeon(TM) Vega 8 Graphics
15DD, D5, AMD Radeon(TM) Vega 8 Graphics
15DD, D7, AMD Radeon(TM) Vega 8 Graphics
15DD, C3, AMD Radeon(TM) Vega 10 Graphics
15DD, D0, AMD Radeon(TM) Vega 10 Graphics
15DD, C1, AMD Radeon(TM) Vega 11 Graphics
15DD, C6, AMD Radeon(TM) Vega 11 Graphics
15DD, C9, AMD Radeon(TM) Vega 11 Graphics
15DD, D3, AMD Radeon(TM) Vega 11 Graphics
15DD, D6, AMD Radeon(TM) Vega 11 Graphics
15DD, 81, AMD Ryzen Embedded V1807B with Radeon Vega Gfx
15DD, 82, AMD Ryzen Embedded V1756B with Radeon Vega Gfx
15DD, 83, AMD Ryzen Embedded V1605B with Radeon Vega Gfx
15DD, 85, AMD Ryzen Embedded V1202B with Radeon Vega Gfx
15D8, 93, AMD Radeon(TM) Vega 1 Graphics
15D8, C4, AMD Radeon(TM) Vega 3 Graphics
15D8, C5, AMD Radeon(TM) Vega 3 Graphics
15D8, CC, AMD Radeon(TM) Vega 3 Graphics
15D8, CE, AMD Radeon(TM) Vega 3 Graphics
15D8, CF, AMD Radeon(TM) Vega 3 Graphics
15D8, D4, AMD Radeon(TM) Vega 3 Graphics
15D8, DC, AMD Radeon(TM) Vega 3 Graphics
15D8, DD, AMD Radeon(TM) Vega 3 Graphics
15D8, DE, AMD Radeon(TM) Vega 3 Graphics
15D8, DF, AMD Radeon(TM) Vega 3 Graphics
15D8, E3, AMD Radeon(TM) Vega 3 Graphics
15D8, E4, AMD Radeon(TM) Vega 3 Graphics
15D8, A3, AMD Radeon(TM) Vega 6 Graphics
15D8, B3, AMD Radeon(TM) Vega 6 Graphics
15D8, C3, AMD Radeon(TM) Vega 6 Graphics
15D8, D3, AMD Radeon(TM) Vega 6 Graphics
15D8, A2, AMD Radeon(TM) Vega 8 Graphics
15D8, B2, AMD Radeon(TM) Vega 8 Graphics
15D8, C2, AMD Radeon(TM) Vega 8 Graphics
15D8, C9, AMD Radeon(TM) Vega 8 Graphics
15D8, CB, AMD Radeon(TM) Vega 8 Graphics
15D8, D2, AMD Radeon(TM) Vega 8 Graphics
15D8, D9, AMD Radeon(TM) Vega 8 Graphics
15D8, DB, AMD Radeon(TM) Vega 8 Graphics
15D8, A1, AMD Radeon(TM) Vega 10 Graphics
15D8, B1, AMD Radeon(TM) Vega 10 Graphics
15D8, C1, AMD Radeon(TM) Vega 10 Graphics
15D8, D1, AMD Radeon(TM) Vega 10 Graphics
15D8, C8, AMD Radeon(TM) Vega 11 Graphics
15D8, CA, AMD Radeon(TM) Vega 11 Graphics
15D8, D8, AMD Radeon(TM) Vega 11 Graphics
15D8, DA, AMD Radeon(TM) Vega 11 Graphics
15D8, 91, AMD Ryzen Embedded R1606G with Radeon Vega Gfx
15D8, 92, AMD Ryzen Embedded R1505G with Radeon Vega Gfx
15D8, CF, AMD Ryzen Embedded R1305G with Radeon Vega Gfx
15D8, E4, AMD Ryzen Embedded R1102G with Radeon Vega Gfx
6600, 0, AMD Radeon HD 8600/8700M
6600, 81, AMD Radeon (TM) R7 M370
6601, 0, AMD Radeon (TM) HD 8500M/8700M
6604, 0, AMD Radeon R7 M265 Series
6604, 81, AMD Radeon (TM) R7 M350
6605, 0, AMD Radeon R7 M260 Series
6605, 81, AMD Radeon (TM) R7 M340
6606, 0, AMD Radeon HD 8790M
6607, 0, AMD Radeon (TM) HD8530M
6608, 0, AMD FirePro W2100
6610, 0, AMD Radeon HD 8600 Series
6610, ...
Aditya Suseno (aditya-suseno) wrote : | #12 |
In Mozilla Bugzilla #1751363, Alwu (alwu) wrote : | #54 |
*** Bug 1762384 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #55 |
*** Bug 1761490 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Kaypa (kaypa) wrote : | #56 |
updated to v99 on arch and MOZ_DISABLE_
In Mozilla Bugzilla #1751363, Lucas Rizzini da Costa Lima (lucasrizzini) wrote : | #57 |
In Mozilla Bugzilla #1751363, Kaypa (kaypa) wrote : | #58 |
(In reply to kaypa from comment #41)
> updated to v99 on arch and MOZ_DISABLE_
looks like it's working again in nightly and has been fixed by https:/
not sure though
(don't know how to edit my comment sorry)
In Mozilla Bugzilla #1751363, Irxil (irxil) wrote : | #59 |
Still having issues with the latest nightly on my end. Running 101.0a1 (2022-04-05) and I see a small increase in video decode usage (using Intel GPU Top) when the [Big Buck Bunny video](https:/
In the console, the following lines repeat themselves multiple times when the Youtube page is loaded:
```
libva info: VA-API version 1.13.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib64/
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0
```
Looks like it is loading Vaapi properly but still not getting processed by the GPU.
In Mozilla Bugzilla #1751363, Irxil (irxil) wrote : | #60 |
When I run Firefox Nightly with `MOZ_SANDBOX_
```
Sandbox: SandboxBroker: denied op=open rflags=0 perms=0 path=/dev/
Sandbox: Failed errno -13 op open flags 00 path /dev/graphics/fb0
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/
Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/
Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/
Sandbox: SandboxBroker: denied op=open rflags=1102 perms=0 path=/etc/
Sandbox: Failed errno -13 op open flags 01102 path /etc/igfx_
```
In Mozilla Bugzilla #1751363, Lxsq131 (lxsq131) wrote : | #61 |
Seems like it's working on Firefox Nightly 101.0a1 (2022-04-06).
`MOZ_DISABLE_
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: VA-API version 1.8.0
libva info: Trying to open /opt/amdgpu/
libva info: Found init function __vaDriverInit_1_8
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: va_openDriver() returns 0
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: VA-API version 1.8.0
libva info: Trying to open /opt/amdgpu/
libva info: Found init function __vaDriverInit_1_8
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: va_openDriver() returns 0`
cat /sys/kernel/
In Mozilla Bugzilla #1751363, Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00) wrote : | #62 |
Wasn't the whole thing fixed in Firefox 100 as a previous comment suggested? Was hoping so but I see the bug is still open.
Aditya Suseno (aditya-suseno) wrote : | #13 |
My workaround:
Set media.ffmpeg.
OR
Set media.rdd-
While still having media.ffmpeg.
In Mozilla Bugzilla #1751363, Lxsq131 (lxsq131) wrote : | #63 |
(In reply to lxsq131 from comment #46)
> Seems like it's working on Firefox Nightly 101.0a1 (2022-04-06).
> `MOZ_DISABLE_
> ATTENTION: default value of option mesa_glthread overridden by environment.
> libva info: VA-API version 1.8.0
> libva info: Trying to open /opt/amdgpu/
> libva info: Found init function __vaDriverInit_1_8
> ATTENTION: default value of option mesa_glthread overridden by environment.
> libva info: va_openDriver() returns 0
> ATTENTION: default value of option mesa_glthread overridden by environment.
> ATTENTION: default value of option mesa_glthread overridden by environment.
> ATTENTION: default value of option mesa_glthread overridden by environment.
> libva info: VA-API version 1.8.0
> libva info: Trying to open /opt/amdgpu/
> libva info: Found init function __vaDriverInit_1_8
> ATTENTION: default value of option mesa_glthread overridden by environment.
> libva info: va_openDriver() returns 0`
>
> cat /sys/kernel/
No. I tried again and the error was back. Still needs to disable RDD sandbox. Firefox Nightly 101.0a1 (2022-04-06).
```
libva info: VA-API version 1.8.0
libva info: Trying to open /opt/amdgpu/
libva info: Found init function __vaDriverInit_1_8
ATTENTION: default value of option mesa_glthread overridden by environment.
/usr/share/
libva info: va_openDriver() returns 0
```
Olivier Tilloy (osomon) wrote : | #14 |
This seems to be an upstream bug indeed: https:/
summary: |
- [apt] Firefox 98 installed from apt cannot Play YouTube + [upstream] RDD sandbox prevents HW-accelerated video playback |
Changed in firefox (Ubuntu): | |
status: | Incomplete → Confirmed |
Changed in firefox: | |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #64 |
*** Bug 1765824 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #65 |
*** Bug 1757791 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Mel34 (mel34) wrote : | #66 |
Can you please clarify what does fix-optional status for firefox 100 mean for this bug?
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #67 |
I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
Until then, MOZ_DISABLE_
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #68 |
*** Bug 1766517 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, Tempel-julian (tempel-julian) wrote : | #69 |
(In reply to Darkspirit from comment #52)
> I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
> Until then, MOZ_DISABLE_
It doesn't work reliably regardless, as also some other reports here indicate: intel_gpu_top shows that hardware decoding initially is used for a brief moment, but then Firefox falls back to CPU decoding with intel_gpu_top reporting 0% hardware video decoding load. For whatever weird reason, it very rarely can continue to show hardware decoding load, but then breaks upon next Firefox launch too. VAAPI is completely unusable since Firefox 99 with at least Intel, also with MOZ_DISABLE_
I think I'll just go back to 98 and perhaps set up some 3rd party sandboxing in case there are open CVEs. Hardware decoding is not a bonus on slow CPUs, it's a must. Really annoying that, despite of still being experimental, it has been broken so hard.
In Mozilla Bugzilla #1751363, Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00) wrote : | #70 |
In my case I use an AMD card on Manjaro Linux (default free amdgpu driver). I can say that with Firefox 99.0.1 video on Youtube usually plays but tries going back to a lower resolution at first, also any extra system load like other tabs will cause playback to freeze and you have to restart the video. MOZ_DISABLE_
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #71 |
(In reply to walmartguy from comment #54)
> (In reply to Darkspirit from comment #52)
> > I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
> > Until then, MOZ_DISABLE_
>
> It doesn't work reliably regardless, as also some other reports here indicate: intel_gpu_top shows that hardware decoding initially is used for a brief moment, but then Firefox falls back to CPU decoding with intel_gpu_top reporting 0% hardware video decoding load.
That indicates a bud in decoding itself and not a sandbox issue. Please file that as a new bug.
In Mozilla Bugzilla #1751363, Distant Thunder (temptempor) wrote : | #72 |
Created attachment 9275655
firefox100_
Hello. Just to add in that this issue at least for my setup (Arch Linux, Firefox 100) is still current.
The previous comment suggest the problem might lie with the decoder but no other software on my machine has problem decoding through vaapi at the moment and the problems began right when RDD sandboxing was made default.
Firefox regularly fails and generate loads of crash log on my system each time it comes across a video since ~v98/99. The videos often crash, try to revert to low quality. It's particularly evident on sites like IMGUR. This was working fine before (and it took a long time to get it working) yet it was broken since 2 releases ago and is still in this state... It's quite sad Linux users are the second-class citizens on these features all over again.
---
Version: Firefox 100
OS: Arch Linux
FFMPEG: 5.0-7
vainfo: VA-API version: 1.14 (libva 2.14.0)
---
MOZ_DISABLE_
Nor does MOZ_ENABLE_
---
Cf. Logs.
In Mozilla Bugzilla #1751363, agm97 (albertogomezmarin) wrote : | #73 |
for me at least the workaround is working as expected .. But I think it's something that has to be fixed as soon as possible.. the no use of vaapi gets a browser that is not smooth and freezes with almost every playback or preview...
firefox is a lot worse since 98 version in my opinion for that.
So I think the RDD sandbox has to be disabled until this is addressed. The day to day use is very bad
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #74 |
I think we can fix that by moving GL code out of RDD process. IIUC we need to implement DMABuf based gfx::SourceSurface which can be serialized over IPC bridge to parent/content process where GL can be used and we'll map dmabuf surface only when we're asked for surface data.
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #75 |
Another option may be EGL_MESA_
In Mozilla Bugzilla #1751363, Gpascutto (gpascutto) wrote : | #76 |
>Can you please clarify what does fix-optional status for firefox 100 mean for this bug?
It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.
>I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.
In Mozilla Bugzilla #1751363, Distant Thunder (temptempor) wrote : | #77 |
(In reply to Gian-Carlo Pascutto [:gcp] from comment #61)
> >Can you please clarify what does fix-optional status for firefox 100 mean for this bug?
>
> It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.
>
> >I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
>
> The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.
Is there an official way of working around this in the meantime? Since disabling RDD sandbox isn't enough anymore on Firefox 100?
In Mozilla Bugzilla #1751363, Klubella (klubella) wrote : | #78 |
(In reply to temptempor from comment #62)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #61)
> > >Can you please clarify what does fix-optional status for firefox 100 mean for this bug?
> >
> > It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.
> >
> > >I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
> >
> > The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.
>
> Is there an official way of working around this in the meantime? Since disabling RDD sandbox isn't enough anymore on Firefox 100?
For me, it still works with disabling sandbox even on Firefox 100.0. But I still hope this gets fixed soon. :)
In Mozilla Bugzilla #1751363, Miren Radia (m1ren) wrote : | #79 |
> For me, it still works with disabling sandbox even on Firefox 100.0. But I still hope this gets fixed soon. :)
What's your system configuration (e.g. OS, GPU, VAAPI library) and what flags have you manually changed in about:config? FWIW, mine is
OS: Ubuntu 20.04
GPU: Intel HD Graphics 630 (Kaby Lake)
VAAPI library: Tried `iHD` and `i965`
and have tried modifying numerous flags (always setting `media.
In Mozilla Bugzilla #1751363, Stransky (stransky) wrote : | #80 |
If MOZ_DISABLE_
Thanks.
In Mozilla Bugzilla #1751363, Evilpies (evilpies) wrote : | #81 |
*** Bug 1771591 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #82 |
As of bug 1770407, MOZ_DISABLE_
In Mozilla Bugzilla #1751363, W-jan-k (w-jan-k) wrote : | #83 |
*** Bug 1771632 has been marked as a duplicate of this bug. ***
Changed in firefox: | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #1751363, Urjryyhbnolzlvtrry (urjryyhbnolzlvtrry) wrote : | #84 |
Created attachment 9283237
firefox log
firefox does not use VAAPI (choppy video playback)
I also get choppy video playback in the beginning of playing a video (only for 1-2 sec) even with VAAPI disabled
Name Firefox
Version 102.0
Build ID 20220623063721
Distribution ID mozilla-flatpak
In Mozilla Bugzilla #1751363, Urjryyhbnolzlvtrry (urjryyhbnolzlvtrry) wrote : | #85 |
(In reply to urjryyhbnolzlvtrry from comment #69)
> Created attachment 9283237
> firefox log
>
> firefox does not use VAAPI (choppy video playback)
> I also get choppy video playback in the beginning of playing a video (only for 1-2 sec) even with VAAPI disabled
> Name Firefox
> Version 102.0
> Build ID 20220623063721
> Distribution ID mozilla-flatpak
Wayland enabled with MOZ_ENABLE_
In Mozilla Bugzilla #1751363, Gpascutto (gpascutto) wrote : | #86 |
This bug is closed because it was fixed, so you're seeing a different problem. Please file a new bug. Flatpak could be a factor here, note above there is another bug linked were specific fixes were needed for Snap too.
Edit: Your log shows VA-API successfully initializing, so this looks unrelated to RDD/sandboxing and may be a completely unrelated performance thing. Again, file a new bug specific to your problem.
We can't create GL context in RDD process which leads to missing video snapshots. It generally brings back Bug 1712588.
What's broken:
- we can't take video snapshots (context menu -> take snapshot)
- bookmarked page with video context is black
- D&D of tabs with video playback is black