• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 11
Nvidia Shield - Worse image quality
#16
black-nv12 is even working on my windows computer.

So - now do you know: is your TV limited range or full range?

If it would be full range we would exactly now know that the shield also outputs full range -> problem for video
If it would be limited range, but as you clearly see values between 235 and 255 and 0 and 16, then the driver would "scale" itself, which would be really, really bad to workaround.

Okay in any case, having limited range video data on a full range display without "range extension" won't give blacks nor whites.
If the second would be true, you would have even less values on screen.

Edit: Btw. the NV12 movie is _completely_ black, no content at all. But the black value is 16.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#17
Looks like not even Google has a clue what they are doing with Nexus Player Smile
https://code.google.com/p/android/issues...?id=188667
Reply
#18
(2016-01-12, 14:21)datranquil Wrote: ATM shield is operating in full range RGB, that is what someone states on nvidia forums. I dont know how I can check this. My AVR keeps saying "8 Bit Input, 8 Bit Output" so I assume it is full range?

There is an update announced for the shield, which should be released this week. (Update to Marshmallow as well) Maybe it is possible to reduce the used colorspace on OS level then.

Actually, according to this (and my observations) it is the other way around: https://forums.geforce.com/default/topic...1/#4549981

My Pioneer AVR said "RGB Limited 24Bit" when watching movies/tv series.
But while in KODI Interface, it said YCbCr 4:2:0 30 Bit.

It turned out that 50Hz and 60 Hz are YCbCr 4:2:0 and 30Hz and below are RGB Limited ( I don't have anything between 30Hz and 50Hz, so Wink ).

Unforunately the Pioneer AVR converted the RGB Limited to YCbCr 4:2:0 (no setting to change that for 4k signal) which resulted in grey color where there should have been deep black. So I had to replace it to be able to use the Shield.
Reply
#19
The final HDMI output on SATV is clamped to 16-235.

@datranquil: I don't think you have your display's brightness/contrast set correctly. Your post says that you cannot see any difference between 246-248, but can see difference between 254 and 255. That doesn't make any sense.

@wweich: only 4K 50/60Hz is YCbCr 4:2:0 10-bit.

I will run it through AVLab TPG and get the actual RGB pixel values later tonight.
Reply
#20
(2016-01-12, 11:11)datranquil Wrote: This is a heavily discussed topic on Nvidia forums and I don't know, if KODI can solve this problem or not.

These are the issues that are going to be discussed:

- Bad black and white levels
- graining and distortion in media
- artifacts on low light situations

Threads and also pictures can be found here:
https://forums.geforce.com/default/topic...valuation/
https://forums.geforce.com/default/topic...aluation-/
https://forums.geforce.com/default/topic...cceptable/

Maybe a Dev can bring some light into the dark. Nvidia did not post only one comment on this officially and it sometimes really a worse image quality.

Someone at the forum with experiences like this and/ or maybe with solutions?

It's a firmware problem, not a Kodi problem.
Mac Mini (2.7GHz, Late 2012, Windows 10, Kodi DSPlayer) | SATV 16GB | Panasonic TX-P50GT50B | Yamaha RX-V675 | Q Acoustics 2010i (FL, FR, Left S, Right S), Q2000ci Center, Q2070si Sub
Reply
#21
(2016-01-12, 19:31)FernetMenta Wrote: Looks like not even Google has a clue what they are doing with Nexus Player Smile
https://code.google.com/p/android/issues...?id=188667

Yep, nVIDIA SATV got the same bug when they backported Marshmallow code to firmware 2.0. nVIDIA managed to fix the bug in 2.1, but I still think there are left overs because I notice problems when RGB 0-255 content from a pattern generator is fed to the SATV. It seems to be doing some weird conversions.
Reply
#22
(2016-01-12, 19:48)wesk05 Wrote:
(2016-01-12, 19:31)FernetMenta Wrote: Looks like not even Google has a clue what they are doing with Nexus Player Smile
https://code.google.com/p/android/issues...?id=188667

Yep, nVIDIA SATV got the same bug when they backported Marshmallow code to firmware 2.0. nVIDIA managed to fix the bug in 2.1, but I still think there are left overs because I notice problems when RGB 0-255 content from a pattern generator is fed to the SATV. It seems to be doing some weird conversions.

According to that bug, it was fixed some time ago by google, and the OTA update came just two days ago for Nexus Player users, hopefully we get Google's own fix with OTA 3.0 on SATV to see if it fixes any remaining issue.
Reply
#23
(2016-01-12, 19:48)wesk05 Wrote:
(2016-01-12, 19:31)FernetMenta Wrote: Looks like not even Google has a clue what they are doing with Nexus Player Smile
https://code.google.com/p/android/issues...?id=188667

Yep, nVIDIA SATV got the same bug when they backported Marshmallow code to firmware 2.0. nVIDIA managed to fix the bug in 2.1, but I still think there are left overs because I notice problems when RGB 0-255 content from a pattern generator is fed to the SATV. It seems to be doing some weird conversions.

Are you sure with the "clamp" from above? Any idea why the testing users sees values between 0 and 16 and values between 235 and 255? If it would really "clamp" and not scale, he should have one black between 0 and 16 and one white tone between 235 and 255.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#24
(2016-01-12, 20:58)fritsch Wrote:
(2016-01-12, 19:48)wesk05 Wrote:
(2016-01-12, 19:31)FernetMenta Wrote: Looks like not even Google has a clue what they are doing with Nexus Player Smile
https://code.google.com/p/android/issues...?id=188667

Yep, nVIDIA SATV got the same bug when they backported Marshmallow code to firmware 2.0. nVIDIA managed to fix the bug in 2.1, but I still think there are left overs because I notice problems when RGB 0-255 content from a pattern generator is fed to the SATV. It seems to be doing some weird conversions.

Are you sure with the "clamp" from above? Any idea why the testing users sees values between 0 and 16 and values between 235 and 255? If it would really "clamp" and not scale, he should have one black between 0 and 16 and one white tone between 235 and 255.

I will check with your video, but I clearly remember the shied not outputting anything blacker than black or whiter than white on contrast and brightness patterns showing black being 16 and white being 235, no matter what setting I set my projector.
Reply
#25
Check the image from my post above, please.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#26
(2016-01-12, 20:58)fritsch Wrote: Are you sure with the "clamp" from above? Any idea why the testing users sees values between 0 and 16 and values between 235 and 255? If it would really "clamp" and not scale, he should have one black between 0 and 16 and one white tone between 235 and 255.
I am using "clamp" as it is defined in FCP and other editors: https://documentation.apple.com/en/final...tasks=true
Reply
#27
(2016-01-12, 21:12)wesk05 Wrote:
(2016-01-12, 20:58)fritsch Wrote: Are you sure with the "clamp" from above? Any idea why the testing users sees values between 0 and 16 and values between 235 and 255? If it would really "clamp" and not scale, he should have one black between 0 and 16 and one white tone between 235 and 255.
I am using "clamp" as it is defined in FCP and other editors: https://documentation.apple.com/en/final...tasks=true

Then please check the image I posted with the values from 0 to 255 above. If it is really "clamped" then every value <= 16 should be the very same black and every value >= 235 should be fully white, right?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#28
(2016-01-12, 21:14)fritsch Wrote:
(2016-01-12, 21:12)wesk05 Wrote:
(2016-01-12, 20:58)fritsch Wrote: Are you sure with the "clamp" from above? Any idea why the testing users sees values between 0 and 16 and values between 235 and 255? If it would really "clamp" and not scale, he should have one black between 0 and 16 and one white tone between 235 and 255.
I am using "clamp" as it is defined in FCP and other editors: https://documentation.apple.com/en/final...tasks=true

Then please check the image I posted with the values from 0 to 255 above. If it is really "clamped" then every value <= 16 should be the very same black and every value >= 235 should be fully white, right?

First the videos, both look black to me, but if I use any HW decoding on KODI, the second one blackyuv444-sw.mkv refuses to play, also won't play on native player.

the image with 4 rows of blacks: I can't distinguish 0 1 2 and 3 on any row from the background, no matter how much I turn up the brightness.

The gray.jpg image, I found hard to interpret, I understand it but since the squares have a different color around them it is easy to identify every square even if they sometimes look like the same color, so it is hard to tell.

I am testing on 1080p only, opened gray.jpg on Kodi and it looks better, I can clearly see most squares on the extremes, but I can't differentiate if they are different blacks or different whites, I can only see that sometimes the +1 or -1 are very hard to differentiate.
Reply
#29
For me it's more or less the same as pedromvu reported.
I tested the two images with both YCbCr 4:2:0 output (2160p@60Hz) and RGB Limited output (2160p@25Hz): No difference.

If I understand the gray test image correctly, the middle row has no difference in color for the square and the column background. If you go up the square goes darker and if you go down the square goes brighter.
I definitely see squares in the left and right column although I did not really check if the 248+7 and 248+8 had a different white to each other.


The blackyuv444-sw.mkv won't even play on my PC (VLC).
Reply
#30
plays perfectly with kodi :-)
Image

But yeah needs a fail safe player ...
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 11

Logout Mark Read Team Forum Stats Members Help
Nvidia Shield - Worse image quality1