Closed Bug 1673184 Opened 4 years ago Closed 4 years ago

VP8+9 VAAPI don't work anymore unless media.rdd-vpx.enabled:false is added to the existing configuration

Categories

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

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1683808
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox81 --- unaffected
firefox82 --- unaffected
firefox83 --- unaffected
firefox84 --- disabled
firefox85 --- disabled

People

(Reporter: popovic.marko, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: power, regression)

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

Steps to reproduce:

Install Pop!_OS 20.10
Enable wayland backend, install ffmpeg and libva libs
Enable webrender in FF, enable vaapi, disable ffvpx
Launch firefox with ENV MOZ_ENABLE_WAYLAND=1 firefox (also tried nightly)

Actual results:

YouTube videos use software decoding exclusively, here are the logs:
https://justpaste.it/3h46c

How would I go about troubleshooting this issue? tried on both my IntelHD laptop and AMD-powered desktop.

My vainfo:
libva info: VA-API version 1.8.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.8 (libva 2.8.0)
vainfo: Driver version: Mesa Gallium driver 20.2.1 for AMD Radeon RX 5700 XT (NAVI10, DRM 3.38.0, 5.8.0-7625-generic, LLVM 11.0.0)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc

Thanks for the report!

Gnome Wayland, Debian Testing, Intel/Mesa
Confirmed. Since bug 1595994 only h264 videos seem to decode on the gpu (sudo intel_gpu_top ). Disabling ffvpx as before is not enough to get VP8/9 hw decoding.

MOZ_X11_EGL=1 mozregression --good 2020-10-10 --bad 2020-10-24 --pref gfx.webrender.all:true media.ffvpx.enabled:false media.ffmpeg.vaapi.enabled:true -a https://upload.wikimedia.org/wikipedia/commons/c/c0/Big_Buck_Bunny_4K.webm

15:23.12 INFO: Last good revision: 2a46f29c8cdd6f6269483e86c6e21e649ffa7127
15:23.12 INFO: First bad revision: 4c3e6fb95aa6184651f215d466e702ff7d1660d3
15:23.12 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3

Blocks: egl-linux-vaapi
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox81: --- → unaffected
status-firefox82: --- → unaffected
status-firefox83: --- → unaffected
status-firefox84: --- → disabled
status-firefox-esr78: --- → unaffected
Component: Audio/Video → Audio/Video: Playback
Ever confirmed: true
Keywords: power, regression
OS: Unspecified → Linux
Regressed by: 1595994
Hardware: Unspecified → x86_64
Summary: [WAYLAND][VA-API] After fresh install of Pop!_OS 20.10 vaapi doesn't work in gnome wayland → VP8 VAAPI doesn't work anymore

(In reply to Darkspirit from comment #1)

Thanks for the report!

Gnome Wayland, Debian Testing, Intel/Mesa
Confirmed. Since bug 1595994 only h264 videos seem to decode on the gpu (sudo intel_gpu_top ). Disabling ffvpx as before is not enough to get VP8/9 hw decoding.

MOZ_X11_EGL=1 mozregression --good 2020-10-10 --bad 2020-10-24 --pref gfx.webrender.all:true media.ffvpx.enabled:false media.ffmpeg.vaapi.enabled:true -a https://upload.wikimedia.org/wikipedia/commons/c/c0/Big_Buck_Bunny_4K.webm

15:23.12 INFO: Last good revision: 2a46f29c8cdd6f6269483e86c6e21e649ffa7127
15:23.12 INFO: First bad revision: 4c3e6fb95aa6184651f215d466e702ff7d1660d3
15:23.12 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3

Thanks for the confirmation, I thought that it was something to do with the update to 20.10

(In reply to Darkspirit from comment #1)

Thanks for the report!

Gnome Wayland, Debian Testing, Intel/Mesa
Confirmed. Since bug 1595994 only h264 videos seem to decode on the gpu (sudo intel_gpu_top ). Disabling ffvpx as before is not enough to get VP8/9 hw decoding.

MOZ_X11_EGL=1 mozregression --good 2020-10-10 --bad 2020-10-24 --pref gfx.webrender.all:true media.ffvpx.enabled:false media.ffmpeg.vaapi.enabled:true -a https://upload.wikimedia.org/wikipedia/commons/c/c0/Big_Buck_Bunny_4K.webm

15:23.12 INFO: Last good revision: 2a46f29c8cdd6f6269483e86c6e21e649ffa7127
15:23.12 INFO: First bad revision: 4c3e6fb95aa6184651f215d466e702ff7d1660d3
15:23.12 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3

Although this issue also happens on Firefox 82 (stable version) for me for some reason.

(In reply to Marko from comment #0)

YouTube videos use software decoding exclusively

If you make a right click on the playing YouTube video, click on "Stats for nerds", the codec is likely (software-decoded) AV1.
You need to disable AV1 to be able to use VP9 hw decoding with Firefox 82: https://addons.mozilla.org/firefox/addon/enhanced-h264ify/

https://justpaste.it/2jy86

Here is LOG from version 82, it's a VP9 video... there seems to be some issue with sandboxing...

DMA-Buf/VA-API can't be used, WebRender/DMA-Buf is disabled

On Linux, WebRender is so far only enabled on Nightly. On Stable you need to set gfx.webrender.all to true to force-enable WebRender. WebRender requires OpenGL 3.2.

(In reply to Darkspirit from comment #6)

DMA-Buf/VA-API can't be used, WebRender/DMA-Buf is disabled

On Linux, WebRender is so far only enabled on Nightly. On Stable you need to set gfx.webrender.all to true to force-enable WebRender.

I did, it doesn't want to work for some reason tho /shrug

See Also: → 1673191

It seems to be once again related to Pop!_OS guys messing with their firefox build... for enabling VAAPI on X11 with X11, it seems to have MOZ_X11_EGL hardcoded in, if I download 82 stable from the FF website, it works like a charm, so I was faced with 2 different issues that had same symptoms.

You need to disable gfx.xrender.enabled and to enable gfx.webrender.all. (Reported downstream to PopOS in bug 1673191.)

Severity: -- → S3
No longer regressed by: 1595994

Description and regression range are correct. The other report regarding Stable (comment 3) had a different reason (bug 1673191).

Regressed by: 1595994

Additionally disabling media.rdd-vpx.enabled works. media.ffvpx.enabled:false alone doesn't work anymore. (Why is VPX integrated twice now?)
Can this be closed as duplicate of bug 1660336, should something else be done, or the additional pref be added to the Arch Linux wiki?

(In reply to Darkspirit from comment #11)

Additionally disabling media.rdd-vpx.enabled works. media.ffvpx.enabled:false alone doesn't work anymore. (Why is VPX integrated twice now?)
Can this be closed as duplicate of bug 1660336, should something else be done, or the additional pref be added to the Arch Linux wiki?

You're mistaken on what a preference does and assume that this is the reason for the regression.

media.ffvpx.enabled controls if our internal copy of ffmpeg is going to be used or not.
media.rdd-vpx.enabled controls in which process it's going to run. If set (the default), it will run in the dedicated RDD process.

There's been no changes to how ffmpeg runs and in which process it runs. Only media.ffvpx.enabled needs to be modified to allow for the system ffmpeg to run.

Additionally bug 1672558 has now landed that will prevent people playing with the wrong pref to end up crashing firefox

No longer regressed by: 1595994

(In reply to Marko from comment #0)

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

Steps to reproduce:

Install Pop!_OS 20.10
Enable wayland backend, install ffmpeg and libva libs
Enable webrender in FF, enable vaapi, disable ffvpx
Launch firefox with ENV MOZ_ENABLE_WAYLAND=1 firefox (also tried nightly)

please provide a copy of your about:support

Flags: needinfo?(popovic.marko)

And I'm not sure why VP8 is mentioned, neither YouTube nor the AMD 5700XT supports VP8

And also provide a copy of "stats for nerds" when playing in YouTube (right click on the video and select Stats for nerds, you can copy/paste the text content)

(In reply to Jean-Yves Avenard [:jya] from comment #12)

You're mistaken on what a preference does and assume that this is the reason for the regression.

I am not mistaken in what I am seeing. I always just describe what I am seeing and additionally what I think it could be. I don't make the conclusions.
Run sudo intel_gpu_top.
Also run
MOZ_X11_EGL=1 mozregression --launch 2020-10-24 --pref gfx.webrender.all:true media.ffvpx.enabled:false media.ffmpeg.vaapi.enabled:true -a https://upload.wikimedia.org/wikipedia/commons/c/c0/Big_Buck_Bunny_4K.webm
=> vaapi is not used.

Run the same with 2020-10-10 and VAAPI works for VP8 and VP9. Now one would need to change their config to make VAAPI for VP8+VP9 work again. Only h264 VAAPI continues to work if one uses the same config as before.

comment 0 supports vp9. It would not be used anymore.
According to "stats for nerds" this uses VP9, but VAAPI is not used according to sudo intel_gpu_top:
MOZ_X11_EGL=1 mozregression --launch 2020-10-24 --pref gfx.webrender.all:true media.ffvpx.enabled:false media.ffmpeg.vaapi.enabled:true -a https://www.youtube.com/watch?v=lB6muro1Ofk

This also uses VP9, but VAAPI is used according to intel_gpu_top because I added media.rdd-vpx.enabled:false:
MOZ_X11_EGL=1 mozregression --launch 2020-10-24 --pref gfx.webrender.all:true media.ffvpx.enabled:false media.ffmpeg.vaapi.enabled:true media.rdd-vpx.enabled:false -a https://www.youtube.com/watch?v=lB6muro1Ofk

media.ffvpx.enabled controls if our internal copy of ffmpeg is going to be used or not.
media.rdd-vpx.enabled controls in which process it's going to run. If set (the default), it will run in the dedicated RDD process.

There's been no changes to how ffmpeg runs and in which process it runs. Only media.ffvpx.enabled needs to be modified to allow for the system ffmpeg to run.

Then I would assume VP8/9 have been something like "[ffvpx disabled] > system ffmpeg > vpx" before, now it is like "[ffvpx disabled] > vpx > system ffmpeg".

(In reply to Jean-Yves Avenard [:jya] from comment #12)

Only media.ffvpx.enabled needs to be modified to allow for the system ffmpeg to run.

vs.

(Darkspirit from comment #1)

MOZ_X11_EGL=1 mozregression --good 2020-10-10 --bad 2020-10-24 --pref gfx.webrender.all:true media.ffvpx.enabled:false media.ffmpeg.vaapi.enabled:true -a https://upload.wikimedia.org/wikipedia/commons/c/c0/Big_Buck_Bunny_4K.webm

15:23.12 INFO: Last good revision: 2a46f29c8cdd6f6269483e86c6e21e649ffa7127
15:23.12 INFO: First bad revision: 4c3e6fb95aa6184651f215d466e702ff7d1660d3
15:23.12 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a46f29c8cdd6f6269483e86c6e21e649ffa7127&tochange=4c3e6fb95aa6184651f215d466e702ff7d1660d3

good = VAAPI is used for VP8 example video
bad = VAAPI is not used for VP8 example video

Please explain what I am seeing here.

(In reply to Jean-Yves Avenard [:jya] from comment #14)

And I'm not sure why VP8 is mentioned, neither YouTube nor the AMD 5700XT supports VP8

Because Wikipedia has VP8 test files and it doesn't matter which one I mention.

Summary: VP8 VAAPI doesn't work anymore → VP8+9 VAAPI don't work anymore unless media.rdd-vpx.enabled:false is added to the existing configuration

Reconfirmed. VP8+VP9 VAAPI do not work with existing configuration anymore unless users additionally set media.rdd-vpx.enabled:false.

H264 VAAPI still works with unchanged prefs:
MOZ_X11_EGL=1 mozregression --launch 2020-11-16 --pref gfx.webrender.all:true media.ffvpx.enabled:false media.ffmpeg.vaapi.enabled:true -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605

This regression would hit release on 2020-12-15.
a) Should this be wontfixed and media.rdd-vpx.enabled=false be recommended on the Arch Linux wiki then?
b) This be solved differently?

status-firefox85: --- → disabled
Flags: needinfo?(popovic.marko)
Regressed by: 1595994

I am seeing similar, not just limited to VP8+9, for firefox-84: Like we (Gentoo) are using Fedora's patch for VA-API usage in FFmpeg in general. It doesn't work anymore in firefox-84:

With MOZ_LOG="PlatformDecoderModule:5" I see messages like

[Parent 7275: Main Thread]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform

and

[Child 7495: MediaSupervisor #1]: D/PlatformDecoderModule DMA-Buf/VA-API can't be used, WebRender/DMA-Buf is disabled

So it looks like "widget::GetDMABufDevice()->IsDMABufVAAPIEnabled()" in https://src.fedoraproject.org/rpms/firefox/blob/master/f/ffvpx.patch#_32 is returning FALSE.

With MOZ_LOG="Dmabuf:5" I am seeing

[Child 13399: Main Thread]: D/Dmabuf wl_drm is available.
[Child 13399: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 13399: Main Thread]: D/Dmabuf GBM device initialized
[Child 13466: Main Thread]: D/Dmabuf wl_drm is available.
[Child 13466: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 13466: Main Thread]: D/Dmabuf GBM device initialized
[Child 13509: Main Thread]: D/Dmabuf wl_drm is available.
[Child 13509: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 13509: Main Thread]: D/Dmabuf GBM device initialized
[Child 13554: Main Thread]: D/Dmabuf wl_drm is available.
[Child 13554: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 13554: Main Thread]: D/Dmabuf GBM device initialized
[RDD 13606: Main Thread]: D/Dmabuf Failed to open drm render node /dev/dri/renderD128

Because it reaches "GBM device initialized" multiple times it looks like it was able to open /dev/dri/renderD128 several times, i.e. not a general failure. But one attempt will fail...

So I debugged this and noticed that RDD 13606 thread was the sandbox.

Starting firefox-84 with MOZ_DISABLE_RDD_SANDBOX=1 set will make VA-API work again.

With RDD, log is full of

[Child 8161: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Agnostic decoder supports requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Agnostic decoder supports requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Agnostic decoder supports requested type
[Child 8161: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[Child 8161: MediaSupervisor #2]: D/PlatformDecoderModule Agnostic decoder supports requested type
[Child 8161: MediaSupervisor #2]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[Child 8161: MediaSupervisor #1]: D/PlatformDecoderModule Agnostic decoder supports requested type
[Child 8161: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[Child 8161: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[RDD 8237: Main Thread]: D/Dmabuf Failed to open drm render node /dev/dri/renderD128
[RDD 8237: Main Thread]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform

The mentioned media.rdd-vpx.enabled setting will not help, same like media.rdd-ffmpeg.enabled.

It should work; provided the RDD sandbox is disabled. Though I haven't done any work to ensure that a DMABuf image works over multi-process / IPC

See Also: → 1679454
See Also: → 1682471

It seems that security policy of RDD was set by SandboxBrokerPolicyFactory::GetRDDPolicy()

media.ffmpeg.vaapi.enabled to true
media.ffvpx.enabled to false

works with firefox-84
with MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD129 LIBVA_DRIVER_NAME=i965 MOZ_X11_EGL=1 MOZ_WEBRENDER=1

but not works with firefox-85 and get log.
[RDD 72994: Main Thread]: D/Dmabuf Failed to open drm render node /dev/dri/renderD129

so, set MOZ_DISABLE_RDD_SANDBOX=1 then get.
[RDD 76097: Main Thread]: D/Dmabuf GBM device initialized

but still not work vaapi so
media.rdd-ffmpeg.enabled to true
then get work vaapi.

See Also: → 1683808
Priority: -- → P3

I am still seeing this with 88.0a1 (20210309161138).

Sorry for being ignorant, could somebody explain to me, why it works with H264 but not VP8?

(In reply to Paul Menzel from comment #24)

I am still seeing this with 88.0a1 (20210309161138).

Sorry for being ignorant, could somebody explain to me, why it works with H264 but not VP8?

This is a dupe of Bug 1683808.

H264 is decoded by ffmpeg, RDD process for ffmpeg is disabled by default now.
VP8/VP9 is decoded by ffvpx (build-in ffmpeg) where RDD process is enabled and you hit Bug 1683808.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

Thank you for the response.

media.ffvpx.enabled and media.rdd-ffvpx.enabled are set to false on my system, and still doesn’t not work VP8. Shouldn’t the external ffmpeg be used then, and it should work?

You need to log in before you can comment on or make changes to this bug.