Posts by wyup

    Hi, I got a replacement TV hat by Amazon, installed again but is undetected by default by dmsg on latest nightly.

    With dtoverlay=rpi-tv and gmem=128 on config.txt, after reboot, I get:

    LibreELEC:~ # dmesg | grep -i cx
    [    4.201132] dvbdev: DVB: registering new adapter (CXD2880)
    [    4.294171] cxd2880: cxd2880_attach: chip id invalid.
    [    4.294186] cxd2880_spi: cxd2880_spi_probe: cxd2880_attach failed

    I have other hats on the Pi, but wouldn't want to take off, since i want to use my spdif transport (it is a IanCanada transportPiDigi), I checked GPIO pins are not taken by means of a website and spidif hat documentation.

    Hello. KMS video acceleration and HDR passthrough is the heart of LibreElec. Is this code original and open source? Is it ever updated in features and maintained? I look at the nightly changelog but I don't find references. I see mesa driver updates.

    popcornmix says LE10/11/12 use the kms driver (kernel side). HiassofT says 4k60p uses direct-to-plane rendering.

    Is H264/H265 acceleration based on any existent library?

    For HDR10 passthrough, does it pass the content's mastering luminance along with maxcll and maxfall to a HDR10 layer for the HDMI display? Does LE check the display EDID luminance capability i.e. to ensure content is within it?

    refresh rate switching is essential if you want (micro-)stutter-free, smooth video playback

    Sorry, I had confused chewitt answer "refresh rate changing for optimal media playback" with kodi 'optimal' setting for variable refresh rate changing within a media file. Now I get it.

    Regarding DV: UHD Blu-Rays have a mandatory HDR10 base layer, so DV on these disc is an additional layer on top and RPi4/5 will output the HDR10 layer just fine - tested that here with 4k (DV) Blu-Ray rips I did on my own with makemkv.

    Regarding HDR10 mandatory compatibility layer on DV rip sources, yes it is there but on HDR displays with lower brightness than content's mastered luminance you need DV (or some kind of) tonemapping, otherwise highlights are blown-out, because HDR10 displays don't tonemap higher nits to their range, only DV does. However, my Samsung S95B tv is non DV and 1,000 nits capable and it can 'map' 10,000 HDR10 content correctly. But a Sony DV-enabled tv clips with 1,000 nits HDR10-only content, only DV content is shown correctly. So sending HDR10 compatibility layer is going to clip highlights on many tvs and monitors, since most of these won't reach content brightness.

    RPi4/5 certainly wouldn't have the grunt to process that - direct-to-plane rendering works fine for 4kp60 but GL/EGL rendering doesn't - it's too slow, even without shaders having to do tonemapping

    I understand a RPI4/5 may not have enough power for vulkan or opengl shader tonemapping, no question. Certainly HDR is not working on linux yet, and LE has the lead here. RPI OS Kodi package appears to use FullKMS open source driver and it has full 4k/HEVC acceleration. Maybe it's the same thing LE uses.

    I've read Wayland can live over KMS. Probably it's an additional layer to direct KMS and slow things up as you say.

    IIRC RPi 4/5 only support Vulkan under Wayland, and we do not run Kodi under Wayland because Wayland does not support refresh rate changing for optimal media playback. So yes FFMpeg added some support for DV but the devil is in the details and this is not a usable solution for our use-case. I'd also argue that using shaders is not "true" DV support; it's simply a way to get DV encumbered media to display with an acceptable (but not exact) on-screen appearance. True support requires knowledge of the proprietary stuff or a clean-room implementation. The former won't happen because it torpedo's Dolby's commercial model and the latter is rather unlikely since it will require a massive effort and the Linux community generally prefers to make a minimum acceptable effort when the target "standard" is vendor proprietary crap. I'll update/reword the wiki article a little to prevent further 2+2=5 conclusions.

    Okay, but nobody says it has to be a 'true' implementation of DV, if there is a good enough one that does Profile 5 conversion to HDR/PQ or SDR and reads side data, it is functional and compatible enough, it is interesting at least to discuss. We're not expecting a 'clean implementation' anywhere near. If the linux community has put an effort in developing this library, obviously they don't consider DV 'propietry crap'. We're talking that most HDR content is in DV, and there are platforms and displays that don't support (or license) it, be TVs (old and new), the most popular RPI or even Windows (Does Windows include free/licensed DV software decoding yet?). If LE is open source, based on ffmpeg and it might include this powerful library (not just for DV decoding, but GPU offloading, jinc upscaling), I think it is worth mentioning. I don't know how LE plays HDR, I read it does by V4L, DRM framebuffer, or KMS on low level programming (I'm not an expert and do not know exactly) and a tight ffmpeg integration.

    If you say RPI4/5 only support Vulkan under Wayland, okay I get it, although it doesn't mention this on building documentation: it only requires support for either opengl, vulkan or d3d11. I'm not sure DV decoding requires Vulkan.

    But talking about Wayland: RPi has got full working support of it on their official desktop distro. RPI has a Vulkan and OpenGL driver GPU. Open source Mpv player, manages HDR and SDR in Windows and Linux. Is there any talks to move from low level DRM processing to a standard Wayland protocol and display server/compositor without requiring a full desktop environment/window manager?

    You say "we do not run Kodi under Wayland because Wayland does not support refresh rate changing for optimal media playback", does it mean it is feasible? How many real content has refresh rate changing? I think some cell phones record video in minimal variable framerate, I don't know if this apply.

    Does Wayland expect support for HDR soon to begin with? (passing HDR metadata)

    I hope my rant is interesting for someone. It's meant for learning and discussing direction. Thanks for the support.

    It has to be conform to Dolby licensing conditions. If you find a legal hack, let us know.

    Libplacebo open source library, which is "provided by ffmpeg as a Vulkan-based video filter, does native support for Dolby Vision HDR, including Profile 5 conversion to HDR/PQ or SDR, reading DV side data, and reshaping. (BL only, currently"). RPi4 has Vulkan 1.2 and GL 3.0 compatibility.

    LE Wiki says:

    Kodi supports Dolby Vision under Android (if the device is licensed for it) but not Linux. Dolby requires manufacturers to license their Intellectual Property and use integration libraries to decode the HDR metadata. Until FFMpeg comes up with a "clean room" reverse engineered open-source implementation, Kodi will not support it.

    I guess this is an open source implementation that LE could use to decode Dolby Vision to HDR10.

    Who could implement it, Kodi or LibreElec?

    I think mpv player already does DV 'decoding' by dynamically tonemapping the HDR10 compatibility layer using open source ffmpeg libplacebo library and converting to SDR (or HDR10). I don't know how does LE tonemap HDR10 to SDR (static or dynamic), i just know by default it passes-through HDR10 and DV to the display.

    I own a Samsung S95B Oled tv and it doesn't decode DV, however I have played DV-L1 processed content into HDR10 and native HDR10 on a split-screen clip and it looks the same. Only DV-L2 trim has a colorist tweak to lift dark scene shadows a bit (dynamic metadata), but the player could do it as mpv does. Dolby Vision L1 basically tonemaps the content to the tv luminance range. My HDR10 tv does this on its own. It statically tonemaps out-of-range mastering luminance to its capacity, i.e: 10,000 nits to approx. native 1000 tv nits without clipping using a curve. In theory, as I've been told, a 'normal' HDR10 tv doesn't do it when it's out of its range, for this you'd need DV or HDR10+ , but my tv does it already.

    Dolby Vision is a locked platform. But a player, in this case LE could dynamically tonemap HDR10 content to its target display range. This is what mpv does. Mpv in Windows has access to the system's output display format. I don't know if LE can access the display HDR characteristics by HDMI/EDID.

    Mpv uses two algorithms, bt.2446a for HDR10->SDR, and st2094-40 for dynamic HDR10+ metadata (available or not). Then the gamma and colorspace conversion is done for the display output (P3, BT.1886...).

    Does RPI4 has the computational power for this? popcornmix says for 4k probably not.

    I watched this pull request to Libreelec:

    mpv-drmprime: update to 0.37.0

    mpv player uses ffmpeg libplacebo that ASAIK is capable of decoding Dolby Vision, default since 0.37.0, which requires Fmpeg 4.4 or newer and libplacebo 6.338.0 or newer. Decoding DV by LE would be a great asset, given that only Android OS set-top-boxes are licensed.

    How exactly is mpv-drmprime library used in Libreelec?

    I say so because mpv library opens up the possibility of dynamic tonemapping of Dolby Vision to HDR10 for non compatible displays (apart from SDR tonemapping), similar to HDFURY LLDV video processor. For example Samsung Tv can't decode Dolby Vision, but can play static HDR10.

    (*) Dolby Vision Single layer can use 0-1023 levels with IPTPQc2 instead of YCbCr - but I'm not sure how that interacts with HDMI LLDV interconnects. (And it's a non-issue for the Pi 4B)

    Any chance of LLDV decoding from Kodi on RPI4 (I read ffmpeg libplacebo can decode DV) and do HDR10 dynamic tonemapping like hdfury processor?

    My TV is a Samsung and it doesn't decode DV.

    I'd like to do a filesystem check/repair of libreelec's current partition with e2fsck or fsck, I try to read /etc/fstab but the file is empty.

    Sometimes in case of cold reboot I'd like to check that the filesystem is ok, because I store my media library on libreelec's partition.

    Hi, I've installed latest librespot (2023-05-14) kodi plugin, version 11.80.1.1 by awiouy (Anton Voyl) on latest kodi nightly on RPI4.

    The plugin works with default options, in my case backend alsa and device hw:2,0

    #librespot -d ? gives my device:

    Code
    iec958:CARD=sndrpihifiberry,DEV=0
    Description:
    snd_rpi_hifiberry_digi, HiFiBerry Digi+ Pro HiFi wm8804-spdif-0
    IEC958 (S/PDIF) Digital Audio Output
    Supported Format(s):
    S16 S24

    I have found you can enter certain unconfigured options, since some are preconfigured by the python scripts that load the daemon (there is no systemctl service any longer to manage as audiobobo pointed out). The python acripts that load the daemon are here:

    /storage/.kodi/addons/service.librespot

    By default, cache is disabled and bitrate is set at 320 by, as default soundcard selected by kodi config.

    You can enter extra options in the librespot kodi addon config interface, I entered -f S24 and it seems to work.


    Note: apart from this client addon, I have found another Kodi .zip wrapper manual plugin for Spotify. (https://github.com/jhjdekker98/plugin.audio.spotifyd-client), and it has a link for a armhf binary on https://github.com/Spotifyd/spotifyd/releases, but I haven't tried installing it since it requires Spotify Developer account settings and copying binaries to a specific path: /resources/lib/spotifyd/spotifyd. It is an alternative to the 'official' librespot kodi plugin, and it lets you customize all options to your liking.

    NB: I'm not sure what advantage you're expecting with aarch64, but it's not going to noticeably improve anything and you will have to reinstall or remove binary add-ons) as they are not aarch64 compatible; and there will be no replacement binary add-ons in the repo as there are no ARM aarch64 releases for LE11 so the add-ons weren't built/don't exist.

    Hi, is this the same situation for RPI4 12 nightly builds? Are all add-ons binary? I say this because I'm running nightly aswell and add-ons work.

    In the past I've run nightly builds for android-tv from kodi repos without problems for basic add-ons.

    I'm waiting for next nightly build, which bumps from 6.1 to 6.4 kernel, yay! I'm expecting improvements on kernel video drivers' hardware acceleration.

    Do most 12/omega add-ons/plug-ins come natively on 64-bits now?

    I heard 12 switches to 64-bits.

    BTW, why do nightly builds occasionally take longer hiatus, such as now, 6 days and no build? (Sorry for the question, didn't want to push)

    Does it show in LE11 without any overlays?

    I tried stable Bullseye 32-bit Raspberry Pi OS without overlays, according to tv hat official guide, but I seem to have a problem recognising the Sony tv tuner chip:

    Code
     [   11.192689] cxd2880: cxd2880_attach: chip id invalid.

    I'm following advice on this post now:

    wyup
    June 27, 2023 at 8:14 PM

    Hello:

    In two cases after flashing two latest RPI4 12 nightly builds on sd card, at first boot, an error like this appears in console:

    Code
    error in mount_storage. mount_common: could not mount UUID-xxxxxxxxxxxx ***
    ## Starting debugging shell for boot step: mount_storage... type exit to quit ###

    then, as I don't have keyboard available, must cold reboot RP4 and normal boot ensues

    note: I had edited config.txt before first boot to add some audio overlay, gpio-ir and little else.

    I did a scandisk and failsafe extract the card from a Windows PC card reader, and had used LibreELEC USB-SD Creator to flash without error.

    Sdcard is a 128GB microSDXC Canvas Go Plus 170R A2 U3 V30, #1 fastest card for PI according to https://pibenchmarks.com/brand/Kingston…us_%28SD128%29/