Posts by HiassofT

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

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

TpmKranz thanks a lot for testing and your detailed report, this is highly appreciated!

I just found out that a bit more plumbing is needed in kodi so we can signal BT2020. Looks like we have a bit of work to do to get proper 10bit BT2020 output - but we'll get there eventually

so long,

Hias

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)

[  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

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

Hmm, this sounds more like a TV settings issue than an issue with the RPi (or these testbuilds) to me now.

I'll cross-check Samsung wonderland two on my LG OLED 55C8 tomorrow. Cross-checks from other users are highly appreciated, too, of course!

so long,

Hias

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

Quote from JohnWayne111

is that part of the newest nightly image?

LibreELEC-RPi4.arm-9.80-nightly-20210212-bb390f9.img.gz

No, the HDR changes are not yet in LE master or nightly builds.

The source code used to build the test image is here: GitHub - HiassofT/LibreELEC.tv at le10-hdr-test

We'll include the changes in LE master / nightly builds when we are confident that testing is fine.

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

Quote from AriaTwoFive

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

AriaTwoFive could you give the build from the very first post a try (it contains additional logging in the kernel driver) and then post a "pastekodi" log?

so long,

Hias

Quote from macgyverel

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

I already answered that here RPi4 Libreelec 9.2.2 Hunds up on loading info (pics) in DB and if I read your last post correctly you confirmed that the nightly build worked better.

The log also shows that you haven't reduced GPU and CMA memory, so the OOM-killer is kicking in because you run out of memory - a well known limitation of 1GB RPi4 on LE 9.2 (just search the forum for more info).

so long,

Hias