[HowTo] Enable Hardware Video Acceleration / Video Decode In Google Chrome, Brave, Vivaldi And Opera Browsers

I see. YouTube uses VP9 or AV1 video encode by default. AFAIK.

What is your GPU?

sorry was bit late respond, i’m using h264fy extension on chrome since i only have codecs for 264. video acceleration was working fine, just dont know when it stopped working. video acceleration works fine on other media players.

iGPU is intel HD Graphics 4000;

Graphics:
  Device-1: Intel 3rd Gen Core processor Graphics vendor: Dell driver: i915
    v: kernel arch: Gen-7 process: Intel 22nm built: 2012-13 ports:
    active: LVDS-1 empty: DP-1,HDMI-A-1,VGA-1 bus-ID: 00:02.0
    chip-ID: 8086:0166 class-ID: 0300
  Device-2: AMD Thames [Radeon HD 7500M/7600M Series] vendor: Dell
    driver: radeon v: kernel arch: TeraScale-2 code: Evergreen
    process: TSMC 32-40nm built: 2009-15 pcie: gen: 1 speed: 2.5 GT/s lanes: 8
    link-max: gen: 2 speed: 5 GT/s lanes: 16 bus-ID: 01:00.0 chip-ID: 1002:6840
    class-ID: 0300 temp: 46.0 C
  Device-3: Microdia Laptop_Integrated_Webcam_HD type: USB driver: uvcvideo
    bus-ID: 1-1.5:3 chip-ID: 0c45:644a class-ID: 0e02
  Display: x11 server: X.Org v: 21.1.7 compositor: kwin_x11 driver: X:
    loaded: modesetting,radeon alternate: fbdev,vesa dri: crocus,r600 gpu: i915
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 361x203mm (14.21x7.99")
    s-diag: 414mm (16.31")
  Monitor-1: LVDS-1 model: LG Display 0x033a built: 2012 res: 1366x768 hz: 60
    dpi: 101 gamma: 1.2 size: 344x194mm (13.54x7.64") diag: 395mm (15.5")
    ratio: 16:9 modes: 1366x768
  API: OpenGL v: 4.2 Mesa 22.3.5 renderer: Mesa Intel HD Graphics 4000 (IVB
    GT2) direct-render: Yes

Maybe h264fy extension is outdated, because I know only YouTube breaks the compatibility of some 3rd-party programmings a few days ago. For example YouTube uploader ID was changed, that is why yt-dlp got a known issue

could be, i’ll report if find a way out of this. so far no bugs have been reported in chrome bug tracker. h264fy seems to function, in the youtube in-player stats indicate that the video stream is indeed; avc1.4d401f (135) / mp4a.40.2 (140) it is also confirmed by chrome developer tools media tab which also says software decoding is in place as also confirmed by intel_gpu_top. i’m having feeling something affecting VAAPI stack is the cause

Since a week or two I had to disable (#)
--use-gl=desktop
on amd and intel igpu to get “vaapi true”.

Edit:
There was a patch for libva (my old intel ivy-bridge needed it)
chromium: hardware video acceleration with VA-API (Page 30) / Applications & Desktop Environments / Arch Linux Forums see post from Akmt

https://raw.githubusercontent.com/archlinux/svntogit-packages/packages/libva/trunk/PKGBUILD

1 Like

rebuilt libva as per instructions, and video acceleration is back again. other than what is already mentioned you can follow the bug@;

From https://chromium.googlesource.com/chromium/src/+/43cfb2f92a5cdc1a787d7326e74676884abf5052, having --ozone-platform-hint=auto will enable native Wayland support and using that on Brave will break hardware acceleration on my system. Not having it will make Brave run on XWayland by default and everything work as expexted.
This breakage seems to only happened recently.
Apparently when not launching from the terminal, Brave would still run in native Wayland. Adding --ozone-platform-hint=x11 “fixed” it but I don’t think this is the optimal solution?

I’m runing X11 server but, e.g: Min browser works accelerated only with --use-gl=egl flag
(tested on Figma sweb app)
(i’m running hybrid graphics mode)

Since some time the old --use-egl=desktop started to break hw-accel.
Replacing with --use-gl=egl works for me. (ungoogled-chromium + amdgpu)

These three work for me (intel H620):

–enable-features=VaapiVideoDecoder,VaapiVideoEncoder
–disable-features=UseChromeOSDirectVideoDecoder
–use-gl=egl

with the new release of libva 2.18.0-1 on systems running old intel iGPUs (AFAIK pre-haswell) on X11, video acceleration is borked again. however new driver now supports flag/ENV to disable DRI3 which causes the issue on the said platform.

if you encounter the issue, please add;

LIBVA_DRI3_DISABLE=1

to /etc/environment, you will have to reboot for it to take affect

In a Wayland session helps the parameter?

no, as far as i know this only affects X11

1 Like

While this still seems to be true…

--use-gl=angle

Produces better results - specifically in cases of 3D.
(example. play-cs.com will not launch without it)

If anyone wants to see a bunch of flags see here. ~/.config/chromium-flags.conf
--start-maximized
--force-dark-mode
--enable-features=WebUIDarkMode
--ignore-gpu-blocklist
--disable-font-subpixel-positioning
--high-dpi-support=1
--force-device-scale-factor=1.25
--enable-accelerated-video
--enable-accelerated-mjpeg-decode
--enable-gpu-rasterization
--enable-oop-rasterization
--enable-quic
--enable-zero-copy
--enable-drdc
--canvas-oop-rasterization
--use-gl=angle
--enable-smooth-scrolling
--enable-accelerated-video-decode
--enable-native-gpu-memory-buffers
--enable-features=MarkHttpAs,StrictOriginIsolation,VaapiVideoDecoder,VaapiVideoEncoder,VaapiVideo,CanvasOopRasterization,VaapiIgnoreDriverChecks,PlatformHEVCDecoderSupport
--disable-features=UseChromeOSDirectVideoDecoder,HardwareMediaKeyHandling,OmniboxUIExperimentHideSteadyStateUrlPathQueryAndRef,OmniboxUIExperimentHideSteadyStateUrlScheme,OmniboxUIExperimentHideSteadyStateUrlTrivialSubdomains,ShowManagedUi
2 Likes

I did not add LIBVA_DRI3_DISABLE=1 to /etc/environment.

However I did comment out --use-gl=egl in my chromium-flags.conf and now chrome://gpu is showing that Hardware Acceleration is working again on my Ivy Bridge KDE Wayland laptop, so go figure…

like i said before, this was intended for X11 only, not wayland which you are using.

side note, just because it reads as HW acceleration enabled in chrome://gpu it might not be so. depend on intel_gpu_top or chrome dev-tools-> media to be sure.

1 Like

I had some issues with HW Acc. apparently Vulkan is the issue, so ignore --use-vulkan since it’s still WIP in chrome, better is to disable it if you encounter issues.

I’m running into a HW video acc. issues on my backup mobile-Haswell notebook, after having updated it recently since some time.
Vivaldi no longer uses (intel_gpu_top) the Video engine and CPU utilization is much higher on video playback.

Yet Vivaldi://gpu shows HW acceleration is enabled and video decoding is HW accelerated. Using these flags:

--use-gl=angle (using egl it falls back to software rendering)
--ignore-gpu-blocklist
--enable-features=VaapiVideoEncoder,VaapiVideoDecoder,CanvasOopRasterization
--disable-features=UseChromeOSDirectVideoDecoder,UseSkiaRenderer
--disable-gpu-driver-workarounds

My media box however uses a Skylake-T and it had no issues. Bar from some extra flags it needed, after updating it recently, to get HW video acc. working again with flags: --use-vulkan --use-gl=egl --webgpu --enable-raw-draw.
Without the vulkan flag HW video acc. would also fall back to software rendering.

FireFox how ever does properly utilize the Haswell’s igpu Video engine on video playback and it’s also not loading the CPU keeping it at idle frequencies.

So what has changed in Chromium that HW video acc. no longer properly works on Haswell, yet does on later igpu’s? Vulkan support?

This guide is severely out of date as Google has changed a lot since I last updated it.

However, one might test only these flags:

--enable-features=VaapiVideoEncoder,VaapiVideoDecodeLinuxGL
--enable-gpu