[DEV ONLY][S905/X] 8.0 with "full Nougat" kernel preview builds

    I've started a build based on your latest (as of this morning, KERNEL_VERSION="ea2a014") and will report back after testing it later today.

    Quote from koenkooi

    I've started a build based on your latest (as of this morning, KERNEL_VERSION="ea2a014") and will report back after testing it later today.

    I got a chance to better test current HEAD and saw dithering was still enabled on 10 bit output. Amlogic had it enabled as well on 10 bit output without the changes (which seems strange), but it may have been unset elsewhere that wasn't affecting us due to resolution switching. This time it's tested as disabled by default for 10 bit output (8140a4c).

    For the most part it won't affect your testing, but wanted to make people aware.

    johngalt:

    Thanks for all your work to bring us closer to proper UHD playback. :)

    Maybe it is just me, but I am a bit confused regarding your 10-Bit tests and statements.
    I'll try to recap what I understood, so please help me out if any (or all) of the following is wrong...

    - Full Nougat is generally capable of 10-Bit output. (?)

    - "Detecting" 10-Bit in the source video and just switching to 10-Bit when necessary is not possible. (?)

    - 10-Bit to 8-Bit dithering and 10-Bit output cannot coexist. (?)

    I am also unsure about the following:

    - What kind of output issue do you see on YCbCr 4:2:0 at 10-Bit? You mentioned this before...

    - Are your tests limited to 10-Bit at 2160p + HDR10 + BT.2020? I would also be interested if 1080p / BT.709 / 10-Bit can benefit from a 10-Bit output.

    --- However, if you can use the resolution as a "trigger" to enable 10-Bit output, I'd prefer to keep the (good) 10-Bit to 8-Bit dithering on 1080p sources and have 1:1 proper 10-Bit output for 2160p....

    - Do you even have to define the color subsampling when you enable 10-Bit? Can you not tell the box to output 10-Bit independent of 4:4:4 or 4:2:0 so it automatically chooses what works and what doesn't?

    Without echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr

    PE II: Vertical banding in sun during intro, AVR says ‘YCbCr420, 24 bit’

    Passengers: OK, AVR says ‘YCbCr4444, 24bit’

    1080p24 SDR: Tons of frameskips

    After echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr

    PE II: TV says “no input”, AVR says it does have input

    Passengers: white dots in picture, audio glitches, AVR says ‘YCbCr444, 30bit’. Could be cable related.

    1080p24 SDR: Tons of frameskips, AVR says ‘YCbCr4444, 30bit’

    Going top down:

    - Yes, we've got 10 bit output here.

    - It's possible, but requires a bit of work (because of resolution switching in libreelec patched kodi side).

    - It can coexist, but we really don't want it to.

    - No output whatsoever when "420,10bit" is set on that sysfs interface. However, I get 4:2:0 10bit on >50hz after setting "444,10bit". I haven't looked into that issue, and am not sure of the priority of the issue either.

    - It can (and does) benefit, and no dithering is needed. I've watched various media on the box since, and have kept "444,10bit" set. This is something that could be set in autostart.sh for now for those of us on capable hardware. Unfortunately the dc_cap route I wanted to go (where we'd check on boot and set accordingly) has issues, as dc_cap is still misreporting hardware that isn't capable of 10bit input. This also means that as of now the "what is available" route you mentioned isn't available. This will be looked into. There's nothing wrong with setting 4:4:4 for now however.

    --- Wait a bit and test a new build (uploaded soon) before you decide on this. This is something that wouldn't be too difficult, but would require patching that probably wouldn't be liked by most users. As I understand it, your reasoning is because you're doing or using 10bit hevc rips of your blurays? In this case dithering is hardcoded into the rips, and you shouldn't need additional dithering with 10 bit output of them.

    - We must define it in that interface, but there are many other ways we could go about this. With that said, I don't see a reason to avoid defining it.

    Without:

    Pe II: Not sure with vertical banding, but even on my display's internal player and android with proper 10bit output I get some banding on this intro, so I don't think it's a great benchmark. However, when I was enabling/disabling dithering and going back with 8bit output, there was noticeably less banding in this intro, and no banding whatsoever in banding_test.mkv I was using (will reupload). I also recommend you set a 1080 GUI to use your displays upscaling on 1080 media. It will change to 2160 on 2160 media playback. The 2160 GUI is just poorly upscaled from 1080 anyway.

    1080p24 SDR: Wasn't able to recreate after ~15 seconds, would need logs. Most of the stuff I've played back took around 15 seconds to "settle in" and playback smoothly. I'm not sure if these changes are affecting it either from kszaq's original dev build.

    After:

    Pe II: I'm assuming your GUI was set to 50hz? I have a workaround on it's way to go back to always setting the mode. Long term this could potentially go back in the kernel to do so on colorspace change only.

    Passengers: Also can't recreate on what I'm assuming is this same rip. I suspect you're right. First, try a different one, and set that interface immediately on boot prior to any playback. If you still have issues and haven't played proper HDR through this cable previously, try a different one.

    1080p24 SDR: same as "without"

    Thank you all for testing. I noticed an issue if a video is played prior and "444,10bit" isn't set immediately on boot as well. So for those testing in the future, could you please test after a fresh boot so we're all on the same page?

    I have my GUI set to 1080p50 after discovering that 2160p is worse due to scaling. I'll try to do the tests you suggested this weekend.

    Quote from johngalt

    - It's possible, but requires a bit of work (because of resolution switching in libreelec patched kodi side).

    That sounds promising, awesome! :)

    Quote

    - No output whatsoever when "420,10bit" is set on that sysfs interface. However, I get 4:2:0 10bit on >50hz after setting "444,10bit". I haven't looked into that issue, and am not sure of the priority of the issue either.

    I asked this question because we need 4:2:0 @ 10-Bit in cases where the HDMI bandwidth is a limitation.
    So I thought it might be an issue...
    However, if you say that it goes into that mode automatically when the bandwidth limitation is reached and everything is fine then - great. :)

    Quote

    --- Wait a bit and test a new build (uploaded soon) before you decide on this. This is something that wouldn't be too difficult, but would require patching that probably wouldn't be liked by most users. As I understand it, your reasoning is because you're doing or using 10bit hevc rips of your blurays? In this case dithering is hardcoded into the rips, and you shouldn't need additional dithering with 10 bit output of them.

    Oh I think you might have misunderstood me here. ;)
    My goal would always be as close to the source as possible (like the "best match" setting for audio ;) ).


    I was asking this because I assumed we can't use the color bit depth alone as a trigger so I thought if we need to have an external trigger, 2160p made sense.

    I know that my Blu-ray encodes will look awesome either way - native 10-Bit output or proper 10-Bit to 8-Bit dithering. ;)

    Quote

    - We must define it in that interface, but there are many other ways we could go about this. With that said, I don't see a reason to avoid defining it.

    Yes, I agree - that was also a "conditional" question. :)

    Those boxes were always outputting YCbCr 4:4:4 for 1080p anyhow, in 8-Bit of course.
    I don't see a reason to change that either, as long as all resolutions, color spaces and color depths are working fine. :)

    Generally speaking, less conversion is always better of course - but the box is already performing quite well on the "Spears&Munsil scoreboard" with the MM build.


    I am looking forward to your build, just let me know when and what to test. :thumbup:

    I actually noticed a problem with the 10-Bit to 8-Bit conversion in the MM build (8.0.2a) today.

    A certain range in the lower grayscale flickers.
    It can easily be reproduced by setting the screensaver to 5% dim and pause a 10-Bit video during a scene that covers various brightnesses.
    Some areas in that frame will most likely show that flicker once the dim kicks in.

    Therefore, I am now looking forward to a 10-Bit testbuild even more. ;)


    EDIT:
    I have to adjust that statement...
    Apparently the flicker is also present on 8-Bit sources.
    Since I have been using MM Jarvis for a very long time and never saw something like that, it must have something to do with MM+Krypton.

    Edited once, last by jd17 (June 2, 2017 at 7:25 PM).

    jd17 To clarify, there's no change between 8 bit output at 10 bit or 8 bit, and there's no conversion occurring while keeping 10 bit output.

    New build:

    Please note IR remotes still won't work.

    Changes from dev build in OP:

    • 10-8 dithering support on 8bit output (fixes the color banding issue that's been posted often for nougat kernel).
    • Audio effectively at previous kernel state (fixes surround sound and passthrough).
    • CEC effectively reverted to MM state (fixes double keypress issue).
    • Resolution switching sets the same mode as current (should fix colorspace not being passed on same mode as well as a possible 10bit output bug on first playback). Edit: fixed, will upload this build: aml/hdmi: if setting attr, set color depth early · amillogical/linux-amlogic@361e832 · GitHub

    One of the benefits of kszaq's excellent work on this kernel is true HDR capability. If you'd like to test, look below.

    10bit output:

    • On a new boot before any other playback has been performed, run the following: echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr
    • This only needs to be set once each boot, so it can be put in /storage/config/autostart.sh


    Known 10bit output bugs:

    • First playback will still have dithering. Some other cases there may still be 10 bit dithering (checking colorspace alone in kernel has issues due to LE resolution switching). This will be fixed. Fixed in new build :)
    • Unsure, but would be surprised if no others exist.

    Download - build updated for dithering issue

    Edited 8 times, last by johngalt (June 2, 2017 at 10:47 PM).

    johngalt I tired ur build, but no changes :( Do you have any idea?

    I had time today and I tired kszaq dev build (and ur too) 10 times start 4k video: 7x black screen, but 3x start the video normal, there was picture and sound. But later the screen went black and some sec. came back again...

    Quote from RedCat

    johngalt I tired ur build, but no changes :( Do you have any idea?

    I had time today and I tired kszaq dev build (and ur too) 10 times start 4k video: 7x black screen, but 3x start the video normal, there was picture and sound. But later the screen went black and some sec. came back again...

    I have some ideas, but saved your logs and haven't had a chance to look into it very far. Sorry, I didn't expect that build to fix your issue.

    Edit: updated download link above for dithering issue with 10 bit output :)

    Edited once, last by johngalt (June 2, 2017 at 10:37 PM).

    Quote from johngalt

    New build:

    .
    .
    .

    10bit output:

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

    I just tested your build (I enabled 10bit output right away).
    BT.2020 is definitely passed. :)
    HDR10 seems to work great too. :)


    10bit probably works as well, unfortunately the TV does not tell me.
    It looks good from a first glance, no obvious banding in either 8bit or 10bit videos.

    Observations (menu is set to 1080p60):

    1080p / BT.709 / 8bit / 23.976fps:
    Seems fine.

    1080p / BT.709 / 10bit / 23.976fps:
    Seems fine.

    1080p / BT.709 / 8bit / 25fps:
    Seems fine.


    2160p / BT.709 / 8bit / 23.976fps (LG Syndney demo):
    Signal is lost after a few seconds. Stopping retrieves signal (in menu).

    2160p / BT.709 / 8bit / 25fps (LG Skiing demo):
    Signal is lost after a few seconds. Stopping retrieves signal (in menu).

    2160p / BT.709 / 8bit / 29.97fps (LG Chicago demo):
    Seems fine.

    2160p / BT.709 / 8bit / 30fps (LG Wonders demo):

    Video won't start.

    2160p / BT.709 / 10bit / 50fps (LG La Boheme demo):   
    Signal is lost after a few seconds. Stopping retrieves signal (in menu).

    2160p / BT.709 / 10bit / 59.94fps (LG OLED Art demo):
    Seems fine.

    2160p / BT.709 / 10bit / 60fps (LG Eclipse 2 demo):
    Seems fine.


    2160p / BT.2020 / 10bit / HDR10 / 23.976fps (Samsung HDR Wonderland demo):
    Signal is lost after a few seconds. Stopping retrieves signal (in menu).

    2160p / BT.2020 / 10bit / HDR10 / 59.94fps (Samsung HDR Chasing the Light + Sony Camp demo):
    Seems fine.

    2160p / BT.2020 / 10bit / HDR10 / 60fps (LG Colors of Journey demo):
    Seems fine.


    Conclusion:
    Apparently 2160p at 23.976 / 25 / 30 and 50 fps is an issue, at least while the menu is set to 60 fps.

    jd17

    Thank you. I'm getting those demo videos to test, but I'm already concerned I won't be able to recreate (have tested 23.976fps 2160p/bt2020/10bit videos). Could you upload dmesg and kodi.log? After each of the following commands you'll get a link to post here:

    dmesg | curl -F 'sprunge=<-' http://sprunge.us

    cat /storage/temp/kodi.log | curl -F 'sprunge=<-' http://sprunge.us