Has anyone checked to see if this issue has been fixed in an update 12.0.1?
Posts by Mikhail
-
-
LibreELEC 12 on Rock Pi 4 (RK3399), if the "Adjust display refresh rate" option is enabled, when playing any video, when the OSD menu appears on the screen, the video starts to twitch, horizontal tears appear, on LibreELEC 11 everything works fine.
-
Hello
I'm going to buy Rock Pi4 Plus (4GB RAM / 32GB eMMC). Are there any major problems with libreELEC on this device? I care most about 4K HDR playback along with HD Audio passthrough to my AVR (Dolby Atmos, DTS HD, DTS X).
There is one significant issue on the LibreELEC 10 (and nightlies LE11) on the RK3399 SBC, intermittent clicks in sound when hardware decoding is enabled. The RK3399 has a very powerful VPU that can decode h264 10-bit (this is a killer feature for me), it's a pity that only one person is working on the Rockchip SOC.
-
One important note, I should have tried it before, with hardware decoding disabled, the sound is absolutely normal, crackling sound occurs ONLY when the video is played with hardware decoding enabled (DRM PRIME).
-
Upgraded to LibreELEC RC1, crackles still occur during video playback. During this time, an SBC ROCKPro64 came to me, there are the same problems with sound, crackling, from which I conclude, problems with sound on the RK3399 do not depend on the SBC. On the 4.4 kernel, it was once possible to eliminate them (RK3399 HDMI audio quality), I hope that on 5.10 it will be possible to do the same.
-
-
When playing some videos on a Raspberry Pi 4 with LibreELEC 10 installed, artifacts are observed that are not present when playing the same video under LibreELEC 9.2.6. Here is a piece of such a video file.
-
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
-
Updated to 9.95.4, still on my TV the image periodically turns pink-green, why does the driver choose YCbCr color space by default? How can I force him to specify that the signal is always RGB Limited? So far, I see only one solution - to make a custom EDID specifying YCbCr there as an unsupported mode. But there must be a simpler solution.
-
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
-
I'm not sure I understand what you're trying to say. Provide a (uart) log, I guess thats more helpful.
Do you need a usb to ttl cable for this? Unfortunately, I have not. Simply put, if you write the image (20210511) to emmc, turn on the power, the rock pi 4 will not boot either from the emmc or from the sd card, there will be no signal to the hdmi, it will not react to anything until the emmc is cleared.
-
After the nightly image 20210511 was written to the EMMC module, rock pi 4 stopped loading at all, even from the sd card
Only physical removal of the module and formatting it through an adapter helped -
I could not boot from the EMMC module on the Rock Pi 4: Could not mount / flash / SYSTEM, as I understand it, you need to change the paths after uploading the image to the EMMC? I tried a new .dtb, it got better, but the problem did not go away completely, if you listen, there are occasional crackles. On the last nightlies, the Kodi interface on my TV began to turn purple-green, which is not on 9.95.2, apparently, the output signal for some reason switches to YCbCr.
-
This is definitely not a hardware problem. I have a new SBC Rock Pi 4B, installed LibreELEC 9.2.6 on the EMMC module and 9.95.2 on the microSD card (by the way, when will LibreELEC 10 be able to boot from EMMC?), I compared rebooting between them, on 9.2.6 there is no such problem. Perhaps this is not a problem with all RK3399 SoCs, but only Rock Pi 4B on the new kernel.
-
I'm not sure which sample, on any video that I would not play, there are crackles in the sound output on hdmi, it is most clearly manifested in ishi's dialogues when music is playing.
-
Updated to 9.95.2 crackles are present in the output sound.
-
This problem has already existed and now it has appeared again: RK3399 HDMI audio quality.
-
Yes, I have the same, I use nightly builds, Rock Pi 4.
