[8.0.2e] LibreELEC 8.0 for S905/S905X

Quote from johngalt

I used test videos (actually same as off avs forum).

I'll grab some photos...

Please do that.

Quote

...but I found out the behavior of full or limited black levels changed between nougat and marshmallow kernels which is where the difference lies: not whether the display is hdr capable. Mix in that many current displays have broken "auto" black level (like Samsung's entire lineup), this is why some of us have seen the black changes, and others haven't.

That theory might be true in some cases, but it is ultimately incorrect.

There is no change in RGB range between builds.

Both Marshmallow and Nougat Frankenstein Kernels output limited YCbCr in video playback.

My TV is always fixed for limited input and I made sure to test both builds again.

When the MM kernel boots up, it looks like the build outputs the full RGB range (0-255), so changing the TV to full range fixes the issue for a second.
However, as soon as you start the first video, the output is back to limited YCbCr, as it should be. So if the TV was changed to full range before, everything will look washed out.

Your theory still has some merit here, because TVs that have the range set to "auto" might read the signal as full range at boot up and stay at full range. The result would be washed out looking video.


So, users who complained about washed out colors with MM builds - please check your TV's RGB range setting and manually set it to limited (HDMI black level / black level = low in some devices).


To be honest, I always assumed this is a given and people have their devices set to limited by default...

Quote from Pelican

In the Krypton it looks very bad on my tv (which is not HDR capable).

There are no black at all:

Set the TV's input RGB range to limited (HDMI black level / black level = low) and see if that fixes it.

Quote from jd17

Please do that.

That theory might be true in some cases, but it is ultimately incorrect.

There is no change in RGB range between builds.

Both Marshmallow and Nougat Frankenstein Kernels output limited YCbCr in video playback.

My TV is always fixed for limited input and I made sure to test both builds again.

When the MM kernel boots up, it looks like the build outputs the full RGB range (0-255), so changing the TV to full range fixes the issue for a second.
However, as soon as you start the first video, the output is back to limited YCbCr, as it should be. So if the TV was changed to full range before, everything will look washed out.

Your theory still has some merit here, because TVs that have the range set to "auto" might read the signal as full range at boot up and stay at full range. The result would be washed out looking video.


So, users who complained about washed out colors with MM builds - please check your TV's RGB range setting and manually set it to limited (HDMI black level / black level = low in some devices).


To be honest, I always assumed this is a given and people have their devices set to limited by default...

Display More

Because it boots into full, I can't set the range to limited on my newer samsung set (stuck on auto due to broken firmware on entire samsung lineup). I was able to test on my sony and can confirm.

Quote from johngalt

Because it boots into full, I can't set the range to limited on my newer samsung set (stuck on auto due to broken firmware on entire samsung lineup).

I am very sorry to hear that... Is there no way to set the RGB range to limited before you boot up the box?

Quote

I was able to test on my sony and can confirm.

So we finally have an explanation, but I still don't know why people kept claiming everything is darker in MM builds.
That makes no sense in any RGB range scenario.

The only logical explanation is that those users never made it past the initial menu screen, despite of all the warnings...

Quote from jd17

I am very sorry to hear that... Is there no way to set the RGB range to limited before you boot up the box?

So we finally have an explanation, but I still don't know why people kept claiming everything is darker in MM builds.
That makes no sense in any RGB range scenario.

The only logical explanation is that those users never made it past the initial menu screen, despite of all the warnings...

There's unfortunately no way, but seeing as I don't do HDR or 10 bit stuff on libreelec, I'm fine sticking with the nougat kernel. I'm glad we were able to get to the bottom of the issue.

I don't know why people have claimed that either. One guy (who I suspect is in the same boat I am) said something like, "as if a grey veil was lifted," which fits the washed out look of mismatched rgb range exactly.

Pelican

Each kernel has different quirks when it comes to HDR=>SDR and colorspace conversion (just as kodi on different platforms (eg before win10 creators update) might have quirks). I recommend sticking with SDR material on libreelec altogether.

Edit: if range_control stuff is reverted, the 10bit=>8bit banding is also "fixed" in nougat kernel. I'll do more testing, cleanup, and submit a PR. Is this the only bug that's been widely reported in the nougat kernel?

Quote from johngalt

if range_control stuff is reverted, the 10bit=>8bit banding is also "fixed" in nougat kernel. I'll do more testing, cleanup, and submit a PR.

Sounds great!

Quote

Is this the only bug that's been widely reported in the nougat kernel?

Unfortunately, it's not.
2160p video has "black screens" (like signal losses) in Nougat Frankenstein, even on SDR / 8-Bit / BT.709 content.

It is more than just color range issues for my s905x box. There is something fundamentally wrong with the driver in MM kernel builds.

The best evidence I have is that the brightness and contrast adjustments while using hardware acceleration are totally fubar on MM, but work exactly as expected on the Nougat-y builds.

I had a post about it HERE, but unfortunately the pic links got jacked with the new forum conversion. I'll try to get some screenshots or pics later.

Quote from Jaaxx

It is more than just color range issues for my s905x box. There is something fundamentally wrong with the driver in MM kernel builds.

The best evidence I have is that the brightness and contrast adjustments while using hardware acceleration are totally fubar on MM, but work exactly as expected on the Nougat-y builds.

I can confirm that both brightness and contrast settings are broken, at least in the current MM build.
Thankfully, there is a very simple solution - don't use those sliders!

Those broken sliders do not mean that "there is something fundamentally wrong with the driver in MM kernel builds", because the output is perfectly fine when both sliders are untouched at 50%.

Quote from kszaq

johngalt I have noticed that you forked my kernel and that you are working on some changes. I think I will be able to create some test builds with full Nougat kernel later this week. I you have any improvements to share, I welcome every PR!

Both those branches are very broken in different ways, I recommend holding off a bit before you play with either :). I accidentally learned a bit about the amlogic drivers though. On one test build, I accidentally forced bt2020 and HDR mode on everything, but it gave me a chance to play around with the SDR to HDR conversion. With removing the saturation boost in that mode, it actually looked quite decent.

Since we know how to set bt2020 colorspace (still 8 bit, but with decent 10bit=>8bit conversion that can be worked on later), I've been thinking a good solution for (near) HDR output would be to read the playback's colorspace, and set the colorspace accordingly (similar to your patch for nougat style framerate automation). I've yet to look into how the colorspace can be read at the kodi level however.

Given the work required for a full nougat kernel, IMO it would be best to start off slow with your current branches + a few commits/reverts, and go from there. A full nougat kernel could be developed in tandem.

Unfortunately I can't replicate the other nougat kernel bugs such as black screens, though I've seen some unmerged commits that mention similar.

Quote from kszaq

I already have full Nougat kernel working here with a few rebase bugs to fix.

Nevermind then :D. I'll PR the banding revert for you and continue playing around with the HDR side of stuff on the nougat kernel.

Quote from jd17

I can confirm that both brightness and contrast settings are broken, at least in the current MM build.
Thankfully, there is a very simple solution - don't use those sliders!

Those broken sliders do not mean that "there is something fundamentally wrong with the driver in MM kernel builds", because the output is perfectly fine when both sliders are untouched at 50%.

When a kernel level code breaks userspace there is a problem. I think it's a safe bet that whatever is breaking bright/cont settings may also be affecting other things. Although given this is Amlogic code it may be more correct to say "never implemented correctly/fully" rather than "breaking."

Quote from Jaaxx

I think it's a safe bet that whatever is breaking bright/cont settings may also be affecting other things.

A safe bet I have not seen the smallest shroud of evidence to support.

The only real world drawback is the minor overscan on the left edge.

when will full nougat kernel build out for Dowloading?

Quote from jazia

oh sorry! i searched but i didn't find it, thanks for your help

anyway someone knows if that patch is added in v8?

It definitely is.

Put "echo 1 > /sys/class/amhdmitx/amhdmitx0/output_rgb" (w/o "") into your autostart.sh and you should be good to go.

Quote from johngalt

Each kernel has different quirks when it comes to HDR=>SDR and colorspace conversion (just as kodi on different platforms (eg before win10 creators update) might have quirks). I recommend sticking with SDR material on libreelec altogether.

This is the most sound piece of advice in this whole HDR colorspace "Adventure".

HDR use at this present point in time belongs firmly in the Android OS, which then has it's own share of issues.