I saw the change they did in the code, IIRC they changed max luminosity from 5000 nits to 1000 nits. Which would be the correct ‘generic’ value to go for. None of the movies I’ve heard of so far are mastered at 5000 nits, some are mastered at 1000 nits and some are mastered at 4000 nits. So if mastering data is missing, generally 1000 nits is going to be a good enough compromise.
I’ve tested some of the HDR content I have and I have not seen any difference in luminance levels between CE and the internal player. I have the box connected directly to the TV, so perhaps there are other factors in play here.
In any case, I think that he fix Sam implemented should be implemented in CE as well, as it’s a very small change that shouldn’t affect anything else.
I just pushed a fix for this. So it should be in today’s\tomorrow’s nightly build.
Thanks.
I’ve tested internally the patches posted by @samnazarko in vero3 kernel (from commeit 2d3ef297fda17d87dcd13d49d0b570fa4bedf358 until last one) and the first tests are very promising.
I’ve tested some HDR 10bit, 2160p samples, and automatically changed to the correct bit depth and color. I have to test a real movie but sound very good. As I my knowledge in git and programming is very very limiting I only made .patches to apply over current kernel.
Kindly share the devel version of latest patches which you applied. I also want to test?
As far as I understood from the thread the issue is not only the default max luminosity. It is also that sometime the correct metadata info are not sent to the display.
I can confirm that, exactly as written in OMSC thread, Cars 3 mastered at 5000 looks ok on my VPR, while other movies, such The Martian, Avenger infinity Wars, etc… look too dark
Dear @anon88919003 and @TheCoolest
I’ve tested the following commits authored by [graham8] and [samnazarko] into CoreELEC linux-amlogic and they are working as expected.
As i don’t know how make request or merge different repositories i made a brute patch between directories.
Do you think that is possible merge this commits into CoreELEC branch?
Thanks.
Commits:
- c5bf3dceb941f8b1347ddfe10758c4c11e0ac817
- e5734c08225b47f75b2f6076c18f2110ab37c832
- ac12bea70dc065b866f74792c1de23c40c906d2a
- 496d526262d96d4f5e6351b867b5f5d74278bee2
- a585e3fba840e80fea8ce1ecfa649ac733380352
- d58165d11a869501b28963c6e798e466c612b440
- 8e1a123dd37a8be38a55d296858a9850439ffe28
- 147dd5d591cf9f6c4c4ed9138c580852358e8d7d
- 52640f8d62a48a3573761b311c7420ab1029b681
These commits send correct peak nits read from metadata or just set 1000 instead of 5000?
Did you try to install the latest nightly as suggested by @TheCoolest?
He already added these commits to the CE repository, so no need to re-merge them again.
Sam has mentioned that the code still needs work. I still don’t know whether the OSMC team will handle it, or we’ll have try to do something about the extra fixes that are required.
Currently I’m busy with a side-project and family, so i don’t really have time to test it out properly.
I know that it should mostly work, but there are still some issues with that code.
@relkai I only committed the fix for the 5000 nits issue. CoreELEC nightlies will now set 1000 nits peak instead of 5000.
@Menion The latest nightly build contain the fix you’re after.
@relkai I only committed the fix for the 5000 nits issue. CoreELEC nightlies will now set 1000 nits peak instead of 5000.
mmmm it does not looks so good, anyhow I will try to test it with 1000 and 5000 movies
Aah, okay…excuse me, I thought this was already the all-inclusive-HDR-package.
If I remember correctly, Sam doesn’t have the time to work on this patch at the moment, though it needs some rework.
But he had very specific ideas, what needs to be done, so it shouldn’t take too long hopefully.
I think, it doesn’t make sense to merge the available commits, if they are being reworked during the next weeks.
Hi
Is his patch (1000nits for HDR fallback) included in 8.95.3?
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.