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

[Simon Wright]

Hi Detlev,

> We do not have documentation for this decoder, but could you check
> your decoder version ? It is store in register 0 and I get 0x38321746.

readl(0x27b00100) reads 0x38321746 on both my RK3576 boards:

  NanoPi R76S (FriendlyElec):  0x38321746
  ArmSoM Sige5:                0x38321746
  Radxa Rock 4D (yours):       0x38321746

Same silicon revision across three different vendors' boards.

> What I don't have is a test showing that the hardware behaves
> properly with the vendor driver.
> Is that something you could try on the NanoPi ?

Done.  The R76S has the FriendlyElec BSP on eMMC, so I booted from
eMMC (kernel 6.1.141, MPP c1f1c12d 2025-09-30) and ran
mpi_dec_test on long.h264 (1920x1080 H.264, openh264enc SMPTE bars).
Then rebooted the same board from SD into Armbian 7.0.1-edge-rockchip64
and ran the same file through v4l2slh264dec.

(Armbian's build of Linux 7.0.x carries one unrelated rkvdec.c patch
that removes a vb2_is_busy check in rkvdec_s_ctrl; rkvdec-vdpu383-h264.c
is byte-identical to torvalds/linux master.)

10 frames of NV12 vs an avdec_h264 SW reference:

  Board         Kernel + driver               Frame 0 diff
  R76S          6.1.141 vendor MPP            0 / 3,110,400 (MATCH)
  R76S          7.0.1   rkvdec-vdpu383-h264   732,094 (23.54%)
  Sige5         7.0.6   rkvdec-vdpu383-h264   639,721 (20.57%)

Same chip, same NanoPi board, same input, same SW reference.  Vendor
MPP produces bit-exact correct output on all 10 frames (0 differences
on every P-frame too); the upstream driver corrupts every frame.  The
Sige5 line is a different vendor's PCB on a slightly newer Armbian
point release running the same upstream driver, included to rule out
a NanoPi board-specific issue.

> The other report also mentioned that the issue was happening 10%
> of the time, but you seem to see it every time, could be nothing
> though.

100% here.  Every frame, every test stream, multiple input sources
(openh264enc, x264, NVENC, QSV), two independent V4L2 userspace
implementations (GStreamer 1.28.2 v4l2slh264dec and a hand-written
Rust submitter).  Rows 4 and 12 mod 16 are fully corrupted every
run.  The exact percentage drifts (20.3% in the original report,
20.57% on Sige5 today, 23.54% on R76S today) because freshly-
generated streams have different intra-prediction modes, but the
rows-4/12-mod-16 pattern is invariant.

I can host the long.h264 + sw_ref.nv12 + hw_bsp.nv12 +
hw_mainline.nv12 bundle (~115 MB) on a public URL if it would
help your reproduction.  Also happy to dump more registers,
instrument the driver, or test patches you'd like me to try.

Regards,
Simon