Posts by diederik

Quote from diederik

Quartz64-B (RK3566):

• BBB 4K: Several display issues like hickups ... and then a black screen (again/still) with rk_iommu page faults.
  vop2_isr ~386K callbacks suppressed
  [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
  rkvdev fdf80200.video-codec: Frame processing timed out!
  last msg was printed only once, the others MANY times
  No return to visible list of files when stopping playback; reboot was only remedy

Earlier today a patch was posted with mentioned POST_BUF_EMPTY:
[PATCH] drm/rockchip: vop2: Scale the AXI clock to the bandwidth the mode needs - Igor Paunovic

No idea if it can help with that, but figured I'd mention it.

Quote from atirage21

Radxa rock 5b+ have feature for booting from nvme through spi boot.

Rockchip SoCs can boot from SPI, eMMC and SDcard (in that order).

From there it can load the rest of the system from (f.e.) NVMe.

Booting from SPI/eMMC/SDcard to NVMe should/could work for any Rockchip SoC. It may be that you need to have some options enabled in U-Boot though. I don't know which those are and whether they are enabled.

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):

• LE Add-ons gave error msg "Could not connect to repo" (too old image?)
• BBB 1080p: AVC or HEVC including 10-bit -> perfect
• BBB 4K: almost perfect, just a couple of minor display problems ('shocks')
• 'Costa Rica' 4K: 8-bit -> works reasonably, including HDR, but also several 'shocks'
  10-bit: quite a lot of artifacts, including green lines
  Probably expected as those files are likely encoded above the RK3328's specs
• Jellyfin: AVC/HEVC-8bit/HEVC-10bit @30M all played fine
• Bo Burnham and Elementary: subtitles didn't work and several artifacts on 10-bit variants; 8-bit was quite a bit better

RockPro64 (RK3399):

• On bootup, my TV (I think) reported "Invalid format" ?!? That also happened on my own Sway system (with 6.19-rc7+media-patches kernel). On LE the display seemed fine afterwards, but on my own system, the right ~1/3th of the screen had some white/gray 'overlay', obscuring most of what would be shown there.
  EDIT: The "Invalid format" message seems related to U-Boot stored on the eMMC (ie my U-Boot). After removing the eMMC (LE is on a SDcard), I did NOT get the "Invalid format" message.
• LE Add-ons gave error msg "Could not connect to repo"
• HDMI audio did NOT work on LE ... but did work on my own Sway system, but not exactly flawless either. I did not test analog audio with LE, but it hasn't been working on my own system for quite a while. Apparently known to several people ...
  Several errors reported in dmesg wrt audio on my own system (for quite a while); didn't check on LE.
  FTR: The HDMI cable is not a/the problem as it works/worked fine with all my other tests
  EDIT: This too is related to my U-Boot version on eMMC. The one provided with LE works fine and I do get HDMI audio.
• Tried BT audio which technically worked, but audio was delayed by 1-2 secs and of very poor quality. May be caused by the WiFi+BT adapter though? (I have nothing to compare its performance with yet)
  EDIT: Removing the eMMC did NOT improve the BT 'performance'.
• 'Costa Rica' 4K: pretty good including HDR, but small 'shocks'. It seems my HEVC 10-bit variant played perfectly \o/
• Jellyfin: AVC/HEVC-8bit/HEVC-10bit @30M all played fine (AV1 in 'slow motion' though)
• Bo Burnham and Elementary: subtitles worked, but sometimes resulted in minor artifacts ... but only with 10-bit files. The 8-bit variants played without artifacts

Quartz64-B (RK3566):

• LE Add-ons worked just fine (installed System Tools successfully)
• BBB 1080p: AVC or HEVC including 10-bit -> perfect
• BBB 4K: Several display issues like hickups ... and then a black screen (again/still) with rk_iommu page faults.
  vop2_isr ~386K callbacks suppressed
  [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
  rkvdev fdf80200.video-codec: Frame processing timed out!
  last msg was printed only once, the others MANY times
  No return to visible list of files when stopping playback; reboot was only remedy
• Jellyfin: All played fine, but no playback (at all) with AV1 (I know HWDEC doesn't support AV1 on RK3568) ... but LE still indicated it was playing 'something'
• Elementary: Subtitles worked on 8-bit file ... but also resulted in black screen. Looks like subtitles cause the problem as without it, it played fine.

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.

Quote from diederik

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.

Quote from chewitt

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

Quote from diederik

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.

Quote from diederik

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.

Quote from diederik

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:

1. Device Tree 101 - 1080p x264
2. Big Buck Bunny (BBB) - 1080p x264
3. BBB - 1080p x265 10-bit (re-encoding of 2)
4. BBB - 2160p x264
5. Bo Burnham - Can't Handle This - 1080p x264
6. Bo Burnham - Kill yourself - 1280x640 x264 10-bit
7. Bo Burnham - White W0man's Instagram - 1080p x264 *
8. Elementary S01E01 - 1280x720 x265 10-bit

*) 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

Quote from chewitt

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.

Quote from ADKM

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

Quote

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)