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

    Wow, that really sounds amazing, thanks for your great work kszaq & johngalt! :)

    I'm really excited to hear that BT.2020 is being passed, I will too do some testing tonight.
    I know this is aimed at devs only, but maybe there is still something I can contribute.

    Quote from johngalt

    Would it be recommended to always have dithering enabled if we could get quality high enough? On some other platforms it's a Kodi default.

    Do you mean additional dithering for regular 8-Bit content too?
    Or just dithering that is being used on 10-Bit to 8-Bit conversion?

    Either way - I'd be happy to do some comparisons if that helps, just send me links to with and without builds. :)

    Quote from johngalt

    Edit: oh wow, manual 10 bit output can work in this kernel. I think I can do a kernel solution to manually setting colorspace and depth for source based on RXCap if I assume there's always going to be a resolution change for playback. It actually looks like we can have full HDR10 on libreelec after all :).

    So you mean 10-Bit could actually be properly passed 1:1?
    That would blow my mind! :)
    Thank you so much for looking into this! :)

    I've done very little...just messed around with kszaq's awesome work.

    re: dithering, I was curious about having dithering for all content, but I'm not sure about getting the quality on par with other implementations that are on by default so let's just forget about that for now I guess.

    I'm not sure if it is being properly passed (I know very little about the overall architecture). I was able to get 10 bit output, but am not sure if it's 10bit video on the 10bit output. From what I've seen, I think it should be possible. With minimal hardware, I think I can revert a fix to test if it's real 10 bit output or not. I ran out of time for testing, and have too much I need to get done to look into it very quickly. With that said, I'd LOVE to drop android/second box and just use libreelec, and kszaq got us closer than ever to that reality :) .

    I've taken kszaq's branch and cherrypicked in 3 commits:

    Code
    koen@libreelec:~/LibreELEC.tv-8.0$ git cherry -v | tail -3
+ 50fc937b8d863c9e50fe73fcd3aef2d49a0fcc7a S905: update audio config and patches
+ 44eebb8c7a27a3d2a23299315823582589e33893 S905: use custom test kernel
+ a1031f5ec821245cd2f1edc207cd31fc62643f3f S905: bump kernel

    Most HDR videos play fine, but the Planet Earth II is given me problems, the colours are weird and the picture is full of artefacts. Below is a photo of the TV with the AVR overlay on the bottom and TV overlay on the top.

    One of the differences between the working movies and this is that the working ones are 24/1.001 fps and this one is 25, so no change is needed from the 50Hz GUI.

    For testing you can use this sample.

    Quote from koenkooi

    I've taken kszaq's branch and cherrypicked in 3 commits:

    Code
    koen@libreelec:~/LibreELEC.tv-8.0$ git cherry -v | tail -3
+ 50fc937b8d863c9e50fe73fcd3aef2d49a0fcc7a S905: update audio config and patches
+ 44eebb8c7a27a3d2a23299315823582589e33893 S905: use custom test kernel
+ a1031f5ec821245cd2f1edc207cd31fc62643f3f S905: bump kernel

    Most HDR videos play fine, but the Planet Earth II is given me problems, the colours are weird and the picture is full of artefacts. Below is a photo of the TV with the AVR overlay on the bottom and TV overlay on the top.

    One of the differences between the working movies and this is that the working ones are 24/1.001 fps and this one is 25, so no change is needed from the 50Hz GUI.

    For testing you can use this sample.

    I have the same PE Ii videos already and was able to test.

    My display's at 60hz, so at first I didn't have an issue due to the mode being set again. When I set my display to 50hz, I was able to replicate your issue. Try setting your display to a different refresh rate prior to playback and see how it goes. This will also cause issues for me with 60fps HDR videos.

    Also, I realized I was testing manually set depth with the dithering fix prior. This is also needed right now on libreelec, and is separate because it can be reverted when output is correctly set aml/hdmitx: enable 10-8 dithering by default · amillogical/linux-amlogic@95f9dae · GitHub . I amended and force pushed the LE fork kernel bump for people like koenkooi.

    When output is correctly set, I think this issue will go away so I won't try to work on a fix before working on that for now (when I get more time).

    Quote from koenkooi

    I've taken kszaq's branch and cherrypicked in 3 commits:

    Code
    koen@libreelec:~/LibreELEC.tv-8.0$ git cherry -v | tail -3
+ 50fc937b8d863c9e50fe73fcd3aef2d49a0fcc7a S905: update audio config and patches
+ 44eebb8c7a27a3d2a23299315823582589e33893 S905: use custom test kernel
+ a1031f5ec821245cd2f1edc207cd31fc62643f3f S905: bump kernel

    Most HDR videos play fine, but the Planet Earth II is given me problems, the colours are weird and the picture is full of artefacts. Below is a photo of the TV with the AVR overlay on the bottom and TV overlay on the top.

    One of the differences between the working movies and this is that the working ones are 24/1.001 fps and this one is 25, so no change is needed from the 50Hz GUI.

    For testing you can use this sample.

    Looks better on my box.

    Quote from johngalt

    I have the same PE Ii videos already and was able to test.

    My display's at 60hz, so at first I didn't have an issue due to the mode being set again. When I set my display to 50hz, I was able to replicate your issue. Try setting your display to a different refresh rate prior to playback and see how it goes. This will also cause issues for me with 60fps HDR videos.

    Also, I realized I was testing manually set depth with the dithering fix prior. This is also needed right now on libreelec, and is separate because it can be reverted when output is correctly set aml/hdmitx: enable 10-8 dithering by default · amillogical/linux-amlogic@95f9dae · GitHub . I amended and force pushed the LE fork kernel bump for people like koenkooi.

    When output is correctly set, I think this issue will go away so I won't try to work on a fix before working on that for now (when I get more time).

    Already doing a new build with that :)

    I've been messing with manually setting color depth and can confirm it really does work correctly. However, color depth is set correctly by this kernel originally when video info is set, but on mode change on playback, color depth gets reset.

    As far as I can see, there are two options:

    1) Expose current color depth in a cleaner way from kernel (with setting all other parameters that go along with color depth), then from Kodi we can check it and set it again on initial resolution switch to maintain it.

    2) Set previous on mode change after initial video info is set. A problem with this solution is that video color depth will persist to the GUI until the next video playback. I'm not sure if this as real world impact or not.

    kszaq, any feedback?

    Edit: or a third option: prior to resolution is set in kodi, read color depth of video (not sure how to do this part from kodi), and set depth prior to resolution switch the same way I've been manually setting it.

    Edited once, last by johngalt (June 1, 2017 at 7:56 PM).

    Has anyone noticed that the ethernet seems to be slightly faster? A movie where it would cache up to 220MiB in the first scene now does 320MiB. Instead of yoyo-ing between 90 and 60 mbit/s it does a stead 85 mbit/s. Measured on an SMB share.

    I'm sorry to make it seem immediate -- it wasn't. I'll stop tagging you until you're back.

    I've made a bit more progress in testing:

    I just force pushed the kernel and le fork repos to disable dithering if 10bit color depth is set (aml/hdmitx: use 10-8 dithering by default on 8bit · amillogical/linux-amlogic@aa97ed1 · GitHub). This should accomodate guys who don't want 10->8bit banding, and also those who want 10bit output.

    In other words, I can finally say "goodbye" to Android :D

    I don't see anything wrong with "standard" video while having 4:4:4 10bit output set unconditionally on capable hardware. From my understanding, this shouldn't make a difference at all with "standard" video so long as no sampling is used, so perhaps we could just check dc_cap on phy bringup and then set it if the display is capable?

    Testing 10 bit output:

    To test 10 bit output on capable hardware, run this ONCE prior to playback (resolution switch). It will stick as long as the device is on:

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

    For now this can be set in autostart.sh if you like the results.

    Why 4:4:4?

    4:2:0 10bit has an output issue, and with 4:2:2 10bit I got some flickering in parts of the video that was fixed when setting 4:4:4 10bit on a 4:2:0 10bit source.

    koenkooi and others, would you mind testing this and reporting your findings?

    P.S.There are situations with compression banding I prefer having the dithering enabled on low bitrate 10bit sources. Unfortunately this dithering noticeably reduces PQ in optimal situations with 10bit output. Perhaps a solution could be to expose it via sysfs and allow the 10bit output users to decide if they want to enable dithering unconditionally? This could potentially be decided later in a "tuning" thread.

    Edit2: I may have unintentionally found the bug that was causing some 4k users to get stuck with no video output. I bookmarked and will take a look later on. Could someone with the bug post a dmesg and check the result of: cat /sys/class/amhdmitx/amhdmitx0/vic

    Edit3: realized the last commit revision was unnecessary and the bug that made me add it: On first playback with 10bit output set, there will be dithering still. On all video playback after, there will not be. This is because of how LibreELEC switches resolution. This last revision does nothing new, so if you built with it you don't need to rebuild with the new force push. I was tired and couldn't read apparently. I was wrong here and it was needed.

    Edit4: here's a build with the dithering commit and audio at the previous state (working surround): LibreELEC-S905.arm-8.0-devel-20170601123601-r26033-g579da302e.img.gz | openload

    Edited 7 times, last by johngalt (June 2, 2017 at 5:40 AM).

    Quote from johngalt

    Why 4:4:4?

    4:2:0 10bit has an output issue, and with 4:2:2 10bit I got some flickering in parts of the video that was fixed when setting 4:4:4 10bit on a 4:2:0 10bit source.

    4:4:4 10-bit will work only for <50 frame rate content.

    Just tried the dev build on Minix NEO U1.

    Everything seems to be working.

    Image quality seems better on dev build. A bit brighter without washing out blacks. But maybe it's all in my head...

    One very annoying bug though... On 8.0.2a framerate switching is almost instantaneous and audio playback starts the same moment video does. On dev build however it takes 2-3 secs to switch framerate and another 5 seconds until audio starts playing (AVR starts to receive pass-though DD stream). This is a major issue.

    Once again, thank you kszaq for your time and effort!

    I tired again the new build. If in setting the gui is 1080p, then gui, sd, 720p, 1080p films are ok, 4k go to black screen (lost signal). If I set the gui to 4k, then after boot, screen is black (lost signal). Box is live, ssh, samba is work.

    8.0.1l-mm, 8.0.2a is perfect, sd, 720p, 1080p, 4k is good.

    Have somebody some idea?

    Quote from RedCat

    I tired again the new build. If in setting the gui is 1080p, then gui, sd, 720p, 1080p films are ok, 4k go to black screen (lost signal). If I set the gui to 4k, then after boot, screen is black (lost signal). Box is live, ssh, samba is work.

    8.0.1l-mm, 8.0.2a is perfect, sd, 720p, 1080p, 4k is good.

    Have somebody some idea?

    please post dmesg output on a paste site (like bpaste.net) and also post the result of: cat /sys/class/amhdmitx/amhdmitx0/vic

    Do this after the black screen has occurred.

    Good news edit:

    wesk05 PM'd me due to having a new account, and confirmed that 10 bit output is good :) . A note of his however: The command actually sets YCbCr 4:4:4 for <50Hz and 4:2:0 for >50Hz.

    From glancing at source, this is because of bandwidth constraints.

    I also couldn't read earlier while exhausted, and re-enabled dithering on 10 bit output (oops). I just force pushed those branches again.

    Edited once, last by johngalt (June 2, 2017 at 5:48 AM).

    Quote from johngalt

    please post dmesg output on a paste site (like bpaste.net) and also post the result of: cat /sys/class/amhdmitx/amhdmitx0/vic

    Do this after the black screen has occurred.

    I copy and in putty ssh paste ur command. If gui 1080p, then the "answer" is 16. If play 1080p video then 32. If play 4k video, and no signal (black sbreen), then 93.

    I did it well? Is the "answer" so short?

    Quote from RedCat

    I copy and in putty ssh paste ur command. If gui 1080p, then the "answer" is 16. If play 1080p video then 32. If play 4k video, and no signal (black sbreen), then 93.

    I did it well? Is the "answer" so short?

    My guess for the issue was incorrect unfortunately. Could you post the output from running "dmesg" after playing 4k as well as the kodi.log?

    I recommend running the following two commands and then posting the two links you get

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

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

    My guess for the issue was incorrect unfortunately. Could you post the output from running "dmesg" after playing 4k as well as the kodi.log?

    I recommend running the following two commands and then posting the two links you get

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

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

    Boot 1080p gui. I play 4k video 3-4 sec (black screen), then stop. After this I do this links:

    1.

    YjgZ

    2.
    AUVf