Which one do you recommend:
I recommend you experiment and figure out if one of them boots with the device-tree file that Armbian are using. Then (most important) you keep quiet if there are any issues, because it's a hack. I'll happily pick support for any new boards to the patchset, but it's a hard requirement to see the patches on a mailing list first.
I did some testing on the PINE64 Quartz64 Model B (rk3566) with my standard set of test files:
Several days ago I checked chewitt's repo and didn't see any additions to the rk356x-base.dtsi (or sth like that), which I think means that rkvdec2 support doesn't work for devices like my Q64-B? That would explain the less then stellar results I got.
Initial support for RK356X, RK3576, and RK3588 has been merged!
I'll give it a few days for 'the internet' to self-build and point out obvious mistakes and then we'll get some nigthlies organised for the wider unsuspecting public to break their setups with 
chewitt I did make/try something for rk356x and I'm about to test whether (and to what extend) that works. Will let you know what comes of it.
In the mean time, I did a new test with the image build dd 20250911 on my Rock64 and while it was generally good, it did have some problems starting my BBB x265 videos (both 8-bit and 10-bit), so I booted again with debug logs enabled and played those 2 files and uploaded the compressed log to 'my share'.
When you go to 'my share' you'll notice that I renamed some files so x264/x265 and 8/10-bit is directly visible in the file name. And it also contains some new files, including 'bbb_sunflower_1080p_60fps_normal.x265.cf24.slow.8bit.mp4' which was one of those test files.
Several days ago I checked chewitt's repo and didn't see any additions to the rk356x-base.dtsi (or sth like that), which I think means that rkvdec2 support doesn't work for devices like my Q64-B? That would explain the less then stellar results I got.
Updated to chewitt's latest build on Q64-B and tried some of my test file while being ssh-ed into the device and running htop. Now I'm sure it doesn't do HW decoding on rk356x. So whether it seems to work or not, depends on the complexity (bitrate I guess) of the video file.
On the bright side, my tests on Q64-B (rk3566) and NanoPi R5S (rk3568) on my Debian system (with a whole bunch of patches) were quite successful \o/
Chewitt: I'll CC you on my test result post and on an RFC PATCH submission I'll do (soon (tm)).
