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

    Quote from diederik

    Dunno if that is in some way relevant for LibreELEC, but it may provide a clue

    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. I'm not familiar with mpv config options but I'd guess --vo=dmabuf-wayland forces the correct output buffer format (that the compositor expects) for that to work.

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

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

    LE has some patches for v4l2_request and v4l2_m2m support. We cannot upstream them to Kodi because they depend upon the corresponding set of patches for ffmpeg that are also not upstream. Once the ffmpeg patches get merged and the ABI becomes defined, we'll be able to finalise the Kodi patches and get them merged.

    The issues with Jellyfin files were related to selecting the correct plane supporting 10-bit pixfmt. This is currently done with some simple patches applied to RK images only as Kodi lacks proper logic for plane selection and plane ordering. If you run Kodi under Wayland, the compositor handles this for you, but for GBM use Kodi needs to have its own similar logic.

    Good evening chewitt, I'm trying to install your LibreElec image on the eMMC of the Orange Pi 3b and when I try to boot it doesn't work.

    The extlinux file does not have the dtb edited for this board and that is why it does not boot on the eMMc.

    Unfortunately, you can't edit the file here like you can on the SD card, so you'd have to edit the file inside the image so that everything is complete when burned.

    I would be very grateful if you could make this change.

    Regards

    This is how the file looks:

    and this is how it should be to be able to burn the image and boot directly into the eMMc:

    If extlinux is /FDTDIR the boot firmware auto-selects the correct device-tree to use whereas /FDT defines a specific device-tree to boot with. I'm not sure how the auto-select in u-boot works for Rockchip (I'd need to go look at current u-boot source) but I trust that Kwiboo knows/knew what he was doing when setting things up like that. To triage the problem you need to attach a UART cable to the board and capture the early boot messages.