[TESTING] Vero 4K / 4K + video improvements

Not sure where you are, now. You should get 8-bit output if you

  • don’t enable 444,10bit in rc.local
  • don’t enable HDR autoswitching
  • run the release kernel (ie the revert instructions in the OP)
  • reboot

When this happens, what is the output of cat /sys/class/amhdmitx/amhdmitx0/config?

I’ve run the above. All seems well (ie, 10-bit HDR files play with no banding issues and are reported as 10-bit by the TV).

The only issue I’m experiencing is all 8-bit SDR files are being reported as 10-bit by the TV. I’m assuming this is due to 444,10bit being enabled in rc.local. Would you know how to disable this? And once disabled, would I be expected to experience any issues?

Thanks for your help with this Graham!

When playing an 8-bit file it returns (TV reporting 10-bit);

cur_VIC: 32
cur_video_param->VIC=32
cd = 5
cs = 2
audio config: on
3D config: off

When playing a 10-bit file it returns (TV reporting 10-bit);

cur_VIC: 93
cur_video_param->VIC=93
cd = 5
cs = 2
audio config: on
3D config: off

So ATM you are running the release kernel with 444,10bit in rc.local. So all output is 10-bit. For proper testing of the test kernel, you need to disable the line in rc.local by deleting it or commenting it like this

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

Use nano to edit it sudo nano /etc/rc.local. Reboot.

OK, thanks for that Graham. I added a ‘#’ to the line in rc.local to make it a comment as you suggested and rebooted. As expected, with the ‘release’ kernel both 8-bit and 10-bit files are reported by the TV as being 8-bit.

I then re-applied the ‘test’ kernel, ensuring HDR auto-switching was disabled. Both SDR 8-bit and HDR 10-bit files report as 8-bit by the TV and banding is present on 10-bit material.

Output of cat /sys/class/amhdmitx/amhdmitx0/config as follows;

10-bit material;

cur_VIC: 93
VIC: 93 3840x2160p24hz
Colour depth: 8-bit
Colourspace: YUV444
Colour range: limited
EOTF: HDR10
PQ colour range: limited
audio config: on
3D config: off

8-bit material;

cur_VIC: 32
VIC: 32 1920x1080p24hz
Colour depth: 8-bit
Colourspace: YUV444
Colour range: limited
EOTF: SDR
PQ colour range: limited
audio config: on
3D config: off

Did a few tests, works perfectly (also reported by TV/AVR)!

24hz material shows:

cur_VIC: 93
VIC: 93 3840x2160p24hz
Colour depth: 10-bit
Colourspace: YUV444
Colour range: limited
EOTF: HDR10
PQ colour range: limited
audio config: on
3D config: off

And 60hz materials shows:

cur_VIC: 353
VIC: 353 3840x2160p60hz
Colour depth: 10-bit
Colourspace: YUV420
Colour range: limited
EOTF: HDR10
PQ colour range: limited
audio config: on
3D config: off

And even when I put the GUI at 3840x2160p50hz (perfect in 8bit SDR)

cur_VIC: 352
VIC: 352 3840x2160p50hz
Colour depth: 8-bit
Colourspace: YUV420
Colour range: limited
EOTF: SDR
PQ colour range: limited
audio config: on
3D config: off

Good job guys!

1 Like

Interesting but it shouldn’t happen. Or are you saying that’s a 4k SDR clip? There’s a new version of the test kernel floating around but I don’t know why Sam hasn’t posted it here.

Could you engage debug logging, reboot and try that clip again and post the logs, please?

I meant the Kodi GUI, so in the menu.
Previously when you set 10bit,444 the menu was overexposed because it was displayed with a BT2020 color scheme.

Hmmm. I never found that and it would not have been BT2020 for the GUI. The ‘over-exposure’ must have been something else. But if it’s working now, that’s good to know.

Have a search on the forum there where multiple people reporting this issue … but that doesn’t matter anymore, since it now is working correctly.

The default colour range for some situations was full. Can’t think why so we changed it to limited.

Done. Log files available here; Logs

Thank you.

Your media seems to be coming from a plex server. The bitdepth isn’t being recognised early enough. Can you confirm if this 8-bit behaviour happens with all your 10-bit titles?

I’ve never used plex so I’m not sure how it works. Could you try copying one movie to a local disk and playing it from disk so we can see if it’s plex that makes the difference?

Got my Vero4k+ yesterday. First time using any of this stuff. Noticed the banding when playing Sicario - AVR confirmed it was capable 10bit. Some movies were fine, others not. Once a ‘not fine’ movie played, all others would be stuck at 8bit also

Saw a couple of previous posts so used the command lines to SSH in and check my logs - all looked good.

Just updated to this beta Kernal. HDR Switch off, menu resolution 1080p

All movies working at 10bit! Has also fixed washed out colours of Coco, that was outputting 10bit but didn’t look right.

1 Like

Your media seems to be coming from a plex server. The bitdepth isn’t being recognised early enough. Can you confirm if this 8-bit behaviour happens with all your 10-bit titles?

Yes, all 10-bit files exhibit this behaviour. Whether played via the Plex Server, or direct SMB path.

I’ve never used plex so I’m not sure how it works. Could you try copying one movie to a local disk and playing it from disk so we can see if it’s plex that makes the difference?

Same file played via ‘Video>Files’ via direct SMB pathing in Kodi. Again, TV reported this as being 8-bit. Log files available here; https://paste.osmc.tv/osuyutefow

Improvement for me…

osmc@MBRVero4Kplus:~$ cat /sys/class/amhdmitx/amhdmitx0/config
cur_VIC: 93
VIC: 93 3840x2160p24hz
Colour depth: 10-bit
Colourspace: YUV444
Colour range: limited
EOTF: HDR10
PQ colour range: limited
audio config: on
3D config: off
osmc@MBRVero4Kplus:~$

With sicario, 10bit, I have this output (with banding):

cur_VIC: 93
VIC: 93 3840x2160p24hz
Colour depth: 8-bit
Colourspace: YUV444
Colour range: limited
EOTF: HDR10
PQ colour range: limited
audio config: on
3D config: off

Can you post debug logs for this case, please?

Can you remind me what TV and AVR you have? Between them, they are not indicating support for 10-bit signals.