For those having issues with a black screen once the Vero 4K kicks into 10bit mode, I encourage you to try changing your HDMI cable. The cable that shipped with my Vero 4K didn’t like 10bit mode but once I swapped it for a High Speed HDMI cable I had lying around 10bit fired up as expected.
Also, may seem obvious, but if you’re connecting to a receiver ensure you’re using a HDMI port that supports what you’re after (I know on modern Denon’s the front HDMI port is less capable than the others. They also encourage you to use a port closest to the TV ARC port).
@dhruv
That fixed it. I swapped the supplied Vero 4K cable with my Xbox One X cable, enabled autoswitching and I now get displayed (3840x2160) 23 Hz YCbCr 444 30 bit.
30 bit has never shown before, just 24 bit (with autoswitching off). I suppose the 24 & the 30 are just multipliers?
Is that correct?
Wonder why it does not just show 8 bit & 10 bit. Maybe it has something to do with the Onkyo.
Darn glad I don’t have to learn how to get in to configure commands.
I am playing Dunkirk & Blade Runner 2049 and there is some light banding when looking at the sky.
I find it strange that the Vero 4K cable does not do 10 bit. Something Sam needs to change quickly so as to mitigate this problem found with the currently supplied cables.
This is very interesting as we should both be experiencing similar problems. What else is connected to your tv? I currently have only the vero4k connected directly to the tv. What hdmi cable are you using? I am using an amazon basics one, not the one that came in the box.
I got new HDMI cables and it’s working perfectly now!
I get 4:4:4,10bit all the time now, with HDR auto switch OFF and forced 4:4:4,10bit output in rc.local.
Without sounddropouts or artifacts.
BUT it only works with the closest HDMI IN (GAME) to HDMI OUT on my Denon X1300W.
When I use the Media Player Input I get artifacts and sounddropouts like before.
Looks like it´s the crappy hardware of the Denon, that can´t handle the bandwidth on all ports.
For the cables:
Get ones with class Highspeed with Ethernet and 18Gbps throughput, but below 3m length and you should have no problems.
@sam_nazarko: whats the best practice now after the OSMC April update regarding this issue?
Can we remove the line from rc.local now and get correct output?
I don´t want to use the HDR auto switch as long as it´s experimental.
The hdr auto switch from my understanding is for 10bit rec709 videos which is not a standard and hasn’t crossed my path yet. Most 10bit stuff will be bt2020 hdr so just leave that line for now imo
@CaptainMoody either sudo echo “444,10bit” or just sudo echo 444,10bit it doesn’t matter it’s just one “word”. I’m using it successfully without any quotes.
Just tried, banding issue is solved for me, thanks.
However I still have an issue which I tought was related but in fact it’s not. I get some pixelisation around moving parts sometimes, typically a fast moving-object with a complex background. I tried another hdmi cable with no luck. Anyone experienced same issue ?
I continued debugging on the March release. Changed HDMI cable from “generic” to the cables included with Vero4k, no change in behavior. I run my Vero4k directly to the TV, so I can’t see the META data on the actual HDMI connection…tricky. Even had two separate and different 4k encodings of the movie…Anyways, I realized I had no exec rights set on /etc/rc.local, so it didn’t run. After that was fixed I saw different image behavior when fiddling with the dither1, round0, round1 depending on whether 444,10bit was written to …/attr or not. In the end, as I noted earlier only dither1 fixed my issue, regardless if 10bit mode was activated or not.
Ultimately i upgraded to April release (again), had exec rights on /etc/rc.local with the 444,10bit force fix and it solves the banding issues without any need for any cmd line haxx. Phew. What an annoying problem that was.
what’s it used for?