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

    I just want to say thank you for your work.

    I can play the BT.2020 movies with testing1 version with normal contrast and black level now even on my non HDR capable tv.

    (My dc_cap is

    420,8bit

    444,10bit

    444,8bit

    422,10bit

    422,8bit

    rgb,10bit

    rgb,8bit

    )

    Done some testing, and the only problem i can see is that the famous frame skip is back for some media.

    Also tested setting dc_cap to 444,12bit , and my AVR reports YCbCr444 36Bit and all 8/10 bit looks OK. Haven't tested any 12bit yet, so don't know if it works;)

    I am back and ready to continue testing... :)
    I don't have the good cables yet, but I'll get them from the post room tomorrow.

    So, I started to look for what I can in "8.0.2-testing1" first.

    Observations:
    - IR is not working, I thought it should? Or was that another build?
    - 8bit is proper 8bit (regular start).
    - Switch command to 10bit switches to 10bit.

    - Frame skips:

    --- Regular boot without command (8bit output mode): no skipped frames within 33 minutes, very promising! (Only two initial skips at video start.)

    --- 10bit output mode: 29 minutes played, not a single skip so far - very promising! I will continue testing for a longer time later.

    - I have not seen the "lower grayscale flicker" from the MM Krypton builds yet.
    - 10bit videos look good in 8bit output mode, no hard banding lines.


    Apart from IR not working and UHD testing pending, this seems to be a very good build. :)
    Thank you very much johngalt.

    Would you like me to continue testing this build or rather focus on "8.0.2-exp1"?

    You're welcome! That dc_cap is interesting (no 10bit 4:2:0 support), what's your TV model?

    Quote from 2re

    Done some testing, and the only problem i can see is that the famous frame skip is back for some media.

    Also tested setting dc_cap to 444,12bit , and my AVR reports YCbCr444 36Bit and all 8/10 bit looks OK. Haven't tested any 12bit yet, so don't know if it works;)

    Interesting re: 12bit...I doubt it will be able to play 12bit media, but didn't consider 12bit output even working. What types of media are frame skips back on? AVC?

    Quote from 2re

    ... And the audio is also off by 0.125s ;)

    What type of media is audio off on? Also, if you pause it and start it again, is the audio still off? I'll work on bringing in comparable changes to peak3d's I reverted which should fix this behavior.

    IR should work if you update the device tree (place dtb without rename into .update folder as well) :) . Also, I'm interested if 4k output works for you on the current cables after a hdmi related change (fixed some 4K AVR compatibility).

    Quote from jd17

    I see those artifacts as well ("8.0.2-testing1").

    They seem to be mostly eliminated in 8.0.2-exp1 :). All future work is going into 8.0.2-exp1 as well.

    Quote from johngalt

    IR should work if you update the device tree (place dtb without rename into .update folder as well) :) .

    Well, this is embarrassing - I completely missed that there is a new DT...

    Quote

    Also, I'm interested if 4k output works for you on the current cables after a hdmi related change (fixed some 4K AVR compatibility).

    Can you explain that change to me? It should not be possible (or advisory) to somehow limit the bandwidth, should it?

    Quote

    They seem to be mostly eliminated in 8.0.2-exp1 :). All future work is going into 8.0.2-exp1 as well.

    That sounds good - so we should focus on the new build?
    I can start testing right away. :)

    However, I am currently considering if I can use "testing1" as permanent replacement in the meantime, since I'm very annoyed be that flicker...
    Is there any drawback compared to the old MM builds?

    Quote from johngalt

    10bit output on capable hardware:

    On a new boot before any other playback has been performed, run the following: echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr

    Force RGB:
    If you have an older display and needed output_rgb, please use the following instead of the old interface:

    echo 'rgb,8bit' > /sys/class/amhdmitx/amhdmitx0/attr

    I have a 8-years-old Panasonic plasma TV with the following display capabilities:

    LibreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/dc_cap
    444,10bit
    444,8bit
    422,10bit
    422,8bit
    rgb,10bit
    rgb,8bit

    Do I need to issue any of the commands I quoted above?

    I don't think dc_cap is reporting correctly for non-4:2:0 modes, but am not sure. If you'd like to try, you could run the first command and play a video to see if you get 10bit output. If you don't get output, reboot.

    The rgb command is only needed if you previously had to enable output_rgb. I think the issue was a green tinted screen.

    Quote from jd17

    Can you explain that change to me? It should not be possible (or advisory) to somehow limit the bandwidth, should it?

    It's actually not a bandwidth change, rather stops a hpll reset from occurring on timeout. I was surprised it worked, but it fixed the 4k nougat output issue for RedCat with a denon AVR.

    Quote from jd17

    However, I am currently considering if I can use "testing1" as permanent replacement in the meantime, since I'm very annoyed be that flicker...
    Is there any drawback compared to the old MM builds?

    "testing1" is in a very good state, with no drawbacks that I'm aware of.

    Edited once, last by johngalt (June 11, 2017 at 5:39 PM).

    Quote from johngalt

    I don't think dc_cap is reporting correctly for non-4:2:0 modes, but am not sure. If you'd like to try, you could run the first command and play a video to see if you get 10bit output. If you don't get output, reboot.

    Video signal goes through my AVR, perhaps it affects dc_cap results. I'll try with direct connection to the TV when I get a chance.

    Unfortunately, my AVR and TV are almost the same (old) age and they don't display any info beyond a simple resolution so I won't know whether I get 10bit output or not.

    I ran the "echo '444,10bit'" command but I didn't see any noticeable difference in picture quality.

    Quote from minimoe

    Video signal goes through my AVR, perhaps it affects dc_cap results. I'll try with direct connection to the TV when I get a chance.

    Unfortunately, my AVR and TV are almost the same (old) age and they don't display any info beyond a simple resolution so I won't know whether I get 10bit output or not.

    I ran the "echo '444,10bit'" command but I didn't see any noticeable difference in picture quality.

    Okay, it's probably the AVR. I wouldn't worry about running either command then.

    Somehow "exp1" turned out to be a mystery build. I'm not sure what I built it off. Whatever it is, it isn't built off the "nougat-exp" branches I pushed to github.

    I've removed the build as such, and will continue working on it. Thank you everyone for testing. I highly recommend using "testing1" instead.

    Edited once, last by johngalt (June 11, 2017 at 6:29 PM).

    Quote from johngalt

    I don't have a S912 device, and additionally I'm not sure if any of these changes will have an effect on it because it uses libhybris and android blobs.

    I hope it's possible :)

    In any case thank you for your work.

    May be kszaq can implement some of your achievements in our device builds

    I surely will. When johngalt considers his work ready, I will start integrating all the improvements. Unfortunately I cannot add anything to it now as I have no HDR/4K/10-bit capable equipment.

    johngalt S912 devices use libhybris only for OpenGL support/GUI rendering, everything playback related works the same way it does on S905(X) and additionally S912 is marketed as DV capable.

    kszaq, Thank you, that's good to know. In that case, I can try a S912 build shortly.

    Regarding merging "upstream:" I have experimental branches I'm working on. Once they're ready and merged in, we'll need testers who had 4k output issues on nougat (so far only one has reported the issue is fixed). After all that, we can address the merge :).

    Uploaded another experimental build (check github release page linked as "download" in OP). This is built off the nougat-exp branches which have many amlogic updates merged in.