[BUG] rkvdec-vdpu383-h264: wrong pixels at horizontal de-blocking edges y=4 and y=12

[Piotr Oniszczuk]

Simon, pls see inline

> Wiadomość napisana przez Simon Wright <Simon at symple.nz> w dniu 10 cze 2026, o godz. 00:14:
> 
> 
>    git clone https://github.com/SympleNZ/rkvdec-vdpu383-vp9
>    cd rkvdec-vdpu383-vp9
>    # against your running kernel's headers/source:
>    KBUILD_MODPOST_WARN=1 make -C /lib/modules/$(uname -r)/build M=$PWD/src modules
> 
>    sudo rmmod rockchip_vdec 2>/dev/null    # unload the in-tree driver
>    sudo insmod src/rockchip-vdec.ko        # warmup is default-on, no params needed
> 

Many thx for detailed hints.

I decided to go with alternative path: I incorporated Your code directly into in-tree on 7.1 mainline, recompiled and give test run on rock4d.  
I think I'm getting Your code running as in dmesg I see: https://gist.github.com/warpme/51bce9532baa37ccb59e1c69a5c2ef43

Unfortunately mine rk3576 h264 issues still happens (approx 5-40% failure rate; only on 3576; only on h264) 
Visually issue is like this: https://ibb.co/gZT6vMZD

Interesting is: mine issue symptoms are imho similar to yours:
1. approx. 5-20% failure rate (but varies per board)
2. only on 3576
3. only on h264

Ad1: some boards have quite low rate: nanopi is few % while rock4d is really high (20-40%)

Ad2: i have single appliance image for >40 boards and only 3576 has this issue

Ad3: on 3576 issue happens only on h264. HEVC, vp9, etc are ok. 


> (If rockchip-vdec is built into your kernel rather than a module, you'll need it as
> a module - or blacklisted - first. The module name may differ slightly on your
> build.)
> 
> Then decode your H.264 as usual (v4l2slh264dec) and compare against avdec_h264 - the
> rows-4/12 corruption should be gone. That repo is the VP9 work, but its src/ builds
> the full VDPU381/383 H.264/H.265/VP9/AV1 driver, so H.264 is included.

Should I collect stats on mine hw or rather maybe I should test the solution (when we will have it)?  

> 
> One honest caveat for the media-player use case: the warmup fixes correctness (the
> wrong pixels), not throughput - and the throughput limit isn't specific to H.264.

Indeed - I see also issue with throughput on 3576.
Iirc 3588 can go with 300mbps samples while 3576 starts to drop on 13...15mbps