Posts by HiassofT

  • RPi4 testbuild with HDR support

    FYI: the HDR and HD audio changes of these testbuilds are now in LE master and included in the latest nightly build, so you can switch back to using nightlies.

    It'll probably take a while until the colorspace and bit-depth issues are fixed, I'll report back when we've got something new to test.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    Quote from linuxuser

    http://ix.io/2PAw this is it, thank you in advance because this problem is fraustrating since the odi on android tv supports dolby atmos and dts hd and eac3 but on this libreelec build and the other libreelec build cant get thse formats

    Thanks for the edid, this is a bug in the linux kernel's EDID passthrough format detection - I recently ran into that as well. I'll have a look if/how we can fix that.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    Quote from linuxuser

    Hi again , do I need to grab this file from the tv or from the Raspberry pi 4? Thank you and also I tried but it says -sh edid.dat : not found

    Use putty to connect to your RPi, enter that command, then use eg filezilla to copy the edid.dat file to your PC.

    As an alternative you can run the following command via putty:

    Code
    cat /sys/class/drm/card0-HDMI-A-1/edid > /storage/videos/edid.dat

    then you can get to the edid.dat file via the "Videos" samba/windows share.

    Edit: if you are using linux then use ssh root@IP-OF-YOUR-RPI instead of putty and "scp root@IP-OF-YOUR-RPI:~/edid.dat ." instead of filezilla.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    noggin thanks a lot for testing, this is in line with my suspicion (video driver using the wrong transformation matrix). Not 100% sure why 10/12bit output isn't automatically enabled, could be that we need to explicitly request it.

    Regarding subsequent playback issues: Which testbuild did you use? The one from the first post (from Feb 5) or the one from here RE: RPi4 testbuild with HDR support (Feb 10)? The later build contains some important fixes that may be related.

    If you got that issue with the newer build please post a log (ssh in, run "pastekodi" and post the URL) and ideally a link to a sample file so I can try to reproduce that locally.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    Quote from linuxuser

    Hi, I have a question how the dolby atmos pass-through works on this libreelec version? Like I have a tv that's is certified dolby atmoa device, if I play some videos that have dolby atmos audio how the audio will be flagged? And will I get audio when I have audio pass-through enabled and play dolby atmos files? Thank you in advance , continue the amazing work

    You have to change settings level to "Expert", then tick Atmos (and whatever other formats your receiver supports) in the "passthrough" section of settings->system->audio.

    Kodi doesn't query the devices capabilites so you have to select formats manually. Note that DD+/E-AC3 passthrough in kodi is buggy, so better keep that disabled. DD/AC3, DTS HD and Atmos should all work fine.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    HLG seems to be properly signaled, my TV displayed "HLG HDR" with one or two of my demo files. Haven't verified the infoframe data in that case but pretty sure EOTF 3 / HLG was set correctly.

    1080p and CLL testing is lso highly appreciated. The metadata in the video files seems to be passed on correctly into the infoframe so I think that part should be fine.

    I'm quite sure you'll see BT.709 in all cases, the kernel code to fill in the colorspace data into AVI infoframe isn't called from the driver :)

    Could also be that a bit of plumbing in kodi is needed, haven't checked yet if the info is passed on correctly. And as CTA 861 lists three different BT.2020 versions (RGB, YCbCr and YcCbcCrc) there might be some additional work ahead.

    so long,

    Hias

  • Nightly builds Rpi4 Audio passthrough TrueHD/Master HD not working (huge stutter) anymore

    The build from Jan 29 is still the latest version of audio patches. You can also test with the HDR testbuilds RPi4 testbuild with HDR support they contain the same patches as the Jan 29 build except for the audio buffersize patch (which is very likely not needed).

    I tried to tweak settings a bit and see if I could resolve the now very rare glitches but didn't have much success with it yet. It's really hard to catch the glitches now and tweaking settings only made things worse so far.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    noggin thanks a lot for testing!

    The video driver should support 4:4:4 RGB output at 8/10/12 bit, just read through the info in the PR KMS 10 & 12 bpc updates (5.10) by 6by9 · Pull Request #3982 · raspberrypi/linux · GitHub again and noticed that 4kp30 is limited to 8bpp ATM... 1080p should support 10/12 bit output though.

    When checking the AVI infoframe this morning I noticed it's missing colorimetry info (C0/1 bits are zero), so there may be a few more bits missing in the driver - I've asked popcornmix about that.

    If the driver doesn't handle and signal BT2020 correctly that might explain why there are colour differences to other players.

    The dynamic range infoframe however seems to be sent fine, EOTF, maxCLL/maxFALL etc seem to be set accordingly.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    AriaTwoFive I had a look at the Mad Max Fury Road sample you sent me, that UHD BluRay is well known for it's rather insane MaxCLL/MaxFALL values (10k/3k), I added some additional debugging to the kernel driver and the dynamic range infoframe seems to be fine, matching the values reported by mediainfo (note that color primaries and min mastering luminance are raw, not scaled in dmesg output)

    Code
    [  138.881105] [drm] DRM infoframe: header 87  1 1a 93
[  138.881105] EOTF 2 metadata type 0
[  138.881105] x0 34000 y0 16000 x1 13250 y1 34500 x2 7500 y2 3000
[  138.881105] white point x 15635 y 16450
[  138.881105] display mastering luminance max 4000 min 50
[  138.881105] maxCLL 9918 maxFALL 3241
    Code
    Mastering display color primaries        : Display P3
Mastering display luminance              : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level              : 9918 cd/m2
Maximum Frame-Average Light Level        : 3241 cd/m2

    Do you have any other (external) players except the plex and vlc of your TV? Some players won't properly transmit maxCLL/maxFALL (eg AppleTV has or at least had that issue) so it could well be that the player you are comparing with is handling it wrong.

    The Mad Max sample looked a bit dark, but that's what I expect from a video with 10k/3k mastering when played back on a TV with about 1k max nits.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    Quote from AriaTwoFive

    Apparently Kodi doesn't like TS files. Samsung Wonderland Two HDR UHD 4K Demo.ts is exactly what I downloaded. Played it directly on my TV using VLC and it looked pretty good (the TV says HDR is enabled).

    Kodi starts the video, but doesn't play it (it's stuck on the first frame). As of now it's frozen up. Kodi doesn't react to remote control inputs nor SSH. Debug is enable any none of the numbers are changing. The frame doesn't look the same as on the TV though. Seems "washed out" a bit.

    The freezing with wonderland two is a bug we fixed in the latest test build - if you are still on the one from the first post please update to the latest one RE: RPi4 testbuild with HDR support

    BTW: it'd be awesome if someone else (with different TVs/players) could compare playback of this video with these testbuilds and internal TV player / BR player/... and report back if they are looking identical or not.

    so long,

    Hias