Posts by mule

    Mhmm, I am compiling my own 8.2.x version with some personal patches. About 2 weeks ago I upgraded to r7p0 on 6 boxes (a mix of S905X and S912) and until now there were no issues/regressions (did also test Billy Lynn with 60Hz). Would be great to know which regressions exactly had been found.

    Thanks for your efforts. I had a look at your patch and would like to clear things up in regards of the different patches:

    - The below attached "dither"-debug code is not of any use, because setting it just results in flickering.

    Code
    1. ++ } else if (strncmp(tmpbuf, "dither", 5) == 0) {
    2. ++ int dither = 0;
    3. ++ if (tmpbuf[6] == '1')
    4. ++ dither = 1;
    5. ++ hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, dither, 4, 1);
    6. ++ hdmi_print(INF, SYS, "hdmitx: adjust dither to %d", dither);
    7. ++ return;

    - The below attached "round"-debug code was implemented in order to test if this setting can fix the banding issues and yes it does, but it has to be set everytime after playback has been started. I'm therefore using the "callbacks" addon for kodi with a script which always gets started by the kodi event "on playback".

    Code
    1. ++ } else if (strncmp(tmpbuf, "round", 5) == 0) {
    2. ++ int round = 0;
    3. ++ if (tmpbuf[6] == '1')
    4. ++ round = 1;
    5. ++ hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, round, 10, 1);
    6. ++ hdmi_print(INF, SYS, "hdmitx: adjust round to %d", round);
    7. ++ return;

    - The below attached code part was implemeted by Sam as a try to generally fix the banding issues after we found out that setting round=0 or round=1 fixed it. Sadly this general approach did not help, because as written before setting round has to be done everytime after playback has been started. So this part of the code is pretty useless.

    Code
    1. + hd_set_reg_bits(P_VPU_HDMI_DITH_CNTL, hs_flag, 2, 2);
    2. + } else {
    3. + hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, 0, 4, 1);
    4. +- hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, 0, 10, 1);
    5. ++ hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, 1, 10, 1);
    6. + }
    7. + break;
    8. + default:

    - The below code part as change of the videoplayer from kodi is just one part of the final solution from Sam on which he is working now. This code part alone does not solve the banding issue.

    Code
    1. ++ CLog::Log(LOGINFO, "Fix potential banding issue with material");
    2. ++ SysfsUtils::SetString("/sys/class/amhdmitx/amhdmitx0/debug", "round1");


    - The below code part Sam implemented in order to switch between BT.2020 and REC709 when using Kodi GUI in 4k resolution. Again this is only one part of the code needed to be useful. To make switching between color spaces possible kodi needs to be updated too.

    Code
    1. ++ } else if (strncmp(tmpbuf, "do2020", 6) == 0) {
    2. ++ hdmi_print(INF, SYS, "hdmitx: BT2020 AVI on");
    3. ++ hdmitx_set_reg_bits(HDMITX_DWC_FC_AVICONF1, 3, 6, 2);
    4. ++ hdmitx_set_reg_bits(HDMITX_DWC_FC_AVICONF2, 6, 4, 3);
    5. ++ return;
    6. ++ } else if (strncmp(tmpbuf, "no2020", 6) == 0) {
    7. ++ hdmi_print(INF, SYS, "hdmitx: BT2020 AVI off");
    8. ++ hdmitx_set_reg_bits(HDMITX_DWC_FC_AVICONF1, 2, 6, 2);
    9. ++ hdmitx_set_reg_bits(HDMITX_DWC_FC_AVICONF2, 0, 4, 3);
    10. ++ return;

    Final conclusion: For now some of these patches are of no use at all, some are not ready for use. Solving banding issues and using kodi GUI in 4k needs extra code from Sam/kodi developers.


    If you have any further questions just ask.

    Thanks for your efforts, it's great to see users helping in this way however I will not be using the legacy kszaq 8.2 nougat kernel anymore, the LE kernel is a more 'recent' nougat kernel and I feel our efforts would be better focused there. I have submitted a PR to add the dither/round/REC709/BT2020 options to the LE kernel link.

    I will add the Kodi portion of the code to the community builds as soon as I get a chance.

    I agree with you that further development should be based on the new kernel. Hopefully the important bugs can be solved quickly.

    wrxtasy

    I made a patch for the old kernel in order to get rid of flickering/noise which is now fully functional. The formerly linked from Sam's OSMC github you linked was not complete, so I made a new one (see attachement).


    This patch also includes the new debug options (dither/round/REC709/BT2020) developed by Sam. Round for avoiding banding on S905(x) and REC709/BT2020 in order to use KodiGUI in 4k. Both needs some (not yet finished) changes to the Kodi code in order to work.


    I tried to fix the green issues with e.g. 422-10Bit but was not yet succesfull. Will try some more changes later.


    linux-000_AntiFlickerBanding_AMLogic.zip

    Let me know how the patch goes for you.

    The patch for the old kernel in order to get rid of flickering/noise is now fully functional. The formerly patch from Sam's OSMC github commit which was posted by wrxtasy was not complete, so I made a new one (see attachement).


    This patch also includes the new debug options (dither/round/REC709/BT2020) developed by Sam. Round for avoiding banding on S905(x) and REC709/BT2020 in order to use KodiGUI in 4k. Both needs some (not yet finished) changes to the Kodi code in order to work.


    I tried to fix the green issues with e.g. 422-10Bit but was not yet succesfull. Will try some changes later.



    forum.libreelec.tv/core/attachment/3325/

    GDPR-2

    As far as I testet: Only with 8.2.

    The flicker only appeared on S905 devices, not on S912 and it is mostly recognizable on OLED TVs. On other TVs and projectors you have exctly to know where to search for and stand next by the screen.

    The noise is very very hard to be recognized on small screens (TVs). The first time I recognized it was when I compared my UHD player with my Minix U9 using my projector: I missed the sharpness of my UHD player in the picture and so went near the screen where I recognized the mentioned noise and that it even exists while playback is being paused.

    This may explain why there are only a few complaints about it.

    Will the 8-bit processing path of S905X affect the "thing" about HDR much - i.e. vivid colours and superior contrast compared to SDR? I've been thinking about getting me a Sony XE9005 which has a true 10-bit display panel but I'd rather wait if the output devices are not up to it. S912 is not an option because of the "stuttering video with subtitles" issue.

    In theory the vividness of colours should not be impacted by the bitdepth, but I did not explicitely test colours because I am busy getting a mostly banding free image from my Vero4k and a flicker/noise free image from my Minix U9. So I did many tests in regards of banding and the result is that with S912 based devices banding is not an issue at all (with the right kernel patch and if the source material is free of banding). With S905X there is some slight banding left which can be recognized if you are using a projector. On a TV screen it is much more harder to be recognized.

    This could be down to deinterlacing or noise reduction, have you tried turning them on/off?

    Let me know how the patch goes for you.

    No, it has nothing to do with noise reduction. The issue is caused by faulty round/dither options. 8.2.2.3 with the patch mentioned by wrxtasy just compiled successfully. Going to test it in the evening, results will follow.


    Side note: The anti flicker/noise patch is already included in the new kernel you are using now.

    GDPR-2 : Thanks for your open words. 8.2.x is without patching not an alternative because with the old kernel there is visible flickering on S905 and noise on S912 with 4k/HDR videos (even while playback is being paused).

    I am going to try to patch the 8.2.x with the anti flicker patch by Sam. Lets see if this is a solution.