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

  • Yes, I know that of course. ;)

    However, have you ever seen a 15m cable that got the Premium label?
    The only ones I have seen in Germany max out at 3m and cost a hilarious 60€ at that length... :D

  • Yes, I know that of course. ;)

    However, have you ever seen a 15m cable that got the Premium label?
    The only ones I have seen in Germany max out at 3m and cost a hilarious 60€ at that length... :D

    Allekabels.nl has premium certified at 6m for €40, but not any longer ones. I wonder if that's a cost or electrical issue (or both).

  • With the same setup, using egreat box A5, 4k hdr 10 output all is okay, so I think that there are some problems with testing version.

    That should not be your conclusion from the experience.

    It is far more likely that this box is just passing a lower bandwidth due to either not passing BT.2020 correctly or 10bit correctly or......

    I think the JVC beamers have a tab in the menu to show the specifics of the input signal...
    Please check if that actually confirms the signal from this egreat box is 2160p / BT.2020 / HDR10 / 10bit.

  • While that is strange, you still have a clear indicator that your 15m cable is a limiting piece in the chain - your own test confirmed that.

    Additionally, most other experiences agree with how difficult high bandwidths are with long distance, passive cables.

    Everyone else who tested john's builds eventually made them work, after upgrading the cables in some cases too.

    This is why I still believe it is more likely that something in that egrat box's signal is off than believing the fault is with john's build.


    Ideally you should use a UHD Blu-ray player to confirm, but I assume you don't have one...

    Do you know what chroma subsampling the egreat box puts out?


    For 10bit, 4:2:0 is officially only supported at 50 Hz and 60 Hz, while 23.976 - 30 Hz are only supported at 4:4:4 by HDMI 2.0:
    HDMI :: Manufacturer :: HDMI 2.0 :: FAQ for HDMI 2.0


    If your cable cannot pass a 23.976 - 30 Hz signal at YCbCr 4:4:4, it does not comply with the HDMI 2.0 standard. For me, that would be reason enough to consider a replacement.

  • Uploaded a new build (8.0.2-testing2) on the github releases page. This is a rather minor update to the testing1 release, and should be a show of stability.

    Changes:

    • Merged in upstream (kszaq) changes.
    • Merged in wrxtasy h265 dynamic_buf_margin (fixes some h265 picture corruption from improper dynamic_buf_margin), and modified vp9 dynamic_buf_margin to fix new corruption from wrxtasy's change.
    • Some minor hdmi driver fixes, with most important being properly
      setting AVI in case of colorspace correction bypass.
  • Thanks johngalt! :)

    I have a question on a side note, maybe you can help me out...
    As you maybe remember, I complained a few times about weird lower grayscale flicker.
    It turns out that my AVR adds that to the signal. :(
    I am bypassing the AVR's video processor and it still messes up the signal - even if I "dumb down" the S905X output signal as much as possible (422, 8bit / rgb,8bit), I tried everything.

    The flicker is not there with the RPi2, however - the image quality of that is also inferior in the lower grayscale range.
    My assumption is that the S905X generally uses some kind of dithering that the AVR does not like...
    I don't know. It happens with MM kernel as well, so it's independent of build.

    Anyhow, long story short, as a last grasp - do you know if it is possible to "boost" the HDMI output signal on AMLogic devices?
    I am asking because the RPis have that function:

    Code
    config_hdmi_boost=0-11
    • Merged in upstream (kszaq) changes.
    • Merged in wrxtasy h265 dynamic_buf_margin (fixes some h265 picture corruption from improper dynamic_buf_margin), and modified vp9 dynamic_buf_margin to fix new corruption from wrxtasy's change.
    • Some minor hdmi driver fixes, with most important being properly
      setting AVI in case of colorspace correction bypass.

    I just want to politely ask if you also fixed my reported h264 SD hardwareacceleration bug?

    Of course I will test it the weekend ;)

    • Merged in wrxtasy h265 dynamic_buf_margin (fixes some h265 picture corruption from improper dynamic_buf_margin), and modified vp9 dynamic_buf_margin to fix new corruption from wrxtasy's change.

    Skipping in HEVC videos now messes up the playback. Everything jumps around.
    I assume the quoted part is responsible for that?

  • I'm not sure of a similar function that's currently implemented (and I'm also not sure if it would help). The 10-8 dithering is disabled on 10bit output, but it could be a sync issue of some kind (though if you also get it on 50/60hz, then possibly not).

    Skipping in HEVC videos now messes up the playback. Everything jumps around.
    I assume the quoted part is responsible for that?

    Damn! Will fix. Thank you for reporting. I also believe that "macro blocking" issue you reported might be related to a color range bug if we fall back on hdmi mode from an edid parsing failure.

    I just want to politely ask if you also fixed my reported h264 SD hardwareacceleration bug?

    Of course I will test it the weekend ;)

    I may have misunderstood when you reported it: did you explicitly enable hardware acceleration for SD videos?

    Edited once, last by johngalt (June 16, 2017 at 9:07 PM).

  • ...and I'm also not sure if it would help.

    Me neither... But I'm desperate, grasping for straws.

    Quote

    The 10-8 dithering is disabled on 10bit output, but it could be a sync issue of some kind (though if you also get it on 50/60hz, then possibly not).

    I get this on regular 1080p / 8bit / AVC stuff too (the only kind I can compare to RPi2)...
    This is what makes it so weird. I had the box basically set up as a 1080p-only device in my last tests (422,8bit / rgb,8bit / 444,8bit).
    I even disabled deep color on the TV's HDMI input, anything to delete noise.

    However, I have not tested 50/60Hz yet - will do!

    What do you mean by sync issue?

    Quote

    Damn! Will fix. Thank you for reporting. I also believe that "macro blocking" issue you reported might be related to a color range bug if we fall back on hdmi mode from an edid parsing failure.

    Good man! :)
    It sounds like you have some compelling ideas.
    Just let me know when there is a build in which I should test those samples for the macroblocking again. :)

  • Just uploaded "testing3." This is the same as testing2, except as far as dynamic_buf_num changes go, only vh265 was dropped down to "stock" to fix the picture corruption. There's still a small stutter after skipping ahead for ~10 seconds.

    What do you mean by sync issue?

    A pixel freq or vertical/horizontal freq issue.