HDR Slight flickering (Workaround available)

I’m experiencing slight color flickering in grey areas of the image of HDR videos, for instance the clouds in this sample. You’ll see red and green pixilation pulsing in a regular pattern, like the decoder doesn’t know what color it should be.

I’ve come across it in other HDR files as well (also only in grey areas). It’s not present when using the software decoder or viewing the file through the player of my TV. (LG OLED 55B6)
I’ve not noticed it in SDR footage.

Hi

Are you on the latest version of OSMC (2017.07-1)?
Have you followed the rc.local advice here?

Sam

I’m on the latest version. Should I still try the rc.local advice?

I added

echo ‘444,10bit’ > /sys/class/amhdmitx/amhdmitx0/attr

to /etc/rc.local and rebooted but this didn’t solve the artifact.

OK – I’ll check out the sample and see what can be done. It might be a bug in amports.

Sam

This feels very familiar. I have/had the same issues and ended up running 10bit/hdr on my TV (LG 55b6) exclusively for now. Does 4k HDR 60fps video work for you? I had issues with 24hz stuff. If I run the latest osmc without the rc.local edit (meaning 8bit instead of 10) through my amp, everything is well (except no HDR).

The LG TV won’t accept a 4:4:4 signal unless you put the input in PC mode which disables all movie features.
You can try to edit the RC local to 420:12bit and set kodi to 2160p default and disable change refresh rate, this should kinda work.

You have the Vero connected straight to the TV right?
I’m waiting to buy a new amp soon with hdr support to see if that changes anything. I think the LG is just picky on input signals

I have it with and without the rc.local edit.

Setting the TV to PC mode didn’t make any difference, deep color was already on btw, and neither did disabling change refresh rate.

I have it connected through an amp.

For clarity though, this isn’t a case of the TV not recognising the HDR signal. It recognises and plays back HDR content from the Vero just fine, with the exception that in mid-gray areas I have a slight color shimmering, as if something can’t decide what that color should be exactly. As it’s only in mid-grey areas it’s only a minor issue, but can be very noticeable in case there’s a lot of grey in the image, like an overcast sky like in the sample I provided.

Could you try this file http://demo-uhd3d.com/files/uhd4k/The_World_in_HDR_in_4K_HDR10.mkv ? It’s a 60fps hdr file which Always played fine for me (before and after patch).

I’m guessing this is what your problem looks like https://goo.gl/photos/NpTcdQnh11rxzZcH7 ? (Still present with a paused video)
Or like this (video where I first play from TV and then switch to Vero input) ArrivalTest - YouTube

You can read my notes in the 10bit test thread from a while back [TESTING] 10-bit, HDR and dithering improvements - #31 by Martorias

Edit: regarding the 4:4:4, from rtings.com “After some more testing we have found that none of the LG TVs support chroma 4:4:4 when in a HDR picture mode, regardless of the input icon.”

It seems to be the same problem.

I also noticed my Vero might not switch to 4K on playback and the resolution setting in Kodi is greyed out for some reason.

I just noticed the same. I kinda forgot about it after I gave up but I just noticed that it doesn’t switch to 4k of the interface is 1080p. I can change the resolution in kodi to 2160p and then videos play in 4k again (my amp won’t put through hdr though)

I fixed the resolution issue for me (I tried plugging it in directly to the TV, which fixed it, and after I reconnected the Vero to the amp and rebooted it worked again. In my case it could have to do with rebooting while my TV isn’t on.

Now that that’s fixed the rc.local edit (444, 10 bit) results in the image cutting out with HDR footage. Removing the edit fixes it, but I believe that’s a known issue and is outside of the scope of this thread.

The files in question are 4:2:0 anyway, so 4:4:4 playback or not shouldn’t be the issue.

According to this table LG OLED only supports 4:2:0 at 10 bits, which is also the subsampling the UHD Bluray standard uses.

Hey could you try something for me?
If you start a clip and pause it where it flickers then run
echo 2160p60hz420 > /sys/class/display/mode

Will that remove the flickering?

I does remove the flickering.

When I do cat /sys/class/amhdmitx/amhdmitx0/disp_cap
It seems the TV don’t report 2160p24hz420 just 50 and 60hz. I’m not sure why the TV doesn’t like that, if it’s a limitation or something with the HDMI driver

Mine does neither:

(…)
2160p30hz
2160p25hz
2160p24hz
smpte24hz
smpte25hz
smpte30hz
smpte50hz420
smpte60hz420
2160p50hz420
2160p60hz420

So whenever we try to play 10bit 2160p 24hz stuff it defaults to “regular” 2160p24hz which might be why it’s not working. I tried to force the display mode but that didn’t help. The LG is supposed to be able to handle it so not sure what we can do.

Sam, do you know if there’s anything else we can try or if there’s some changes to the HDMI driver that can be done?

Hi,

Thanks for letting me know about the limitations of the LG OLED sets. The list of currently supported video modes are:

const char *disp_mode_t[] = {
        "480p60hz",
        "576p50hz",
        "720p60hz",
        "1080i60hz",
        "1080p60hz",
        "720p50hz",
        "1080i50hz",
        "1080p30hz",
        "1080p50hz",
        "1080p25hz",
        "1080p24hz",
        "2160p30hz",
        "2160p25hz",
        "2160p24hz",
        "smpte24hz",
        "smpte25hz",
        "smpte30hz",
        "smpte50hz",
        "smpte60hz",
        "smpte50hz420",
        "smpte60hz420",
        "2160p50hz",
        "2160p60hz",
        "2160p50hz420",
        "2160p60hz420",
        NULL
};

vout has more modes. I’ll see what can be found out.

Looked in to this:

only 2160p60/50hz smpte60/50hz have Y420 mode

This indeed seems expected, and validation checking was added upstream by AML some time ago.

commit f7cde58dcab4d7fc974e32b6ef80eed67bc12de4
Author: Zongdong Jiao <zongdong.jiao@amlogic.com>
Date:   Wed Feb 22 11:03:52 2017 +0800

    PD#139639: hdmitx: optimize 'valid_mode' checking
    
    For Y420 modes, only 4k50/60hz modes have this colorspace.
    Forbidden for any other hdmi modes.
    
    Change-Id: I6d01d03d15fbcdcc4711b8d1de7404b3c15193af
    Signed-off-by: Zongdong Jiao <zongdong.jiao@amlogic.com>

Some more pointers on picking the right mode:

 1) Add '/sys/class/amhdmitx/amhdmitx0/attr' node for hdmitx output
    format setting. For example, '422,12bit'.
    / # ls -l /sys/class/amhdmitx/amhdmitx0/attr
    -rw-rw-r-- root     root         4096 2015-01-01 00:00 attr
    2) Should be setted 'attr' before setting 'sys/class/display/mode',
    otherwise it will be YCbCr 444, 8bit by default.
    3) Before setting colorspace and colordepth, you can get RX info by
    / # cat /sys/class/amhdmitx/amhdmitx0/dc_cap
    420,10bit
    420,8bit
    444,10bit
    444,8bit
    422,10bit
    422,8bit
    rgb,10bit
    rgb,8bit
    4) Add '/sys/class/amhdmitx/amhdmitx0/valid_mode' for test whether
    mode is supported by RX.
    5) If RX has no MAX_TMDS_CLK2, consider that don't support 5.94G mode

Sam

Ok, so no TV has 2160p24hz420 from the Vero then? What display mode do others use when viewing 2160p24 10bit material? Right now for us it defaults to “regular” 2160p24hz, and while it’s trying to send the video something gets weird and we get flickering. So far this only seems to affect LG (oleds?).
Is there any way to trick it to switching to 2160p60hz420 when playing a 24fps file without having the UI in 4k? (Except for manually echoing the display mode) or do you have some other ideas? :slight_smile: