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

[Detlev Casanova]

Hi Simon,

On 5/20/26 02:45, Simon Wright wrote:
> 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.
Good, that's one thing less to worry about.
>> 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.
I also have an Armsom Sige5, on which I can't reproduce this either.
But it is a good thing that the vendor driver is not affected, it also 
rules out hardware issues.
>> 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.
It could help to use the same input file as you (maybe different version 
of encoders generate different files).
But the output files won't be needed.

Another thing that could be helpful is information about BL31.
Which version are you using ?
Can you share the bootloader binary you use on the Sige5 ?
Is the vendor image booted with the same bootloader as the upstream one ?

 From the serial, on my sige5, I get:

INFO:    Preloader serial: 0
NOTICE:  BL31: v2.3():v2.3-859-gc481e5368:derrick.huang, fwver: v1.14
NOTICE:  BL31: Built : 09:37:28, Nov  8 2024
INFO:    ext 32k is detected
INFO:    SOC (0x35760101)
INFO:    spec: 0x1
INFO:    soc cold boot
INFO:    ARM GICv2 driver initialized
INFO:    bypass memory repair

Regards,
Detlev.