chromium: Add optional vaapi hw video decoding support #56794
Conversation
Emacs loads all the elisp files in the top-level of the site-lisp directory. However some packages (e.g. mu4e) put their elisp files in a subdirectory of site-lisp. Emacs will not load these packages unless subdirs.el is present. This commit links the subdirs.el file from the emacs package into the emacs-package-deps package so that packages that put their elisp files in a subdirectory of site-lisp are loaded.
Was failing with the following error: ServerDB: Database driver QSQLITE not available
This enables inspection of the currently used overlays. Useful for
usecases where nixpkgs is imported multiple times.
eg. different channels
self: super:
let
latest = import <nixpkgs-trunk> {
inherit (super) config overlays;
};
in
{
hello-custom-latest = latest.hello-custom;
}
No release tags on the repo, unclear how versioning works, keeping version number reported in repo for now. Users of this (such as twemoji-color-font) have build instructions that always grab latest git revision so this seems appropriate.
https://github.com/eosrei/emojione-color-font/releases/tag/v1.4 twemoji-color-font is suggested as replacement for unicode 11 and such, but as long as we have this expression might as well use latest.
* 30.pre2 source is no longer available, apparently
Since changelog seems to be only inside the sources,
here's the diff from pre2 to pre9's CHANGELOG.h:
---
o When using takeover, redo probing in case eth0 was in use [ifrename]
o Update Hotplug documentation, add uDev bits [HOTPLUG-UDEV.txt]
o Add ESSID bug patches and documentation [ESSID-BUG.txt]
o Make wireless.21.h LGPL as promised a long time ago [wireless.21.h]
---
(Bug reported by Shaddy Baddah)
o Fix unaligned access on SPARC in the 64->32 bit workaround [iwlib.c]
---
(From Maxime Charpenne <maxime.charpenne@free.fr>)
o Mise à jour de la traduction en francais des pages manuel [fr/*]
---
o Use wireless.22.h, make it LGPL [iwlib.h/wireless.22.h]
o Show Scanning Capabilities in "iwlist event" [iwlist]
(Bug reported by Nikita Zhernosenko)
o Fix parsing of retry/power when modifier is used [iwconfig]
(Bug reported by Alexis Phoenix)
o Remove trailing '/' in INSTALL_* that fooled checkinstall [Makefile]
(From Dan Williams <dcbw@redhat.com>)
o Scan capabilities in struct iw_range [wireless.h]
(From Guus Sliepen <guus@debian.org>)
o Install localised man page [Makefile]
---
o Fix #define that broke 32->64 bit workaround [wireless.22.h]
o Workaround kernel bug when getting ESSID [iwlib/iwconfig/iwgetid]
(From Gerald Pfeifer <gerald@pfeifer.com>)
o Fix gramar in man page, add about hidden networks [iwlist.8]
---
(From Reinette Chatre <reinette.chatre@intel.com>)
o Enable scan buffer to grow up to 65535 instead of 32768 [iwlist]
o Return a proper error if scan result exceed buffer max [iwlist]
(From Jean Tourrilhes)
o Do above two fixes for the simple scan API [iwlib]
(From Claudio Ferronato <claiudio@libero.it>)
o Spelling and typos in [iwconfig.8]
---
o Create iwlib-private.h to minimise namespace pollution [iwlib]
o More fix to the 64->32bit band-aid for encode [iwlib]
o Update udev rule to remove a warning [19-udev-ifrename.rules]
(from Ritesh Raj Sarraf <rrs@researchut.com> and Guus Sliepen)
o Propagate error codes out of main for get [iwconfig/iwlist/iwspy]
(From Guus Sliepen <guus@debian.org>)
o Remove spurious commands from Czech iwconfig manpage.
And move to .tar.xz since .tar.gz is only offered until 0.02.03.
Similarly move .tar.gz -> .tar.xz
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/bind/versions
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/ffms/versions
Pinning ponyc to use llvm_39 was done way back in 2016[1] and shows no indication that this was done for any reason other than specifying what ponyc supported at the time :). [1] ae4ef90
We have 2.5.2 now.
Also move to GNU mirror for the file, as we do for unifont.
This update was generated by hackage2nix v2.14.1-7-g6b9bca8 from Hackage revision commercialhaskell/all-cabal-hashes@98dbc22.
This reverts commit fe0f471.
Add 'VAAPISupport' parameter to chromium expression. If set to true, a patch enabling hw video decoding through vaapi is applied. The patch originates from Arch Linux https://git.archlinux.org/svntogit/packages.git/plain/trunk/chromium-vaapi.patch?h=packages/chromium Tested on 72.xx
- rename enable-vaapi.patch - import all related patches from Arch - check for version = 72 - actually enable use_vaapi gn parameter
|
I have a build that is built similarly, this is the error I get when I run:
|
|
@colemickens thanks for the input. I actually get the same log. Looks like libva is linked at runtime through dlopen and not the usual linker. So the lib file aint in the standard LIBDIR and can't be resolved. |
|
@amazari I've done just that in my branch and I am progressing further (I'd had to do that already to enable Ozone). I have just been reluctant to post updates as I don't want to spam too much. Also, I fear that some other complications around libva (#55975) are related (I can cause similar errors as below with mpv+x11 but not with mpv+wayland.) Attempt 1 Naive: [cole@xeep:~]$ unset LIBVA_DRIVER_NAME # it's not normally set
[cole@xeep:~]$ GDK_BACKEND=x11 /nix/store/65n4m3rkn9q2bfcrmz2xpp61823v7cwm-chromium-72.0.3626.121/bin/chromium --log-level=9 --enable-logging=stderr --v=9 &> log.txt
[cole@xeep:~]$ cat log.txt | grep libva
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)Attempt 1 Explicit: i965 [cole@xeep:~]$ ls /run/opengl-driver/lib/dri | grep drv_video | grep i965
i965_drv_video.la
i965_drv_video.so
[cole@xeep:~]$ export LIBVA_DRIVER_NAME=i965
[cole@xeep:~]$ GDK_BACKEND=x11 /nix/store/65n4m3rkn9q2bfcrmz2xpp61823v7cwm-chromium-72.0.3626.121/bin/chromium --log-level=9 --enable-logging=stderr --v=9 &> log.txt
[cole@xeep:~]$ cat log.txt | grep libva
libva error: /run/opengl-driver/lib/dri/i965_drv_video.so init failed
[17809:17809:0305/163001.156500:ERROR:vaapi_wrapper.cc(324)] vaInitialize failed: unknown libva errorI'm wondering if this is related to my local workaround for #55975. Attempt 2 Explicit: iHD [cole@xeep:~]$ ls /run/opengl-driver/lib/dri | grep drv_video | grep iHD
iHD_drv_video.so
[cole@xeep:~]$ export LIBVA_DRIVER_NAME=iHD
[cole@xeep:~]$ GDK_BACKEND=x11 /nix/store/65n4m3rkn9q2bfcrmz2xpp61823v7cwm-chromium-72.0.3626.121/bin/chromium --log-level=9 --enable-logging=stderr --v=9 &> log.txt
[cole@xeep:~]$ cat log.txt | grep libva
[cole@xeep:~]$ cat log.txt | grep --text vaapi
[19095:19095:0305/163315.855345:VERBOSE2:vaapi_video_encode_accelerator.cc(202)] VaapiVideoEncodeAccelerator():
[19095:19095:0305/163315.855375:VERBOSE2:vaapi_video_encode_accelerator.cc(206)] ~VaapiVideoEncodeAccelerator():
[19095:19095:0305/163315.855389:VERBOSE2:vaapi_jpeg_decode_accelerator.cc(306)] ~VaapiJpegDecodeAccelerator(): Destroying VaapiJpegDecodeAccelerator
[19095:19095:0305/163317.384730:VERBOSE2:vaapi_video_decode_accelerator.cc(198)] Initialize(): Initializing VAVDA, profile: h264 main
[19095:19312:0305/163317.385901:VERBOSE2:vaapi_video_decode_accelerator.cc(446)] DecodeTask(): Decoder requesting a new set of surfaces
[19095:19095:0305/163317.385941:VERBOSE2:vaapi_video_decode_accelerator.cc(499)] InitiateSurfaceSetChange(): Initiating surface set change
[19095:19095:0305/163317.385964:VERBOSE2:vaapi_video_decode_accelerator.cc(543)] TryFinishSurfaceSetChange(): Requesting 11 pictures of size: 1280x720
[19316:19316:0305/163317.489346:VERBOSE2:vaapi_video_encode_accelerator.cc(202)] VaapiVideoEncodeAccelerator():
[19316:19316:0305/163317.489375:VERBOSE2:vaapi_video_encode_accelerator.cc(206)] ~VaapiVideoEncodeAccelerator():
[19316:19316:0305/163317.489392:VERBOSE2:vaapi_jpeg_decode_accelerator.cc(306)] ~VaapiJpegDecodeAccelerator(): Destroying VaapiJpegDecodeAcceleratorscreenshot of media-internals with iHD Does this mean it is working? |
|
Hey @colemickens.
That's weird, at least libva is resolved and in the right library search path, which is better the current state of my tree.
It does look like libva intialization is successful but the screenshot contradicts that as it looks like FFmpegVideoDecoder is actually used. AFAIK, HW-accelerated decoding goes through MojoVideoDecoder or GpuVideoDecoder. Thanks tor your time, dude |
Ok, so I had a look at your patch and you dont use the |
Put libva.so in dlopen seach path by tweaking LD_LIBRARY_PATH env var in the launcher script.
amazari
requested review from
alyssais,
basvandijk,
edolstra,
Ericson2314,
FRidh,
infinisil,
matthewbauer,
nbp,
peti and
zimbatm
as code owners
|
Ok, so I obviously messed up with git. I am closing this PR and create a new one. Sorry about that. |
Add 'VAAPISupport' parameter to chromium expression. If set to true, a
patch enabling hw video decoding through vaapi is applied.
The patch originates from Arch Linux
https://git.archlinux.org/svntogit/packages.git/plain/trunk/chromium-vaapi.patch?h=packages/chromium
Tested on 72.xx
Motivation for this change
Using HW video decoding should improve performances and "smoothness" while reducing battery consumption.
Seems to be a requested feature per issue #21481
Things done
Import a patch from Arch and enable its application behind the boolean VAAPISupport parameter for the chromium function (default = false).
Naming of the parameter is debatable as there seems to be 2 conventions: xxxSupport and enableXxx.
Also should the value be conditioned by the presence of the libva package and/or the presence of libva in opengl libs?
Should an assertion be added to ensure that the version of chromium is equal to 72.xx ?
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)