Then you are where I was a month ago and you and Sony have exposed my ignorance. In fact, YQ is nothing to do with HDR. Could you please check what happens if you try rgblimitnow and rgbfullnow. If that makes a difference we can get it sorted.
Tested it right at the beginning, no difference whatsoever. In fact, none of the settings (limitnow, fullnow, rgblimitnow and rgbfullnow) made any difference to the dynamic range. Again, I could see the display changing something. Unfortunately the Sony doesnāt report any more details about the video mode it switches to, except for the resolution and refresh rate. But my AVR at least confirmed itās receiving RGB when applying rgbfull or rgblimited.
Thanks for confirming. I will make a change which may help.
I just glanced over the last few posts. What @norbertlang wants is expand 16-235 to 0-255 with YCbCr or RGB Full output. YCbCr Full mode is technically reserved for xvYCC gamuts. It is not meant for BT.709 as per the various standards. What a specific display does with BT.709 YCbCr Full input will need to be tested.
Changing the dynamic range in the InfoFrame isnāt going to help with this problem. Unless something has changed in recent Amlogic kernels, it used to be that it allowed passthrough of full range with YCbCr Limited output. The OP is seeing 16 as gray because the display is calibrated for 0 as black. It is not clear whether this calibration was done visually or with a meter. With RGB Limited mode, 0-15 and 236-255 are clipped, and 16-235 is preserved. With RGB Full mode, 16-235 is expanded to 0-255 and 0-15/236-255 are lost.
@wesk05, the display was calibrated with a meter. It was calibrated from a PC, with 0 as black and 255 as white, but thereās no way to calibrate it for 16-235. (You could tune down the black level to crush everything below 16 thus simulating the proper lower end, but thereās absolutely no way to tune up 235 to appear white. The black level hack obviously messes the calibrated gamma range as well.)
The InfoFrame idea came from the fact that the TV should be able to do dynamic range adjustments based on the input signal, as this is what it advertises in its EDID:
RGB quantization range... Selectable (via AVI YQ)
YCC quantization range... Selectable (via AVI YQ)
The TV supports BT.709, BT.2020, DCI P3 and Auto as color space, and 8 bit and 10 bit RGB or YCbCr 4:2:0, 4:2:2 or 4:4:4 signal (SDR and HDR), but apparently this makes no difference in its interpretation of incoming signal dynamic range.
What Iād like to test somehow is whether thereās any way to force the display to internally map / expand 16-235 to 0-255 via the YQ bit, as suggested by its EDID.
Iād love to see this behavior, but couldnāt reproduce it. Forcing player to rgbfull did not change the Vero output range, 0-15 and 236-255 were clearly visible.
After thinking this through on a 3-hour walk yesterday I think what may be happening is you have, by calibrating the screen, overriden the TVās proper behaviour which is to expand the 16-233 range into the full brightness range of the panel.
I would be interested in what happens if you re-set the calibration to āfactoryā.
What it was doing was IMHO bizarre. A signal flagged as limited range by the decoder would exit the video processing chain the same as it went in. A signal flagged as full range would be converted to limited range and then further compressed into an even smaller range (about 64-215 presumably). The InfoFrame was always saying limited for YCC. So those full-range flagged clips that @retroresolution posted ended up being expanded by the display back to only 16-235 (washed out).
Itās now been changed (in this test kernel) so that clips flagged as full range exit the video chain the same as they went in. YCC is still flagged as limited in the InfoFrame so those buggy clips end up being expanded back to 0-255 in the display.
Limited range was hard-coded into the InfoFrame YQ bits. I have now changed it so that the YQ bits are manually settable with echo limit > attr. Previously that attr setting only affected the RGB range (Q bits). That will give @norbertlang something to play with to test if his TV reacts as expected. But if Iām not mistaken, setting full-range in the InfoFrame will only make his pictures even worse. It wonāt solve his problem but may provide some insights.
Tested this, but no change. The TV supports different picture modes like Cinema Pro, Cinema Home, Standard, etc. and thereās 10-pt calibration available for each mode. Calibration data is stored per mode, per HDMI input. Changing the picture mode confirms that the previous calibration data is not used anymore, but blacks and whites behave similarly.
Later Iāll try and test using a different HDMI input.
FWIW, thereās absolutely no reaction from the TV when changing from limited to full via attr except for a small blackout of the TV, acknowledging that something indeed changed in the input signal. So the picture gets neither better nor worse.
Sorry if I wasnāt clear. That attr switching hasnāt been built into the test kernel yet so you will not see any effects until @sam_nazarko builds it. You already confirmed echo rgbfull didnāt change anything (which it should, and does on my TV as long as I set the TV to RGB range auto). Iām just trying to check if the same applies to YCC on your Sony.
Ok, understood.
In the meantime, I tested another HDMI input, and found the following:
- The TV now seems to correctly adjust the black range if the input signal is limited, so 16 appears black. The higher end is not adjusted though, so itās still 255 that looks white, 235 is light gray.
- On this input, the TV indeed reacts to
rgbfull, making 0 to appear black instead of 16. Switching back tolimitedorrgblimitedcorrectly changes back the TV to display 16 as black. Whites are not affected at all. - The only difference between the two inputs is a feature called Enhanced HDMI mode, which enables the TV to receive 4k 60Hz 4:4:4 and HDR signals. The input which did not react at all to dynamic range flags had this enabled. On the new input I used for testing this was disabled.
To me, this confirms two things:
- The Vero apparently properly sends the signal to the TV, and probably YCbCr YQ flagging works as well, itās the Sony that ignores this on Enhanced-enabled HDMI inputs.
- The TV probably has one or more software bugs in the range mapping algorithm, since even in limited mode it doesnāt make 235 whites full white. Plus, it completely ignores YQ / Q flags when its HDMI is set to Enhanced.
Now go figureā¦ 
Thanks. We are homing in on it, now. FWIW, on my TV itās ~244 that shows as white when in limited range. I havenāt got to the bottom of that. Are you sure it goes all the way up to 254/5?
Yepp, white is 254. I can still see 253 flashing on the AVS HD White Clipping test clip.
Can you please post the output of cat /sys/class/amhdmitx/amhdmitx0/edid and cat /sys/class/amhdmitx/amhdmitx0/rawedid for each of the two HDMI inputs you have been testing.
I got the same TV as you Norbert, maybe I could test the same with some detail what to test.
I got my HDMI setting on Enhanced, because I run everything through my AVR, I havenāt noticed any color issues though 
Please provide me with some basic stuff to test if you want.
Thanks a lot @Theetjuh, Iād definitely appreciate your help here! Iāll PM you with a link to a short black clipping / white clipping test video to see if you have the same as me.
Pls. find all the requested info here:
http://paste.osmc.io/dalogopaji.mel
UPDATE on inputs and Enhanced mode:
Checked the Enhanced mode on HDMI 1, and it works the same as in default mode.
Then I went ahead and plugged back in the Vero to HDMI 4, confirmed that the black range is off, and changed HDMI 4 from Enhanced to default. Result: black range did not change for HDMI 4, even in default mode it fails to render 16 as black.
So, itās not Enhanced vs Default after all, but rather HDMI 4 / ARC vs HDMI 1 (and probably other HDMI inputs as well - although I havenāt tested, they are hidden behind the back of my TV which is on the wall).
Iām curious if the EDID data give any hints as to whatās going on here, but it could be that the HDMI ARC input on the TV is somehow not working properly. Which is a pain, as Iām using an AVR for the TVās sound as well and want to keep my cabling to the minimum.
Well thatās interesting. The only difference between the HDMI1 and HDMI4 EDID prints is the checksum!!
Can you run:
cat /sys/class/amhdmitx/amhdmitx0/edid_parsing
for both ports.