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
My settings in chrome-flags.conf are as follows:
--disable-gpu-driver-bug-workarounds
--use-gl=desktop
--ignore-gpu-blocklist
--enable-gpu-rasterization
--enable-zero-copy
--enable-features=VaapiVideoDecoder,VaapiVideoEncoder,CanvasOopRasterization
This works perfectly on a KBL Intel UHD 620 graphics, X11, Plasma.
EDIT: Later I disabled --use-gl=desktop flag with no observable issues.
as indicated in the OP, chrome(ium) 98 requires;
either of these flags:
--enable-features=Vulkan
OR
--disable-features=UseChromeOSDirectVideoDecoder
to get hardware acceleration functional
[56:519:0203/220150.818813:ERROR:vaapi_video_decoder.cc(1201)] : failed Initialize()ing the frame pool when i enable vulkan. any ideas?
try the other one, it’s either that or this
I don’t get that vaapi error above, but it won’t switch to vaapi either. Any other ideas? Thanks!
Update: I added both vulkan and disable chromeosd… . After I removed vulkan it works 
Chrome 98, Brave 1.35.100, Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2)
.config/chromium-flags.conf
--flag-switches-begin
--start-maximized
--force-dark-mode
--enable-features=WebUIDarkMode
--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
--ignore-gpu-blocklist
--enable-smooth-scrolling
--use-gl=desktop
--enable-accelerated-video-decode
--enable-features=MarkHttpAs,StrictOriginIsolation,VaapiVideoDecoder,VaapiVideoEncoder,CanvasOopRasterization
--disable-features=HardwareMediaKeyHandling,OmniboxUIExperimentHideSteadyStateUrlPathQueryAndRef,OmniboxUIExperimentHideSteadyStateUrlScheme,OmniboxUIExperimentHideSteadyStateUrlTrivialSubdomains,ShowManagedUi
--flag-switches-end
(obviously skip the dpi/scale/dark/theme things unless you want the same)
Oh yeah … I will mention this is on an AMDGPU with all the relevant HW-Accel packages installed etc.
The flags probably have some old stuff in there too that is no longer required … but I dont feel like investigating right now.
This…
--enable-features=MarkHttpAs,StrictOriginIsolation,VaapiVideoDecoder,VaapiVideoEncoder,CanvasOopRasterization,RawDraw
…will make your graphics feature status a bit more green. 
1 Like
If you mean a literal green tint … that likely means there is a problem with your HW-Accel.
(see related experiences on poorly configured VLC)
It certainly doesnt produce ‘green’ here.
any of you folks got dr-dc(Direct Rendering Display Compositor) working. if so how? (simply enabling flag/switch doesnt work)
RawDraw is getting better BTW.
Don’t take it that serious, I’m joking a bit. When dabbling around with these flags, I sometimes think “less is more”. 
No worries. Just seeking clarification.
I tried to be up front about how its a bunch of things I havent re-analyzed anytime recently.
(seems to work though)
Oh …but I did forget to mention its ungoogled-chromium here 