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

Installed the latest updates, kernel is still 3.14.29-133-osmc, mediacenter updated today (vero3-mediacenter-osmc_17.6.0-60).

Some quick testing:

Reboot: still no picture during reboot.

Playback of 4K media: still no playback of 4K media after reboot

After “echo422now”: 4k24 HDR and 4k60 HDR play back fine.

Dark scenes/dark content in 4k HDR media is still too dark (overall brightness is fine, just dark detail gets lost).

1 Like

Good. This is expected as your beamer apparently cannot handle 444 or 420 at 4k. You will have to add echo 422 > /sys/class/amhdmitx/amhdmitx0/attr to rc.local.

If your Sony is correctly recognising the input as HDR and the Denon isn’t messing with video, I can only suggest looking at adjustments (brightness+, contrast - perhaps) on the Sony.

Unfortunately contrast adjustment is still not persistent. On resuming playback from a resume point for a 4K file with the contrast previoulsy set to a high value to compensate for the dark profile of the HDR>SDR conversion, the contrast adjustment is not active.

Contrast adjustment also not active if resume playback from start of the file. The moment I touch the contrast adjustment slider, the contrast jumps up considerably, that seems to be the only circumstance in which the adjustment activates.

Just installed the latest updates.
Playing files from Vero to LG C8 via Denon X-3500h
All 4K files with HDR are playing fine now! (before update no picture when using auto refresh rate)
4K24 files are 4:4:4 and 4K60 are 4:2:0

I’m a happy user now! :slight_smile:

1 Like

Mh, strange. Before the update it worked to play 4k movies with Auto Refresh Rate On (using the CEC trick) on my LG C8 without any problems. But now, after the update, I can’t play 4k movies anymore again, (no picture/signal). I checked and tried the settings several times. Even with the CEC trick it doesn’t work. Only when I switch off the Auto Refresh Rate again.

The Vero4k is connected directly to the TV with the supplied cable, without AVR or anything else.

After echo 422now it works! But that shouldn’t be the normal way?

No it shouldn’t but it seems this ‘normal’ for certain LG models. Thanks for the feedback.

Sorry to say that it’s not working for me. LG C8 (55").

Followed the instructions, changed Adjust display refresh rate to Always. 4K content doesn’t play. Happy to help if there’s anything else I can try.

Edit - ran echo 422now | sudo tee /sys/class/amhdmitx/amhdmitx0/attr and 4k is playing now

Edit2 - how rude of me - massive thank you for your efforts in this. Dealing with what appears to be a shonky implementation from LG is hugely appreciated :smiley:

5 Likes

Followed the instructions but uname -r still tells me i’m running 3.14.29-119-osmc

Hi,

Please provide logs:

grab-logs -a

post the link here, this will provide your apt history; this should tell us why the update didn’t complete.

Thanks Tom.

@sam_nazarko this is expected manual action for LG C8? Or should we wait for another patch that will try some CEC trick?

Edit1: After I got home from weekend house, I tried out of curiosity some HDR and it did not play even with CEC trick. So I updated to 3.14.29-133, added 422 and it works great. Thank you for this!

Steps I did:
sudo nano /etc/apt/sources.list
added line deb http://apt.osmc.tv stretch-devel main
sudo apt-get update && sudo apt-get dist-upgrade && reboot
echo 422now | sudo tee /sys/class/amhdmitx/amhdmitx0/attr
sudo nano /etc/rc.local
added line echo 422now | sudo tee /sys/class/amhdmitx/amhdmitx0/attr

Edit2: Looks like I see terrible lagging (or flickering or what is it) when playing Life Untouched HDR UHD 4K Demo | 4K Media - first 5 seconds camera goes up with tree on the right. The tree itself is flickering a lot (or banding or how the effect is called?) . Both 422 enabled/disabled in attr. I don’t think it was there before

1 Like

This is looking good so far.

Are there any video performance improvements in this? A couple of my test clips are now playing smoothly when, as far as I can remember, they weren’t before.

My Billy Lynn’s Long Half-Time Walk clip doesn’t seem to be skipping frames any more (or is skipping a lot less, anyway, I’m not sure if it’s perfect yet).

And also one of the jellyfish test clips - 120Mb/s, 29.97fps, 2160p, h.264 - is now glassy smooth, but I seem to remember it staggering before. Possibly Mr @direx might want to retest his 4K24 h.264 stuff with this patch.

EDIT: Could be placebo effect :slight_smile: but I think my iperf3 numbers have improved a bit too. (That’s a bit more expected).

Output of apt-get update and dist-upgrade:- osmc@osmc:~$ sudo apt-get updateIgn:3 http://ftp.debian.org/debian stretch InR - Pastebin.com

Logs:- https://paste.osmc.tv/zabuvuqahe

Thanks

Same here.

Please try:

sudo apt-get install --reinstall vero364-image-3.14.29-133-osmc

IIRC 133 is the latest. I’m away from my devices atm.

Yep, that did the trick.
Thanks Graham.

That worked, Thanks.

I don’t know if this is a new thing or if it was doing it anyway, but as you say you’ve made changes to the Ethernet driver: I’m getting rather low iperf3 numbers using UDP.

With TCP it’s fine:

osmc@Vero4K:~$ iperf3 -c 192.168.1.13
Connecting to host 192.168.1.13, port 5201
[  4] local 192.168.1.175 port 60562 connected to 192.168.1.13 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   105 MBytes   878 Mbits/sec    1    220 KBytes
[  4]   1.00-2.00   sec   113 MBytes   947 Mbits/sec    0    247 KBytes
[  4]   2.00-3.00   sec   113 MBytes   948 Mbits/sec    1    192 KBytes
[  4]   3.00-4.00   sec   111 MBytes   934 Mbits/sec    2    123 KBytes
[  4]   4.00-5.00   sec   113 MBytes   946 Mbits/sec    1    115 KBytes
[  4]   5.00-6.00   sec   112 MBytes   944 Mbits/sec    0    164 KBytes
[  4]   6.00-7.00   sec   113 MBytes   947 Mbits/sec    0    200 KBytes
[  4]   7.00-8.00   sec   113 MBytes   947 Mbits/sec    2    120 KBytes
[  4]   8.00-9.00   sec   113 MBytes   945 Mbits/sec    0    165 KBytes
[  4]   9.00-10.00  sec   113 MBytes   947 Mbits/sec    0    195 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec    7             sender
[  4]   0.00-10.00  sec  1.09 GBytes   937 Mbits/sec                  receiver

iperf Done.

But with UDP:

osmc@Vero4K:~$ iperf3 -c 192.168.1.13 -u -b 0
Connecting to host 192.168.1.13, port 5201
[  4] local 192.168.1.175 port 39226 connected to 192.168.1.13 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  29.2 MBytes   245 Mbits/sec  3740
[  4]   1.00-2.00   sec  24.9 MBytes   209 Mbits/sec  3190
[  4]   2.00-3.00   sec  28.5 MBytes   239 Mbits/sec  3650
[  4]   3.00-4.00   sec  27.4 MBytes   230 Mbits/sec  3510
[  4]   4.00-5.00   sec  27.6 MBytes   231 Mbits/sec  3530
[  4]   5.00-6.00   sec  29.3 MBytes   246 Mbits/sec  3750
[  4]   6.00-7.00   sec  26.1 MBytes   219 Mbits/sec  3340
[  4]   7.00-8.00   sec  25.3 MBytes   212 Mbits/sec  3240
[  4]   8.00-9.00   sec  27.6 MBytes   231 Mbits/sec  3530
[  4]   9.00-10.00  sec  29.8 MBytes   250 Mbits/sec  3820
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   276 MBytes   231 Mbits/sec  0.036 ms  20/35300 (0.057%)
[  4] Sent 35300 datagrams

iperf Done.

UDP in the opposite direction is okay:

osmc@Vero4K:~$ iperf3 -c 192.168.1.13 -u -b 0 -R
Connecting to host 192.168.1.13, port 5201
Reverse mode, remote host 192.168.1.13 is sending
[  4] local 192.168.1.175 port 54730 connected to 192.168.1.13 port 5201
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-1.00   sec   112 MBytes   943 Mbits/sec  0.086 ms  572/14970 (3.8%)
[  4]   1.00-2.00   sec   113 MBytes   947 Mbits/sec  0.089 ms  27/14470 (0.19%)
[  4]   2.00-3.00   sec   113 MBytes   947 Mbits/sec  0.102 ms  13/14465 (0.09%)
[  4]   3.00-4.00   sec   113 MBytes   947 Mbits/sec  0.112 ms  8/14471 (0.055%)
[  4]   4.00-5.00   sec   113 MBytes   948 Mbits/sec  0.075 ms  14/14469 (0.097%)
[  4]   5.00-6.00   sec   113 MBytes   948 Mbits/sec  0.097 ms  4/14467 (0.028%)
[  4]   6.00-7.00   sec   113 MBytes   948 Mbits/sec  0.095 ms  4/14465 (0.028%)
[  4]   7.00-8.00   sec   113 MBytes   946 Mbits/sec  0.077 ms  39/14471 (0.27%)
[  4]   8.00-9.00   sec   113 MBytes   948 Mbits/sec  0.089 ms  4/14470 (0.028%)
[  4]   9.00-10.00  sec   113 MBytes   947 Mbits/sec  0.083 ms  12/14466 (0.083%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.11 GBytes   952 Mbits/sec  0.055 ms  697/145223 (0.48%)
[  4] Sent 145223 datagrams

iperf Done.

What version did you update from?
Were you on staging before?

Do you have comparable UDP iperf tests from an older version?

Sam

I was using the most up to date standard version, not a test build.

I don’t have numbers from before the upgrade, I’m afraid, but if you can tell me how to downgrade back to standard, I’ll do that and take some more.