…and VDAVideoDecoder on Chrome 91?’’ 
seems to be d3d11videodecoder on windows now, I’ll check my personal box when I get home
IDK why they change it every release
I’m on brave, which latest is 90, shows
Decoder : VideoDecodeAccelerator
Hardware Decoder: True
Put chrome 91 on to test
Chrome has hard disabled the ability to turn on video decode in chrome://flags
Removed Chrome 91
I’ve updated the guide. With Chromium 91, it’s now --enable-features=VaapiVideoDecoder instead of --enable-accelerated-video-decode.
2 Likes
This is also broken on brave 91
vainfo and vdpauinfo both working, was working before update with brave 90
Cant get to work with --enable-features=VaapiVideoDecoder or --enable-accelerated-video-decode. It’s been broken on every chromium 91 based browser I’ve touched on linux, and they all seem to be missing the flags that were previously there for it from browser://flags.
This seems to be something broken or removed upstream
This is a tutorial, not a support thread. Please create your own thread in #support instead of cross-posting on the Arch forums and here.
1 Like
@Yochanan, so post chrome 88 i had my vid acceleration working with --enable-features=VaapiVideoDecoder switch and everything was working fine. However inbetween chrome 90-92, video acceleration has cease to function again.
after advise from a forum user to uninstall and reinstall with fresh config to fix the issue, i found vid. accel. works only the first time you invoke chrome after clearing the config. every subsequent invocation results in vid. accel. being disabled. then after comparing GPU settings in chrome:///gpu page, i found that ozone platform is loaded only successive chrome invokes. disabling ozone (via flag), gets video acceleration back.
ozone could be disabled by CLI switch --disable-features=UseOzonePlatform or flag #use-ozone-platform.
i’m on X11 with intel i915/965 driver with VAAPI enabled. and still cant makeout whether ozone is meant to help X11 or xwayland users. with G deciding that ozone to be enabled by default, there can be a performance penalty if it is disabled. however it seems it is the only way to get hw v. acceleration back.
2 Likes
Yep, just discovered that earlier and tested it. I updated the guide.
1 Like
For those trying to use Electron apps such as Discord, Signal or TutaNota on Wayland but get blank window contents, the Chromium launch option --use-gl=desktop fixes that for me! Make sure to also set up the proper Wayland config as described on the ArchWiki too. (You can indeed put --use-gl=desktop in that file if you want to apply it universally.)
Kind soul by the name of JonnyBoss taught me that over on the GamingOnLinux forum. Was gonna make a thread about it, but this one seems similar enough to only warrant this reply.
1 Like
@Yochanan looks like chrome 95 is the final nail in the coffin for video acceleration on X11/VAAPI users. ozone-platform cannot be disabled anymore, and and video acceleration with it .
did bit of digging up on the bug i reported and the final bug that it was merged into. apparently their fix will only available in chrome 96.
https://chromiumdash.appspot.com/commit/a4de986102a45e29c3ef596f22704bdca244c26c
1 Like
Apparently not. Tested with 96.x as well as with version 97.0.4681.0, and it still fails:
[4210:4961:1102/135750.651953:FATAL:vaapi_wrapper.cc(2358)] : Check failed: sequence_checker_.CalledOnValidSequence().
#0 0x7f8c160035fe base::debug::CollectStackTrace()
#1 0x7f8c15f30efb base::debug::StackTrace::StackTrace()
#2 0x7f8c15f4c0ea logging::LogMessage::~LogMessage()
#3 0x7f8c15f4cc85 logging::LogMessage::~LogMessage()
#4 0x7f8c064c84fa media::VaapiWrapper::SubmitBuffers()
#5 0x7f8c064a038f (/usr/lib/chromium/libservice.so+0x23238e)
#6 0x7f8c064d4fa4 media::H264Decoder::StartNewFrame()
#7 0x7f8c064d7904 media::H264Decoder::Decode()
#8 0x7f8c064aa50f media::VaapiVideoDecodeAccelerator::DecodeTask()
#9 0x7f8c15fb30bc base::TaskAnnotator::RunTask()
#10 0x7f8c15fc95be base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl()
#11 0x7f8c15fc92fc base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#12 0x7f8c15fc9989 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#13 0x7f8c15f569db base::MessagePumpDefault::Run()
#14 0x7f8c15fc9c26 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
#15 0x7f8c15f89061 base::RunLoop::Run()
#16 0x7f8c15fea29b base::Thread::Run()
#17 0x7f8c15fea451 base::Thread::ThreadMain()
#18 0x7f8c1601894c (/usr/lib/chromium/libbase.so+0x22294b)
#19 0x7f8c0700b259 start_thread
#20 0x7f8c069f25e3 __GI___clone Task trace:
#0 0x7f8c064ac67e media::VaapiVideoDecodeAccelerator::AssignPictureBuffers()
#1 0x7f8c0d82075a (/usr/lib/chromium/libmedia_mojo_services.so+0x9f759)
#2 0x7f8c064ab814 media::VaapiVideoDecodeAccelerator::TryFinishSurfaceSetChange()
#3 0x7f8c064aa80b media::VaapiVideoDecodeAccelerator::DecodeTask()
#4 0x7f8c064aa01b media::VaapiVideoDecodeAccelerator::QueueInputBuffer() Task trace buffer limit hit, update PendingTask::kTaskBacktraceLength to increase. Crash keys: "last-video-decoder" = "name=VDAVideoDecoder:codec=h264:profile=3:size=1280x720:cs=[1,1,2,1]:hdrm=0" "num-video-decoders" = "1"
GpuProcessHost: The GPU process crashed!
As of now, it looks like you will have to stick to version 95.x unless you happen to use Wayland (like the Chromium developers apparently all do).
it seems so, but owners/devs(maybe) of the merged bug are sort of in denial. there are already stack-traces reported on 97.x failure for acceleration. please refer to the bug, and add to it as you see fit; 1121948 - chromium - An open-source project to help move the web forward. - Monorail
the fix was backported to chromium 95 by arch;
would be great to know from chromium users who installed from repo how they’ve fared so far.
Can anybody explain the following?
Currently, I have installed Chromium in a version built from sources, 95.0.4638.74, with the extended-h264ify extension.
extended-h264ify works as intended (H.264 is chosen for YouTube videos) but any videos from sites other than YouTube are played using FFMPEGVideoDecoder, regardless of their codec being H.264 as well.
When I try to play a video someone sent me on Whatsapp, Chromium does not even seem to try to initialize the VDAVideodecoder:
"Selected FFmpegVideoDecoder for video decoding, config: codec: h264, profile: h264 baseline, level: not available, alpha_mode: is_opaque, coded size: [640,352], visible rect: [0,0,640,352], natural size: [640,352], has extra data: true, encryption scheme: Unencrypted, rotation: 90°, flipped: 0, color space: {primaries:SMPTE170M, transfer:SMPTE170M, matrix:SMPTE170M, range:LIMITED}"In contrast, for YouTube, VDAVideoVideoDecoder is chosen automatically:
"Selected VDAVideoDecoder for video decoding, config: codec: h264, profile: h264 main, level: not available, alpha_mode: is_opaque, coded size: [1280,720], visible rect: [0,0,1280,720], natural size: [1280,720], has extra data: false, encryption scheme: Unencrypted, rotation: 0°, flipped: 0, color space: {primaries:BT709, transfer:BT709, matrix:BT709, range:LIMITED}"Currently, I am evaluating the stock version 95.0.4638.69 installed from the official repo. At least here, the patch to enable VA-API on Ozone/X11 seems to work - all OK in the logs, no crashes so far.
It is interesting that there seems to be almost no interest in this topic.
There are no responses or contributions, even in the bug reports.
Looks like nobody needs to care about video acceleration anymore as computers sold these days are fast enough to make accelerated video playback unnecessary.
They might be fast enough, but they sure as hell are not as (energy) efficient. Notebook users will notice the reduced battery life and higher noise level from their fans - but what can they do…
If video acceleration in browsers is not available, one switches to external players which provide it 
That’s, of course, reasonable. But what to do in case of YouTube videos? Having to copy the video URL to an external player each time, also sounds cumbersome.
And, for some external players, the problem with video acceleration applies as well.
Example: vlc.
vlc does not seem to support VA-API on VDPAU (as it is needed when using a Nvidia graphics card).
In that situation, you will have to compile vlc yourself, as well as ffmpeg. So, it looks like at least when using a Nvidia card under Linux, external players do not exactly seem to solve the problem.
Even worse: What are you doing with videos that you cannot play in external players (examples: Whatsapp, Facebook, Instagram, and a lot of news services)?
Again, as computers are that fast these days, it looks like nobody is noticing the drawbacks of accelerated video playback being missing.
There is send-to-mpv (for Firefox) and play-with-mpv (for Chrome) to play videos by button-clicking instead of manually pasting the URL.
It will use youtube-dl to stream the file into mpv.
running fine on chrome 96 with hardware acceleration.
modesetting driver on kernel 5.15.
installed also manjaro-vaapi package and gstreamer vaapi package ( maybe its useless dont know)
also i havent created intel.conf for forcing intel driver instead of modesetting
using flags
–ignore-gpu-blocklist
–enable-gpu-rasterization
–enable-zero-copy
–enable-features=VaapiVideoDecoder
–use-gl=desktop
system:
inxi -v1 ✔
System:
Host: martin-hpprobook640g2 Kernel: 5.15.2-2-MANJARO x86_64 bits: 64
Desktop: KDE Plasma 5.23.3 Distro: Manjaro Linux
CPU:
Info: Dual Core Intel Core i5-6200U [MT MCP] speed: 800 MHz
min/max: 400/2300 MHz
Graphics:
Device-1: Intel Skylake GT2 [HD Graphics 520] driver: i915 v: kernel
Device-2: Cheng Uei Precision Industry (Foxlink) HP HD Camera type: USB
driver: uvcvideo
Display: x11 server: X.Org 1.21.1.1 driver: loaded: modesetting
resolution: 1366x768~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 520 (SKL GT2) v: 4.6 Mesa 21.2.5
Drives:
Local Storage: total: 238.47 GiB used: 21.28 GiB (8.9%)
Info:
Processes: 214 Uptime: 25m Memory: 7.65 GiB used: 1.99 GiB (26.1%) Shell: Zsh
inxi: 3.3.09
maybe it will help someone or its fixed by meantime