Hello, is it possible on the Rock Pi 4 to forcefully set the output on the hdmi port rgb limited (16-235) when playing video? The fact is that I have an old TV (sony kdl32ex402), which has a known problem, when a signal in the YCbCr format is input to the hdmi input, the colors are inverted, the screen may randomly turn pink / green. But when I select the RGB output in the LibreELEC player settings, dark shades become too darka, apparently due to the fact that the rgb full signal is being output. At the same time, the raspberry pi 4 connected to this TV shows absolutely normal. Can this problem be solved?
Rock Pi 4 and old Sony TV
-
Mikhail -
April 1, 2021 at 5:27 AM -
Thread is Unresolved
-
You're obviously using old 9.2.x image. Please check 9.95.2 or latest nightlies.
-
You're obviously using old 9.2.x image. Please check 9.95.2 or latest nightlies.
Yes, on 9.2.6 everything works fine, including clear sound, no crackling, working WiFi, but there is no way to force the pixel format to RGB Limited. At 9.95.2, everything is fine with the image, apparently, RGB Limited is automatically selected, but then, on the new nightlies, the image periodically turns purple-green again, which means that for some reason the YCbCr pixel format is selected. In LibreElec 10, you really need to make it possible to manually select the pixel format for the Rockchip SoC, as, for example, in OSMC for Raspberry Pi 4, where you can forcibly select RGB FUll or RGB Limited, or YCbCr Full or YCbCr Limited in the settings menu, if possible
-
why does the driver choose YCbCr color space by default?
Its just the way the upstream driver works (YCbCr is the default as per HDMI specs) - we had a workarround for that in b1/b2 releases since colorspace conversion was broken (driver preferred RGB).
So far, I see only one solution - to make a custom EDID specifying YCbCr
Only way I'm seeing also: Your TV should not announce YCbCr , if it is broken. Or even better: treat yourself and get a working TV - you will see this issue with everything which implements HDMI specs correctly.
In LibreElec 10, you really need to make it possible to manually select the pixel format for the Rockchip SoC, as, for example, in OSMC for Raspberry Pi 4
You should start to understand, that this project's main goal is to use (only) upstream software - which increases compatibilty and future support in so many ways. This is currently a limitation of upstream(!) drm framework - we could do something like that our own, but nobody has a intention to do so (it would be a waste of time and will get dropped whenever there is a upstream solution)
-
Its just the way the upstream driver works (YCbCr is the default as per HDMI specs) - we had a workarround for that in b1/b2 releases since colorspace conversion was broken (driver preferred RGB).
Now it is clear why after beta 2 I could not use the SBC normally.
Only way I'm seeing also: Your TV should not announce YCbCr , if it is broken. Or even better: treat yourself and get a working TV - you will see this issue with everything which implements HDMI specs correctly.
In fact, an excellent TV, many devices are connected to it (PS3, PS4, XBOX 360, WD TV Live, Raspberry Pi 4) for many years I did not even know about this bug with YCbCr, and only found out when I bought SBC on SoC Rockchip. The essence of the bug is described here [SOLVED]HDMI handshake issues with Philips TV- magenta/green - ODROID, it is present on TVs of different models and manufacturers.
But, I seem to have solved this problem. Made a custom EDID by changing two fields (YCbCr 4:2:2 and YCbCr 4:4:4) in the EDID section: CEA-861 -> CHD: CEA-861 header so that they are passed as unsupported, see here RE: HDMI Passthrough RPi4 - AVR detection and here https://wiki.libreelec.tv/configuration/edid how to do it so that the changed EDID is loaded at the start of LibreELEC, and so far there is no more purple-green image
