Created attachment 497472 [details] Chromium dev channel ebuild with VAAPI enabled. Google has hardcoded VAAPI out of Linux builds of Chromium. However, Ubuntu and Archlinux ship with VAAPI support enabled, and Gentoo should as well. With VAAPI support enabled, I'm able to turn on all features under "Graphics Feature Status" on the "chrome://gpu" page, and have been able to verify that I have "GpuVideoDecoder" working on the "chrome://media-internals" page. I'm attaching here an ebuild and two patches, tested working here on my AMD64 system with GTX 970 graphics card using 'nvidia-drivers'. This works on my system using libva-vdpau-driver as the backend. This ebuild should also work on Intel GPUs. Radeon users may have trouble as both Nvidia and Radeon users have reported issues at the Arch Linux repository: https://aur.archlinux.org/packages/chromium-vaapi/?comments=all. Please test this so we can move towards getting Linux VAAPI support back into Chromium.
Created attachment 497474 [details, diff] Patch to enable VAAPI support on Chromium This is the patch that enables VAAPI support on Linux Chromium, modified slightly from the patch at this page: https://chromium-review.googlesource.com/c/chromium/src/+/532294 The AUTHORS hunk was defunct because that file had already been updated in Chromium. Removed.
Created attachment 497476 [details, diff] Patch that enables a fallback max resolution of 1920x1080 The libva calls chromium makes to get the max resolution currently don't work, or at least not on VDPAU. This patch enables a fallback resolution of 1920x1088 in case those calls don't work.
please write the cat/pkg in the title.
JMW, thanks for the ebuild and patches. This works for me on amd64 with Intel HD Graphics. It is actually the only way to have a working Chromium on my system, as all the versions in portage fail to build due to various bugs all in Gentoo Bugzilla. This is available in my overlay at https://github.com/mapmot/edge-overlay
Jonas Stein, fixed. Thanks for the reminder.
Valentin Marinov, can you post the bugs in question? I actually can't emerge unstable versions of chromium using stable gcc-5.4.0 on my AMD Phenom ii system running stable gentoo. I have to temporarily switch to 6.4.0 to make it work.
61.x and 62.x fail because https://bugs.gentoo.org/626970 63.x fails because of https://bugs.gentoo.org/633452 I am on Intel SandyBridge with unstable gcc 7.2.0
Created attachment 510832 [details, diff] Patch for vaapi working with chromium 65.0.3294.5 chromium-intel-vaapi_r16.diff.patch and chromium-intel-vaapi-fix.patch stopped working from about version 64.0.3253.3 or something like that, so I sat down and edited the patch at a best effort basis and created a working vaapi patch for version 65.0.3294.5. 1) Have x11-libs/libva-2.0.0 and x11-libs/libva-intel-driver-2.0.0 installed. 2) Edit the chromium ebuild so src_configure() contains > myconf_gn+=" use_vaapi=true"; 3) Include the patch, e.g. in /etc/portage/patches If I haven't forgotten anything, then VAAPI accelerated video should work again (remember to enable video accel and MJPEG accel in chrome://flags and use the plugin h264ify). Not that thouroughly tested since it takes quite a while to build this, so sorry if I forgot anything...
www-client/chromium-65.0.3298.3 with vaapi USE flag and adjusted patch from Mads is in https://github.com/mapmot/edge-overlay
www-client/chromium-65.0.3315.3 with vaapi USE flag is in https://github.com/mapmot/edge-overlay. I would appreciate some testing and feedback from more knowledgeable souls, as chrome://media-internals/ now gives video_decoder:FFmpegVideoDecoder, where it was giving video_decoder:GPUVideoDecoder before.
FFmpegVideoDecoder means it's not working, yes... Haven't had time to try updating the patch again, but I see there's a pastebin of a patch on https://aur.archlinux.org/packages/chromium-dev/, have anyone tried that?
FFmpegVideoDecoder means it's not working, yes... Haven't had time to try updating the patch again, but I see there's a pastebin of a patch on https://aur.archlinux.org/packages/chromium-dev/, has anyone tried that?
Tested that pastebin patch now (had to do some adjustments to the patch to make it compile), unfortunately it did not work. Guess I'll have to revisit this later if it keeps being this way. Really hoping they'll upstream the support for this soon.
Patch r16 got released just a few days ago! https://chromium-review.googlesource.com/c/chromium/src/+/532294 It does not apply cleanly to 3315.3, so I'll try amending it.
Created attachment 519290 [details, diff] Patch for vaapi working with chromium 65.0.3315.3 Couldn't get the r16 patch to work after amending it to compile with 3315.3. So I just took my old patch based on r15 and edited it to compile with 3315.3. And it seems to work, chromium is yet again showing GpuVideoDecoder. Haven't had time yet to compare the patches and see what the difference between them is that makes r16 not work.
Created attachment 523530 [details, diff] chromium-66.0.3359.22-vaapi.patch Updated for v66.0.3359.22.
The patch still works for chromium 68.0.3438.3 if you modify it a little (remove Enable/DisableWebRTCDecode/Encode flags). Managed to get GpuVideoDecoder here too. Hope upstream actually commits this patchset soon, they're on patchset v18 now...
Seems to still work with chromium 70. I did this: - Run the patch manually, ignore all the failed patches for fixing webrtc flags (they have removed the need for them) - Manually fix all "switches::kDisableAcceleratedVideoDecode -> switches::kEnableAcceleratedVideo" patches (go through all the .rej-files after applying the patch and look for those switches and then manually patch them in yourself). - Amend away all mentions of switches::kEnableAcceleratedMjpegDecode and switces::enableWebRTCEncode/Decode that the patch inserted (it gets some of them in when running the patch, but those mjpeg flags the patch are referencing are gone now. I guess the best thing would be to edit the patch to not patch them in in the first place). Shows GpuVideoDecoder. I see that Google also have added support for hardware accelerated audio decoding now, I wonder what kind of hardware that is... So I can see audio uses FFMpeg, but video uses GpuVideoDecoder. Since the switches for MJPEG and WebRTCEncoding/Decoding has disappeared, the out-of-tree patch needed to make VAAPI work keeps getting smaller. At least that's a plus.
I have consolidated and cleaned up the various patches floating around and managed to get www-client/chromium-71.0.3554.4 working with VAAPI support. chrome://media-internals shows video_decoder:GPUVideoDecoder. Ebuild is in https://github.com/mapmot/edge-overlay
(In reply to Valentin Marinov from comment #19) > I have consolidated and cleaned up the various patches floating around and > managed to get www-client/chromium-71.0.3554.4 working with VAAPI support. > chrome://media-internals shows video_decoder:GPUVideoDecoder. Ebuild is in > https://github.com/mapmot/edge-overlay Have you tested enabling Mojo Video Decoder with chromium 73? See https://bugs.chromium.org/p/chromium/issues/detail?id=522298#c51 Seems like it still needs those vaapi patches to be able to use it.
Mojo also needs java to build, apparently.
(In reply to Mads from comment #20) > (In reply to Valentin Marinov from comment #19) > > I have consolidated and cleaned up the various patches floating around and > > managed to get www-client/chromium-71.0.3554.4 working with VAAPI support. > > chrome://media-internals shows video_decoder:GPUVideoDecoder. Ebuild is in > > https://github.com/mapmot/edge-overlay > > Have you tested enabling Mojo Video Decoder with chromium 73? See > https://bugs.chromium.org/p/chromium/issues/detail?id=522298#c51 > > Seems like it still needs those vaapi patches to be able to use it. No, I haven't tested Mojo Video Decoder and VDAv2. Chromium is a royal pain to compile and exponentially more difficult to test patches. I usually wait before the vaapi patches make it to Arch or Ubuntu and then stick to a working build as long as possible. I am still on 71.0.3554.4.
Gentoo should consider adding vaapi patches now, after the good news arrived that Fedora adds vaapi to their official vaapi package! https://src.fedoraproject.org/cgit/rpms/chromium.git/tree/ Testing out now if I can get these applied.
Sorry, but I do not intend to apply these patches on Gentoo.
*** Bug 686272 has been marked as a duplicate of this bug. ***
Hi, I was able to apply the following patch on chromium-76.0.3809.87 (which is stable on portage now): https://aur.archlinux.org/cgit/aur.git/tree/vaapi-fix.patch?h=chromium-vaapi&id=8f003b83bb48f631cee53c16719f4dcd0b32ba42 I'm compiling the patched chromium now (it can take up to 8h) and I'll let you know about the results. The patch is simple and small. If it works and the VAAPI support can be enabled with a simple patch, then I think that it's stupid to refuse that patch. I encourage the Gentoo team to evaluate the patch. As told before, I'll let you know if the patch worked. Regards.
How did it go with the patch?
For people that arrives here from google... On new version of chromium vaapi support is compiled by default. you need to do: 1. go to: chrome://gpu/ 2. check that your gpu is blacklisted 3. go to chrome://flags/ 4. search for ignore-gpu-blacklist 5. enable "ignore gpu blacklist" 6. relaunch after that you will see on chrome://gpu/ the Video Decoding is enabled. for having hardware decoding on youtube you need to install h264ify for prefferring mp4 videos instead of vp9. https://chrome.google.com/webstore/detail/h264ify/aleakchihdccplidncghkekgioiakgal?hl=es If your graphics card is NVIDIA and uses vdpau... you probably need another patchs like: https://aur.archlinux.org/cgit/aur.git/tree/vdpau-support.patch?h=chromium-vaapi (NOT TESTED)
Which version of chromium is that?
> > after that you will see on chrome://gpu/ the Video Decoding is enabled. > this is not how you check if your video decoding is accelerated, you check it by going to chrome://media-internals during video playback and making sure that "MojoVideoDecoder" is used. Chromium from Gentoo does _not_ enable video decoding acceleration.
For those who wants vaapi support in chromium: 1) The configure step must include "use_vaapi=true" 2) Patches must still be applied, the most currents ones now is from RPMFusion's chromium-freeworld: https://github.com/rpmfusion/chromium-freeworld (two patches). I have working video accel in chromium 84.0.4147.45 after taking these steps.
If use nvidia graphics, you also need other patch for x11-libs/libva-vdpau-driver. https://launchpadlibrarian.net/398645569/vdpau-video_0.7.4-7_0.7.4-7ubuntu1~ppa1~18.10.1.diff.gz
Created attachment 652094 [details] chromium-84.0.4147.105.ebuild with vaapi This is a quick and dirty ebuild which enables VAAPI support of Chromium. Enable the 'vaapi' USE flag. You must place the two vaapi-related patches from https://github.com/rpmfusion/chromium-freeworld into /etc/portage/patches/www-client/chromium/ directory. Awaiting compilation and will update with testing results.
Created attachment 652096 [details, diff] chromium-enable-vaapi.patch Used with chromium-84.0.4147.105.ebuild
Created attachment 652098 [details, diff] chromium-fix-vaapi-on-intel.patch Used with chromium-84.0.4147.105.ebuild
Alright, Chromium has finished compiling. The VAAPI patches applied successfully and the build is stable. However, the hardware decoding doesn't actually work, and it just falls back to ffmpeg. I will not continue investigating further - I just installed an extension which allows me to open videos in MPV (which has proper hw decode).
I confirm working VAAPI acceleration with chromium-85.0.4183.102 and Intel UHD Graphics 620 GPU. Accessing chrome://gpu/ shows: Video Decode: Hardware accelerated Video Acceleration Information Decode h264 baseline 16x16 to 4096x4096 pixels Decode h264 main 16x16 to 4096x4096 pixels Decode h264 high 16x16 to 4096x4096 pixels Decode vp8 16x16 to 4096x4096 pixels Decode vp9 profile0 16x16 to 4096x4096 pixels Decode vp9 profile2 16x16 to 4096x4096 pixels Encode h264 baseline 321x241 to 4096x4096 pixels, and/or 30.000 fps Encode h264 main 321x241 to 4096x4096 pixels, and/or 30.000 fps Encode h264 high 321x241 to 4096x4096 pixels, and/or 30.000 fps Steps to enable (based on previous comments): 1. Drop the following two patches from https://github.com/rpmfusion/chromium-freeworld to /etc/portage/patches/www-client/chromium/ directory: chromium-enable-vaapi.patch chromium-fix-vaapi-on-intel.patch 2. Patch the chromium ebuild like this (create a local overlay): --- chromium-85.0.4183.102.ebuild.orig 2020-09-11 10:47:35.203484853 +0300 +++ chromium-85.0.4183.102.ebuild 2020-09-10 19:49:50.670075403 +0300 @@ -599,6 +599,9 @@ myconf_gn+=" proprietary_codecs=$(usex proprietary-codecs true false)" myconf_gn+=" ffmpeg_branding=\"${ffmpeg_branding}\"" + # Enable Video Acceleration + myconf_gn+=" use_vaapi=true" + # Set up Google API keys, see http://www.chromium.org/developers/how-tos/api-keys . # Note: these are for Gentoo use ONLY. For your own distribution, # please get your own set of keys. Feel free to contact chromium@gentoo.org 3. Add the following flag to `/etc/chromium/default`: # Options to pass to chromium. CHROMIUM_FLAGS="--use-gl=desktop" Otherwise the ANGLE renderer is used, which disables VAAPI. I read that in chromium 86 VAAPI will be enabled also with ANGLE. But until then this flag is necessary.
I appreciate the work the devs put into maintaining the ebuilds, but I've followed the above and also have hardware acceleration working. This is the only way I can, for example, use Stadia in 4k on the VP9 codec. Debian, Arch, and Fedora all include this patch. Subsequently, ALL downstream distros also subsequently get this. Gentoo is the odd one out, what is the rationale that the devs won't ever add this patch? Is it strictly "upstream doesn't do it, so we won't either"? Is there the possibility we could have some flexibility on this?
Binary distros have this inherent benefit that they are binary hence process of building packages is better controlled (by distro developers). In Gentoo there are a lot more variables to take account like compiler versions, USE flags, CFLAGS in make.conf, etc. Chromium takes ages to compile and upstream releases new versions very often. With upstream refusing to soft-disable VA-API (via chrome://gpu) and hard-disables it instead, it requires patching source and all these extra 3rd party patches need to be rebased/fixed when they no longer apply so if we just put them in portage and patch fails to apply or work at some point, bugu reports will arrive. So it all comes down to maintenance cost.. I'm not chromium maintainer and I cannot speak for them, but I think what could be possibly done is force-enable VA API support in ebuild only (it would still do nothing but it would eliminate the need for users to patch ebuild as well, and given that they are bumped often) and let people drop these patches themselves in /etc/portage/patches/ to actually test-enable it. This could be some possible compromise I think - not really breaking or increase maintenance cost by default but still make it convenient to maintain by user.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=add1b12dc5e74f23686f3652c251ef1f3f991722 commit add1b12dc5e74f23686f3652c251ef1f3f991722 Author: Stephan Hartmann <sultan@gentoo.org> AuthorDate: 2020-09-24 16:36:33 +0000 Commit: Stephan Hartmann <sultan@gentoo.org> CommitDate: 2020-09-24 16:37:39 +0000 www-client/chromium: dev channel bump to 87.0.4270.0 - Add experimental vaapi support - drop USE=system-libvpx, because vaapi uses internal libvpx API Bug: https://bugs.gentoo.org/633332 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Stephan Hartmann <sultan@gentoo.org> www-client/chromium/Manifest | 4 +- ...0.4263.3.ebuild => chromium-87.0.4270.0.ebuild} | 43 ++--- .../files/chromium-86-fix-vaapi-on-intel.patch | 40 +++++ .../files/chromium-87-fix-vaapi-build.patch | 177 +++++++++++++++++++++ .../chromium/files/chromium-87-ozone-deps.patch | 15 ++ 5 files changed, 258 insertions(+), 21 deletions(-)
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=84ce0858cd275482a211e99b3600f648a6990f3f .... the change has apparently been reverted, probably by accident. too bad :(. when pulling the file from git and putting it in files/, it still works
With www-client/chromium-92.0.4512.4 I had to put this in /etc/chromium/default to get "VDAVideoDecoder" in chrome://media-internals (they've changed name again): CHROMIUM_FLAGS="--enable-features=VaapiVideoDecoder --enable-accelerated-video-decode"
(In reply to Mads from comment #42) > With www-client/chromium-92.0.4512.4 I had to put this in > /etc/chromium/default to get "VDAVideoDecoder" in chrome://media-internals > (they've changed name again): > > CHROMIUM_FLAGS="--enable-features=VaapiVideoDecoder > --enable-accelerated-video-decode" I updated the elog message with chromium-92 to "--enable-features=VaapiVideoDecoder" some time ago. Are you sure that "--enable-accelerated-video-decode" is needed too? I don't see it in chrome://flags.
Don't know where else to put this. If I tried using intel-media-driver (LIBVA_DRIVER_NAME=iHD) lately, I get lots of "GPU process exited unexpectedly: exit_code=139" errors when starting chrome and no working GPU accel. But it works with the default i965 driver. Just thought I should write that out there somewhere.
(In reply to Mads from comment #44) If you want to report a bug, please create a new bug report. If you just want to write stuff on the internet, start a blog or a social media post.
