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.
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-dlpgot 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
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)
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
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.
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?