[split] YCbCr RGB Colorspace - technical discussion
#1
Is the Odroid with LibreElec recognised as a PC input source or a set-top box? I've just got a new 65KS9000 and find my Chromebox with OpenElec is often being picked up as a PC source when powering on, which reduces picture settings on the TV so you need to manually alter the source type on the TV, but it doesn't seem to survive a power cycle.
Reply
#2
Never seen this reported in the whole time I've been around AMLogic OpenELEC / LibreELEC or Android OS devices. And there have been quite a few.
AMlogic devices definitely won't be detected as a RGB source either, unless forced. The colorspace output is YCbCr by default.

I suspect something is up with the Chromebox sending out a RGB signal and altering the colorspace output. All the blacks and greys should appear duller and washed out when switching from YCbCr to RGB without picture setting adjustments on a TV.

Ask in the Chromebox thread. Mr Chromebox aka Matt Devo very likely knows the solution.

Reply
#3
(2016-10-21, 18:59)wrxtasy Wrote: Never seen this reported in the whole time I've been around AMLogic OpenELEC / LibreELEC or Android OS devices. And there have been quite a few.
AMlogic devices definitely won't be detected as a RGB source either, unless forced. The colorspace output is YCbCr by default.
Suspect some devices output RGB initially so that they are compatible with HDMI->DVI connected displays (DVI can be RGB only). Similarly some boxes output non-TV resolutions (i.e. not 720x576, 720x640, 1280x720, 1920x1080 or 3840x2160) and instead output PC modes (1024x768, 800x600 etc.). Both of these could force a TV into 'PC' mode - though in my experience most ARM boxes we use (I know the Chromebox 1 is based on a Pi-like SoC but ignore that!) are OK.

The Chromebox is a device aimed at both TVs and Desktop PC use - and from memory the BIOS outputs a non-TV resolution (1024x768 I think) initially (some TVs and/or AVRs won't display it) and that is probably the cause of the issues in your case.

Quote:I suspect something is up with the Chromebox sending out a RGB signal and altering the colorspace output. All the blacks and greys should appear duller and washed out when switching from YCbCr to RGB without picture setting adjustments on a TV.

Eh? What makes you say that?
RGB and YCbCr level space can be the same. No reason to change levels between RGB 16-235 (i.e. Limited) and YCbCr 16-235 on most displays. I have sources outputting both RGB (Raspberry Pis) and YCbCr (ODroids, Blu-ray player, PS3, PS4 etc.) routed via my AVR in pass-through mode (it outputs what it receives) and have no need to change my TV levels no my HDMI input as I switch between RGB and YCbCr sources.

And if the HDMI source is inserting HDMI infoframes (which it should) and the display recognises them (and most new displays will), then even the RGB 0-255 vs RGB 16-235 issue should be moot, as the display should switch to Full or LImited range respectively.
Reply
#4
(2016-10-22, 10:06)noggin Wrote:
(2016-10-21, 18:59)wrxtasy Wrote: I suspect something is up with the Chromebox sending out a RGB signal and altering the colorspace output. All the blacks and greys should appear duller and washed out when switching from YCbCr to RGB without picture setting adjustments on a TV.

Eh? What makes you say that?

RGB and YCbCr level space can be the same. No reason to change levels between RGB 16-235 (i.e. Limited) and YCbCr 16-235 on most displays. I have sources outputting both RGB (Raspberry Pis) and YCbCr (ODroids, Blu-ray player, PS3, PS4 etc.) routed via my AVR in pass-through mode (it outputs what it receives) and have no need to change my TV levels no my HDMI input as I switch between RGB and YCbCr sources.

The Android and LibreELEC AMLogic S905 guys found an issue with specific models of (approx 7 year) Philips and Sony TV's. HDMI Handshaking has some sort of problem with these TV and they default to RGB even when fed a YCbCr colorspace. It not only AML devices having issues with these TV's, I've also seen a lot of reports with Apple Hardware and others as well.

Consequently the problem had to have a workaround implemented. We now have this in LibreELEC Kodi for S905's and also MINIX and Wetek has an Android RGB Toggle option setting implemented.
If I toggle YCbCr to RGB switching manually I can clearly see washed out Blacks and Grey shades on my unadjusted 4K TV. I am not changing HDMI inputs or toggling between others and then back to the AML S905 one either.

I bet if I plug a RGB video output capable RPi into another HDMI port on the TV and switch to that HDMI input I would see the same results as you.

No idea what the Chromebox does, and that is why the question needed to be repeated and asked in the correct thread.

Reply
#5
I have checked this on the Minix U1. When you force RGB colorspace in the settings, the output is RGB Full with no scaling/remapping i.e, YCbCr 16 is RGB 16 and YCbCr 235 is RGB 235. The issue here is quantization range is not provided in the AVI InfoFrame (Data Byte 3 - bits 3,4, Q0, Q1: 00- Limited, 01 - Full). On newer TVs, when quantization range is not available in auto mode they will default to Limited. On older TVs they seem to default to Full range which is actually correct in this particular scenario and this is what causes the washed out look. RGB 16 in Full range is not black, it is gray!

You don't really need an analyzer to check whether the InfoFrame has quantization range or not. If you can override black level settings on your TV's picture options, it means quantization bits are not present in the InfoFrame.

@wrxtasy: I cannot get this to work in your latest build for C2. I have edited it in boot.ini, but it still outputs YCbCr.

BTW: nVIDIA Shield also has the same problem. It doesn't provide the quantization range in the InfoFrame.
Reply
#6
(2016-10-22, 12:35)wrxtasy Wrote:
(2016-10-22, 10:06)noggin Wrote:
(2016-10-21, 18:59)wrxtasy Wrote: I suspect something is up with the Chromebox sending out a RGB signal and altering the colorspace output. All the blacks and greys should appear duller and washed out when switching from YCbCr to RGB without picture setting adjustments on a TV.

Eh? What makes you say that?

RGB and YCbCr level space can be the same. No reason to change levels between RGB 16-235 (i.e. Limited) and YCbCr 16-235 on most displays. I have sources outputting both RGB (Raspberry Pis) and YCbCr (ODroids, Blu-ray player, PS3, PS4 etc.) routed via my AVR in pass-through mode (it outputs what it receives) and have no need to change my TV levels no my HDMI input as I switch between RGB and YCbCr sources.

The Android and LibreELEC AMLogic S905 guys found an issue with specific models of (approx 7 year) Philips and Sony TV's. HDMI Handshaking has some sort of problem with these TV and they default to RGB even when fed a YCbCr colorspace. It not only AML devices having issues with these TV's, I've also seen a lot of reports with Apple Hardware and others as well.

Consequently the problem had to have a workaround implemented. We now have this in LibreELEC Kodi for S905's and also MINIX and Wetek has an Android RGB Toggle option setting implemented.
If I toggle YCbCr to RGB switching manually I can clearly see washed out Blacks and Grey shades on my unadjusted 4K TV. I am not changing HDMI inputs or toggling between others and then back to the AML S905 one either.

Are you toggling between YCbCr Limited and RGB Limited, or YCbCr Limited and RGB Full? And what is the HDMI Infoframe you are sending saying? (Infoframes can carry levelspace information - but aren't mandatory, and many earlier TVs ignore them. My Sony Full HD set from 2007 ignores them, but my Sony UHD set from 2014 follows them - so I obviously can get different visual results with the same device on two diferent displays depending on the Infoframe support on source and display)

If you send RGB Limited but the HDMI Infoframe says it is full - then any modern TV will interpret it as Full, automatically switch to Full mode, but because you are sending Limited video you will get set-up blacks (as black level on the display is 0, but in the video source is 16 - and washed out colours) This would be because you're saying one thing and sending another and you will get the wrong result.

If you send RGB Limited video, and your TV is expecting RGB Limited (either because it is configured as Limited and/or because the HDMI Infoframe flags it as Limited) - then no problem. If you are sending RGB Full and your TV is expecting RGB full (either because it is configured for RGB Full and/or because the HDMI Infoframe flags it as Full), again no problem. That said I don't think YCbCr Full is a proper standard (YCbCr is almost universally Limited range)

Quote:I bet if I plug a RGB video output capable RPi into another HDMI port on the TV and switch to that HDMI input I would see the same results as you.

The Pi has config options for both RGB Full and RGB Limited, as well as YCbCr Limited in its config.txt ISTR - and I'm pretty certain it sends the right info frames (or doesn't send any).

Pi config
Quote:hdmi_pixel_encoding=0 default (limited for CEA, full for DMT)
hdmi_pixel_encoding=1 RGB limited (16-235)
hdmi_pixel_encoding=2 RGB full ( 0-255)
hdmi_pixel_encoding=3 YCbCr limited (16-235)
hdmi_pixel_encoding=4 YCbCr full ( 0-255)

The CEA vs DMT thing is how Intel drivers behave as a default too. If you select a CEA mode (i.e. a consumer electronics association 'video' mode - 480/576/720/1080) you get Limited, if you select a DMT (i.e. a PC monitor resolution like 1024x768, 800x600, 1280x1024 etc.) there is an expectation you are probably connected to a DVI-type display which will want 'PC' levels which are Full.

The key thing with RGB is to make sure you are in the right level space - Limited or Full AND that you are flagging it correctly OR have your TV manually configured correctly. If you have an older TV that ignores HDMI info frames, you should always make sure that multiple sources routed to a single input are in the same RGB/YCbCr levelspace - and for sanity's sake I'd suggest all Limited as a default position (as lots of CE devices are Limited only)
Reply
#7
(2016-10-23, 12:24)noggin Wrote: (Infoframes can carry levelspace information - but aren't mandatory, and many earlier TVs ignore them. My Sony Full HD set from 2007 ignores them, but my Sony UHD set from 2014 follows them - so I obviously can get different visual results with the same device on two diferent displays depending on the Infoframe support on source and display)

The Pi has config options for both RGB Full and RGB Limited, as well as YCbCr Limited in its config.txt ISTR - and I'm pretty certain it sends the right info frames (or doesn't send any).

If you have an older TV that ignores HDMI info frames.

HDMI 1.4b specs actually has this
Quote:A Source shall always transmit an AVI InfoFrame at least once per two Video Fields if the Source:
is ever capable of transmitting an AVI InfoFrame or,
is ever capable of transmitting YCbCr pixel encoding or,
is ever capable of transmitting any colorimetry other than the transmitted video format's default colorimetry or,
is ever capable of transmitting any xvYCC or future enhanced colorimetry or,
is ever capable of transmitting any Gamut Metadata packet or,
is ever capable of transmitting any video format with multiple allowed pixel repetitions or,
is ever capable of transmitting Content Type other than "no data" or,
is ever capable of transmitting YCC Quantization Range.

The AVI InfoFrame shall be transmitted even while such a Source is transmitting RGB and non-pixel-repeated video. When a Source is not explicitly required to transmit AVI InfoFrames, it is reccommened that the Source transmit AVI InfoFrames.

HDMI 2.0b has extensions to HDMI 1.4b to include additional VICs defined in CEA-861-F, YCbCr 4:2:0 encoding and also mention version 3 AVI InfoFrame defined in CEA-861-F, but that has not been implemented yet.

Quantization bits were first introduced in the AVI InfoFrame with HDMI 1.4. So, I don't think any TV built before 2009 can honor the AVI InfoFrame quantization bits even when present. Most likely they will default to RGB Full. I am not even sure whether those old TVs will have option to select the dynamic range/black level.

Pi2 doesn't provide quantization bits in the InfoFrame. So far, the only ones that I have seen provide it is Intel.
Reply
#8
Thanks wesk05. So Limited vs Full signalling in Infoframes arrived with HDMI 1.4. That makes sense - as my 2007 Sony 40W4000 ignores them (which meant it worked great with the early Limited carried within Full Intel hacks to get 16-235 all the way through without going via 0-255) but my 2014 Sony UHD set didn't ignore them (which meant the Intel hack didn't initially work, until fritsch et al also added Infoframe flagging support)

Lots of TVs had Full/Limited config options (though some incorrectly called it IRE - equating it with the North American NTSC vs Japanese NTSC black level pedestal differences) which allowed you to manually set whether an HDMI input was in Full or Limited colour space. I think by default most assumed Limited levels though - as the assumption was that a source would be in 'video' rather than 'PC' space. In some cases I think switching your display into 'PC' mode or even just labelling the input 'PC' would do things like defeating overscan simulation and switch to Full level space.

Either wrxtasy's TV is assuming RGB = Full and YCbCr = Limited (and his C2 is outputting Limited for both) or in RGB mode something is going wrong elsewhere in the C2? (I've seen horrible situations where 16-235 conversion is applied twice - meaning even with Limited level output you get set-up blacks, dim whites and desaturated chroma)
Reply
#9
My Brain hurts after all that !

I see the same Video Output if fast switching to RGB with every AMLogic S905 board I have here. Its not isolated to the C2 or any specific Seller. Its all of them.

Anyway I'm not affected by this RGB - Philips TV colorspace issue, along with 99% of all the other AMLogic S905 device owners, so its not worth anyones time digging deeply into it.

Normal YCbCr output looks just fine, no need to even mess with it.

@wesk05 LE 7.1 RGB switching on the C2 its a very old hack, and unreliable. The LibreELEC implementation RGB switching for the Hub/Play2 and Krypton running on the C2 work as they are using a new linux-amlogic common kernel.

Reply
#10
(2016-10-23, 21:05)wrxtasy Wrote: My Brain hurts after all that !

I see the same Video Output if fast switching to RGB with every AMLogic S905 board I have here. Its not isolated to the C2 or any specific Seller. Its all of them.

Anyway I'm not affected by this RGB - Philips TV colorspace issue, along with 99% of all the other AMLogic S905 device owners, so its not worth anyones time digging deeply into it.

Normal YCbCr output looks just fine, no need to even mess with it.

Yeah - but YCbCr (source) -> RGB (decode on playback) -> YCbCr (over HDMI) -> RGB (conversion in the TV) in the chain from source to display (unless the middle YCbCr->RGB->YCbCr process doesn't involve going via the RGB domain and includes YCbCr->YCbCr matrices for both 601 and 709 colour space)? (You could argue there is another RGB at the very beginning of the chain as most sources start life RGB)

If you can run RGB out over HDMI then you potentialy have a simple YCbCr (Source) ->RGB (decode on playback, over HDMI, display on TV) chain from source to display IF the AMLogic stuff doesn't go via YCbCr internally before going to RGB?

I'm sure YCbCr looks OK - but all of those colour space conversions, particularly if they are done at 8 bit, are not ideal.
Reply
#11
(2016-10-24, 12:52)noggin Wrote: If you can run RGB out over HDMI then you potentialy have a simple YCbCr (Source) ->RGB (decode on playback, over HDMI, display on TV) chain from source to display IF the AMLogic stuff doesn't go via YCbCr internally before going to RGB?
Are you forgetting RGB ->YCbCr conversion in the display? With the exception of Pioneer Kuro Plasma TVs and select projectors all other displays do their internal processing in YCbCr. It is much easier to do processing when you can separate luma and chroma.
Reply
#12
(2016-10-24, 19:23)wesk05 Wrote:
(2016-10-24, 12:52)noggin Wrote: If you can run RGB out over HDMI then you potentialy have a simple YCbCr (Source) ->RGB (decode on playback, over HDMI, display on TV) chain from source to display IF the AMLogic stuff doesn't go via YCbCr internally before going to RGB?
Are you forgetting RGB ->YCbCr conversion in the display? With the exception of Pioneer Kuro Plasma TVs and select projectors all other displays do their internal processing in YCbCr. It is much easier to do processing when you can separate luma and chroma.

Ah - wasn't aware that modern displays still did all their processing in the YCbCr domain. Is that true of HDR stuff too? (No reason why it shouldn't be - HDR is still YCbCr domain for distribtion AIUI) Makes sense - particularly for controls like saturation (i.e. colour) I know some older sets used to convert RGB 4:4:4 to YCbCr 4:2:2 internally - presumably modern displays are 4:4:4 YCbCr (at least) internally - otherwise you'd see chroma subsampling artefacts on both 4:2:2 and 4:4:4 inputs (on my TVs there is a clear difference between the two)

What colour space YCbCr do TVs use internally in your experience. Would HD sets be in the 709 space, with UHD HDR sets in 2020 or similar? (So a 601 YCbCr input in SD will be colour-space converted to 709 or 2020 either via RGB or via a YCbCr matrix conversion?)
Reply
#13
(2016-10-25, 12:31)noggin Wrote: I know some older sets used to convert RGB 4:4:4 to YCbCr 4:2:2 internally - presumably modern displays are 4:4:4 YCbCr (at least) internally - otherwise you'd see chroma subsampling artefacts on both 4:2:2 and 4:4:4 inputs (on my TVs there is a clear difference between the two)
What colour space YCbCr do TVs use internally in your experience. Would HD sets be in the 709 space, with UHD HDR sets in 2020 or similar? (So a 601 YCbCr input in SD will be colour-space converted to 709 or 2020 either via RGB or via a YCbCr matrix conversion?)
Actually, most of them seem to do processing in 10-bit YCbCr 4:2:2. There is some speculation that flagship LG OLED may be doing 12-bit processing. The colorspace is usually the same as the input signal. Most of this is based on empirical data and input from engineers. The manufacturers are less than forthcoming to provide these details.

I'm expecting @wrxtasy to soon tell us to take this conversation elsewhere Smile
Reply
#14
@wesk05, Yes and you are right, I'm having trouble following C2 support questions with all the deep - colorspace Tech discussion taking place....

Thread split

Reply
#15
(2016-10-21, 15:42)t2ffn Wrote: Is the Odroid with LibreElec recognised as a PC input source or a set-top box? I've just got a new 65KS9000 and find my Chromebox with OpenElec is often being picked up as a PC source when powering on, which reduces picture settings on the TV so you need to manually alter the source type on the TV, but it doesn't seem to survive a power cycle.

did you try using the UEFI firmware and reloading LibreELEC as I suggested? Unlike the Legacy BIOS firmware installed by the EZ Setup Script, the UEFI firmware won't put the display into VESA text mode on boot.

(2016-10-22, 10:06)noggin Wrote: Both of these could force a TV into 'PC' mode - though in my experience most ARM boxes we use (I know the Chromebox 1 is based on a Pi-like SoC but ignore that!) are OK.

The Chromebox is a device aimed at both TVs and Desktop PC use - and from memory the BIOS outputs a non-TV resolution (1024x768 I think) initially (some TVs and/or AVRs won't display it) and that is probably the cause of the issues in your case.

Not sure what device you are thinking of, no Chromeboxes are ARM-based.

The stock Chromebox firmware inits the display to 1024x768 / 8-bit when in Developer Mode, but this is not an issue with the standalone/custom firmware. Though in either case, when SeaBIOS loads, it inits the screen to VESA text mode in order to show the boot menu. As I mentioned above, the UEFI firmware will not do this, but instead will init the screen at it's reported preferred/native resolution.
Reply

Logout Mark Read Team Forum Stats Members Help
[split] YCbCr RGB Colorspace - technical discussion0