Posts by HiassofT

The preferred and easiest way to post logs is to either use the upload logfile option in LibreELEC settings or to ssh into the RPi and enter "pastekodi".

Both variants will give you an URL, just post that URL here.

so long,

Hias

Quote from JohnWayne111

---

One question to all: Doe anybody knows, whether HDR is only available with HDCP 2.2? Is HDR passthrough not possible with HDCP 1.4 ?

HDR and HDCP are completely independent - RPi doesn't even have a certified trust path, so no widevine, HDCP etc.

so long,

Hias

RPi4 doesn't support 1366x768, see the official documentation Raspberry Pi 4 HDMI pipeline - Raspberry Pi Documentation

Try the workaround from there or just search for "RPi4 1366x768" and you'll find plenty of info and other possible workarounds.

so long,

Hias

Quote from linuxuser

Hias, the image that is tagged by its file on the above quote I just tried and I still don't have the hd audio formats ... although kodi on the TV has all the HD sudio formats (and the tagged build is the latest nightly build) any solutions?

No. As I already wrote 2 times, here RE: RPi4 testbuild with HDR support and here RE: RPi4 testbuild with HDR support there is no fix/solution available yet to get HD audio with your TV.

so long,

Hias

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

The fix hasn't been written yet...

so long,

Hias

master/nighly is missing 2 commits from the latest testbuilds which further reduce the chance of audio dropouts - I'll include them in the next RPi kernel update.

so long,

Hias

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

linuxuser run this command on your RPi, then post the URL you got:

od -t x1 /sys/class/drm/card0-HDMI-A-1/edid | pastebinit

copy-and-paste that into putty/ssh and make sure all is in one line and exactly as above.

so long,

Hias

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:

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

linuxuser can you please grab the edid of your TV and upload it? Run

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

then upload edid.dat (you may need to ZIP it so attaching works in the forum software).

so long,

Hias

Yes. RPi4 uses the ARMv8 addons, RPi2 the ARMv7 ones.

so long,

Hias

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