[oo.viper.oo]

If you want to be fully complete - then you can also consider that the HDMI 2.0 4:2:0 8-bit YCbCr 2160/50-60p mode can be carried at the lower, HDMI 1.4b clock rate (which is how NVidia and Sony were able to upgrade graphics cards and TVs with HDMI 1.4b physical hardware to support this bit of HDMI 2.0)

Agreed, but that's why I stated "uncompressed" 4K@60p. 4:2:0 has compressed chroma, thus requires lower bandwidth, thus fits within HDMI 1.4 bandwidth.

You only need the HDMI 2.0-specific higher bandwidth for the 2160/50-60p 4:2:2 and >8 bit 4:2:0 modes I believe. (There isn't a 4:4:4 RGB or YCbCr implementation for >30p at 2160p even with HDMI 2.0)

"4:4:4 RGB" is another misconception, because 4:4:4 (or 4:2:2 or 4:2:0, etc.) denotes luminance and chroma subsampling (=compression) of YCbCr color space. There's no such thing in RGB color space, RGB is always uncompressed (=fully sampled as opposed to subsampled).

HDMI 2.0 can carry 4K@60p in RGB and YCbCr 444 at 8bpc. >8bpc@60p apparently requires compression.

(Bear in mind it's not a problem for 4K 10bpc movies as movies are running @24p and HDMI 2.0 can carry 4K up to 30p in RGB and YCbCR 444 at up to 16bpc)

Btw just stumbled upon nice summary here, when verifying my statements:
http://blog.toonormal.com/2014/01/10/4k-...eep-color/

[honcho]

The one he links to comes with 32 GB storage, 2 GB RAM and Win10 Home. So, it's still 90 USD in postage and import fees.

The other one isn't for sale yet, a simple google will confirm.

[wesk05]

"4:4:4 RGB" is another misconception, because 4:4:4 (or 4:2:2 or 4:2:0, etc.) denotes luminance and chroma subsampling (=compression) of YCbCr color space. There's no such thing in RGB color space, RGB is always uncompressed (=fully sampled as opposed to subsampled).

HDMI 1.4b and earlier specifications specifically mention it as RGB 4:4:4. You will see it as RGB 4:4:4 in nVIDIA/AMD driver settings. It is because that is how it is referred to in the specs. HDMI 2.0 and later have it as RGB only.

While I agree that RGB 4:4:4 notation is redundant these days, in the past there were other RGB sampling formats. Previous discussion on this topic: http://forum.kodi.tv/showthread.php?tid=...pid2242828

[htpcero]

It's the very same DP -> HDMI bridge. It's a driver bug and kodi can't fix that. If you would have valuable information for the bug piotrasd opened, please add them.

Upstream / freedesktop bug: https://bugs.freedesktop.org/show_bug.cgi?id=98797

No patch in sight apparently

[piotrasd]

still WIP

"Adding the support would involve several parts:

1) Add all the generic HDMI forum VSDB parsing and whatnot to the EDID parser

This is needed so that we'll know whether the sink supports YCbCr 4:2:0. There have been some patches towards HDMI 2.0 support for the EDID parser, but I can't recall how much was still missing from them. Not much merged so far.

3) Implement YCbCr 4:4:4 output support

This would involve doing RGB->YCbCr conversion with the pipe CSC. I started to implement this at some point, but got sidetracked and never actually finished. I should probably have a branch with some half finished code somewhere.

2) Extend out DP->HDMI dongle support to allow YCbCr 4:2:0 output.

Looking at the DP 1.4 spec, I see a PROTOCOL_CONVERTER_CONTROL_1 register that would allow you to enable YCbCr 4:2:0 conversion. If I'm reading things correctly we need to output YCbCr 4:4:4 to the dongle, and then dongle will downsample that to 4:2:0 when instructed to do so via this register. We probably have to parse a few other things from the DPCD as well so that we'll know whether the dongle even supports this."

[fritsch]

What do you think it is? (I am quite sure you think it's something else.)

[raidflex]

still WIP

"Adding the support would involve several parts:

1) Add all the generic HDMI forum VSDB parsing and whatnot to the EDID parser

This is needed so that we'll know whether the sink supports YCbCr 4:2:0. There have been some patches towards HDMI 2.0 support for the EDID parser, but I can't recall how much was still missing from them. Not much merged so far.

3) Implement YCbCr 4:4:4 output support

This would involve doing RGB->YCbCr conversion with the pipe CSC. I started to implement this at some point, but got sidetracked and never actually finished. I should probably have a branch with some half finished code somewhere.

2) Extend out DP->HDMI dongle support to allow YCbCr 4:2:0 output.

Looking at the DP 1.4 spec, I see a PROTOCOL_CONVERTER_CONTROL_1 register that would allow you to enable YCbCr 4:2:0 conversion. If I'm reading things correctly we need to output YCbCr 4:4:4 to the dongle, and then dongle will downsample that to 4:2:0 when instructed to do so via this register. We probably have to parse a few other things from the DPCD as well so that we'll know whether the dongle even supports this."

So what is being output currently with Libreelec is it full or limited RGB?

[Dragen]

Jumped the gun and ordered the NUC6CAYH today. Now to wait 3 weeks for delivery.

[fritsch]

still WIP

"Adding the support would involve several parts:

1) Add all the generic HDMI forum VSDB parsing and whatnot to the EDID parser

This is needed so that we'll know whether the sink supports YCbCr 4:2:0. There have been some patches towards HDMI 2.0 support for the EDID parser, but I can't recall how much was still missing from them. Not much merged so far.

3) Implement YCbCr 4:4:4 output support

This would involve doing RGB->YCbCr conversion with the pipe CSC. I started to implement this at some point, but got sidetracked and never actually finished. I should probably have a branch with some half finished code somewhere.

2) Extend out DP->HDMI dongle support to allow YCbCr 4:2:0 output.

Looking at the DP 1.4 spec, I see a PROTOCOL_CONVERTER_CONTROL_1 register that would allow you to enable YCbCr 4:2:0 conversion. If I'm reading things correctly we need to output YCbCr 4:4:4 to the dongle, and then dongle will downsample that to 4:2:0 when instructed to do so via this register. We probably have to parse a few other things from the DPCD as well so that we'll know whether the dongle even supports this."

So what is being output currently with Libreelec is it full or limited RGB?

Limited - No scale. It announces Limited, but does not scale nor clamp values. It's a special output patch I did some months ago to ease switching between full and limited.

[Nekromantik]

the builds posted here, are they recommended ones to use for apollo lake verses millhouse version 18 builds?

[noggin]

If you want to be fully complete - then you can also consider that the HDMI 2.0 4:2:0 8-bit YCbCr 2160/50-60p mode can be carried at the lower, HDMI 1.4b clock rate (which is how NVidia and Sony were able to upgrade graphics cards and TVs with HDMI 1.4b physical hardware to support this bit of HDMI 2.0)

Agreed, but that's why I stated "uncompressed" 4K@60p. 4:2:0 has compressed chroma, thus requires lower bandwidth, thus fits within HDMI 1.4 bandwidth.

Yes - though I think 'compressed' and 'uncompressed' are misleading terms. The terms used everywhere I encounter 4:2:2 and 4:2:2 are 'sub-sampled'. 'Compressed' is reserved for compression schemes like MPEG2, H264, AVCi100, DV100 etc. 4:2:2 has horizonally sub-sampled chroma, 4:2:0 has horizonally and vertically sub-sampled chroma. 4:4:4 YCbCr and RGB are equal bandwith with no sub-sampling. HDMI and HD-SDI are both considered uncompressed interconnects - as the video remains in the baseband domain and runs in real-time (i.e. you don't have to run it through frame stores to generate video)

If you describe baseband HD-SDI 4:2:2 as 'compressed' you'll get a lot of strange looks as it is usually, and specifically, described as 'uncompressed' in broadcast circles...

You only need the HDMI 2.0-specific higher bandwidth for the 2160/50-60p 4:2:2 and >8 bit 4:2:0 modes I believe. (There isn't a 4:4:4 RGB or YCbCr implementation for >30p at 2160p even with HDMI 2.0)

"4:4:4 RGB" is another misconception, because 4:4:4 (or 4:2:2 or 4:2:0, etc.) denotes luminance and chroma subsampling (=compression) of YCbCr color space. There's no such thing in RGB color space, RGB is always uncompressed (=fully sampled as opposed to subsampled).

It does now... But the 4:4:4 and 4:2:2 nomenclature has been with us since the 80s, when 3:3:3 RGB and 8:8:8 RGB were also used in some devices. The numbering scheme is all about relative sampling rates - and there have been RGB-based systems that use rates other than 13.5MHz (in SD).

For many using the same 4:4:4 for RGB and YCbCr sampling ensures it is clear that the same sampling rates are being used.

HDMI 2.0 can carry 4K@60p in RGB and YCbCr 444 at 8bpc. >8bpc@60p apparently requires compression.

Yes - I had missed out the 4:4:4 RGB/YCbCr 8-bit modes (I'd convinced myself they didn't exist!)

The >8 bit modes require subsampling to 4:2:2 or 4:2:0 and are YCbCr only.

(Bear in mind it's not a problem for 4K 10bpc movies as movies are running @24p and HDMI 2.0 can carry 4K up to 30p in RGB and YCbCR 444 at up to 16bpc)

No - but for broadcast purposes where you have to run at a fixed 50 or 59.94Hz rates that's a moot point.

[MasterYous]

Jumped the gun and ordered the NUC6CAYH today. Now to wait 3 weeks for delivery.

From where? Hard to find it for sale anywhere in US atm.

[flyingernst]

Why, wall already too high?! :-p

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

[movie78]

Jumped the gun and ordered the NUC6CAYH today. Now to wait 3 weeks for delivery.

From where? Hard to find it for sale anywhere in US atm.

This model NUC6CAYS come fully packed and its the same thing, it's also available on Amazon and Newegg

[Nekromantik]

Jumped the gun and ordered the NUC6CAYH today. Now to wait 3 weeks for delivery.

From where? Hard to find it for sale anywhere in US atm.

This model NUC6CAYS come fully packed and its the same thing, it's also available on Amazon and Newegg

Yup.
It's one I got. Only issue with it is it's got weird boot issue where it shows boot screen 3 times before getting to bootloader. Not for this forum so will ask Intel.

Was originally going to get i3 kaby lake nuc but after components it's almost 200 pounds more! Yes gpu more powerful and faster Ram but still can't do madvr 720p to 2160p ngu medium scaling so no point