[meta][Linux/EGL] Implement ffmpeg/VAAPI video playback
Categories
(Core :: Audio/Video: Playback, enhancement, P3)
Tracking
()
People
(Reporter: stransky, Assigned: stransky)
References
(Depends on 17 open bugs)
Details
(Keywords: meta)
Attachments
(1 file, 4 obsolete files)
With dmabuf support already implemented it should be feasible to implement VAAPI playback by ffmpeg.
I already checked that the playback works fine on Wayland/Intel on mpv player which also uses ffmpeg to decode frames and vaExportSurfaceHandle() to convert AVFrame to dmabuf memory layout.
Some integration work needs to be done to carry dmabuf buffer by MediaDataDecoder::DecodedData to correct TextureClient to map it as EGL texture.
Comment 1•5 years ago
|
||
playback works fine on Wayland/Intel on mpv player
This require intel-vaapi-driver 2.4.0+, correct? At least according to https://github.com/intel/intel-vaapi-driver/issues/449
Assignee | ||
Comment 2•5 years ago
|
||
I use Fedora 31 as a reference distro with latest updates (libva-2.6.0).
Do you also plan to implement video encoding hardware acceleration through VAAPI? It could help quite a lot for video conferencing scenarios.
And a bit of a side question, in case of Vulkan + Wayland, would it use something else rather than EGL?
Assignee | ||
Comment 5•5 years ago
|
||
(In reply to Shmerl from comment #3)
Do you also plan to implement video encoding hardware acceleration through VAAPI? It could help quite a lot for video conferencing scenarios.
No, that's implemented by WebRTC project (https://webrtc.org/) so it needs to be implemented there. This work also does not help with video played via WebRTC like video conferencing.
You mean that Firefox uses WebRTC project code, and I should check there for VAAPI support?
WebRTC on Linux a major problem for clients like Cisco Webex, which constantly chokes in Firefox, complaining that "CPU is overutilized". I thought may be hardware acceleration can help it.
Assignee | ||
Comment 7•5 years ago
|
||
(In reply to Shmerl from comment #6)
You mean that Firefox uses WebRTC project code, and I should check there for VAAPI support?
Yes, exactly. Firefox uses WebRTC for video conferences which also includes video encode/decode there.
Hm, according to https://webrtc.org/web-apis/firefox/
For specific issues with the FIrefox WebRTC code, please use our bug tracker
And it points back to bugzilla here. I can open another bug, for WebRTC component.
Comment 9•5 years ago
|
||
(In reply to Shmerl from comment #4)
And a bit of a side question, in case of Vulkan + Wayland, would it use something else rather than EGL?
It will use vulkan extentions instead of EGL.
Importing VAAPI decoded frames to vulkan surface is not yet supported. There is a similar concept implemented on mpv though which fails on my configuration(amdgpu).
Comment 10•5 years ago
|
||
Pardon me if this is off-topic, but is this bug tracking all implementations of VA-API, or just the Intel one for now?
Assignee | ||
Comment 11•5 years ago
|
||
(In reply to Sandi Vujaković from comment #10)
Pardon me if this is off-topic, but is this bug tracking all implementations of VA-API, or just the Intel one for now?
This bug is tracking a playback by ffmpeg (image decode) and libva (decoded image transfer to dmabuf).
Comment 12•5 years ago
|
||
Just for the reference, if anyone will be looking. I opened WebRTC bug for VAAPI support: https://bugs.chromium.org/p/webrtc/issues/detail?id=11296
Comment 13•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #7)
Yes, exactly. Firefox uses WebRTC for video conferences which also includes video encode/decode there.
Really unfortunate that we're using the reference/Chrome implementation (libwebrtc). In GStreamer, this would be easy to do >_<
But anyway, if anyone would be interested in modifying libwebrtc to do this, seems like there was an attempt to do a similar thing for Android: bug 969395.
Comment 14•5 years ago
|
||
Is Firefox on Android not using libwebrtc? Otherwise it's upstream issue like above.
Assignee | ||
Comment 15•5 years ago
|
||
WIP patch. Video has wrong colors (perhaps due to wrong YUV color profile) and frames are shuttered. But decodes frames on gpu and pass them by dmabuf to compositor as gl textures.
Assignee | ||
Updated•5 years ago
|
Comment 17•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #15)
Created attachment 9122629 [details] [diff] [review]
WIPWIP patch. Video has wrong colors (perhaps due to wrong YUV color profile) and frames are shuttered. But decodes frames on gpu and pass them by dmabuf to compositor as gl textures.
I remember having problems like this when trying to get VAAPI/DRI3 to work with Chromium/X11 under Wayland. It worked fine with Weston, but under GNOME it would have the wrong colour profile, due to necessary colourspace conversions not being fully supported in mutter. I don't know if the situation is still the same, but I wouldn't be all that surprised if it exercised similar code paths with wayland-egl-dmabuf. Maybe this is a Red Herring, but I thought I'd mention it.
Assignee | ||
Comment 18•5 years ago
|
||
Thanks, I already solved the wrong colors with moving to WebRender which supports NV12 format correctly. Last issue remaining is frame scattering, seems to be caused by conversion from DRI prime to GL texture - at least ffmpeg internal conversion works fine.
Comment 19•5 years ago
|
||
Is this hooked up to the "Media Capabilities API" so powerEfficient return true if VAAPI is available?
Assignee | ||
Updated•5 years ago
|
Comment 20•5 years ago
|
||
(In reply to Kristian Klausen from comment #19)
Is this hooked up to the "Media Capabilities API" so powerEfficient return true if VAAPI is available?
This doesn't exist on any OS - see bug 1569686 to track this.
Comment 21•5 years ago
|
||
Martin,
In the WIP patch you attached earlier, you call av_hwdevice_ctx_create()
. It's possible to build ffmpeg without CONFIG_LIBDRM, and in that case it will call vaGetDisplay()
and not vaGetDisplayDRM()
expected by your code. To ensure X11 version is never called, you can specify "connection_type" in options:
bool FFmpegDataDecoder<LIBAV_VER>::CreateVAAPIDeviceContext() {
AVDictionary *opts = nullptr;
mLib->av_dict_set(&opts, "connection_type", "drm", 0);
if (mLib->av_hwdevice_ctx_create(&mVAAPIDeviceContext, AV_HWDEVICE_TYPE_VAAPI,
NULL, opts, 0) < 0) {
mLib->av_dict_free(&opts);
…
Assignee | ||
Comment 22•5 years ago
|
||
Thanks, I'll update the patch.
Comment 23•5 years ago
|
||
Hi, just a small question if I'm not bothering you. When will the initial patches land in nightly? I would like to participate with testing this, but my PC dislikes compiling from source because my CPU is too weak.
Assignee | ||
Comment 24•5 years ago
|
||
(In reply to Marko from comment #23)
Hi, just a small question if I'm not bothering you. When will the initial patches land in nightly? I would like to participate with testing this, but my PC dislikes compiling from source because my CPU is too weak.
I have no idea.
Assignee | ||
Comment 25•5 years ago
|
||
First version of the patch for latest trunk, seems to be working somehow.
Assignee | ||
Comment 26•5 years ago
|
||
All needed patches are submitted in the tracked bugs here so we'll have working VAAPI on Wayland when these ones hit mozilla-central.
My performance measures are here - https://bugzilla.mozilla.org/show_bug.cgi?id=1616185#c7
Comment 27•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #26)
All needed patches are submitted in the tracked bugs here so we'll have working VAAPI on Wayland when these ones hit mozilla-central.
My performance measures are here - https://bugzilla.mozilla.org/show_bug.cgi?id=1616185#c7
What preferences are needed to enable all of it?
Comment 28•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #26)
All needed patches are submitted in the tracked bugs here so we'll have working VAAPI on Wayland when these ones hit mozilla-central.
My performance measures are here - https://bugzilla.mozilla.org/show_bug.cgi?id=1616185#c7
Awesome! To bad there are no reaction possibilities in bugzilla, this post deserves a thousand thumbs up and the likes.
Looks like you could rightfully claim https://www.bountysource.com/issues/55506502-add-va-api-hardware-decoding-support-on-linux now :)
Comment 29•5 years ago
|
||
If you can document all the required preferences, I'll enable it for testing.
Assignee | ||
Comment 30•5 years ago
|
||
It doesn't work yet, Bug 1616129 and Bug 1616185 need to be fixed first.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 31•5 years ago
|
||
As Bug 1616185 landed you should be able to run va-api accelerated video playback on Wayland with latest nightly. I just tried 20200302212732 build and it works for me on Fedora 31 / Gnome / Mesa DRI Intel(R) UHD Graphics 630.
In order to run it you need to:
- run Firefox under wayland compositor with MOZ_ENABLE_WAYLAND=1
- set widget.wayland-dmabuf-vaapi.enabled to true at about:config
- enable appropriate HW acceleration for Firefox (GL compositor or WebRender), verify that in about:support
- have libva installed (I have libva-2.6.0-0.1.fc31.x86_64 on Fedora)
You can verify that VA-API is enabled by running Firefox with MOZ_LOG="PlatformDecoderModule:5" env variable and check in the log output that VA-API is enabled and used.
Comment 32•5 years ago
|
||
Comment 33•5 years ago
|
||
Confirmed. vaapi doesn't work with gl either. Aidan too reported the same error.
Assignee | ||
Updated•5 years ago
|
Comment 34•5 years ago
|
||
I see the same thing on Arch Linux with Intel iGPU:
[Child 14174: Main Thread]: D/PlatformDecoderModule Couldn't load function avcodec_get_hw_config
[Child 14174: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwdevice_ctx_create
[Child 14174: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwframe_transfer_get_formats
[Child 14174: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwdevice_ctx_create_derived
[Child 14174: Main Thread]: D/PlatformDecoderModule Sandbox decoder rejects requested type
I verified that libva.so.2.600.0
, libva-drm.so.2.600.0
and libva-x11.so.2.600.0
are loaded in the content process. I also attached gdb
to the content process and checked that disas
can find the four functions above.
Assignee | ||
Comment 35•5 years ago
|
||
(In reply to Akarshan Biswas from comment #32)
Doesn't work on amdgpu with webrender.
amdgpu should be supported, It worked for me when I tested it some time ago. If there's any bug I'll fix that.
from the log:
[Child 2692: MediaPDecoder #1]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform
that means:
- you're not running on Wayland or dmabuf is not supported
- it's disabled by a preference or GL/Webrender is disabled
Please file a new bug for it and attach about:support page and also firefox log obtained by running:
MOZ_ENABLE_WAYLAND=1 MOZ_LOG="WidgetWayland:5" ./firefox
Thanks.
Assignee | ||
Comment 36•5 years ago
|
||
Guys, please file a new bug for it against Core / Audio,Video playback component (or just clone this one) and drop a link here.
Thanks.
Comment 37•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #35)
[Child 2692: MediaPDecoder #1]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform
I don't think the error is related to this. The error is on bug id 1616128 I think (loading library symbols from ffmpeg libraries )
But anyway, I will open a new bug report with all the logs.
Comment 38•5 years ago
|
||
@Martin: Bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1619530
Assignee | ||
Updated•5 years ago
|
Comment 39•5 years ago
|
||
Video flickering on BBC video player when controls appear and disappear:
https://bugzilla.mozilla.org/show_bug.cgi?id=1621951
Comment 40•5 years ago
|
||
https://crash-stats.mozilla.org/report/index/87c543ef-efc7-4da8-abeb-243a70200318
This crash happens to me on Gnome shell 3.36.0 / Mutter 3.36.0 on Fedora 32 beta. It worked on Gnome Shell 3.34.3 / Mutter 3.34.3,
Is this bug already documented?
Comment 41•5 years ago
|
||
Hm why is it marked as fixed if it still occurs?
Comment 42•5 years ago
|
||
It was fixed 2 hours ago. Your build id is 20200318041411 (2020-03-18 04:14:11). Now we have to wait for the next update of Nightly.
Edit: You could also try out Linux x64 shippable opt build from bug 1622729 comment 4. If that crash still occurs, please comment in bug 1622729.
Comment 43•5 years ago
|
||
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #42)
It was fixed 2 hours ago. Your build id is 20200318041411 (2020-03-18 04:14:11). Now we have to wait for the next update of Nightly.
Edit: You could also try out https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A_UE9lP6T4aNqonpQDe-eQ/runs/0/artifacts/public/build/target.tar.bz2 (Linux x64 shippable opt). If it doesn't work, please comment in bug 1622729, not here.
Ooooooh such a coincidence that it got fixed just today :D I've been eyeing this bug for days now.
Comment 44•5 years ago
|
||
https://i.imgur.com/1jxhIe1.png
Why doesn't it work for 4k 60fps videos on youtube yet? The CPU usage goes bonkers and videos stutter like crazy. I have intel UHD 620 and my vainfo shows all H264, VP9 and HEVC decoding supported.
Comment 45•5 years ago
|
||
You might not be using VAAPI at all because of the sandbox (bug 1619585). Stuttering especially in case of overlays is known (bug 1619882) - or you might be decoding on the CPU. If you have multiple GPUs, it's bug 1622132. Only use https://nightly.mozilla.org for VAAPI testing.
Run $ GDK_BACKEND=wayland MOZ_LOG="PlatformDecoderModule:5" path/to/firefox
to find out what's going on. Please create an own ticket and attach the log to it if you can't figure out what's the cause. If it's the sandbox, try to use env var LIBVA_DRIVER_NAME=i965
as well.
Comment hidden (me-too) |
Comment hidden (me-too) |
Comment 48•5 years ago
|
||
(In reply to Marko from comment #47)
https://gitlab.freedesktop.org/snippets/922
Sry here is the proper link for the log.
Marko, please open individual issues. This is a general bug for the implementation with lots of people subscribed that are not necessarily interested why things don't work on individual setups. You can then mark your new bugs as blockers for this one. Thx.
Comment 49•5 years ago
|
||
I wander if Bug 869813 "Option to set WebM or H.264 as preferred" could help Bug 1625431 and/or Bug 1624103
Not sure.
Thanks for your work.
Comment 50•5 years ago
|
||
Did anyone notice weird stuttering/shaking issues with 60 FPS H264 videos? They seem to happen exactly when the Youtube control appear and disappear. I'm on Arch Linux with Firefox 75 Wayland and intel-media-driver (LIBVA_DRIVER_NAME=iHD), with Intel UHD Graphics 630 integrated graphic card. No problems at all with 30 fps videos. Mpv seem to work fine with vaapi and 60 FPS H264 videos.
Comment 51•5 years ago
|
||
@michelesr
This is Bug 1619882
Comment 52•4 years ago
|
||
Just for the reference, since libwebrtc support came up before, I commented here with some details from libwebrtc developers: https://bugzilla.mozilla.org/show_bug.cgi?id=969395#c101
who basically recommend for Firefox to implement VAAPI support outside of libwebrtc anyway. So may be this effort can be somehow shared with the one for regular video handling.
Comment 53•4 years ago
|
||
bug1645671 |
I just updated nightly and while now dmabuf.video-textures is not needed, I get some green frames when GPU decoding. I don't see it mentioned somewhere which is why I comment. Maybe related to #1645673 ?
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 54•4 years ago
|
||
With Bug 1619523 added (vaapi via dmabuf/x11) let's track all linux va-api issues as the X11/Wayland va-api&dmabuf code is almost identical.
Assignee | ||
Comment 55•4 years ago
|
||
(In reply to gsf.greece from comment #53)
I just updated nightly and while now dmabuf.video-textures is not needed, I get some green frames when GPU decoding. I don't see it mentioned somewhere which is why I comment. Maybe related to #1645673 ?
Let's finish X11/dmabuf/vaapi implementation first. I'll look at those minor ones after that as I expect they affect both X11 and Wayland backends.
Comment 56•4 years ago
|
||
Martin, are you going to make vaapi on X11 too? I understood that you could not and you left this work to other person. Or are you helping him? It's curiosity to know if this work is going to some place by you or by other that I have not seen XD.
And about the post in the other site, okey, didn't know it. But nevermind, thank to you for this.
Assignee | ||
Comment 57•4 years ago
|
||
(In reply to albertogomezmarin from comment #56)
Martin, are you going to make vaapi on X11 too?
Yes, a basic implementation is waiting at Bug 1619523.
Comment 58•4 years ago
|
||
but anyone are(In reply to Martin Stránský [:stransky] from comment #57)
(In reply to albertogomezmarin from comment #56)
Martin, are you going to make vaapi on X11 too?
Yes, a basic implementation is waiting at Bug 1619523.
but anybody has yet be assigned to this work. so until anybody go ahead you cant do nothing. right?
Comment 59•4 years ago
|
||
I have tried EGL on my computer with amdgpu drivers. The only thing I noticed is that the close windows is transprent like in the nvidia driver bug. But I think is another thing in WR.
Apart from this, I have tried to use vaapi and it doesn't work. I have seen VCN block not being used when playing a video in youtube so..
The video was in VP9 format that my ryzen is capable to decode and I have tested in chromium so...
maybe someone can help me a little bit?
Firefox-nightly with EGL and dmabuff and vaapi enabled things in about:config
Comment 60•4 years ago
|
||
(In reply to albertogomezmarin from comment #59)
I have tried EGL on my computer with amdgpu drivers. The only thing I noticed is that the close windows is transprent like in the nvidia driver bug. But I think is another thing in WR.
Apart from this, I have tried to use vaapi and it doesn't work. I have seen VCN block not being used when playing a video in youtube so..
The video was in VP9 format that my ryzen is capable to decode and I have tested in chromium so...
maybe someone can help me a little bit?Firefox-nightly with EGL and dmabuff and vaapi enabled things in about:config
For VP9 videos you'll currently also need to disable media.ffvpx.enabled
.
For further debugging question please also refer to https://mastransky.wordpress.com/2020/06/03/firefox-on-fedora-finally-gets-va-api-on-wayland/ and try running with MOZ_LOG="PlatformDecoderModule:5"
(explained in the blog post).
Comment 61•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #60)
(In reply to albertogomezmarin from comment #59)
I have tried EGL on my computer with amdgpu drivers. The only thing I noticed is that the close windows is transprent like in the nvidia driver bug. But I think is another thing in WR.
Apart from this, I have tried to use vaapi and it doesn't work. I have seen VCN block not being used when playing a video in youtube so..
The video was in VP9 format that my ryzen is capable to decode and I have tested in chromium so...
maybe someone can help me a little bit?Firefox-nightly with EGL and dmabuff and vaapi enabled things in about:config
For VP9 videos you'll currently also need to disable
media.ffvpx.enabled
.For further debugging question please also refer to https://mastransky.wordpress.com/2020/06/03/firefox-on-fedora-finally-gets-va-api-on-wayland/ and try running with
MOZ_LOG="PlatformDecoderModule:5"
(explained in the blog post).
done. I have been testing and firefox works with vaapi in a x11 .
I have been testing and this was my benchmarking:
cpu usage:
firefox stable with webrender: 26%
firefox vaapi: 14%
chromium vaapi: 6%
all was done in a fast way with VP9 and 1080p and youtube
But at least we have at the end vaapi
Comment 62•4 years ago
|
||
Thanks Alberto. To really measure the effect you'd need to compare the same FF version with and without VAAPI however, as a lot of work goes into optimizing WR atm.
For further optimizations AFAIK it's worth to keep an eye on frame building (bug 1596042 - bug 1650378 sound especially relevant here) and partial damage (bug 1625070 etc.)
Comment 63•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #62)
Thanks Alberto. To really measure the effect you'd need to compare the same FF version with and without VAAPI however, as a lot of work goes into optimizing WR atm.
For further optimizations AFAIK it's worth to keep an eye on frame building (bug 1596042 - bug 1650378 sound especially relevant here) and partial damage (bug 1625070 etc.)
I am on exams right now so I cant do more tests.
But in the future I will. I hope this can improve the laptop experience in linux. And I expect firefox to be more power efficience than chromium that is the goal with this I think. I will do power tests in my laptop in the future so you can have the numbers
Updated•4 years ago
|
Comment 64•4 years ago
|
||
bug1658772 |
Comment 65•4 years ago
|
||
bug1658772 |
On a Mac Mini 2009
with Nvidia onboard GPU NVIDIA Corporation C79 [GeForce 9400] (rev b1) with 256MB RAM and nouveau 1.0.16 drivers. I get accelerated (?) but corrupt video. Attaching the video screenshot. It looks similar to the wayland issue reported on the other bug
.
I can reproduce logs etc but I am not sure if they are needed.
Assignee | ||
Comment 66•4 years ago
|
||
bug1658772 |
(In reply to ilgaz from comment #65)
On a
Mac Mini 2009
with Nvidia onboard GPU NVIDIA Corporation C79 [GeForce 9400] (rev b1) with 256MB RAM and nouveau 1.0.16 drivers. I get accelerated (?) but corrupt video. Attaching the video screenshot. It looks similar to the wayland issue reported on the otherbug
.
I can reproduce logs etc but I am not sure if they are needed.
Please file a new bug for it.
Thanks.
Comment 67•4 years ago
|
||
I'm having trouble getting this working with proprietary nvidia-drivers on Linux with patched firefox 80 (vaapi fix backported from firefox 81). The log consistently complains about lack of webrender/dmabuf despite doing all the usual (webrender enabled, EGL enabled via environmental variable, relevant config options set).
I was going to find a bug, but I realized it might be not working because proprietary nvidia-drivers can't do dma-buf? There seems to be a lot of confusion about this around the net and I was hoping someone could clarify if it should be able to work so I can file a bug (or not).
Comment 68•4 years ago
|
||
(In reply to Gregory from comment #67)
I'm having trouble getting this working with proprietary nvidia-drivers on Linux with patched firefox 80 (vaapi fix backported from firefox 81). The log consistently complains about lack of webrender/dmabuf despite doing all the usual (webrender enabled, EGL enabled via environmental variable, relevant config options set).
I was going to find a bug, but I realized it might be not working because proprietary nvidia-drivers can't do dma-buf? There seems to be a lot of confusion about this around the net and I was hoping someone could clarify if it should be able to work so I can file a bug (or not).
Note this is on x11.
Comment 69•4 years ago
|
||
Proprietary Nvidia doesn't support GPL-licensed DMABUF Linux kernel API. There is no confusion. They would need to provide the required patches/firmware to the Mesa/Nouveau project. Please try to use your integrated graphics instead. bug 1658772 is about Mesa/Nouveau.
Comment 70•4 years ago
|
||
(In reply to Gregory from comment #67)
I was going to find a bug
There is already a bug about VDPAU/NVDEC support: bug 1210729.
VDPAU is not restricted to NVIDIA only, it's available for Gallium-based Mesa drivers too. But since that API is one of NVIDIA's native APIs, bug 1210729 is the most relevant tracking bug.
Comment 71•4 years ago
|
||
(In reply to Darkspirit, Servo QA from comment #69)
Proprietary Nvidia doesn't support GPL-licensed DMABUF Linux kernel API. There is no confusion.
Apparently there is for “normal” users. Could the logging be improved? Separating the message about DMABUF and WebRender for example, and explicitly mentioning the driver as a cause of errors in the logs?
[…]
Comment 72•4 years ago
|
||
What happened to the vaapi compatibility in latest nightly? It went from constantly crashing but working to not working at all even with all the flags set correctly? Any additional flags added to make VP8/9 vaapi work?
Assignee | ||
Comment 73•4 years ago
|
||
(In reply to Marko from comment #72)
What happened to the vaapi compatibility in latest nightly? It went from constantly crashing but working to not working at all even with all the flags set correctly? Any additional flags added to make VP8/9 vaapi work?
Can you file a new bug and attach your about:support there?
Thanks.
Comment 74•4 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #73)
(In reply to Marko from comment #72)
What happened to the vaapi compatibility in latest nightly? It went from constantly crashing but working to not working at all even with all the flags set correctly? Any additional flags added to make VP8/9 vaapi work?
Can you file a new bug and attach your about:support there?
Thanks.
Assignee | ||
Comment 75•3 years ago
|
||
This bug a blocked by Bug 1683808 (and similar). The correct way forward here is to implement GPU process on Wayland (by dmabuf EGL framebuffer) and then implement VAAPI in GPU process as we actually can't use VAAPI in RDD process.
Comment 76•3 years ago
|
||
Just as note: Maybe I missed something:
start firefox 92 (both VAAPI settings are enabled) in Linux Mint 20.2:
MOZ_X11_EGL=1 MOZ_LOG="PlatformDecoderModule:5" firefox 2>&1 | grep 'VA-API'
[RDD 93271: Main Thread]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform
Comment 77•3 years ago
|
||
(In reply to star from comment #76)
VA-API FFmpeg is disabled by platform
gfx.x11-egl.force-enabled=true (can be set instead of using the MOZ_X11_EGL=1 env var. As of yesterday (bug 1695933), Mesa 21 users don't need to set this anymore.)
gfx.webrender.all=true (force-enabling by setting this pref is not needed for most people as they already use it by default)
media.ffmpeg.vaapi.enabled=true
media.rdd-ffvpx.enabled=false (until bug 1683808 has been done)
media.rdd-vpx.enabled=false (until bug 1683808 has been done)
https://addons.mozilla.org/firefox/addon/enhanced-h264ify/
https://wiki.archlinux.org/title/Firefox#Hardware_video_acceleration
Comment 78•3 years ago
|
||
I used the setup and with my startup (MOZ_X11_EGL=1 MOZ_LOG="PlatformDecoderModule:5" firefox 2>&1 | grep 'VA-API')
I could observe it seems to use VAAPI.
At least I get a lot of
[Child 98006: MediaPDecoder #6]: D/PlatformDecoderModule Reusing VA-API DMABufSurface UID = 21
[Child 98006: MediaPDecoder #7]: D/PlatformDecoderModule VA-API Got one frame output with pts=76533333dts=76533334 duration=33333 opaque=-9223372036854775808
BUT: the CPU usage seem not to be lower than before. Is it because of the log? Anyhow, I changed to your
gfx.x11-egl.force-enabled=true and restarted, but CPU usage keeps nearly same level. So its not caused by logs prints.
Don't know how can I really measure that....
Comment 79•3 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #75)
This bug a blocked by Bug 1683808 (and similar). The correct way forward here is to implement GPU process on Wayland (by dmabuf EGL framebuffer) and then implement VAAPI in GPU process as we actually can't use VAAPI in RDD process.
For the record, there's also work on a so-called UtilityProcess (bug 1731890). From a Matrix chat:
gerard-majax: I'm not sure exactly about VA-API specifically, but the plan is to have such a utilityprocess that can be used by different actors, and each with a specific sandboxing
and from that discussion, I think the first customer might be moving RDD audio decoders to this new
So in case it proves hard to make the GPU work (especially on Wayland), this might be a good way to go.
Comment 80•3 years ago
|
||
With latest nightly (including 1698778 fixes) VA-API appears to work on AMD with just needing to switch media.ffmpeg.vaapi.enabled
to 1
, including VP9 and ffvpx (?).
Assignee | ||
Comment 81•3 years ago
|
||
(In reply to Julian Sikorski from comment #80)
With latest nightly (including 1698778 fixes) VA-API appears to work on AMD with just needing to switch
media.ffmpeg.vaapi.enabled
to1
, including VP9 and ffvpx (?).
Yes, it's supposed so due to fixed Bug 1698778.
Comment 82•3 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #81)
(In reply to Julian Sikorski from comment #80)
With latest nightly (including 1698778 fixes) VA-API appears to work on AMD with just needing to switch
media.ffmpeg.vaapi.enabled
to1
, including VP9 and ffvpx (?).Yes, it's supposed so due to fixed Bug 1698778.
Does this mean that Firefox flatpak will also work with VAAPI from this version on? :)
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 83•3 years ago
|
||
For the record, there's a new project trying to make nvidia drivers work with this: https://github.com/elFarto/nvidia-vaapi-driver
See also bug 1748460
Assignee | ||
Comment 84•3 years ago
|
||
To test VA-API by mozilla testsuite you can run it with:
MOZ_DISABLE_RDD_SANDBOX=1 ./mach mochitest dom/media/test --setpref media.ffmpeg.vaapi.enabled=true
MOZ_DISABLE_RDD_SANDBOX=1 ./mach reftest dom/media/test --setpref media.ffmpeg.vaapi.enabled=true
MOZ_DISABLE_RDD_SANDBOX=1 is needed for Bug 1751363 and Bug 1751709.
Looks like there are some decode failures during testing, will look at it.
Assignee | ||
Comment 85•3 years ago
|
||
Testing results of mochitest on Mesa Intel(R) UHD Graphics 630 (CFL GT2)
mochitest-browser
~~~~~~~~~~~~~~~~~
Ran 55 checks (52 subtests, 3 tests)
Expected results: 55
Unexpected results: 0
OK
mochitest-chrome
~~~~~~~~~~~~~~~~
Ran 47 checks (46 subtests, 1 tests)
Expected results: 46
Unexpected results: 0
Unexpected Results
------------------
ERROR TEST-UNEXPECTED-FAIL | dom/media/test/chrome/test_accumulated_play_time.html | application terminated with exit code -11
mochitest-plain
~~~~~~~~~~~~~~~
Ran 246 checks (10 asserts, 218 subtests, 18 tests)
Expected results: 236
Skipped: 7 tests
Unexpected results: 2
subtest: 2 (2 fail)
Unexpected Results
------------------
dom/media/test/test_background_video_drawimage_with_suspended_video.html
FAIL Pixels aren't all the same color
SimpleTest.ok@SimpleTest/SimpleTest.js:417:16
drawVideoToCanvas@dom/media/test/test_background_video_drawimage_with_suspended_video.html:53:5
runTest/<@dom/media/test/test_background_video_drawimage_with_suspended_video.html:71:26
FAIL Pixels aren't all the same color
SimpleTest.ok@SimpleTest/SimpleTest.js:417:16
drawVideoToCanvas@dom/media/test/test_background_video_drawimage_with_suspended_video.html:53:5
runTest/<@dom/media/test/test_background_video_drawimage_with_suspended_video.html:71:26
Assignee | ||
Comment 86•3 years ago
|
||
Reftest also needs some fixes:
REFTEST INFO | Successful: 28 (28 pass, 0 load only)
REFTEST INFO | Unexpected: 12 (11 unexpected fail, 0 unexpected pass, 0 unexpected asserts, 1 failed load, 0 exception)
REFTEST INFO | Known problems: 3 (0 known fail, 0 known asserts, 0 random, 3 skipped, 0 slow)
Assignee | ||
Updated•3 years ago
|
Comment 88•3 years ago
|
||
bug1752431 |
Comment 89•3 years ago
|
||
VA-API does not work since some Nightly releases even when disabling the sandbox – currently I am using 99.0a1 (20220213092920).
I am using
MOZ_LOG="PlatformDecoderModule:1" MOZ_DISABLE_RDD_SANDBOX=1 nightly
and get
[Child 201138, MediaDecoderStateMachine #1] WARNING: Decoder=7f5ecce31c00 Decode error: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - mozilla::MediaResult mozilla::FFmpegVideoDecoder<58>::CreateImageVAAPI(int64_t, int64_t, int64_t, MediaDataDecoder::DecodedData &): VAAPI dmabuf allocation error: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:3579
Is there a way to get it working by setting other options?
Assignee | ||
Comment 90•3 years ago
|
||
(In reply to Paul Menzel from comment #89)
Is there a way to get it working by setting other options?
Please file a new bug for it.
Comment 91•3 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #90)
(In reply to Paul Menzel from comment #89)
Is there a way to get it working by setting other options?
Please file a new bug for it.
It’s fixed today (20220214213941). The Debian (non-free) package intel-media-va-driver-non-free was also updated to 22.1.1+ds1-1 on February 7th, 2022, and then to 22.2.0+ds1-1 on February 13th, 2022 (on my system February 14th, 2022). No idea if that’s related.
Comment 92•3 years ago
|
||
Are any settings needed besides media.ffmpeg.vaapi.enabled=true in Firefox 98.0b7?
I noticed that VAAP isn't working now neither for H.264 nor for VP9. (X11/EGL).
Comment 93•3 years ago
|
||
To clarify - I'm not using any flatpak.
vainfo: Driver version: Mesa Gallium driver 21.3.5 for AMD Radeon RX 6800 XT (SIENNA_CICHLID, DRM 3.44.0, 5.16.10, LLVM 13.0.1)
Comment 94•3 years ago
|
||
You need to start Firefox with MOZ_DISABLE_RDD_SANDBOX=1 environment variable until bug 1751363 is fixed.
Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 95•2 years ago
|
||
Please add bug #1772028 as a dependency too.
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 96•2 years ago
|
||
Opened bug 1799350 for AV1 VA-API failure, since bug 1745225 is closed.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Description
•