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?
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
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.
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. 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.
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.
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.
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.
Edit two: Ugh, if guisettings.xml is check for the logs, it contains the password set for chorus.)