Lg oled and setting 444 10bit still required?

Hi, I bought a oled tv and a vero 4k which i set up yesterday. I did lots of research on which device to buy and settled on the vero, really impressed with it. Watched Pacific Rim and Last jedi in 4k and used wifi streaming from a nas drive, didn’t have any buffering issues which i assumed i would have. Hdr symbol in corner of screen did pop up briefly.

I am not sure if the 444 10bit still needs to be manually set or has it been fixed since the March update?
If it needs to be set its done via putty and ssh?
Could someone point me to some easy instructions to follow?

Many thanks

If you want 10-bit output you will want to set it.

I will add a GUI option shortly

I SSH’d into the device but noticed any 1080p bt709 content has funny looking colours. I believe this has already been covered so i will just wait until its fixed.


Thanks for clarifying the problem. The problem occurs when setting 444,10 manually. Ideally, we should switch to this mode only when the content being played warrants this.

I’ve had a play with detecting colour primaries and should be able to add an option to automate switching only when necessary




i have an LG OLED TV for HDR10 YCbCr 4:2:0 do i need to activate any setting ?

i have a weird greenish effect on some HDR 4k movies;
Thanks for your help,

Can you take a photo so we can see?



1 Like

I managed to produce a green effect when i tried to use 420 12 bit.

Yes – that’s a known issue for the moment.

But OSMC shouldn’t be automatically switching to that output at this time.

Hope you guys don’t mind me hijacking/necromancing this thread. Yesterday I had the ominous colour problem for the first time.

LG B6D, HDMI Ultra Deep Colour is activated for the HDMI port.

Vero 4K connected with enclosed HDMI cable to HDMI1. HDR autoswitch on. Adjust display refresh rate on start/stop. GUI 1080p60. Delay after change of refresh rate 1.0 seconds. /sys/class/amhdmitx/amhdmitx0/attr is empty during idle and shows reset during HDR playback.

Every UHD/60FPS/HDR file works flawlessly except for a quite new one. It makes the GUI have its green turned up to 11 (or 257 if you want). Like that:

The .nfo of the file in question reads http://paste.osmc.io/venuleribu.avrasm
The only thing I found to differ from other working UHD HDR files is line 25: Mastering display color primaries : R: x=0.340000 y=0.160000, G: x=0.132500 y=0.345000, B: x=0.750000 y=0.300000, White point: x=0.156340 y=0.164500 A quick search for this interestingly leads to this thread on kodi.tv with a similar problem. @Theetjuh answered there as well. As far as I’m able to understand the problem – which isn’t very far –, it is caused by the file erroneously announcing its colour space to the playback device.

A two minute sample can be downloaded here. If you haven’t guessed already, it’s a UHD BD remux.

If you need any logs, just tell me which of the categories should be checked and I’ll provide them. Simply ticking all seemed overkill to me.

Never assume this.

http://paste.osmc.tv/yozujolisi (edited to contain everything except the fstab because the first try included passwords for NFS mounts. This is one of the reasons why I was asking what’s necessary. :frowning: Edit two: Ugh, if guisettings.xml is check for the logs, it contains the password set for chorus.)

Rebooted, played 20 seconds of the file, uploaded log. It’s still a lot to go through.

You can turn off HDR autoswitching and use the hotfix method for now, or wait a couple of days where I’ll put up some new HDR improvements


Since http://paste.osmc.tv/ebuhuyajej and https://paste.osmc.tv/raw/edawoyazuh aren’t available anymore, I edited rc.local and also /sys/class/amhdmitx/amhdmitx0/attr accordingly. No change. It’s still just this one file that acts up.


If there’s a solution a few days ahead, I’ll gladly wait for that.

Did you verify attr to make sure it’s being set properly?


Just realised rc.local wasn’t set to be executable, my bad. Didn’t change anything, though, as before I also manually echoed 444,10bit to attr.

Try the two-minute sample for yourself.

The green GUI is due to the incorrect HDR10 metadata. The mastering display metadata is totally wrong. Correcting the metadata will fix the green GUI issue. You can test it out with this corrected clip.


What did you do to correct it?
I wonder if there’s something we can do to work around this.

(Good spot).


HDR10 metadata has to be corrected in HEVC SEI message. Other than setting it to ignore the metadata, I don’t see any other work around for this issue. This particular issue is due to a bad encode.

Thanks. Didn’t check the clip yet, but I will see if we can pick up obvious red flags and simply refuse to pass through the meta data.

Just wanted to clarify that the video itself plays back fine. It is the GUI that is green. There may be something in Amlogic compositing code that relies on HDR10 metadata.