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)).
I've merged CI changes so LE13 nightlies should commence in the next 24-48h. There's a probability of boot issues with RK3576 as the Rock4D that I have boots and runs great .. for 30 seconds .. then the board stops responding.
There's also a Rock 3C gathering dust that needs to go into the test rotation so I can look for issues.
I'm not aware of any other issues, but ignorance is bliss 
chewitt
Could you please test the latest image on your RK3588 device?
RK3588S devices were able to boot on the latest image. (NanoPi R6C, NanoPi R6S, OrangePi 5, ROCK 5A, ROCK 5C)
But, RK3588 devices weren't able to boot. (ArmSom Sige7, OrangePi 5 Max, OrangePi 5 Plus)
In my RK3588 cases, it restarts on u-boot phase (OrangePi 5 Max, OrangePi 5 Plus) or it stops on u-boot phase (ArmSom Sige7).
I don't know what the cause is because I don't understand it well enough.
NB:
OrangePi 5 Max device with OrangePi 5 image was able to boot.
OrangePi 5 device with OrangePi 5 Max image wasn't able to boot.
- it restarts on u-boot phase.
So both image may had something difference or not.
Yasai-san please see https://github.com/LibreELEC/LibreELEC.tv/pull/10495 which the patch descriptions show also touches on some RK3588 boards. I pushed updated images to my share about 30 mins ago.
Thanks pushed.
But, these images were same result.
I'd wait nightly image coming and test them.
