[meta] Add VA-API hardware decoding support on Linux
Categories
(Core :: Audio/Video: Playback, enhancement, P3)
Tracking
()
People
(Reporter: jya, Assigned: stransky)
References
(Depends on 1 open bug, )
Details
(Keywords: meta, parity-chrome)
This would do decoding only ; not rendering (yet)
Comment 1•9 years ago
|
||
Hardware decoding on Intel Ironlake should be used only for 720p and lower. Hardware 1080p decoding on Intel Ironlake is slower than software decoding on CPU: https://bugs.freedesktop.org/show_bug.cgi?id=47858 GPU model from about:support Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile I need to fill separate issue about VA-API on Ironlake or drop this info here is fine?
Reporter | ||
Comment 2•9 years ago
|
||
(In reply to russianneuromancer from comment #1) > Hardware decoding on Intel Ironlake should be used only for 720p and lower. > Hardware 1080p decoding on Intel Ironlake is slower than software decoding > on CPU: https://bugs.freedesktop.org/show_bug.cgi?id=47858 > > GPU model from about:support > Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile > > I need to fill separate issue about VA-API on Ironlake or drop this info > here is fine? We have a generic preference to disable hardware acceleration, I'll hook it up to vaapi, but I have no intention at this stage to make specific cases for particular chipset. Would have to be in a separate bug.
Updated•9 years ago
|
Comment hidden (offtopic) |
Comment hidden (offtopic) |
See bug 1210726.
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Gentle reminder: * Our guidelines ask you don't argue about priority setting on bugs. Triage leads and Mozillians working on the bug set the priority. See: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html * "Me too" or "Fix this or I'm moving to Chrome/Lynx/Gopher/Edge/Webkit" comments are off topic and just add noise.
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment 14•7 years ago
|
||
(In reply to Paul Menzel from comment #11) > Laurent, if this is still reproducible – I only have 45.9.0 here –, could > you please create a separate report for this issue? That’d be great. Is there already a separate report for this issue? There are also some other useful informations gone (i can't remember exactly, but e.g. regarding OpenGL acceleration).
Reporter | ||
Comment 15•7 years ago
|
||
Yes, we also need accelerated layers to be able to render the frames. And right now, this has taken a set back and the feature has been disabled for now.
Reporter | ||
Updated•7 years ago
|
Comment hidden (me-too) |
Comment 17•7 years ago
|
||
Just FYI: https://chromium-review.googlesource.com/c/532294 this will be [chrome-parity] soon
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•7 years ago
|
Comment hidden (advocacy) |
Reporter | ||
Updated•7 years ago
|
Comment 21•7 years ago
|
||
There is a bounty for this issue at https://www.bountysource.com/issues/55506502-add-va-api-hardware-decoding-support-on-linux
Comment hidden (offtopic) |
Comment 23•5 years ago
|
||
The dependency of this bug could probably changed from ogl-linux-beta to bug 1491303, as webrender will replace all the old rendering architecture and is already enabled on linux + intel in nightly.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 24•5 years ago
|
||
Although this bug is only about decoding support, I'd like to leave a note about the rendering: AFAIK rendering without any slow copies requires DMABUF support, so processes can share resources on the GPU.
For the Wayland backend this about to land, see bug 1552590, quote:
Wayland dmabuf surface are located in GPU and can be attached as EGLImage or wl_buffer. It allows direct rendering to GPU and share the HW buffer across processes.
Also see bug 1010527
Comment 25•5 years ago
|
||
I've recently spent some time testing the implementations in various browsers. Chromium implements VA-API but it's disabled in official builds and fragile, breaking regularly. Webkit uses gstreamer-vaapi and I've had quality issues with that using both Intel (wrong colours) and AMD (blur) hardware.
I've seen Mozilla tracks issues for VA-API and VDPAU/NVDEC. Have you seen libplacebo1? It encapsulates the core video rendering used in mpv in a reusable library. mpv's video acceleration has been stable and flawless for both VAAPI and NVDEC (and DXVA, FWIW, but I've no experience with that) for years. In contrast to the browsers' and gstreamer va-api implementations, I've never had performance, stability or quality issues with mpv.
In fact, hundreds (thousands?) of Firefox users use several WebExtensions to have videos played in mpv2,3,4.
I haven't worked with either Firefox or mpv code so I can only speak from a user's perspective right now. I just thought, it might be worth to consider implementing libplacebo instead of rolling an own implementation for va-api and vdpau/nvdec. libplacebo is licensed in LGPLv2.1.
Note: I initially wanted to post this in #1210726, quoting first comment:
This bug will track support for hardware decoding on Linux and the various system available (VA-API, VDPAU, DXVA and others)
There's so many frameworks available, it's hard to keep track!
But this one's locked. If it suits better there, feel free to move this comment.
Comment hidden (advocacy) |
Comment 27•5 years ago
|
||
@grmat libplacebo is a renderer not a hardware decoder and is unfit to be used in a browser. First thing we need dmabuf support so that we can import decoded frames without copying them back to the system RAM and then display it on the screen. If I understand it correctly this is the toughest part.
Comment 28•5 years ago
|
||
That should be bug 1572697 for Wayland.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 29•5 years ago
|
||
HW decoding support has landed at Bug 1616185.
Comment 30•5 years ago
|
||
I'm glad to here that, but what about support for Firefox on X11? Is it given up?
Assignee | ||
Comment 31•5 years ago
|
||
(In reply to lilydjwg from comment #30)
I'm glad to here that, but what about support for Firefox on X11? Is it given up?
Hardware decoding is platform independent so it generally works under X11 as it's implemented as Bug 1616185.
For whole playback chain see Bug 1610199 what's needed to be done fox X11.
I was closing this one as it refers to HW decode only, not the playback.
The overall video playback is tracked at Bug 1210726.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 32•5 years ago
|
||
(In reply to lilydjwg from comment #30)
I'm glad to here that, but what about support for Firefox on X11? Is it given up?
Filed Bug 1619523 for it.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 33•5 years ago
|
||
re-opening as a meta bug for VA-API implementation (including X11)
Reporter | ||
Updated•5 years ago
|
Comment 34•4 years ago
|
||
Reminder that there is still a bounty for this issue at BountySource
https://www.bountysource.com/issues/55506502-add-va-api-hardware-decoding-support-on-linux
I got an email from BountySource that they're going to start taking old bounties for themselves starting 2020-07-1 (reproduced below)
In my opinion the bounty was already earned when this issue was resolved but I don't know who gets to be the arbiter.
Hi,
You are receiving this email because we are updating the Bountysource Terms of Service, effective 1st July 2020.
What's changing?
We have added a Time-Out clause to the Bounties section of the agreement:
2.13 Bounty Time-Out.
If no Solution is accepted within two years after a Bounty is posted, then the Bounty will be withdrawn and the amount posted for the Bounty will be retained by Bountysource. For Bounties posted before June 30, 2018, the Backer may redeploy their Bounty to a new Issue by contacting support@bountysource.com before July 1, 2020. If the Backer does not redeploy their Bounty by the deadline, the Bounty will be withdrawn and the amount posted for the Bounty will be retained by Bountysource.
You can read the full Terms of Service here
What do I need to do?
If you agree to the new terms, you don't have to do anything.
If you have a bounty posted prior to June 30, 2018 that is not currently being solved, email us at support@bountysource.com to redeploy your bounty. Or, if you do not agree with the new terms, please discontinue using Bountysource.
Thanks for reading
Bountysource Team
Comment 35•4 years ago
|
||
(In reply to eric.riese from comment #34)
In my opinion the bounty was already earned when this issue was resolved but I don't know who gets to be the arbiter.
That would certainly be Martin Stránský :)
Martin, do you want to claim the bounty? If you don't care about it / don't need it yourself, you could donate it or so.
Assignee | ||
Comment 36•4 years ago
•
|
||
(In reply to Robert Mader [:rmader] from comment #35)
(In reply to eric.riese from comment #34)
In my opinion the bounty was already earned when this issue was resolved but I don't know who gets to be the arbiter.
That would certainly be Martin Stránský :)
Martin, do you want to claim the bounty? If you don't care about it / don't need it yourself, you could donate it or so.
Okay, I'll try to claim it and send it to a charity.
Assignee | ||
Comment 37•4 years ago
|
||
This needs to be closed to claim the bounty at https://www.bountysource.com/issues/55506502-meta-add-va-api-hardware-decoding-support-on-linux so closing this one.
Wayland va-api decoding was implemented by Bug 1616185
X11 variant is pending at Bug 1619523
Comment 38•4 years ago
|
||
This should depend on bug 1616185 and bug 1619523 so it's easier to find where the work happened.
Updated•4 years ago
|
Description
•