[fritsch]

I hope your fight has helped ... for the next gen atoms ...

[wizziwig]

Whatever it can do on paper - the framebuffer configuration with linux seems to be RGB 8 bit on kernel side ... the rest is marketing I see no implementation there that would maintain a chain of 10 bit to output.

Don't most of these Android players use overlays for direct video decoding? In that case, the video is never actually stored inside the frame buffer like you have on PC. As long as they mix/composite the video overlay inside a 10-bit or higher pipeline, it should preserve full precision. Someone would need to test this with a 10-bit gradient pattern. Maybe like the ones posted here.

[noggin]

Whatever it can do on paper - the framebuffer configuration with linux seems to be RGB 8 bit on kernel side ... the rest is marketing I see no implementation there that would maintain a chain of 10 bit to output.

Don't most of these Android players use overlays for direct video decoding? In that case, the video is never actually stored inside the frame buffer like you have on PC. As long as they mix/composite the video overlay inside a 10-bit or higher pipeline, it should preserve full precision. Someone would need to test this with a 10-bit gradient pattern. Maybe like the ones posted here.

That's my understanding (and I think that's how the Pi works too) - the video is on a separate compositing layer to the frame buffer output - and there is often an alpha channel (or a key signal as I like to think of it!) with the frame buffer to allow for transparency (allowing a UI to be rendered over video)? Just because the OS is rendering 8 bits, doesn't mean the VPU decoding the video and outputting it on another layer is?

[fritsch]

So the TV should switch modes the moment you start a video?

[wesk05]

I cannot say what is happening internally, but what comes out of Amlogic S905 only has 8-bit color depth. The Shield does output 10-bit color, but I really don't know how to verify whether it is untouched native 10-bit or has undergone conversions.

[fritsch]

Does the shield _always_ output 10 bit? or do you see that something changes in the info frames the very moment it starts playback?

[wesk05]

Does the shield _always_ output 10 bit? or do you see that something changes in the info frames the very moment it starts playback?

It is always 10-bit Rec.2020 or Rec. 709 depending on HDR capabilities of the display. This is only for 4K 50/60Hz. No 10-bit for other resolutions. I am pretty sure that it is not doing any meaningful Rec. 709 to Rec. 2020 conversion.

[fritsch]

1) So - what happens if you play 1080 hevc 10 bit content?
2) And what happens if you play 4k@60p standard NV12 content?

[wesk05]

1) So - what happens if you play 1080 hevc 10 bit content?
2) And what happens if you play 4k@60p standard NV12 content?

It doesn't matter what the original content is, everything that comes out of the Shield will be 10-bit Rec. 2020/790. This is why I said earlier that I don't know how to verify whether there are conversions taking place or not. The only thing that I can say is the Rec. 2020 flag is fake. The output is not even DCI-P3. nVIDIA added that mode for Netflix 4K, but so far all non-HDR Netflix UHD content has been mastered only in Rec. 709 (which can also be confirmed on the Shield by just looking at the logcat when Netflix 4K shows are streamed).

[fritsch]

Yeah - that's what I said above :-) Not sure how you imagine a fancy "overlay" ... it needs to end somewhere on screen and if the mode is an 8 bit mode ... bad for you. If it always outputs 10 bits, something needs to be done to the standard 8 bit data - most likely some dithering algorithms, but - as we don't do it ... someone else does it actively without any control by us (especially on android with surface rendering).

On AMLogic it is simply decoding and then most likely postprocessing / clamping / scaling depending on the actual output mode ... all done in the nice blackbox that you control via a sysfs file.


So an "intelligent solution" could be:
if output_mode == 10 bit && overlay has 10 bit content -> dithering all stuff but not the overlay -> output.
else if output_mode == 8 bit && overlay has 10 bit content -> scale to 8 bit -> output

Add some limited range to the supper, remember that you don't have any influence on what you are doing (besides on Android going the GLES way) ... not good at all. But marketing seems to work - and nothing else.

[wesk05]

So an "intelligent solution" could be:
if output_mode == 10 bit && overlay has 10 bit content -> dithering all stuff but not the overlay -> output.
else if output_mode == 8 bit && overlay has 10 bit content -> scale to 8 bit -> output

Yep! that makes sense I am really curious to find out how the Himedia Q10/Q5 Pro is handling 10-bit output.

[fritsch]

I am fed up with that 10 bit stuff before it even started :-) When I look at the mess with 8 bit limited vs full vs rgb and then think of even more tuning with:

display driver 8bit / 10 bit / some mixture / native dithering?
decoder: Can one get the decoded NV12 / 10 bit P010 data and work with it?
rendering (kodi): Do we know what the driver does (e.g. clamping, scaling by its own, which mode it is running)

And: How can a simple user configure all that stuff magically :-)

[wesk05]

When I look at the mess with 8 bit limited vs full vs rgb and then think of even more tuning with:

While we are on this full vs limited topic, what exactly does Kodi's limited color range option do? I had posted this on the DX11 thread - http://forum.kodi.tv/showthread.php?tid=...pid2307604. It is only when I enabled the limited color range option, I got BTB (0-15) and WTW (236-255) in the output signal. I haven't chekced this on Linux.

[fritsch]

It does several things - but _it depends_

For kodi's gui output (leave video alone for now) it scales 0..255 to 16..235. This applies directly to the PictureViewer and everything that is rendered by kodi (leave video alone).

Now video comes into play. Here that setting hooks into the decoder (e.g. VDPAU, VAAPI, DXVA check this setting) and when ticked VDPAU uses it's studio color mixer to adjust the colors to be limited. On VAAPI it controls the rendering. We get NV12 data directly after decoding without being touched (alternatively after doing the vpp chain like deinterlacing) again everything still valid Limited Range. From here the Shaders in the render are controled.

If setting is enabled: -> direct output
if setting is disabled: Apply Dithering, upscale to 0 .. 255 and output

So - it's quite transparent what kodi does ... but don't underestimate the display drivers which can fuckup our nice chain quite hard :-)

Edit: No effect for video output on AMLogic (Bypass, it does what it wants to do), on Android no effect if surface rendering is done. No effect in the decoder on IMX. But also used in GLES path, if you use that one for rendering.

Edit2: So in short, kodi needs a cooperating display driver, which kodi does not control, but user needs to properly setup.

Good example:
User set full range for display driver, kodi use limited range not set, dithering 8 bit set <- suggested on PC monitor
User set limited range _without_ touching video data, kodi use limited range set <- suggested on TVs, take great care the driver does not influence the values
Use set limited range _scaling the data from full to limited, kodi use limite range _not_ set, dithering 8 bit set <- scaled twice but should end up roughly at the same range again.

[wesk05]

So, the video level is set to 16-235, but not clamped when the limited range option is enabled in Kodi? BTB and WTW from NV12 is passed only when the display driver is set to full and limited range option is enabled in Kodi. In all other combinations, the levels are clamped to 16-235 for NV12.