LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    I tried the (awesome) build on my Radxa Rock 5 ITX board. Install was flawless... Overall performance is pretty nice. On my 4K TV set - the GUI runs buttery smooth (at 4K60!)...

    However, I noticed some wonky things, besides the known ones (no passthrough, no HDR)...

    - Audio drops out irregularly while watching (48khz and 192khz content)

    - 192KHz Audio is not played "cleanly" - you can hear a popping/hissing/clicking

    - Dropped frames even though the video is decoded via hardware - is there something I can do about or is this known?

    - Video HDMI timings are odd - the OSD of my AVR (Marantz Cinema 70) is not shown - I only had this with a pc where I altered HDMI timings... - Running ARMbian (with vendor kernel and closed source Mali Valhall or open source panfrost driver) the OSD is shown perfectly


    If needed, I can send the sample file that I use(d) for testing audio things (it has different audio tracks, stereo, 5.1, 7.1, 16bit, 24bit, 48khz,192khz)

    Question:

    hw decoding of h264 and HEVC work fine - so are the hw decoding bits from here - that are sent upstream (https://gitlab.collabora.com/hardware-enabl…nline-status.md) already in there?


    thanks!

    I've noticed occasional audio dropouts during movies, but there are no traces of anything in Kodi or ffmpeg logs and the event is not reproducable, e.g. rewind media and the event does not reoccur at the same point. I have no idea how to reproduce or debug this so it's something I need to flag to upstream devs. I have a hunch (based on similar issues with Amlogic hardware) that this is related to unstable clocks, but I have no way to prove that and I have low expectations of an easy find or fix.

    I've not experimented much with 192KHz audio. If you have some structured test media that you can share, send me a download link; email to chewitt@ our domain or Kodi domain.

    I've not seen dropped frames in videos other than some known-bad test media with exotic/problem encodings, but playback is sensitive to using correct modes so I would strongly advise everyone to use adjust-refresh and the general config outlined in this wiki article: https://wiki.libreelec.tv/configuration/4k-hdr

    The kernel DRM layer is using HDMI 2.0/2.1 mode timings which are standards and both LE and Armbian are broadly using the same versions of mesa/panfrost, although this is only relevant for rendering the Kodi GUI an has nothing to do with HDMI modes and DRM connector timings. The one possible difference between LE and Armbian is that I have a bunch of in-flight patch series that enable deep-colour and HDMI 2.1 capabilities in the kernel and Armbian probably doesn't. That's all going to be merged upstream at some point though, and it's still the AVR's responsibility to generate its own OSD and overlay this onto the HDMI signal sent to the TV so if it can pass HDMI video/audio but not show its own OSD that sounds like an AVR bug. FWIW, the OSD of my 2018-ish Marantz AVR shows up fine on the rare occasions I display it.

    There are lots of in-flight patch series required for the image. All current hardware decode ones are included.

    Quote from chewitt

    Papaya5595 I've updated the RK3588 images in my test share to include newer iwlwifi firmware.

    Thanks for the quick response. The new image no longer outputs video to my display but instead repeatedly flashes "HDMI 1 No Signal" which I interpret as difficulty completing a handshake.

    Also noticed that the naming convention for the new image changed from "LibreELEC-RK3588.aarch64-12.90.1-rock-5b.img.gz" to "LibreELEC-ARMv8.aarch64-12.90.1-rock-5b.img.gz".

    I updated https://chewitt.libreelec.tv/testing/LibreE…-rock-5b.img.gz first before starting some work on an ARMv8 image that might become the future of support. We build too many images that are essentially the same aside for some compile time optimisation that doesn't make a huge different to performance. Consolidating to a single image will save a ton of CI time when building nightlies and releases.

    Add video=HDMI-A-1:1920x1080M@60D to kernel boot params in extlinux.conf and see if that helps?