I don't have the knowledge/skills to do that.
I (probably) should've left out that sentence. What I wanted to point out is that I don't understand why there is (completely) different behavior based on SoC (or board) ... which may indicate some bug in the kernel or somewhere else in the display pipeline. I don't have the knowledge/skills to do that either, but hopefully someone on the LE team does.
> AV1 isn't supported on the hardware
I know. But with RockPro64 it then tried CPU based decoding, which is exactly what I'd expect. Therefor on RockPro64 I did get normal video output, but as said in 'slow motion' (i.e. the CPU wasn't fast enough).
Displaying an error like "format not supported" (and then return to file list) would've made sense to me too.
What doesn't make sense to me is what it actually did.
I did some new tests and these are my findings:
Rock64 (RK3328):
RockPro64 (RK3399):
Quartz64-B (RK3566):
HTH
My message may not have come across correctly then? I think both Detlev's v8 as your patch set are ready to be merged.
There do need to come additional fixes ... somewhere (ffmpeg, mpv, RK356x SoC support, board support, etc) and possibly in multiple places. To make it even better!
To me the issues I found (only) with LibreELEC indicate some issue on the LE side? And thus not with Detlev's and your patch set. Otherwise I should've gotten the errors also outside LE ... which was not the case. OTOH, I also got the feeling that it worked better on LE because it did its (decoding) work better ... which in turn showed there were actual issues. Again, dunno where. But those can be worked on in subsequent patch series?
I actually tried both 8-bit and 10-bit ... and I thought HDR needed 10-bit? Both worked though.
chewitt Could you update the image for the following devices? Rock64, RockPro64, Quartz64-A, Quartz64-B, NanoPi R5S. Then I'll do my best to do a test run with them shortly.
Chewitt should have already seen it, but for completeness, I wrote a test report here:
Re: [PATCH v3 0/3] media: rockchip: rkvdec: add support for the VDPU346 variant - Diederik de Haas
I was a bit surprised that it was so easy to break it. My testing was only while connected to my 4K TV ... and maybe 4K input files also made it break faster?
That's next to a 4K HDR video file (sort of) working, which was surprising and really cool 
chewitt Could you update the image for the following devices? Rock64, RockPro64, Quartz64-A, Quartz64-B, NanoPi R5S. Then I'll do my best to do a test run with them shortly.
I realize it may not be strictly needed for non-RK356x devices, but I prefer to have them all in the (exact) same software state.
I'd expect Wayland to be using zero-copy rendering as this is supported by the DRM layer and Mesa on RK hardware. For zero-copy to work mpv needs to use DRMPRIME pixfmt so buffers contain a pointer to a frame (in DMA) not a decoded frame.
...
LE is not using mpv or Wayland, but Kodi and ffmpeg support both zero-copy (DRMPRIME) and normal (EGL) output. DRMPRIME is the default in all our ARM SoC images as it's more efficient, which is important for ARM SoC boards.
NB: I have no playback issues with any of your private test samples on newer RK boards (356X, 3576, 3588).
IIRC LE has some ffmpeg patches related to DRMPRIME which I may not have, so that could be a factor.
I knew LE wasn't using mpv or Wayland, but I thought you encountered some issues too with Jellyfin test files ... and those were gone for me too with that dmabuf-wayland parameter. In case there were still issues, it could've pointed to a possible solution and that's why I mentioned it.
But if there are no (more) issue with playback in LE, all the better 
chewitt On #linux-rockchip 'linkmauve' suggested to add '--vo=dmabuf-wayland' to my mpv parameters and that had a spectacular result:
No more frame drops in the BBB video 
and the problems I had with x265 files (all blue output) ... were solved too \o/
See https://libera.catirclogs.org/linux-rockchip/2025-10-06 (I saw you weren't online, hence this message)
Dunno if that is in some way relevant for LibreELEC, but it may provide a clue. Hopefully 
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)).
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.
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.
I did some testing on the PINE64 Quartz64 Model B (rk3566)
I also noticed that Bluetooth didn't seem to work. Which was kind of a relieve as it also doesn't work on my 'normal' (Debian) system.
The controller is there and it gives the impression that it (can) work ... but I've not been able to actually make a connection with anything.
I did some testing on the PINE64 Quartz64 Model B (rk3566) with my standard set of test files:
*) Mangled the title a bit as it contained a disallowed word ...
Test results:
1. Played, but starting took a while (possibly due to debug logging and its size (>1GB)?; without debugging it seemed to just play fine)
2. Played fine
3. Failed to start
4. Audio played, but picture 'refreshed' once per 30 secs or once per minute?
5. Played fine
6. Audio played, but no picture. The wait screen (kind of) flickered
7. Played fine
8. Failed to start, just wait screen. No screen flickering though
I uploaded a compressed debug log (both FFmpeg and 'Video' components enabled) to the location chewitt knows. It's 8.2MB compressed, but uncompressed it's 256MB
I've been running tests on an RK3576 Rock-4D board. The kernel codebase is still maturing in places but I think this will be a nice sweet-spot for LE use. The boards are less-featured than RK3588, which makes the boards cheaper, but the peripherals that have been omitted are all things that LE has no use for, while the media capabilites are essentially the same.
RK3576 actually has a better (or at least newer) multimedia capabilities (VOP3 for RK3576 vs VOP2 for RK3588). Not sure if the all the code to make use of it are upstreamed already though.
https://lore.kernel.org/all/1678323982…[email protected]/ is comparable/same as a part of the above referenced patch set and is sufficient to fix the alignment issue \o/
AFAICT it should become part of the 6.4 kernel.
From memory there was some issue at setup and things were done 'differently". Possibly a script of some kind was needed, but impossible to say for sure.
After reading the links I've been able to change directories and see various files including mountshares.sh and startup.log. I've not found any autostart.sh.
Permanent mount of Samba share fails may be of use and especially the link referenced there:
https://wiki.libreelec.tv/how-to/mount_network_share
Are these text files. Is there a way to view them ?
In Unix/Linux, everything is a file (unless it is a process).
You can view files in a number of ways: cat, less (quit with 'q') or nano (=text editor)
Look through the log files in .kodi/temp/ to see if you can find any hint as to why it is failing.
Generally, if you want help, you should provide WAY more info (in English) so people have something to go on. Right now it only says "it doesn't work", which is not useful for others to start with.
Info like 'used hardware'/'LE version' should be considered the bare minimum.
When errors occur, run pastekodi and share the URL that is printed which generally provides a LOT of information for people to go on.
HTH
but sorry I guess I never will support those platforms.
That's quite alright
why ?
look into nightly download directory and compare with your os-release.
on the first you'll see a lot of "sub-variants" (?, the part between git tag and .img.gz) for .eg. 3328, but no such sub-variants in your os-release.
Knowing that it's not automatically applicable to all devices, is useful to know.
I don't know a way to differentiate those sub-variants programmatically either.
and I feel I'm getting old, earlier ~18 h nonstop wasn't a theme. When I have bitten in a task it goes nonstop until tiredness isn't "fixable" with further caffeine and lastely realizing that I repeat the same programming mistake over and over again ...
One of the best and often underappreciated 'debugging' techniques, is taking a break/nap or plainly a good nights sleep
