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

Panasonic TH-55EZ950U OLED TV and a Yamaha YAS-107 soundbar, both of which support HDMI 2.0a.

I also tried playing the same 10-bit file with the soundbar out of the loop, ie a direct Vero 4K > TV connection. Same result. TV reports 8-bit signal. Log for this here; https://paste.osmc.tv/xusixuwonu

The odd thing is the TV does report a 10-bit signal, with no banding being present, when forced by enabling 444,10bit in rc.local

Thanks for that. Can you try the latest kernel, please?

To test this update:

  1. Login via the command line
  2. Edit the file /etc/apt/sources.list
  3. Add the following line: deb http://apt.osmc.tv stretch-devel main
  4. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  5. Your system should have have received the update.

Please see if the issue is resolved.

I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.

This kernel has also some experimental networking improvements (wired ethernet). If you find any side-effects then let us know.

Oct 01 06:46:31 osmc kernel: hdmitx: video: VIC: 3 (93) 3840x2160p24hz
Oct 01 06:46:31 osmc kernel: hdmitx: video: Bit depth: 10-bit, Colour range: limited, Colourspace: YUV422

Log shows the colorspace is being set to YCbCr 4:2:2 when switching to 4K24. Only advanced HDMI protocol analyzers can detect the true color bit depth of YCbCr 4:2:2 signal. Most devices simply go by the color bit depth bit set in HDMI GCP which is not used for YCbCr 4:2:2 pixel encoding. Most devices would show the color bit depth incorrectly as 8-bit. Denon AVRs would display it as “—”.
In this case, the TV reports 10-bit depth for YCbCr 4:4:4 signal because the CD bits are set to 10 indicating Deep Color Mode YCbCr 4:4:4 encoding.

We are sending 422 in this case because the EDID reports a MaxTMDSClock of 300MHz and no higher rate clock. Therefore YUV444,10-bit is not apparently supported. Going through the AVR, EDID VSDB(HDMI) byte 6 is also indicating 12-bit support but not 10-bit which is consistent if you equate 12 bits with 422. I’m not sure yet why we are sending only 8 bits, but the newer kernel (121) handles it differently which may help.

The log from direct connection to the TV also indicates no higher rate TMDS clock but does indicate 10-bit support (byte 6 is b8, not a8). I wonder if @monochromic rebooted after plugging vero into the TV direct or at least re-started Kodi to re-read the EDID. His TV does 4k@60p so a higher rate clock should be available.

I would lay money the received signal is actually 8-bit if banding is apparent.

Done. Rebooted. Log file here; https://paste.osmc.tv/pamokamiqa

This is again a direct connection of Vero 4K > TV. One odd thing I did notice was that playing the file directly via SMB and the Kodi interface resulted in a 4:2:2 8-bit signal being reported (with no banding), whereas if I played the same file via the Plex-for-Kodi add-in (and hence via Plex Server) it resulted in a 4:4:4 8-bit signal (with banding). Odd.

1 Like

Byte 6 of VSDB indicates Deep Color Mode support for RGB/YCbCr 4:4:4. YCbCr 4:2:2 support is a global declaration in byte 3 of CEA extension header block. Deep Color doesn’t apply to 4:2:2 encoding.

The TV does support 600MHz pixel clock. It doesn’t look like @monochromic has enabled 4K Mode 2 for the input. The input is probably in Mode 1 which is limited to 300MHz pixel clock.

If the output signal from Vero is indeed 10-bit YCbCr 4:2:2 as shown in the last two logs that @monochromic has provided, the 8-bit that is shown on the TV info page can simply be ignored. If it is 8-bit YCbCr 4:4:4 output, then it should be looked into.

I switched to HDMI ‘Mode 2’ for the Vero HDMI input. Same results being reported however, 4:2:2 and 8-bit. No banding present whilst playing the 10-bit file.

Again, playing the same file using the ‘Plex for Kodi’ add-in and it’s reported at 4:4:4 and 8-bit by the TV. But this time banding is present. Odd, as the add-in is obviously using the Kodi playback engine.

Log for the above here; https://paste.osmc.tv/koxajebuve

Thank you and @wesk05 for his usual excellent advice. I was puzzled because my 2017 Panasonic does render 422, 10-bit properly on it’s HDMI3 input which is ‘Mode 1’ only.

Also the distinction between Mode1 and Mode2 is not clear in the Panny manual I looked at. Just now trying to understand why vero was sending 8-bit to your TV when it sends 10-bit to mine in apparently the same situation. Could it be that even on Mode1, you were receiving 10-bit when not playing from Plex? You didn’t mention whether there was banding under this condition.

As for Plex, looks like some more work on Kodi is needed. Then we have the problem of playing through your soundbar. Did you test that route without Plex?

Should I try the last kernel too @grahamh? Anything usefull from my log?

I had a quick look last night to confirm your issue is not the same as @monochromic’s. Yes, please try the latest kernel.

Ok, I’ll try as soon as I’ll arrive to my home after work tonight and I’ll let you know!

Yes, a massive thank you to you both for your help on this! Has been most appreciated. Fingers crossed we can get to the bottom of the issue.

Yes, when I had ‘444,10bit’ enabled in rc.local, the TV reported receiving a 4:4:4 10-bit signal when playing a 10-bit file via either SMB direct path through Kodi or when playing via the ‘Plex for Kodi’ add-on. The TV’s HDMI input for this was set to Mode 1. There was also definitely no banding present in this situation.

Yes, I tested this playing the file straight from Kodi (via SMB direct path, no Plex in the loop) without the soundbar in the chain. Results for this are a few posts up.

No, I mean direct from SMB, with the soundbar. If that works, then it’s only Plex we have to address.

Ahhh… gotcha. Playing the 10-bit file straight from Kodi, with the soundbar in the chain, yields 4:2:2 8-bit reported by the TV. No banding is present.

2 Likes

We are getting there, then. I checked my Panny this morning on HDMI1 with Mode1 and it works (ie 10bit with no banding). I’m running kernel 121, but there’s no reason I can see why the kernel you have should be different. Perhaps you could do the upgrade so we on the same page.

Discovered if I set the GUI to 4k,30Hz and play a 4k,60Hz vid on Mode1, I get 444, 8bit output. Will look into that. Just a warning if anyone is following this.

Does anyone know how to check the display info (resolution, colordeep etc) on OLED LG with WEBOS 4 running on it?

I can’t help you with LG. I’m testing with this The World In HDR UHD 4K Demo | 4K Media

If you see banding in the sky over the skateboarder in the second scene or over the Taj Mahal, you are likely on 8-bit.

Oh I’m pretty sure I’m on 8bit, I’ve noticed banding on Solo and Sicario (10bit both), I just want a confirm from the TV, if possibile

We can all probably just rely on our eyes when it comes to whether 422 is output with proper 10bit (padded to 12bit) as @wesk05 correctly pointed out. Even Denon AVRs which already show more information about the audio and video stream than most consumer equipment don’t show the bit-depth of 422 video. And the 8bit your TV is advertising with 422, @monochromic, will most likely also be what @wesk05 said: wrong information about bit-depth. But as long as banding is gone and video playback just works as expected, we should be coming closer… :+1:t2: