Hardware accelerated video encoding and decoding in Chromium is coming soon to the stable snap channel. It has been (and continues to be) available for testers in hwacc branches.
Background
Computers usually have at least one Graphics Processing Unit (GPU). Different from the Central Processing Unit (CPU), which is general purpose, a GPU is, as the name suggests, specialized in image manipulation, so media is more efficiently processed by it. In the Chromium snap today all video processing is done by the CPU which is not nearly as efficient as it could be and may result in a more sluggish desktop because the CPU is doing tasks it is not optimized for. Recognising that GPUs are perfect for certain types of tasks we can use “hardware acceleration” to send specific types of tasks to the GPU, freeing up the CPU and resulting in a more efficient system overall. Enabling hardware acceleration in Chromium results in lower energy consumption and also increased overall performance.
Enabling hardware acceleration is more complicated than flipping a switch and in fact a lot of work had to go into the Chromium snap to make this happen. So, here is an overview of the steps we took to enable hardware acceleration in the Chromium snap.
In the snap world we are restricted to using the packages in the series corresponding to the base snap version, which was core20 (so 20.04 series) at the time the project started. Unfortunately, 20.04 does not provide recent enough versions of Libva or the Intel GPU driver to enable hardware accelerationÂą. And so last year we started building Libva and the Intel media driver from source to lay the foundation for hardware acceleration in the Chromium snap.
Such a process generally involves debugging with e.g. correct dependency resolution and environment fine tuning; here is what a typical merge request looked like.
We had hit-or-miss results with those builds; it was clear that we would need time and structure to get reliable results. The original intent to merge this directly into the dev source tree (used to build the main snap on the edge channel) was thus abandoned, and instead the hwacc branches were created to continue those efforts in a staging area that would be used to build opt-in snaps.
With the help of more Canonical’s eyes², Intel’s partnership and automated tests for different hardware configurations, we are now in a much better position to merge our work into the main Chromium snap.
Scope and testing
The scope of the project are machines with Intel GPU. To verify if your machine is covered, go to Settings > About and see if your graphics is Intel HD or UHD Graphics (you can also use the command line: lspci | grep HD\ Graphics).
If yes, your machine will benefit from the hwacc Chromium snap. It is still in testing, but if you want to give it a try, run:
snap install --channel candidate/hwacc chromium
Monitoring whether your Intel GPU is actually used for decoding video is straightforward with intel_gpu_top, provided by the intel-gpu-tools package:
sudo apt install intel-gpu-tools
sudo intel_gpu_top
Then use the browser to play media (video calls are also covered) and verify in intel_gpu_top that the video engine is busy (video demonstration).
For that VP8 video, hwacc Chromium brings the CPU consumption down from roughly 110% to 50% in my experiment — that will vary from machine to machine.
Finally, it must be noted that, although the support for hardware accelerated video encoding is quite broad, not absolutely all codecs are supported, and for video encoding that number is more limited. The exact Intel platform can also be a relevant variable.
Why Intel platforms only
We have to start somewhere and generally speaking Intel provides the best support in drivers and maintenance for Linux.
As such, acceleration in Chromium hwacc snap is currently done via the VA-API over Libva. If you look for kVideoDecoderName in about://media-internals while playing media, it will say VaapiVideoDecoder — if the functionality is actually working.
Where does development happen and how is it organized?
The repository lives in Launchpad and the edge/hwacc snap is built there.
In the main Chromium snap, stable, beta and edge channels map to upstream’s stable, beta and dev channel. The hwacc snap does not follow that routine and edge/hwacc is manually promoted to candidate/hwacc when its ready.
What exactly are the hwacc changes?
By now the changes are merged into the official edge channel, so just see the merge commit.
For example, these are flags enabled by hwacc Chromium:
-
--use-gl=angle --use-angle=gl: select OpenGL renderer. -
--enable-features=VaapiVideoDecoder,VaapiVideoEncoder,VaapiVideoDecodeLinuxGL,to enable VAAPI video decoding in Linux — upstream only enables that in ChromeOS by default. -
--enable-features=UseChromeOSDirectVideoDecoderto use VaapiVideoDecoder instead of the legacy VDAVideoDecoder. -
--video-capture-use-gpu-memory-bufferenables one-copy, observed to slightly reduce power consumption. -
--ozone-platform-hint=autoto use Wayland Ozone backend if Wayland is detected as the system platform but not if Xorg is detected as the system platform.
If you are giving it a try, let us know your observations. Bug reports are always welcome, you can file one with ubuntu-bug chromium-browser or directly via the Launchpad interface.
ÂąThis is not a problem anymore since Chromium is migrating to core22. In fact, the Gnome 42 extension itself provides the driver now.
²Hector Cao, Bram Stolk, Daniel van Vugt, Sebastien Bacher, Ricardo Martins, Pierre Equoy.