Posts by HiassofT

    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

    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

    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

    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

    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

    I mean test the publicly available demo files and tell us which ones work and which ones look different. Taking a picture with your phone won't hurt, though it's rather hard to tell from the picture if something's off.

    If you can tell us eg if "Samsung Wonderland Two HDR UHD 4K Demo.ts" from 4kmedia.org shows identical output with kodi, plex, ... or not that would help.

    If you can't reproduce the issues with the publicly available samples it may be somthing specific to your file(s). In that case you'd need to cut out a short 20-30 seconds sample and upload it somewhere so we can try to reproduce - also make sure you test with the cut sample to rule out issues with the cutting software.

    so long,

    Hias

    It does show HDR.

    I flashed the file through the /storage/.update/ folder, enabled debug, rebooted and started the movie. Here the log:

    Thanks for the log, dynamic range infoframe seems to be sent fine, not quite sure what might be going wrong.

    Can you test with some publicly available samples, eg the ones from 4kmedia.org (4k HEVC 24fps ones should work well), and/or upload a short 20-30secs sample? Then we can try to reproduce it and have a closer look.

    so long,

    Hias

    I have question about 4k30. I have mp4 files h264 and files not working. Only music/sound. Thumbnails are genereted but no video - black screen. What is wrong?? Rasbery Pi 4 4MB. Output resolution on HDMI is 1080p. Kodi should scale 4k to 1080p.

    4K working if I disable DRM Prime Hardware Acceleration, but video is stuttering.

    The RPis support hardware decoding of h264 only up to HD resolution and only 8bit. 4k / 10bit hardware decode is only supported for HEVC.

    RPi4 is too slow to software decode 4k h264 files and software decoded 10bit videos aren't supported by kodi's DRM prime renderer yet - there's a PR to add that but it's marked for Kodi 20 DRM PRIME: allow using multiple layers by lrusak · Pull Request #19140 · xbmc/xbmc · GitHub

    so long,

    Hias

    aakister not quite sure why 4k HDR didn't work for you, the kodi log looked fine.

    Can you please post a "pastekodi" log? Run the "pastekodi" command on the shell or use the logfile upload function in LE settings and post the URL.

    A link to a short sample (20-30 seconds will do) that shows these issues would also be great, then I can try to reproduce it locally.

    so long,

    Hias

    JohnWayne111 just talked to RPi devs but you might not like the answer:

    RPi4 doesn't have hardware support for HDR-to-SDR tonemapping, it might be possible to tweak things a bit but the result will always be off - either too dark or too light.

    Simple solution: don't use HDR encodes if you don't have a HDR display.

    You could also try to re-encode the HDR files on your PC, ffmpeg (and probably other encoders) should support that with tonemap filters (never used that myself though).

    so long,

    Hias

    AriaTwoFive have you checked if the Plex player on TV and Kodi used identical picture settings?

    On my LG TV picture settings (brightness, colour temperature, "optimizations" etc) can be configured independently for internal player(s) and each HDMI port - and it's quite easy to miss that they might be set differently.

    If you have another player app on your TV (eg to play from USB media) or some other external player it'd also be interesting to cross-check with these.

    As it's bleeding edge code I wouldn't rule out that something is off a bit, but we also have to make sure we don't compare with a player/source that applies different video settings.

    so long,

    Hias

    Here's a new testbuild with HEVC decoding fixes: LibreELEC-RPi4.arm-9.80-devel-20210210171544-68ac68f.tar

    Some HEVC files showed pixelation artefacts (decode errors) and the "Samsung Wonderland Two" demo from 4kmedia.org resulted in a hard crash because the decoder ran out of memory. The HEVC decoder now handles out-of-memory situations much more gracefully and we've increased the default CMA memory size to 512MB so the file can be properly decoded.

    so long,

    Hias