Ok, I think this is a wild goose chase hunting down seis.
What’s bothering me now is the colorimetry bits (C0,C1) seem to be missing from AVI infoframe byte 2. So EC0-2 might not be invoked. Can you confirm that?
Yep. I use MakeMKV for all movies.
I do see EC0-EC2 in the AVI InfoFrame with BT.2020 content. For BT.709 C0-C1 is being set to 0 (which is fine).
BT.709 - 82:02:0d:57:50:a8:00:20:00:00:00:00:00:00:00:00:00
BT.2020- 82:02:0d:ae:40:c0:60:61:00:00:00:00:00:00:00:00:00
Data Byte 1 starts at 50/40. Not sure why active format description is sometimes not set.
1 Like
Thanks for that. The only oddity (I think) is that YCC444 is being signaled for a 4kp60 signal. If 10-bit was set (was it?) that should be YCC420?
The output is 4K24, so YCbCr 4:4:4 is correct.. The only oddity that I find is Active Format Information/Aspect Ratio in data byte 1,2 being set inconsistently, but that has nothing to do with the current issue.
The problem also occurs with “backup” made with another popular software. So, it’s not specific to makeMKV backups. Going back to my previous question- when is HDR10 metadata received? Is it during the demux or initial decode?
Edit: I see, you were commenting based on what you saw in the AVI InfoFrame. Yes, it is odd why the VIC is set to 97 when the actual output is 4K24 and the VIC should have been set to 93.
But was the actual output 4kp24? AFAICT, we are correctly sending YCC420, 10-bit, 4kp60 or YCC444, 10-bit, 4kp24 as appropriate to the source.
You can ignore that AVI InfoFrame. I am not sure what was going on there. I checked again today several times.
1080p60 BT.709 - 50:a8:00:10
4K24 BT.2020 - 50:e8:60:00
4K24 VIC is not defined in the InfoFrame. I guess the display is going by timings.. See updated post below.
No, the HDR infoframe isn’t used for that - 4kp24 is one of the ‘extra’ VICs in HDMI1.4 so you have to probe the VSIF, as I found out today. I think everything is fine. Thanks again for your help.
We will be putting out a test kernel shortly which atm just believes the EDID and switches bit-depth accordingly. But we are aware there are AVRs that mangle the EDID from displays and displays that can do 10-bit but only with YCC422. So planning some overrides for these cases if we can get some feedback.
Correct. For 4K24/25/30, AVI InfoFrame VIC is set to 0 and the extended resolution is defined in VSIF. I forgot about the VSIF.
As I said before, this issue regarding not getting HDR metadata in HEVC SEI messages from joined m2ts files is specific to the Vero 4K. If I had more time, I would have analyzed the HEVC bitstream to check what is different with these joined m2ts files.
Sorry if I missed something here, should I still be applying a hotfix after the August update? If so can someone link it here please? I’m on a Vero 4K and LG B7, HDR stuff looks good but I am going to do a test with Coco later.
Thanks!
Steve
Just enable auto HDR in System->display and you should be right.
I’m curious as I don’t know anything about how HDR10 works internally but seeing how Coco (with 1000nits mastering) was too dark because the Vero was telling the TV it’s 5000nits, would in turn telling the TV it’s (e.g.) 400nits make Coco even brighter than with its correct 1000nits?
probably. But there are some smarts in the code which adjust the output based on the display capabilities. YMMV
The reason I ask is because I have a disagreement with how HDR10 content is handled on my TV (LG OLED C7, maybe this applies to all TVs).
A lot of movies are just too dark, especially those that were just lazily re-released with HDR10 slapped on (e.g. The Bourne Collection). Scenes in daylight are usually fine, but anything other is way too dark for my taste, the picture quality might as well be 720p with a low bitrate, I wouldn’t be able to tell the difference it’s so dim. My room can be completely darkened to a point where you barely see your hand in front of you, so that’s not the issue. I don’t even dare think about watching during the day with this.
My TV is properly calibrated for HDR10 and I find myself having to use the “Vivid”-mode to make the entire picture brighter, obviously that looks very silly but at least I can see properly.
I don’t have that issue with Dolby Vision. Because Dolby (or LG) were smart enough to have the “OLED Backlight” be at 50 for “maximum luminance”, leaving you with room to make the picture darker or brighter if needed (obviously by sacrificing contrast). HDR10 on the other hand is at 100 OLED Backlight already, leaving you no room to make it brighter, you just have to take it as it is.
I already use “Active HDR” (dynamic tonemapping on the LG) to make it brighter but it’s still not enough. And it screws up shadows in some situations, which is annoying.
So I was thinking, a slider similar to the “Brightness”-slider popup dialog in the video player, but one that “overrides” what the Vero sends to the TV for the maximum mastering display luminance, thereby tricking the TV into making the picture brighter (I don’t care if it screws up the contrast between highlights and mid-tones or whatever). Would something like that or similar solutions be possible or even viable?
I’m at a point where I don’t enjoy watching HDR10 content at all anymore and would rather watch an SDR-conversion in 4k (but I don’t even have a way of doing that, so I’m SOL).
This can be done.
My understanding is we can make this configurable as a sysfs parameter and in turn, a Kodi option. We’d need to take care with resetting to default when video playback ends / a new video starts however.
If we set this as a sysfs attribute, we should be able to peek on vframes and adjust accordingly. There probably won’t be a one-size-fits-all approach to HDR given the differences in implementations in displays and studios, so our role may simply involve being as flexible as possible.
Sam
2 Likes
Thanks for considering such a feature in the future. I’d sacrifice my first-born child for such a slider 
Thanks for considering such a feature in the future. I’d sacrifice my first-born child for such a slider
Me too! As a projector user, I too find HDR just too dark most of the time, even though I’ve tweaked my gamma settings to death! I could probably use the standard HDR gamma setting of the X5500 if I could more easily tweak the source when needed.
1 Like
So, I’m not sure but it seems like the issue is still there for some files. I’ve uploaded a short sample to https://collab.osmc.tv/s/zuJn8aVn94owg8V (antman_hdr4000.mkv)
When I started watching this movie on my Vero I immediately noticed something was off (I have actually noticed this very rarely before on some files but it wasn’t bothersome). The picture just seemed so dim. The best way to describe it: highlights are way too bright while midtones and shadows are too dark. When I play the same file through my internal LG player (OLED C7) the picture is much more balanced, specular highlights are still there but they’re not constantly blinding you (this might be visual perception though because everything else is not so dim on the internal player).
My TV is calibrated for HDR10 on both inputs. But the same issue can be observed with default presets.
I’m on the latest update just before Kodi v18 on my Vero 4k but going through the changelog, there don’t seem to be any changes regarding HDR playback(?) so if it’s an issue it should still be there.
This is its metadata:
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 577 cd/m2
Maximum Frame-Average Light Level : 512 cd/m2
Maybe it’s the MaxCLL and MaxFALL being ignored over HDMI? Although I think I did read LG 2017 models seem to ignore these anyway. This also wouldn’t explain why the tonemapping seems much better on the internal player.
It’s possible the internal player does interpret luminance data but doesn’t parse it via HDMI.
We have accurate Fall/CLL metadata in an impending update, although it will not be in tonight’s update.
Cheers
Sam