[TESTING][S905(X)] 10bit/HDR/Dithering Test Builds & Discussion

Quote from [email protected]

Hello,

First of all congrats on your awsome job

I've been testing your dev release with various 4k 10 bits HDR mkv files. BT2020 is sent, and the TV switches to HDR mode.

Without running the "echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr" command, everything works fine except a stuttering on 24p movies (unsure if it's related to this release, will have to check)

With the command, I get nothing, a black screen. My TV a Panasonic 50DX750 is 10 bits compliants and I've got a HDMI 2.0a Amazon cable.

Don't have an AVR which can tell me more precisely what's been send to the TV.

I have a beelink Mini MX3 2 2/16

Display More

Please wait for the output compatibility tests. Thank you for testing. Same to astep

Quote from wrxtasy

LibreELEC.tv/platform_init at nougat-wip · amillogical/LibreELEC.tv · GitHub

Try setting this parameter to 0 and then saving in autostart.sh

echo 0 > /sys/module/amvdec_h264/parameters/dec_control

Thank you, this is a great idea. According to commit history, it was set to fix "BBC H.264 DVB-T." There's a good chance this issue was fixed in the backports, unfortunately I can't test it.

Quote from wrxtasy

I was actually watching DVB-T 1080i H.264 and it had annoying Jerkiness during video playback.

Reverting the dec_control to 0 has fixed it for me.

That's good to know. We didn't bring in the poc fix I was thinking of, so I will when I get a chance in addition reverting the platform_init change.

I did more nougat backports, and was able to bring in the h264 stutter (referred to as "slow motion") bug (topic-nougat-squash branch). This will be good to help narrow down the problem on the full nougat kernel at a later point

Quote from jd17

This is weird.
I just wanted to test if I see the skips on regular 8bit output too...

So I deleted the line (echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr) from autostart.sh and rebooted - AVR still shows YCbCr 30bit!
I checked autostart again and turned the box off completely (removed cable too)...
After booting, it is still 10bit, both with 60fps and 24fps!

Did you hardcode 10bit output in this build?

Display More

I'm not yet sure, but I didn't intentionally hardcode 10bit output if so. You can run echo '444,8bit' > /sys/class/amhdmitx/amhdmitx0/attr from GUI to get back to stock behavior.

Quote from jd17

What 4k flicker are you referring to?

On some 4k output on the marshmallow kernel there was a slight flicker.

jd17 and astep

At this point there are very few changes between this kernel and the full nougat kernel -- none that could cause this in hdmi modules at least, but dtb is another story. Because 8bit-only users were using the full nougat kernel, this doesn't seem to be shared. I don't have an AVR (with video going through) to test at the moment. When I reboot, according to kernel the video depth is 10 bit, but output is 8 (cd = ), and as such dithering and rounding are reenabled. However, this info doesn't seem trustworthy based on your reports.

Needless to say, we're taking some changes here back to the full nougat kernel very shortly, and switching focus back to it.

Switched back to the full nougat kernel due to multi-instance decoding related reverts fixing playback issues on it. I was also never able to get the same level of 10 bit PQ on this kernel as the full nougat kernel. If desired, this thread could be closed and moved back to kszaq's thread -- or it could stay open as discussion primarily for 10bit output.

This build needs the nougat-wip device tree again. Since I can't specifically test if this fixed the 10bit only output issue (since the kernel lied), it would be much appreciated if someone with video through an AVR could test.

This also breaks the IR remote again, so CEC or another remote is recommended.

The links were updated in OP.

Quote from jd17

I just did.
It's still 10bit only...

Triggering 8bit manually does not work either (echo '444,8bit' > /sys/class/amhdmitx/amhdmitx0/attr)...

Just on a side note - the frame skips are still there too.

I tested the full nougat build on a very old (unused) TV, and it can do 8bit output without any changes after the second boot. /sys/class/amhdmitx/amhdmitx0/attr isn't changing the actual output, rather what the video is output as. Without setting "444,10bit", even if it's 10bit output, the video is 8bit.

BTW, I was getting 4-6 frame skips/min on marshmallow with 10bit output and SPMC 16.7.0. I'm also still getting the frame skips here, but closer to 1-2/min. On the 8bit display I got frame skips, but only 2 after ~11min of playback (which from glancing at afl1's thread looks similar to what's current on those builds).

Quote from wesk05

I checked the latest full nougat build. 1080p is now 10-bit only. echo 8-bit command doesn't change anything. 4K is now stuck in 8-bit. echo 10bit command doesn't do anything.

Sink reads the color depth from the CD fields in the general control subpacket of HDMI signal. The CD fields are indeed being set to 10-bit for 1080p and 8-bit for 4K. What is weird is, I tested this on a simulated display with Deep Color support purposely removed and I could still get a picture and the CD field was still set to 10-bit. This doesn't comply with HDMI protocol which stipulates that the source shouldn't send Deep Color signal if the sink doesn't support it. Since I did get a picture I wonder whether the signal is indeed only 8-bit and that the CD fields are being incorrectly set.

I think you're correct that the cd fields are being incorrectly set. When I tested 10bit 4k output, I disabled 10-8 dithering but didn't get any banding in a banding test video I've been using.

I may have mentioned it earlier, but I've read deep color support (using dc_cap) on devices that don't support deep color as well.

I think setting CD as 10bit if "10" is in attr so early is a problem at one of the later CD checks prior to setting it, but haven't looked in depth. I started setting it early to fix a dithering CD check with libreelec resolution switching. The last builds that were reported to exhibit proper behavior (save for 10-8 dithering at 10bit output) were just before that workaround.

For the next build I'll revert it to be certain this fixes the issue.

For a better fix, I think we can switch to using cur_video_param for cd on the dithering check since we always resolution switch and keep the early setting from attr commit reverted. This should make the dithering check (cd switch case) exhibit the proper behavior on the mode change. We'll find out shortly.