Any way to strip HDR metadata?

Most UHD-BD-Players allow you to strip HDR metadata from the output signal.
Is there any way to make the Vero 4K not transmit any HDR metadata (except for stuff like color primaries etc. of course)?
And probably related: any way to change the default 1000cd/m2 fallback the Vero uses?

I’ve looked through the package/mediacenter-osmc/patches directory to find the patch you added when you changed the fallback but I couldn’t find it. I’m not that familiar with Kodi or how OSMC is set up, so I was probably looking in the wrong place.

My goal is to either always have the Vero 4K output 4000cd/m2 (without any MaxCLL/MaxFALL) or no data at all. I’d be even willing to write my own patch if I knew where to start looking.

Reason I ask is because the firmware on 2017 LG OLEDs is beyond broken and, unfortunately, not something the new kernel will fix completely. Having no metadata (or just always 4000) and enabling the TV’s Active HDR would be the easiest fix without having to buy a HDFury device.

1 Like

It’s a kernel patch, not a Kodi patch.
The next kernel sends the correct metadata.

If I understand correctly, do you want to just not send HDR metadata or do you want HDR to SDR conversion? Either are fairly simple to achieve.

No conversion. Just not sending the mastering display luminance values (the last two values found in SEI type 137, or the entire message if not possible) and no maxcll/maxfall (all of SEI type 144).

When will the next update be released?

When it’s ready.

1 Like

It’s possible not to send the EOTF, but I can’t imagine the picture looking very good…

By EOTF, do you mean the SMPTE ST2084 transfer characteristic? I’m not too familiar with how the HDMI signal works exactly, but I imagine the HDMI signal for HDR10 consists of signalling BT2020 color space + SMPTE ST2084 as the specified transfer characteristic. If either one is missing the TV will not see it as HDR10, I guess.

I just want to remove the HDR10 mastering metadata found in the content itself (Mastering Display Luminance Min/Max, MaxCLL, MaxFALL - or all of metadata if it’s impossible to remove just these to keep the DCI-P3 signal).

If you’re interested in knowing why:
LG OLEDs treat no mastering data like it’s 4000cd/m2, which is what I want. With its Active HDR enabled this would allow me to have a “one fits all”-solution for pretty much all content. Because signals which fall into the range 0-539cd/m2 or 801-1199cd/m2 (either via MaxMDL or MaxCLL) will make the TV use a bugged tone curve that cannot be fixed or corrected via calibration. This bug was introduced in some past firmware update on 2017 OLEDs and has been confirmed by industry professionals. Knowing LG, this won’t be fixed.
The TV’s 4000nits curve however is not bugged. So having the Vero just send 4000 all the time (or nothing at all) will be perfect and with ActiveHDR enabled (LG’s dynamic tone mapping feature) this will make lower luminance content still appear correctly.
Any other workaround would be too content-specific.

If you could consider some sort of switch one could change via SSH or something that strips the metadata (or overrides it with something else) for a future release, that’d be very nice. Because for right now I had to write myself a HDR10 metadata editor tool to change/remove all of the relevant SEI messages from a HEVC stream in a file before watching it :sweat_smile: Spending money on an HDFury just seems insane to me just to fix what LG broke via software.

I imagine there are more use-cases for stripping HDR metadata, since UHD BD-players have this feature as well.

1 Like

I’m not surprised the 2017 OLED HDR is messed up. The conclusion seemed foregone when the built-in app etc was also showing borked results with those HDR test patterns.

Thanks, LG. Thanks.

Yeah, that was basically 2 issues masquerading as one. One was the Vero not correctly sending even the Min/MaxMDL data and then it turned out the 2017s do some other weird stuff. That was a damn rabbit hole. You wouldn’t believe what kind of dumb stuff the TV does for no logical reason whatsoever - for example, it applies tonemapping to movies that don’t need to be tone mapped at all while it skips tonemapping (correctly) for movies that barely make it into the panel’s luminance capabilities, i.e. it makes extremely dim movies even dimmer. And the 1000nits curve has a life of its own. Movies using that curve can appear just as dim as with 4000nits in some situations. There seems to be some dynamic component to the 1000nits curve’s behavior that makes it unpredictable, unrealiable, uncalibratable, and unmeasurable.

The easiest solution is to just force 4000nits (or no luminance data, the TV itself will then default to 4000nits) and enable Active HDR. People that don’t like Active HDR’s “delay” in some high luminance scenes are out of luck though or need to live with other drawbacks.

In the past firmware(s) they changed a lot in regards to HDR on 2017 models (MaxCLL tracking instead of MaxMDL, change to Active HDR, buggy tone curves, etc.). So a lot of stuff you read online about how 2017 LG OLEDs handle or track or perform with HDR content is pretty much out of date. Especially the PQ EOTF tracking for 1000nits content. Most professionals have abandoned “analyzing” that TV since it’s 2 generations old and most of their clients buy 2018/2019 models which they want calibrated.

Edit: I should mention - when I got the TV 2 or so years ago, I calibrated it and none of today’s issues were present back then. And it’s not just some weird behavior on my TV.

1 Like

You could force vero not to signal HDR by spoofing an EDID with no HDR capabilities. But it would do a HDR->SDR conversion about which a few column-inches have been expended in here. Anything else will need some kernel surgery which is not going to happen on the 3.14 kernel now.

I do not want to remove the HDR signal, just the HDR mastering luminance metadata associated with the video file played.

I know.

1 Like

So the curiosity got to me and I had a look through /drivers/amlogic/amvecm/amcsc.c on GitHub (which I assume is for the old kernel). There’s a variable customer_hdmi_display_en which is associated with an array of customizable HDR10 metadata customer_hdmi_display_param. Those variables are being set via module_param() and module_param_array() which seem to make the amvecm_cp_hdr_info() function use the custom HDR10 metadata instead of the actual metadata.

I thought the solution is basically already there and would just require me to override the two /sys/module/am_vecm/parameters/customer_hdmi_display_xxx files on my Vero. I did and it works!
(Side note: when filling DRM_DB in hdmitx_set_drm_pkt() you correctly have divided the MaxMDL by 10000 previously in amvecm_cp_hdr_info() when passed on from the source, since the value wouldn’t even fit into 16bits - but you do not do that if your function uses the custom data from customer_hdmi_display_param). You probably have already reworked that for the new kernel anyway, so it probably doesn’t matter anymore.

Anyway, it (almost) works now just like I wanted it. There’s just one issue: when returning to the main menu I’m stuck on HDR and it won’t revert back to SDR. Is there maybe a solution for this? @grahamh @sam_nazarko If yes, I’d be basically all set :grin:

Glad you found a solution. Maybe someone can suggest some python-fu that can set/reset those module parameters.

Yeah, for now I just have two scripts on my desktop that enable/disable this so that it resets to SDR again. Some python-hook in Kodi or something that does this automatically would be nice but I’m too unfamiliar with Kodi.

Edit:
I’ve put the commands into two python files. One to turn it on, one to turn it off.

I remapped the Stop-button on the remote to execute the script to disable the override before actually stopping the video. This way it gets automatically disabled everytime I finish a movie and it returns to SDR in the menu.
<keymap>...<FullScreenVideo><remote>...<stop>RunScript(/home/osmc/.kodi/userdata/keymaps/hdr10override_stopbutton.py)</stop>...

import xbmc
import os
os.system("sudo bash -c 'echo \"0\">/sys/module/am_vecm/parameters/customer_hdmi_display_en'")
xbmc.executebuiltin("XBMC.Action(Stop)")

To enable it I have to press the Stop-button in the movie list. This will run the script to turn on the override before I press OK to start the video. It’s not as automated as disabling it but at least it’s something for now.
<keymap>...<Videos><remote>...<stop>RunScript(/home/osmc/.kodi/userdata/keymaps/hdr10override_on.py)</stop>...

import xbmc
import os
os.system("sudo bash -c 'echo \"1\">/sys/module/am_vecm/parameters/customer_hdmi_display_en'")
os.system("sudo bash -c 'echo \"9,16,8500,39850,6550,2300,35400,14600,15635,16450,4000,1,0,0\">/sys/module/am_vecm/parameters/customer_hdmi_display_param'")
xbmc.executebuiltin("Notification(HDR10-Override, Enabled with 4000cd/m2, 5000)")

If anyone has an idea how to automate the “enabling”-step, that’d be great. The tricky part is it should only do this for HDR videos of course.
Or we could hope for a module_param()-like solution in the new kernel that works like customer_master_display_en but only for actual HDR content. From what I can tell from the v3-kernel’s source code we’re not that far off from a solution. If I was more experienced in the Linux kernel and its compilation I’d gladly write a patch for the new kernel.

3 Likes

Let me check against 4.9 and see if we can only parse these params when playing HDR content

Sam

2 Likes

Great work. I’ll wait on this for some sort of automated procedure since my missus won’t be excited about manual overrides etc.

Yeah, it’s not the most comfy solution for now. But with the above button remapping everything will work as it does now if you don’t press a special button (in this case Stop) before starting a movie. So for her nothing would change. But whenever you’re there you can just press Stop before pressing Play and that’s it. Everything will revert back to normal when you finish/stop the movie afterwards, regardless if you did the override or not. (Active HDR can stay enabled either way anyway).
It just might be difficult to initially set up for somone who’s just a basic user.

1 Like

Yep, agreed. I’ll keep an eye on it. I haven’t been too bothered by the dimness since the original fix, so I’d be interested to see what this does further…

I will look into the possibility of making it work fully automatic and into an easy to install addon. In theory this should even allow for a solution that doesn’t rely on Active HDR to be always on (its delay can sometimes be a bit distracting in certain situations).

1 Like