VP9 VDPU381 patch v9: Two bugs causing decode artifacts at 2K+

[dongioia]

Summary

Your v9 VP9 VDPU381 patch (3564-media-rockchip-rkvdec-vdpu381-add-vp9-support-v9.patch) inherits two bugs from dvab-sarma's original code that cause visual artifacts at resolutions above 1080p.

We tested on RK3588 (Rock 5B+, kernel 7.0-rc3+) with Chromium V4L2 stateless decode. VP9 works perfectly at 720p/1080p but shows corruption at 2K+.

I also reported this upstream to dvab-sarma: dvab-sarma/android_kernel_rk_opi#3

Bug #1 (CRITICAL): Altref vertical scale copy-paste error

In config_registers(), at the scale calculation loop:

case 2:
    regs->vp9_param.reg92.vp9_aref_hor_scale = hscale;
    regs->vp9_param.reg93.vp9_aref_ver_scale = hscale;  // BUG: should be vscale
    break;

Cases 0 and 1 correctly use vscale for vertical. Case 2 (altref) copies hscale instead. This causes incorrect reference frame scaling when the altref has different dimensions from the current frame.

One-line fix:

-    regs->vp9_param.reg93.vp9_aref_ver_scale = hscale;
+    regs->vp9_param.reg93.vp9_aref_ver_scale = vscale;

Bug #2: Segmap buffer overflow at 4K

#define RKVDEC_VP9_MAX_SEGMAP_SIZE 73728

Segmap size = ceil(w/64) * ceil(h/64) * 64. At 4K this is 130,560 bytes, exceeding 73728. This causes buffer overflow and potential memory corruption.

Fix: Increase to 524288 for 8K safety.

NOT bugs (we investigated these too)

• Missing yuv_virstride: VDPU381 doesn't have this register (confirmed by checking H.264/HEVC backends)
• Missing lastref_yuv_virstride: Same — hardware design difference from VDPU2

Test setup

• Rock 5B+ (RK3588), kernel 7.0-rc3+, Mesa 26.0.3, Chromium 148 V4L2 zero-copy
• Beryllium OS (ex-BredOS)

— Sav (dongioia @ beryllium-org)

[warpme]

Thx for reporting this!
I prepared test kernel with fixes: http://minimyth2.mooo.com/pkg/aarch64/miniarch/linux-aarch64-7.0.rc7-1-any.pkg.tar.gz

[dongioia]

Thanks for the quick fix, Piotr!

I tested both fixes on my Rock 5B+ (kernel 7.0-rc3+, Beryllium OS) and can confirm they are correct. However, I discovered that the 2K+ artifacts issue is NOT in the kernel driver — it's in Chromium's V4L2 pipeline.

Key finding:

• mpv --hwdec=v4l2request plays VP9 correctly at all resolutions including 1440p and above
• Chromium 148 (with V4L2 stateless decode) shows artifacts only above 1080p
• The VDPU381 VP9 hardware decoder works correctly at all resolutions

So the vscale + segmap fixes are genuine kernel bugs that should be applied, but the visual artifacts I originally reported at 2K+ are caused by Chromium's V4L2VideoDecoder / VideoDecoderPipeline buffer handling, not the kernel driver.

I also investigated several other potential kernel bugs (#4 reg78 lasttile_size, #5 reg103 HW prob engine, #8 stream alignment, #9 segmap resolution change) — none of them affect the decode quality. Note: enabling the HW probability engine (reg103.prob_update_en) without allocating the HW prob buffers causes IOMMU page faults at address 0x0 — the driver correctly uses SW probability updates in the done() callback.

I'll continue investigating the Chromium side. Will update dvab-sarma's issue too.

— Sav (dongioia @ beryllium-org)

[warpme]

I included above changes in recently published 7.0 kernel.
pls test and and report.

btw: i'm playing with chromium browser of qt6.11 using patched for v4l2_request system 8.1 ffmpeg. Maybe you know what i need to patch in chromium (qt6.11 has chromum 122 i think) to get video decoding using hw accell?

[dongioia]

Thanks Piotr, I'll rebuild and test the 7.0 kernel on the Rock 5B+ in the next days and report back (recent boot regressions on my board turned out to be my GPU overclock service, not your kernel).

On the Qt 6.11 / Chromium 122 question: patching FFmpeg alone won't give you HW decode for <video>. Chromium doesn't route <video> through libffmpeg for decode — it has its own media/gpu/ stack. FFmpeg in Chromium is used mostly for demuxing and a few legacy codecs, not hardware-accelerated video on <video> elements.

To get V4L2 stateless HW decode on non-ChromeOS Linux in Chromium, you need:

Build args (args.gn):

use_v4l2_codec = true
use_linux_v4l2_only = true
use_vaapi = false

Runtime flags:

--enable-features=AcceleratedVideoDecodeLinuxV4L2,AcceleratedVideoDecodeLinuxGL
--ignore-gpu-blocklist
--enable-accelerated-video-decode

Caveats specific to Chromium 122:

• The V4L2 stateless Linux path in media/gpu/v4l2/ was still maturing during 2024. Chromium 122 (Feb 2024) lacks several fixes landed later. The V4L2StatelessVideoDecoder exists but codec coverage (VP9, AV1) was incomplete. Bumping QtWebEngine to a newer Chromium (130+) helps a lot.
• VideoDecoderPipeline in 122 had a USE_CHROMEOS_MEDIA_ACCELERATION guard that gated frame-pool / ImageProcessor on non-ChromeOS builds. I had to patch that out in Chromium 148 too.
• QtWebEngine sandbox: ensure /dev/video*, /dev/dri/renderD128, /dev/v4l-subdev* are accessible inside the sandbox (QtWebEngine tightens permissions vs stock Chromium).

For reference, my Chromium build notes (both the Flatpak wrapper and the recompiled-from-source variant with V4L2 patches) are documented in https://github.com/dongioia/rock5bplus-rkvdec2 — may save you some trial and error.

Separate heads-up: if you do get V4L2 HW decode running, expect visual artifacts above ~1080p. I have not fully resolved this yet. What I've confirmed:

• The kernel decoder is correct (frame dumps HW vs SW match byte-for-byte)
• mpv --hwdec=v4l2request plays cleanly at all resolutions (up to 4K) via both OpenGL and Vulkan paths on Panfrost/PanVK
• A minimal C program doing plain Mesa EGL NV12 DMA-BUF import at 2560×1472 with a known pattern also works
• So the issue sits somewhere in Chromium's GL/compositor path (ANGLE import + whatever Chromium wraps around the imported image), not in the driver or Mesa EGL itself

What I've tried without success: forcing MMAP+EXPBUF, forcing the LibYUV ImageProcessor path in VideoDecoderPipeline::PickDecoderOutputFormat(), per-plane EGL import (R8 + RG8) via ozone_image_gl_textures_holder.cc, coded_height instead of visible_height on EGL_HEIGHT. Each changed the artifact color/pattern but didn't eliminate it. Filed as https://issues.chromium.org/issues/503755157 for upstream eyes — still open.

Practical take for Qt 6.11: if the goal is playback, mpv embedded (or as a QProcess) works reliably. If the goal is <video> in WebEngine, HW decode at ≤1080p should work once you flip the V4L2 path on; beyond that you'll hit the same wall I did.

— Sav (dongioia @ beryllium.gr)

[JFLim1]

Hi @dongioia,
Device: Orangepi-5-Plus
OS: MiniArch-EOS
DE: Gnome-50.1
Kernel: 7.0.0 (latest MiniArch Kernel)

Downloaded and install chromium-v4l2-148.0.7774.0-arm64-rk3588.tar.gz

Followed the guidelines to install Chromium as in https://github.com/dongioia/rock5bplus-rkvdec2/blob/main/docs/chromium-v4l2-rk3588-analysis.md (10. Reproduction)

Somehow cannot get vp9 Youtube to work on Chromium-v4l2-148. Artifacts. 480p, 720p or 1080p.

Had same issue with vp9 youtube video on Chromium-146 or earlier.

Just noticed on Chromium-v4l2-148 and kernel-7.0, av1 video, no vpu hardware acceleration

[alarm@opi5plus ~]$ chromium-v4l2
[5504:5504:0422/174234.640683:ERROR:ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc:252] '--ozone-platform=wayland' is not compatible with Vulkan. Consider switching to '--ozone-platform=x11' or disabling Vulkan
[5504:5504:0422/174234.641827:ERROR:gpu/vulkan/vulkan_instance.cc:200] vkCreateInstance() failed: -9
[5504:5504:0422/174234.641975:ERROR:gpu/ipc/service/gpu_init.cc:1398] Failed to create and initialize Vulkan implementation.
[5461:5461:0422/174243.156533:ERROR:components/dbus/xdg/request.cc:173] Request ended (non-user cancelled).

Chromium-146 and kernel-7.0, av1 video is vpu hardware accelerated.

[dongioia]

Hi @JFLim1, thanks for the detailed report — your setup actually helps isolate what's going on.

You're running our Chromium build (same binary I use on my Rock 5B+), but the kernel is different: MiniArch's linux-aarch64-7.0.0 instead of my patched tree. That difference fully explains why you see artifacts at every resolution while I only see them above 1080p.

Two bugs are stacked in your case:

1. Kernel VP9 / VDPU381 — without the altref vscale fix and segmap size fix (commit 75d2d8291849), the RK3588 VP9 hardware decoder emits corrupted inter-predicted blocks at any resolution. This is what your screenshot shows (typical pattern: blocky green/pink smears following motion).
2. Chromium GL path — the one I filed at https://issues.chromium.org/issues/503755157. Only manifests above ~1080p, because the kernel decoder itself is correct on my side.

In your case bug #1 is corrupting every frame, so bug #2 is completely masked by it. As soon as you fix the kernel, you'll see VP9 work cleanly up to 1080p and then run into the same wall I have above it.

Quick verification:

• mpv --hwdec=v4l2request <vp9_file> — if mpv also shows the same artifacts, it's the kernel decoder, conclusively. On a patched kernel, mpv plays VP9 cleanly at all resolutions.
• Ask Piotr whether the current linux-aarch64-7.0.0 MiniArch package actually carries those two patches. Earlier in this thread he mentioned a test kernel (linux-aarch64-7.0.rc7-1) that did include them — not sure whether the fixes made it into the 7.0.0 release or only that test build.

If your kernel is missing the patches, installing a kernel that has them (Piotr's test build, or any build from mainline after commit 75d2d8291849) should remove the all-resolutions artifacts entirely.

On AV1 losing HW decode on Chromium-v4l2-148:

Separate issue, unrelated to the Vulkan error in your log — V4L2 stateless decode doesn't use Vulkan; those lines are Wayland/Vulkan init noise and can be ignored.

To diagnose: open chrome://media-internals while playing an AV1 video — it will show the actual decoder in use (V4L2StatelessVideoDecoder vs a software fallback like Dav1dVideoDecoder). chrome://gpu → "Video Decoding" section will say whether AV1 V4L2 is registered at all. Between Chromium 146 and 148 the codec-profile gating changed a couple of times, and it's plausible my 148 build is missing an AV1 profile registration that 146 had.

If you can attach chrome://media-internals dumps (right-click → save as) from an AV1 playback attempt on both 146 and 148, I can diff them and see what regressed.

— Sav (dongioia @ beryllium.gr)

[warpme]

Guys,
re vp9 code in current published miniarch 7.0 kernel:

basing on #73

minimyth2/script/kernel/linux-7.0/files/3564-media-rockchip-rkvdec-vdpu381-add-vp9-support-v9.patch

Line 1243 in 570900f

+ regs->vp9_param.reg93.vp9_aref_ver_scale = vscale;

minimyth2/script/kernel/linux-7.0/files/3564-media-rockchip-rkvdec-vdpu381-add-vp9-support-v9.patch

Line 611 in 570900f

+#define RKVDEC_VP9_MAX_SEGMAP_SIZE 524288

is this ok?

[dongioia]

Yes, both lines are correct, Piotr. They match the upstream fix commits exactly:

• Line 611 (#define RKVDEC_VP9_MAX_SEGMAP_SIZE 524288) — matches the segmap size fix from 96fd7a39122b. The old value (73728) was only sufficient up to ~1440p; 524288 is 8K-safe.
• Line 1243 (regs->vp9_param.reg93.vp9_aref_ver_scale = vscale) — matches the altref vscale fix from the same commit. The original code had = hscale (copy-paste bug), which caused incorrect altref scaling whenever the altref frame had different dimensions than the current frame.

I also checked that reg103 in your patch only sets vp9_intra_only_flag and does not enable prob_update_en, refresh_en, or prob_save_en — which is correct. The VDPU381 VP9 backend uses software probability updates (computed in done()), and enabling the HW prob engine without allocating the HW prob buffers causes IOMMU page faults at address 0x0 (that is the third fix, from f075bba09e7c, which your patch is already compatible with).

So your v9 patch carries all three critical VP9 fixes.

Given that, @JFLim1's artifacts at every resolution on Orange Pi 5 Plus with the same patch are probably something else. The quickest triage is mpv --hwdec=v4l2request <vp9_file>:

• If mpv artifacts too → something hardware/DTB-specific to Orange Pi 5 Plus (different PMIC / VDD_VDPU rails vs Rock 5B+ with otherwise identical RK3588).
• If mpv is clean → the problem is only in the Chromium V4L2 pipeline, not in the kernel.

Worth checking before digging deeper.

— Sav (dongioia @ beryllium.gr)

[warpme]

BTW: i'm rutinelly testing my every released kernel with mythtv for all major codecs (mpeg2, h264, hevc, vp8, vp9), resolutions (576p, 720p, 1080p, 4k) and refesh rates (23.97, 24, 25, 59.9, 60) on my mythtv distro.
in my case current 7.0 plays all as expected...

[JFLim1]

Chromium-146-media-internals.txt
Chromium-148-media-internals.txt

Chromium-146-media-internals.txt

• mpv --hwdec=v4l2request <vp9_file> — if mpv also shows the same artifacts, it's the kernel decoder, conclusively. On a patched kernel, mpv plays VP9 cleanly at all resolutions.

Hi @dongioia,
Sorry for the delayed response. The mpv-v4l2request and ffmpeg-v4l2request that I have does NOT seems to support 10Bit Video or HDR videos. With MiniArch kernel 7.0 it mpv does stream/play vp9, hevc and av1 videos

[alarm@opi5plus ~]$ mpv '/run/media/alarm/writable/home/jfl/Videos/Big_Buck_Bunny_1080_10s_30MB.webm' 
● Video  --vid=1  (vp9 1920x1080 30 fps) [default]
File tags:
 Artist: Blender Foundation 2008, Janus Bager Kristensen 2013
 Comment: Creative Commons Attribution 3.0 - http://bbb3d.renderfarming.net
 Composer: Sacha Goedegebure
 Genre: Animation
 Title: Big Buck Bunny, Sunflower version
Using hardware decoding (v4l2request).
VO: [gpu-next] 1920x1080 drm_prime[nv12]
V: 00:00:09 / 00:00:10 (99%) Dropped: 4
Exiting... (End of file)
[alarm@opi5plus ~]$ mpv https://www.youtube.com/watch?v=aqz-KE-bpKQ
● Video  --vid=1  --vlang=eng  (vp9 3840x2160 60 fps) [default]
● Audio  --aid=1               (aac 6ch 48000 Hz 387 kbps) [default]
File tags:
 Date: 20141110
 Uploader: Blender
 Channel_URL: https://www.youtube.com/channel/UCSMOQeBJ2RAnuFungnQOxLg
Using hardware decoding (v4l2request).
AO: [pipewire] 48000Hz 5.1 6ch floatp
VO: [gpu-next] 3840x2160 drm_prime[nv12]
AV: 00:00:10 / 00:10:34 (2%) A-V:  0.000 Cache: 4.2s/14MB
Exiting... (Quit)
[alarm@opi5plus ~]$ mpv https://lafibre.info/videos/test/201411_blender_big_buck_bunny_60fps_2160p_av1.mp4
● Video  --vid=1  (av1 3840x2160 60 fps) [default]
● Audio  --aid=1  (opus 2ch 48000 Hz 99 kbps) [default]
File tags:
 Artist: CC-BY Fondation Blender
 Album: https://LaFibre.info Vivien GUEANT
 Date: 2022
 Genre: Court métrage d'animation néerlandais
 Title: Big Buck Bunny, 10min00sec version
AO: [pipewire] 48000Hz stereo 2ch floatp
Using hardware decoding (v4l2request).
VO: [gpu-next] 3840x2160 drm_prime[nv12]

AV: 00:00:08 / 00:10:00 (1%) A-V:  0.000 Dropped: 59 Cache: 2.9s/1MB
Exiting... (Quit)
[alarm@opi5plus ~]$ mpv https://lafibre.info/videos/test/201411_blender_big_buck_bunny_60fps_1080p_av1.mp4
● Video  --vid=1  (av1 1920x1080 60 fps) [default]
● Audio  --aid=1  (opus 2ch 48000 Hz 99 kbps) [default]
File tags:
 Artist: CC-BY Fondation Blender
 Album: https://LaFibre.info Vivien GUEANT
 Date: 2022
 Genre: Court métrage d'animation néerlandais
 Title: Big Buck Bunny, 10min00sec version
AO: [pipewire] 48000Hz stereo 2ch floatp
Using hardware decoding (v4l2request).
VO: [gpu-next] 1920x1080 drm_prime[nv12]
AV: 00:00:07 / 00:10:00 (1%) A-V:  0.000 Cache: 28s/6MB
Exiting... (Quit)
[alarm@opi5plus ~]$ 

Just that on Chromium-148 or Chromium-146 both stream vp9 videos with artifacts and green screen on all resolutions.

Chromium-148 av1 video no vpu hardware acceleration (Dav1dVideoDecoder)

Chromium-146 av1 video is vpu hardware accelerated.
"Selected V4L2VideoDecoder for video decoding, config: codec: av1, profile: av1 profile main, level: not available, alpha_mode: is_opaque, coded size: [3840,2160], visible rect: [0,0,3840,2160], natural size: [3840,2160], has extra data: true, encryption scheme: Unencrypted, rotation: 0°, flipped: 0, color space: {primaries:INVALID, transfer:INVALID, matrix:INVALID, range:INVALID}"

[dongioia]

Hi @JFLim1, thanks for the detailed report.

Quick clarification on your media-internals log: it only contains the AV1 test from lafibre.info/.../201411_blender_big_buck_bunny_60fps_2160p_av1.mp4, which falls back to Dav1dVideoDecoder (software). That's a separate AV1-on-Chromium-148 regression — the kernel exposes /dev/video5 = rockchip,rk3588-av1-vpu-dec but Chromium 148's decoder factory doesn't pick it up the way 146 did. I see the same on RK3588 (Rock 5B+).

For the VP9 issue you're tracking (artifacts even at 480p/720p/1080p), I don't see a VP9 player in your log. Could you share a media-internals dump captured during a VP9 YouTube playback (e.g. https://www.youtube.com/watch?v=aqz-KE-bpKQ, force VP9 via the Stats for Nerds overlay)? Plus a chrome://gpu save — specifically the "Video Acceleration Information" section.

On my side (Rock 5B+, kernel 7.0.0+ with VP9 VDPU381 patches, Hyprland/Wayland), the chromium-v4l2-148 build reports kVideoDecoderName: V4L2VideoDecoder, kIsPlatformVideoDecoder: True for VP9 at all resolutions:

• 1080p: HW decode, clean
• 1440p / 2160p: HW decode, but ANGLE NV12 DMA-BUF artifacts above 2048px (this is the issue tracked at https://issues.chromium.org/issues/503755157, kernel/driver are not at fault — mpv --hwdec=v4l2request plays the same files cleanly).

Your error

'--ozone-platform=wayland' is not compatible with Vulkan
vkCreateInstance() failed: -9
Failed to create and initialize Vulkan implementation.

suggests Chromium picked the Wayland ozone backend (Gnome 50.1 + Wayland session probably). The Vulkan failure itself doesn't break VP9 V4L2 decode (I get the same warning under Hyprland/Wayland and VP9 still HW-decodes). So that's not the root cause of the 480p artifacts you see — but please double-check that you're not passing --ozone-platform=wayland (force) or --use-gl=egl directly. Both break decoder selection on this build.

I launch chromium with these arguments:

#!/bin/bash
export CHROME_DEVEL_SANDBOX=/opt/chromium-v4l2/chrome_sandbox
exec /opt/chromium-v4l2/chrome \
  --enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL \
  --enable-gpu-rasterization \
  --enable-zero-copy \
  --ozone-platform-hint=auto \
  --ignore-gpu-blocklist \
  "$@"

Note the -hint=auto, not -platform=wayland. It lets Chromium pick X11 or Wayland based on the session. Avoid passing --use-gl=... or --use-angle=... — defaults are correct on this binary.

If after using exactly this launcher you still see VP9 artifacts at ≤1080p (I don't), please share:

1. chrome://gpu saved → "Video Acceleration Information" + "Driver Information" sections
2. media-internals during VP9 playback → kVideoDecoderName + kIsPlatformVideoDecoder
3. v4l2-ctl --device=/dev/video0 --info and v4l2-ctl --device=/dev/video0 --list-formats-out

That'll tell whether on your OPi5+ the kernel is exposing VP9F properly at the V4L2 layer or if Chromium is falling back to libvpx software with the wrong feature flags being applied.

[JFLim1]

VP9-media-internals.txt

Hi @dongioia,
Thanks.
Changed to "--ozone-platform-hint=auto " and the issue with vp9 video persists.

chrome://gpu saved → "Video Acceleration Information" + "Driver Information" sections

media-internals during VP9 playback → kVideoDecoderName + kIsPlatformVideoDecoder
VP9-media-internals.txt

v4l2-ctl --device=/dev/video0 --info
[alarm@opi5plus ~]$ v4l2-ctl --device=/dev/video0 --info

Driver Info:
	Driver name      : hantro-vpu
	Card type        : rockchip,rk3568-vpu-dec
	Bus info         : platform:fdb50000.video-codec
	Driver version   : 7.0.0
	Capabilities     : 0x84204000
		Video Memory-to-Memory Multiplanar
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04204000
		Video Memory-to-Memory Multiplanar
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : hantro-vpu
	Model            : hantro-vpu
	Serial           : 
	Bus info         : platform:fdb50000.video-codec
	Media version    : 7.0.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 7.0.0
Interface Info:
	ID               : 0x0300000c
	Type             : V4L Video
Entity Info:
	ID               : 0x00000001 (1)
	Name             : rockchip,rk3568-vpu-dec-source
	Function         : V4L2 I/O
	Pad 0x01000002   : 0: Source
	  Link 0x02000008: to remote pad 0x1000004 of entity 'rockchip,rk3568-vpu-dec-proc' (Video Decoder): Data, Enabled, Immutable
[alarm@opi5plus ~]$

[VP9-media-internals.txt](https://github.com/user-attachments/files/27094310/VP9-media-internals.txt)

[dongioia]

Hi @JFLim1, your media-internals + the mpv v4l2request 4K clean playback already prove two things:

1. Chromium is picking V4L2VideoDecoder for VP9 at all resolutions (HW path is selected correctly).
2. The kernel decoder on your MiniArch 7.0.0 is good (mpv renders VP9 4K cleanly via --hwdec=v4l2request → vscale/segmap/vb2_is_busy fixes are all in).

So the artifacts live entirely in the Chromium GL/compositor path, and we're running the same Chromium binary. The remaining differences vs my Rock 5B+ setup are:

• Mesa/Panfrost version — strongest suspect. The GBM NV12 second-plane offset bug (Mesa #9952, fixed in 23.3) produces green/garbled chroma at every resolution. If MiniArch's Mesa is older than that, you'd see exactly your symptom while mpv's gpu-next+drmprime path bypasses GBM entirely and stays clean.
• Compositor: Gnome 50.1 / Mutter (Wayland) vs my Hyprland. Mutter handles imported NV12 DMA-BUFs differently and has hit similar regressions before.

Two concrete diagnostics:

1) Mesa version
```bash
glxinfo -B 2>/dev/null | grep -E "Mesa|OpenGL renderer"
eglinfo 2>/dev/null | grep -E "EGL_VERSION|Mesa" | head
pacman -Q mesa libdrm 2>/dev/null # MiniArch is Arch-based
```
If Mesa is <23.3 → please update; that alone may fix it.

2) Bypass Mutter — force X11 session

Log into a GNOME-on-Xorg session (or just run Chromium with `--ozone-platform=x11`):
```bash
chromium-v4l2 --ozone-platform=x11 \
--enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL \
--enable-gpu-rasterization --enable-zero-copy --ignore-gpu-blocklist \
'https://www.youtube.com/watch?v=aqz-KE-bpKQ'
```

• Clean under X11 → it's Mutter-Wayland's NV12 import path.
• Still corrupted under X11 → it's Mesa/ANGLE-side, regardless of compositor.

Also, if you can capture stderr during a VP9 playback under your normal Wayland session:
```bash
chromium-v4l2 --enable-logging=stderr --v=1 \
--ozone-platform-hint=auto --ignore-gpu-blocklist \
'https://www.youtube.com/watch?v=aqz-KE-bpKQ' 2>&1 | tee chromium-vp9.log
```
and grep the result for `LibYUV`, `Failed to map`, `EGL_BAD_PARAMETER`, `gbm_bo_get`, `ImageProcessor`, `dmabuf` — those keywords usually nail the exact failure point.

(Side note for the device list: `/dev/video0 = hantro-vpu` on RK3588 hosts the legacy codecs only; VP9 goes through `rkvdec` on a different `/dev/videoN`. Loop `for d in /dev/video*; do v4l2-ctl --device=$d --info; done` to find it — but given mpv works, that's not where the bug is, just FYI for future debugging.)

[JFLim1]

chromium-vp9.log

1. Mesa version

MiniArch-EOS which is basically archlinuxarm is already on Mesa 26.0.5-arch1.1

OpenGL vendor string: Mesa
OpenGL renderer string: Mali-G610 MC4 (Panfrost)
OpenGL core profile version string: 3.1 Mesa 26.0.5-arch1.1

2. Bypass Mutter — force X11 session

Am on Gnome-50.1, not sure xorg X11-session has been installed or available.

Will launch Chromium in X11 and report back.
No difference, still vp9 video stream with visual artifacts.
chromium-vp9.log

Side note for the device list: /dev/video0 = hantro-vpu on RK3588 hosts the legacy codecs only; VP9 goes through rkvdec

This is MiniArch Kernel issue as far I can tell, depending on boot up sometime "Hantro" driver is on top and other time "rkvdec" is on top. Example on this boot up "rkvdec" is on top. Have raise this issue before. warpme/miniarch#97

[alarm@opi5plus ~]$ v4l2-ctl --device=/dev/video0 --info
Driver Info:
Driver name : rockchip-rga
Card type : rockchip-rga
Bus info : platform:rga
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
[alarm@opi5plus ~]$

[JFLim1]

On this boot up, MiniArch-EOS kernel-7.0 boot up with "rkvdec" first over "hantro". But other times it boot up with "hantro" first over "rkvdec". Random (but so far more likely to hantro first).

[alarm@opi5plus ~]$ for d in /dev/video*; do v4l2-ctl --device=$d --info; done
Driver Info:
Driver name : rockchip-rga
Card type : rockchip-rga
Bus info : platform:rga
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Driver Info:
Driver name : rkvdec
Card type : rkvdec
Bus info : platform:rkvdec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : rkvdec
Model : rkvdec
Serial :
Bus info : platform:rkvdec
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : rkvdec-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000004 of entity 'rkvdec-proc' (Video Decoder): Data, Enabled, Immutable
Driver Info:
Driver name : hantro-vpu
Card type : rockchip,rk3568-vpu-dec
Bus info : platform:fdb50000.video-codec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : hantro-vpu
Model : hantro-vpu
Serial :
Bus info : platform:fdb50000.video-codec
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : rockchip,rk3568-vpu-dec-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000004 of entity 'rockchip,rk3568-vpu-dec-proc' (Video Decoder): Data, Enabled, Immutable
Driver Info:
Driver name : hantro-vpu
Card type : rockchip,rk3588-vepu121-enc
Bus info : platform:fdba0000.video-codec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : hantro-vpu
Model : hantro-vpu
Serial :
Bus info : platform:fdba0000.video-codec
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : rockchip,rk3588-vepu121-enc-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000004 of entity 'rockchip,rk3588-vepu121-enc-proc' (Video Encoder): Data, Enabled, Immutable
Driver Info:
Driver name : hantro-vpu
Card type : rockchip,rk3588-av1-vpu-dec
Bus info : platform:fdc70000.video-codec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : hantro-vpu
Model : hantro-vpu
Serial :
Bus info : platform:fdc70000.video-codec
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : rockchip,rk3588-av1-vpu-dec-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000004 of entity 'rockchip,rk3588-av1-vpu-dec-proc' (Video Decoder): Data, Enabled, Immutable
Driver Info:
Driver name : rkvdec
Card type : rkvdec
Bus info : platform:rkvdec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : rkvdec
Model : rkvdec
Serial :
Bus info : platform:rkvdec
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : rkvdec-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000004 of entity 'rkvdec-proc' (Video Decoder): Data, Enabled, Immutable
Driver Info:
Driver name : hantro-vpu
Card type : rockchip,rk3568-vpu-dec
Bus info : platform:fdb50000.video-codec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : hantro-vpu
Model : hantro-vpu
Serial :
Bus info : platform:fdb50000.video-codec
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : rockchip,rk3568-vpu-dec-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000004 of entity 'rockchip,rk3568-vpu-dec-proc' (Video Decoder): Data, Enabled, Immutable
Driver Info:
Driver name : hantro-vpu
Card type : rockchip,rk3588-av1-vpu-dec
Bus info : platform:fdc70000.video-codec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : hantro-vpu
Model : hantro-vpu
Serial :
Bus info : platform:fdc70000.video-codec
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : rockchip,rk3588-av1-vpu-dec-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000004 of entity 'rockchip,rk3588-av1-vpu-dec-proc' (Video Decoder): Data, Enabled, Immutable
[alarm@opi5plus ~]$