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

  • I started testing the high bitrate Rogue One Blu-ray remux (39mbit/s average video + audio) with the new build this morning (10bit output).

    Unfortunately, out of the 11 frame skips within 10 minutes of playing, at least 6 were "unprovoked", i.e. not triggered by me opening the overlay.

    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

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

    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.

  • 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. ;)

  • 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.

  • jd17 I can recreate the frame skips, but haven't compared on 8bit output yet. I won't have a chance to test thoroughly until mid week. The late frame patch update may help, not sure. The next priority for me is 4k output compatibility for users having issues, then I can work on everything else.

    Sure, I understand! :)

    Quote

    Build in OP updated. Changelog:

    • afl1's late frame patch updated (haven't tested thoroughly at all).

    Thank you for including the patch anyways! :thumbup:

    I am testing this build right now.

    First observations:
    - PlayerDebug looks different, the font changed.

    - The refresh rate switch did not work at first boot after the update (video was being output at 60fps). I rebooted and now it's displayed at 23.976fps, as it should.

    - The frame skips are not gone. I have seen 6 unprovoked skips within 9 minutes

    Quote

    Dev note: I found that restoring some hpll registers (frac frame rate support takes some adapting) can bring back marshmallow 4k flicker. If so, you can change the register set sequence to avoid it for the affected clock to avoid it :).

    What 4k flicker are you referring to?

    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

    I am testing now. What is behind this? What does it do? :)

    After just ssh-ing the command, I still have frame skips.

    Trying with autostart now...
    No... still seeing frame skips. 3 within the first few minutes.

  • 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?

  • 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 :)

    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.

  • 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.

    I had actually already tried that as well (via SSH).
    It does not work, output is still 10bit (according to AVR).

    I also booted into 8.0.2a MM again to make sure there is no other issue, but the AVR shows YCbCr 24bit in that build, as it should.

  • It does not work, output is still 10bit (according to AVR).

    I also booted into 8.0.2a MM again to make sure there is no other issue, but the AVR shows YCbCr 24bit in that build, as it should.

    Same here. No 10bit TV hence the black screen.

  • 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.

    Edited once, last by johngalt (June 5, 2017 at 6:05 PM).

  • As previously announced, I won't be able to continue testing in the next 5 days...

    That gives you 5 days to build the holy grail of builds with flawless UHD playback, no frame skips and perfect a/v sync for all audio at all frame rates. 8o:D



    Kidding of course... But thanks again for your amazing work and I already look forward to continue testing with the new cables next Sunday. :)

  • 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.

    Edited 3 times, last by johngalt (June 5, 2017 at 9:12 PM).

  • 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.

    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 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).

    Edited once, last by johngalt (June 6, 2017 at 5:26 AM).

  • 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 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.

    Edited once, last by johngalt (June 6, 2017 at 8:14 AM).

  • 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).

    8.0.1l and 8.0.1k-l from afl1, both Nougat Frankenstein builds, were definitely free from frame skips.

    I tested those thoroughly, which is why I then changed that thread title to RESOLVED.

    Unfortunately they had the 10bit banding...

  • Kszaq's "Full Nougat" preview ran fine. No 4k or 10bit hardware here. Good old 1080p. i don't think my problem is cable related at that resolution.

    Your TV doesn"t support 1080p/10 bit, that's why your screen is black.