Yes, it is.
Does it mean that my 1400 nits capable TV gets lower maximum brightness signal in this version?
If yes, why not let the TV to do tone-mapping for HDR as before, what is the benefit?
Maybe it is worth to add an entry in the release note
I added it to the list of changes.
It is a fallback, not the “correct” HDR metadata handshake. The reason why the video pipeline goes in fallback is still unknown. It is a big problem, because the correct metadata handshake (not only maxFLL) is crucial for a good HDR playback, especially for display capable of doing auto tone mapping
The problem is that the hardcore linux developers are moving to mainline, which is still far from being usable, basically only OMSC and CE guys are still working on amlogic kernel, but the pipeline is very complex to debug and has also dependencies on the Kodi videoplayer, so it is a nightmare to debug.
Thank you for sharing some technical information about HDR implementation.
I see that the maxFLL as a fallback value should be used only if the correct value wasn’t read from the video-file metadata.
If I understood it correctly the problem is that in current CE kernel the handshake is not working and fallback value of 1000 nits will be used in all cases for sending HDR10 signal to the TV?
If the TV is capable of more than 1000 nits, will the maximum brightness be reduced?
Could you please make this a custom parameter in the future which user could set-up according to his TV max. brightness?
It is nothing to do with your tvs brightness.
It is the brightness the movie is mastered at.
Most HDR movies are mastered at 1000 nits, some others at 4000 nits.
The default fallback value b4 this change was 5000 nits, which was just wrong.
The only movies that seemed to missing the brightness data like terminator 2 are all mastered at 1000 nits.
Try watching terminator 2 on the old version and comparing it to one of your tvs built in apps or the new version of coreelec
The picture will be noticeably darker on the old version without this fix.
There are a few other films missing this data, if you would like to know which then have a proper read of the links i posted here a couple of weeks ago.
OK, thank you for clarification. I haven’t understood it right before.
If only the movies missing the metadata value will use the fallback that’s OK.
So the change is not as dramatic as I have afraid 
Will test the new version.
The TV needs information about the brightness the movie is mastered at. Then it uses this Information and the maximum brightness it can display to calculate the brightness levels that it will show to you.
This is to account for different capabilities of different TVs. The 1000 nits value does not mean that your TV shows 1000 nits max. It only is the value the TV uses for its internal calculation of brightness levels.
In principle it works like this: With the old fallback value of 5000 nits, your TV would think “hey I cannot show 5000 nits but only 1400. So I scale all brightness levels down by about 1/4”. (I guess it is not really a linear scaling but the TV will do some more complex calculation, because there can also be meta tags about maximum light level and average light level). And as a result, the whole movie is too dark, because in reality it was not mastered for 5000 nits.
With the new fallback value of 1000 your TV does not have to scale so much and the movie looks as it is intended.
I’m using the latest CoreELEC/Kodi build (8.99.2) on a Mini M8S II (2 GHz S905X with Mali-450) box, outputting to an LG 65E6 OLED set. When I play 10-bit 4K HDR files within Kodi, the TV displays the HDR flag as expected, and it switches into its HDR picture profile, and manages to play the content at the correct resolution without any buffering. However I get the same issue as the other people in this thread, in that the brightness is far lower than similar non-HDR files, and that cannot be resolved using the TV’s image controls without killing the black level.
I know some hardware does not handle HDR correctly at all, so is this likely to be an S905X issue or a software issue in ColeELEC/Kodi? I’m a bit lost with all the conversations on the matter here, and not sure if it should be working now or not?
Andre
Maybe its the content you’re watching that is poorly mastered in HDR?
Try some other movies or sample clips. Sony HDR demos are quite nice, try one of those.
I agree with punkid. I have a Mini M8S II too, and a LG B7. And HDR works just fine.
Try to compare to CE using the TV’s built in player.
1 Like
@andrewilley, play the file from a USB by your TV media player and compare it against playback with your Mini M8S. Take some pictures to see if there is a difference in brightness. Most likely it’s the sample. Is it a encode or a remux? Give us at least some more details if you want us to look more into it!
Most likely it’s the sample as I’ve neither noticed any problems regarding brightness with my S905X box from playback of HDR content etc, and I watch Netflix and Prime with HDR all the time.
Work yes, remove <
#!/bin/bash
string=$(cat /sys/class/display/mode)
if [ $string = 2160p24hz ] || [ $string = 2160p60hz422 ] || [ $string = 2160p60hz444 ]; then
echo “444,8bit”>/sys/class/amhdmitx/amhdmitx0/attr
echo ‘444,8bit’
elif [ $string = 1080p60hz ]; then
echo “444,10bit”>/sys/class/amhdmitx/amhdmitx0/attr
echo ‘444,10bit’
fi
###################################
string=$(</sys/class/display/mode)
##################################
to
#################################
string=$(cat /sys/class/display/mode)
################################
What’s the point of bumping a dead thread with wrong information?
CE does automatic color space and color depth switching, according to content and display capabilities, and doesn’t need any scripts.
Wrong or right the user is free to do what he wants
So everyone who posts scrits is wrong on your watch.
Everyone who posts scripts that conflict with the built-in functionality of the OS - yes.
1 Like
So because there is nothing in ==> cat /sys/class/amhdmitx/amhdmitx0/attr
Configs default CE ?
##############################################
CoreELEC
https://coreelec.org
##############################################
CoreELEC (official): 9.0.3 (Amlogic.arm)
CoreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/config
cur_VIC: 97
VIC: 97 3840x2160p60hz
Colour depth: 8-bit
Colourspace: YUV420
Colour range: limited
EOTF: SDR
YCC colour range: limited
Colourimetry: BT.709
PLL clock: 0xc800027b, Vid clock div 0x000a339c
audio config: on
3D config: off
CoreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/attr
CoreELEC:~ #
If you want automatic change just leave the attr empty.
1 Like