So that kinda had me wondering what direction was better to look into "stateful or the newer stateless" and didn't want to go in a direction that was opposite to where everyone here is working towards.
Hardware IP is either stateless or stateful .. it's not a choice. Amlogic is stateful.
Kodi v19 is still in a pre-Alpha state, and that suits us just fine since there's still a ton of plumbing that we'd like to do for GBM/V4L2 support on ARM devices. So there will be an LE10, but not anytime soon, and we're not in a rush. The K19 add-on Python3 migration situation will also ensure lots of people will remain on K18 for a while yet anyway.
I've no idea which image Hummingboard might require, but LE10 pre-Alpha images for iMX6 are here: Index of / .. best to test on a clean SD card as iMX6 things are a little experimental and unmaintained.
The original Amlogic vdec work last year was done before a firm API was agreed and documented for stateful decoders, and the current stateful V4L2 code path in ffmpeg is based on that work. Since then the API was confirmed, and most of the vdec code has been reworked for it (HEVC is the main remaining one - it's also the most complex so has been deliberately left until last). Now ffmpeg needs to have the matching userspace work to align a few things around the confirmed specs. There are a bunch of things that need tweaking, but main thing that doesn't work right now is flushing/draining so we see hangs with seeking and when you reach the end of file (end of playback). Raspberry Pi needs the same/similar changes; RPi0-4 use the same stateful path for H264 and some other decoders in the original RPi IP, while H265 which is new IP added for RPi4 is stateless and uses the same code path Allwinner/Rockchip use (which is already in good shape). There are a couple of people who can do the work, but it's taking an eternity for other items to be cleared from their to-do list (mostly HDR related) so that fixing this is the top item.
frankviana 8726MX devices like the WeTek Play(1) aka WeTek OpenELEC box are Meson 6, not Meson 8. There is little mainline kernel support for that hardware generation and nobody I know of is working on mainline kernel support. I do not expect this to change.
Bubba2017 the above videos were filmed using an Odroid C1 (S805) and it will be a while before we make any attempt at public images for Meson 8. You can also expect issues with "M8 boxes" because there were probably 30+ different Chinese manufacturers simultaneously producing identical labelled boxes with slightly different hardware inside. Most of the hardware differences aren't a problem, but not all, so they will always be a bit of a lottery to support. I would expect any future official support/images for S802/S805/S812 to focus on a limited set of devices with public sources where we can go check what their legacy kernel has implemented.
Someone fat-fingered a filename. It has been corrected.
It would be best to ask on Freaktab or somewhere else that supports Android devices.
The AMLGX "box" image on Index of / is pre-Alpha LE10, but there is no newer 9.x release - we abandoned Amlogic legacy kernels and have devoted out time/attention to moving off old garbage code to the mainline Linux kernel.
WP1 aka WeTek OpenELEC box uses 8726MX.
WP2 uses an S905 chip and is well supported in the mainline kernel. There are currently some gremlins with playback and ffmpeg which cause issues with seeking and end-of-playback; otherwise the AMLGX "box" image available from Index of / can be used.
Movies are normally [email protected] not 4K@60 but yes, RPi4 can do this. HDR and High-Bitrate audio are technically possible in hardware but not currently implemented in software. All current development is focussed on the Kodi v19 codebase (will be LE10) so there is subzero likelihood of current LE 9.2 release ever gaining the features.
If you want more of that stuff today, you need to look at Intel NUC devices.
Zameero If you disable hardware decode in Kodi player settings you can probably watch all 1080p media without issues - the S912 has lots of CPU on hand and ffmpeg behaves when software decoding. For the sake of asking - which device tree file are you using?
The release manager fat-thumbed the filename that's served and it became 9.2.0 .. this has been corrected.
I need to acquire a box from somewhere for testing as I don't have any Meson 8 hardware.
because .. Meson 8* Lives! 
If you're running from SD card, perhaps try another SD card - they don't always last forever. If running from internal emmc, perhaps try running from an SD card - for the same reason. Otherwise I don't see anything obvious 
S905L is a cost-engineered version of S905X (no hardware VP9 decoder). There are no specific S905L device trees in the AMLGX image (check the official nightlies in Index of /) but S905X dtb's like meson-gxl-s905x-p212.dtb in the "box" SD card image might work.
If you do get something booted please run "dmesg | paste" and share the URL so I can see the SoC ID and other info.
Oleg is on an mission to ship a single "ARM" image that (multi)boots on Allwinner, Amlogic and Rockchip hardware. From a userspace perspective this not hard now that all three SoC plaforms are using lima/panfrost, but it requires some differences in the u-boot scripts and boot configuration. Other than this (once booted) his images should be much the same as official nightlies - he is normally using my Amlogic kernel patch-set as-is (he feeds me any changes he finds to send upstream so things are mostly in-sync) and Kodi things are based on LE master.
Playback should be smooth except for HEVC (software decode is beyond an S805X board, hardware decode for HEVC is still work in progress). If you attempt to seek you will see hangs and it's likely the end of playback might require a reboot. It is proving to be an epic quest to get someone interested in the changes the V4L2 stateful code path in ffmpeg needs to solve those things. Raspberry Pi is about to hit the same roadblock though, so that's probably the road to success for that quest.
The mainline kernel direct rendering manager subsystem (aka DRM, just to confuse) only has rudimentary support for HDCP on later Intel hardware, but nothing else so Amlogic, Rockchip etc. need to evolve "secure path" support before any further poking at widevine support. NB: the entire process of Widevine device certification is also designed to ensure it's legally impossible to use a common certificate accross many devices, even if it is technically possible.
I'm not sure if mali supported DVFS (dynamic re-clocking) of the GPU, but lima currently does not, so the GPU is allways running at full speed. I'm not sure if that's the issue or not, but there are patches on the mailing list to add DVFS support so it's being looked into. Again, no idea if that's the issue.
