Login at Kodi Home

pedromvu · 2016-01-12, 21:49

So then it is pretty weird that datranquil was able to notice differences in the black rows image between 0, 1, 2, 3, I assume those are lower or equal to 16 black? since I can see them on my PC, I did try changing hdmi mode on projector but same result.

**fritsch** · 2016-01-12, 21:53

Yeah - the problem is:

If Android clamps, we can workaround it, stop surface rendering, but render the surface with EGL and use a custom matrix to achieve limited range
If Android scales, we need to stop surface rendering, upscale to full range (with dithering) so that the damn driver could downscale again.

All solutions suck ... as they are quite slow (no direct zero copy rendering) and overhead :-(.

Also what I absolutely don't understand. When Android clamps - there should be no issue at all with MediaCodec surface rendering, besides they get their BT709 / BT601 wrong ... then they need to go whining in the corner and fix their mediacodec implementation.

datranquil · 2016-01-12, 22:24

Its not only the colorspace which drives me crazy. For example this screenshot is showing a poor quality on fadings. (this is a screenshot from liveTV during a fade to black sequence)

You maybe need to open it in full screen. Take a look in the upper left. I never had this issues with OpenElec or KODI on Windows.

wesk05 · (This post was last modified: 2016-01-12, 22:37 by wesk05.)

(2016-01-12, 21:14)fritsch Wrote: 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?

Sure! I will check the image on AVLab TPG and post a video similar to this one:

https://www.youtube.com/watch?v=qyqEMwnZ...tu.be&t=74

The pixel readings are from the input side of AVLab TPG. It is a display independent measurement.

This was done for the Minix X8-H and the pattern has only one level that is above or below. I will check with yours that has 0-255.

**fritsch** · 2016-01-12, 22:45

Really curious! Thanks much in advance.

~~Ned Scott~~ · (This post was last modified: 2016-01-12, 22:53 by Ned Scott.)

This is the firmware bug that has been hitting all of the Android TV boxes (exact results depend on TV hardware used, I think). Apparently Google broke something when fixing something else and didn't want to rush a second fix (which might break something else, and the cycle continues). So it took a while, at least a few weeks if not a month or more, to get a fix. The Nexus Player has already been updated with the fix, and I would expect the Shield TV and Razor Forge to follow with their own specific updates.

pedromvu · (This post was last modified: 2016-01-12, 23:29 by pedromvu.)

(2016-01-12, 22:51)Ned Scott Wrote: This is the firmware bug that has been hitting all of the Android TV boxes (exact results depend on TV hardware used, I think). Apparently Google broke something when fixing something else and didn't want to rush a second fix (which might break something else, and the cycle continues). So it took a while, at least a few weeks if not a month or more, to get a fix. The Nexus Player has already been updated with the fix, and I would expect the Shield TV and Razor Forge to follow with their own specific updates.

Yeah but the point is while the Nexus Player problem seems to affect everyone (like with SATV FW 2.0), Nvidia already tried to fix it on their own and apparently it is not affecting everyone anymore, but hopefully everything get's fixed with the new update coming soon, and I mean that it get's fixed for everyone.

Now the other problems described on the OP threads that are not washed blacks related, I am not sure that will get fixed since Nvidia never acknowledged those issues, but we will see, hopefully it does get better.

**Tinwarble** · (This post was last modified: 2016-01-12, 23:53 by Tinwarble.)

(2016-01-12, 23:26)pedromvu Wrote: Yeah but the point is while the Nexus Player problem seems to affect everyone (like with SATV FW 2.0), Nvidia already tried to fix it on their own and apparently it is not affecting everyone anymore, but hopefully everything get's fixed with the new update coming soon, and I mean that it get's fixed for everyone.

Now the other problems described on the OP threads that are not washed blacks related, I am not sure that will get fixed since Nvidia never acknowledged those issues, but we will see, hopefully it does get better.

But we don't know if the second issue was caused by Nvidia fixing the first issue. We also don't know if was specifically a Android issue a kernel issue or a combination of both. And Nvidia doesn't always acknowledge issues, but that doesn't mean that they won't or aren't addressing them.

The fact is that none of this make much of a difference since the "M" update is imminent and we don't know if it will fix all the problems with the PQ, make it worse or keep it the same.

wesk05 · 2016-01-13, 06:45

Well, Well... this turned out to be interesting. It turns out that RGB levels are scaled in the picture viewer, but the levels are clamped in video player (mediacodec surface rendering). In the YouTube video, you can see that for the black level test pattern, levels are scaled. 0-10 is scaled to 16-24 and for the white level pattern, 236-255 is scaled to 219-235. Original 16 becomes 30 and 235 becomes 218. This explains why @datranquil was able to see some differences in the gray level pattern. The video was captured with mediacodec surface and mediacodec enabled. I did repeat the measurement with both the codecs disabled, but I didn't see any difference between the two measurements.

@fritsch: Do you happen to have the original Burosch calibration disc? Are the black/white level test patterns actually video or just image?

**fritsch** · 2016-01-13, 09:02

@wesk05: Thanks very much for those tests. I sadly don't have those disks. Btw. kodi's picture viewer should not scale, but also clamp.

What do you propose?

wesk05 · (This post was last modified: 2016-01-13, 10:23 by wesk05.)

(2016-01-13, 09:02)fritsch Wrote: @wesk05: Thanks very much for those tests. I sadly don't have those disks. Btw. kodi's picture viewer should not scale, but also clamp.
What do you propose?

Are you sure about the picture viewer? I just checked RPi2 (Kodi 17 build 1/10) with RGB Limited output in the config file and it is also being scaled exactly like on SATV. There is no scaling when pixel encoding is set to RGB Full in the config file, but with that setting 0-15 in the test pattern video becomes 0 and 236-255 is 255. Nothing in between those ranges is seen in the HDMI output.

pedromvu · 2016-01-13, 10:41

Hmm so I am right in assuming the correct behavior of video player is to clamp? since all media content is made in limited range anyways? and since the SATV itself outputs at that range.

What I am wondering is why I can't see the 1 2 and 3 blacks (17, 17, 19 after scale) on that image,as they are clearly shown on wesk video, if it didn't scale I should be seeing a black screen only right?

Also since no one has the video of the image test, isn't it possible to use a picture from wesk second test and save it in the proper format to see if it looks different when opening via picture instead of video?

**fritsch** · 2016-01-13, 10:43

(2016-01-13, 10:22)wesk05 Wrote:
(2016-01-13, 09:02)fritsch Wrote: @wesk05: Thanks very much for those tests. I sadly don't have those disks. Btw. kodi's picture viewer should not scale, but also clamp.
What do you propose?
Are you sure about the picture viewer? I just checked RPi2 (Kodi 17 build 1/10) with RGB Limited output in the config file and it is also being scaled exactly like on SATV. There is no scaling when pixel encoding is set to RGB Full in the config file, but with that setting 0-15 in the test pattern video becomes 0 and 236-255 is 255. Nothing in between those ranges is seen in the HDMI output.

On the PI it's special as it uses OMXImage and most likely handles that accordingly or drives kodi limited by default. Sorry I don't know - I meant "standard" x64 systems.

Ogreen · 2016-01-13, 10:46

Very interesting Wink

I'm going to check that between my SATV, Zappiti player,Minix 8H plus and PI2 Wink

**fritsch** · 2016-01-13, 10:47

(2016-01-13, 10:41)pedromvu Wrote: Hmm so I am right in assuming the correct behavior of video player is to clamp? since all media content is made in limited range anyways? and since the SATV itself outputs at that range.

What I am wondering is why I can't see the 1 2 and 3 blacks (17, 17, 19 after scale) on that image,as they are clearly shown on wesk video, if it didn't scale I should be seeing a black screen only right?

Also since no one has the video of the image test, isn't it possible to use a picture from wesk second test and save it in the proper format to see if it looks different when opening via picture instead of video?

It's the task of the renderer. Kodi was a desktop player which renders in OpenGL which is full range by default. So when video was decoded it was transfered to full range rgb with the given matrices. Recently we implemented a mechanism (for VDPAU, VAAPI, SW decoding on X11 / GL) that has the possibility to drive the GUI in limited range, by scaling and directly output the NV12->RGB conversion _without_ upscaling, so keeping the levels.

On Android and other "black box" decoder / renders stuff is hidden. In surface mode Render / videoplayer does absolutely nothing. In EGL mode it can care for "upscaling color" or direct output. I am not fully sure how this is currently handled in the current state of the EGL implementation. I am most into VAAPI with EGL ctx via X11.