HDR Problems on S912 and S905

It appears to be a race condition as you have experienced sometimes it works and others it doesn’t.

I removed it until it can be fixed properly as if we included it in a release then there would only be a flood of complaints from people not aware of the progress we are trying to make.

Thanks @anon88919003 for your comment. Well actually all my movies are or hdr 10bits or bdremux 8bits. Are played from streaming and link stored in strm format. Kodi 18 has a better support for this kind of links (can resume movies, load names, plots…) Until now all is played correctly (well AVR recognizes hdr content, 10bits, and 444). Could not be perfect, but as workaround is functional.
I saw that OMSC team has submit some hdr fixes to Linux kernel, I’m sure that the solution is not far away.

It is true that there are some problems, like hdr 10bits content at 59,97hz but it is only on samples.

Thanks guys for your work

I think this depends on the HDMI specifikation, because there are only 422/10bit for a datarate of greater 4K/30Hz defined.
For more information about HDMI-2.0 You can look here and here!

Paul

Is there any way to add a context menu item like ‘Play in 10bit mode’ for manually overriding until a proper fix is implemented?

for s912 device you can just use autostart.sh to enable 444 10 bit permanently for now until a proper fix is added, i see no issues with regular bluray files or HDR content this way.

Any how to guide?

echo "echo 444,10bit > /sys/class/amhdmitx/amhdmitx0/attr" >> /storage/.config/autostart.sh

do we need to use an autostart to force 444 10 bit with latest update?

At the moment yes. We don’t have autoswitching working yet.

Thanks for this great update.
I’ve build new image from sources applying HDR autoswitch patch previously reverted. As you know is not working properly; for UHDRemuxes works great, but for some videos not. Also, I’ve experimented some strange behaviour when apply Auto Croma/Color patch. If i play UHDremux by streaming (http in strm file), you cannot jump to any position because the video/audio is truncated. If i revert the patch (or using nightlies builds) video is playing correctly.
If i repeat the same procedur with LE 9 images, video plays correctly with autochroma/color patch.

Regards.

any updates on 10 bit auto switching?
i was excited, but seems progress has slowed or halted?

I’m hoping that the improved HDR implementations OSMC is testing will find the way to CE as both autoswitching and the dimmed HDR fix are much appreciated! :slight_smile:

It’s not final yet, but we will test it.

Great!

I don’t think the flickering/banding issue is completely fixed either since my screen is doing a 1-3 seconds flickering every 10-15 min when playing HDR10 content after running

echo “444,10bit”>/sys/class/amhdmitx/amhdmitx0/attr

In addition, if I have whitelisted 3840 x 2160 30+ fps, my Samsung TV looses the HDMI signal with my S905X box and I’ve to reboot. From reading the logs I can see that the resolution changes first to 3840 x 2160 60 fps, then 23 fps even when the content is 3840 x 2160 23.976 fps 10bit 4:2:0 BT.2020.

TIMESTAMP CoreELEC kernel: codec:hevc video changed to 3840 x 2160 60 fps clk->667MHZ
TIMESTAMP CoreELEC kernel: codec:hevc video changed to 3840 x 2160 23 fps clk->667MHZ

If I’m not running the ‘444,10bit’ command above before playback or have whitelisted 2160p 30+ fps and run ‘444,10bit’, the problem doesn’t occur. The problem might be related to that HDMI 2.0 can’t handle 3840 x 2160 60 fps 4:4:4 10bit because of bandwith limitations.

As most HDR10 content is 4:2:0 chroma, I’ve tried to run the command above with 420 instead of 444, yet my TV looses the signal and I’ve to reboot. When this get’s resolved in the future, shouldn’t Kodi extract the chroma specs from the file and set the correct chroma instead of 4:4:4 for all HDR10 content? Or is it indifferent?

PS: I would have uploaded the logs if it haven’t been for that I’m using PlexKodiConnect, so there are too much personal information in the logs as username, IDs, IPs, filepaths etc. I can make a clean setup where I run the files from a harddrive if you guys want logs.

This sounds like an issue with your HDMI cable.
We and the guys at OSMC have tested the flickering fix and confirmed that it indeed fixes the issue.
Get a Premium Certified HDMI cable, and it should fix your problems.

Well, it indeed was my HDMI cable who caused the flickering as it’s gone after changing the HDMI cable.

I’ve narrowed the whitelist problem down to the resolution of 4096 x 2160 23-24 fps, which cause the problem if I’ve them active and run the 4:4:4 10bit command. My TV supports the resolution and I only have problems when I run the command and play 3840 x 2160 content (1080p is fine), so it isn’t something that I would see prioritized to get fixed. Yet, there might be others who could face the same problem when activating 444, 10bit and playing 2160p content.

You shouldn’t use 4096x2160 anyway, because all 4K TVs have a physical resolution of 3840x2160. Also there is no ‘normal’ content that I know of that is 4096x2160, everything has a width of 3840.

Any update about this topic? I’ve seen that OSMC has a experimental kernel with some improvments. It is possible to test this kernel on CoreElec in easy way?

Thanks

I have also just been reading about the new kernel. It sounds REALLY promising.

  • Added support for automatic colour space switching without having to set 10-bit manually or enable HDR autoswitching in Kodi.

Improved picture quality for some HDR content. After some discussion , we’ve found some scenarios where HDR content will appear to be too dark on OLED TVs. This seems to occur when the video is muxed in a way that prevents the mastering data from being stored properly. We now use a more sane fallback and inject static metadata in such a scenario.

Coco was a film that was reported to be particularly improved. We continue to work on improving support for HDR content.

  • Fix an issue with YUV -> RGB conversion when a file is encoded with the full range flag. This affected some HEVC content and caused crushed colours for some users

As an aside, this kernel also contains some improvements for the Gigabit Ethernet interface found on the Vero 4K +.

The bold italic part is the MAIN problem I have with COREELEC and the reason I don’t use it atm.

Most people in the thread report EXCELLENT results, there are a few that have had problems but those people don’t seem to be able to follow simple instructions.

Would it be possible to add this kernel to COREELEC (for people willing to try/test ) in a similar way that @sam_nazarko has instructed users of OSMC to ? which is through SSH running the following.

wget https://collab.osmc.tv/s/DKFOE1k8H4QuuCq/download -O /home/osmc/kernel.deb
sudo dpkg -i /home/osmc/kernel.deb
rm /home/osmc/kernel.deb
sudo reboot

I am desperate to use COREELEC so I can get True HD and DTS:X sound but with the really DIM HDR picture on my LG B7 I would rather use built in apps and have Lossy sound but a STUNNING bright picture.

@TheCoolest @anon88919003 please please tell me I can test this for you :innocent:

Interestingly enough every time i tested HDR on COREELEC i used terminator 2 which is like the only movie out there with absolutely no luminance data :joy: sods law

T2 truly is missing both mastering display metadata and content light level

Seems all that is needed is changing the default fallback value of 5000 to 1000.

Did I mention I am MORE than willing to test this for you guys :grinning: