Posts by johngalt

    I have a new test build I'm not updating OP with because it's very experimental and the last build is in a good state. You can use the linked device trees from OP.

    Changes:

    • A very experimental buffer change in an attempt to improve the frame skip situation.
    • A hdmitx change that may improve compatibility with some AVRs (to be tested by those with 4k output on their TVs but not AVRs).

    Download

    Edit: RedCat, who had nougat output issues with 4k through his Denon AVR, let me know that after a few minutes of testing this seems to have fixed the issue.

    Test in progress, after 20 minutes no frame skips, remote works fine. Great nougat build, great work.

    There still are frame skips, but it depends on the media type. I have a very experimental buffer change that has reduced frame skips from my testing. I still need to get a h264 4k test file as a benchmark (all my 4k media is h265).

    OK, thanks :)

    I'll install the latest version, hoping that I won't have problems like those saltanar had.

    I think those problems were from using the nand device tree.

    New build uploaded and links updated in OP (must update dtb).

    This is the same as the previous build, except IR remote has been fixed. It looks like kszaq and I both did this at around the same time effectively the same way with different commit histories. To save time, I'm still linking to his device trees for all except the non-nand gxl (kszaq hasn't uploaded yet).

    Before the next build, I'll bring our commit histories together again and add changes in this build on top.

    I just force pushed a new kernel and kernel config that fixes IR remote, no other changes. It will require a dtb update, and will be a bit until I get a chance to upload a build and all dtb.

    I did a build with KERNEL_VERSION="b05cd25" and the following cherry-picks from your tree:

    Code
    + 2b5bbfb661fb6ee7603ed584c76ba35a78dc8510 S905: update audio config and patches
    + e0d87740a4c7ef327ca3d9bb915546be0f571a24 S905: use custom test kernel
    + 1ac55183798d10b148c207527b856acd65d519bf projects/S905: set same mode during switch
    + 129ed2cd207b226e22bf398066fc96e72fc4ab0d kodi/patches/amlogic: @afl1 lateframes patch
    + 25cc0edccc5591646158874fa9f9c0bf1ec9e72b Revert "projects/S9*: fix BBC H.264 DVB-T"
    + c852260023320f9d2bb42c3a853b5455d63844c5 S905: bump kernel

    With GUI set to 1080p50 and having done echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr all the previously mentioned issues are gone. I get artefact free and skipless playback on 'passengers', 'lucy', 'PE II' and web-dl content.

    However, I did notice an issue with 4k h264 SDR playback ('deadpool'), a lot of frameskips there. I went back to your previous hybrid nougat/mm kernel and frameskips are worse there, about double.

    All in all this seems to be the best 4k/hdr configuration so far, good work!

    That's great news! I have a few things to try regarding the frameskips. I've yet to try 4k h264 playback (think all my 4k media is h265), so will use that to test.

    New build is working fine on 1080p 8bit AVR/TV. Everything seems to be working although i didn't have time to test everything.

    One issue that seems to be specific to my setup only since nobody mentioned this. Framerate switching with 8.0.2a is blazing fast. I even disabled pause after refresh rate change. Audio kicks in instantly. Builds preceding 8.0.2a and the latest build here behave differently. AVR starts playing audio (bitstream) after 5-8 seconds (video plays ok). Can I tweak something to bring this to some acceptable level?

    My setup:

    Minix NEO U1 - NAD M15HD - Sony KDL-52HX900

    Thank you once again.

    I'm doing passthrough and don't have this behavior. In 8.0.1l, kszaq "reverted some experimental audio patches." However from your description, this doesn't sound responsible for the change.

    • What are your GUI and video refresh rates?
    • Did you run 8.0.1l-mm at all?

    If the answer is "no" to the latter, this is probably a nougat->marshmallow change (though audio is basically the same).

    Just uploaded a new build that should fix the 10bit only output issue I introduced. I've yet to push to git but will shortly. LibreELEC-S905.arm-8.0-devel-20170606085306-r26036-g421c0fb43.img.gz | openload

    r26036 fixes all dvb-s2 720p playback issues that I observed with prior releases. Still impressed with the responsiveness on the S905X. I switched my regular use to the S905X box and will try to find media that exhibits problems with playback. While I understand that you are more focussed on the new 4k/10bit/hdr functionality, I can only test on my 8-bit, non-hdr, 1080p display :)

    One remaining visible issue (also present on older kernels/releseases): 1080p hevc video is shifted one pixel to the right, with the rightmost line of pixels showing on the left side.

    That's probably from reverting the dec_control fix.

    Edit: kszaq, I just force pushed a kernel and kernel config update that fixes IR remote (reverted new driver changes).

    Edit2: it looks like kszaq did this at around the same time. Here's a new test build with working IR if you update dtb as well: LibreELEC-S905.arm-8.0-devel-20170607071212-r26026-g31bc96b61.img.gz | openload

    trees that haven't yet been uploaded: gxl_p212_1g.dtb gxl_p212_2g.dtb

    I checked the latest full nougat build. 1080p is now 10-bit only. echo 8-bit command doesn't change anything. 4K is now stuck in 8-bit. echo 10bit command doesn't do anything.

    Sink reads the color depth from the CD fields in the general control subpacket of HDMI signal. The CD fields are indeed being set to 10-bit for 1080p and 8-bit for 4K. What is weird is, I tested this on a simulated display with Deep Color support purposely removed and I could still get a picture and the CD field was still set to 10-bit. This doesn't comply with HDMI protocol which stipulates that the source shouldn't send Deep Color signal if the sink doesn't support it. Since I did get a picture I wonder whether the signal is indeed only 8-bit and that the CD fields are being incorrectly set.

    I think you're correct that the cd fields are being incorrectly set. When I tested 10bit 4k output, I disabled 10-8 dithering but didn't get any banding in a banding test video I've been using.

    I may have mentioned it earlier, but I've read deep color support (using dc_cap) on devices that don't support deep color as well.

    I think setting CD as 10bit if "10" is in attr so early is a problem at one of the later CD checks prior to setting it, but haven't looked in depth. I started setting it early to fix a dithering CD check with libreelec resolution switching. The last builds that were reported to exhibit proper behavior (save for 10-8 dithering at 10bit output) were just before that workaround.

    For the next build I'll revert it to be certain this fixes the issue.

    For a better fix, I think we can switch to using cur_video_param for cd on the dithering check since we always resolution switch and keep the early setting from attr commit reverted. This should make the dithering check (cd switch case) exhibit the proper behavior on the mode change. We'll find out shortly.

    I just did.
    It's still 10bit only...

    Triggering 8bit manually does not work either (echo '444,8bit' > /sys/class/amhdmitx/amhdmitx0/attr)...

    Just on a side note - the frame skips are still there too. ;)

    I tested the full nougat build on a very old (unused) TV, and it can do 8bit output without any changes after the second boot. /sys/class/amhdmitx/amhdmitx0/attr isn't changing the actual output, rather what the video is output as. Without setting "444,10bit", even if it's 10bit output, the video is 8bit.

    BTW, I was getting 4-6 frame skips/min on marshmallow with 10bit output and SPMC 16.7.0. I'm also still getting the frame skips here, but closer to 1-2/min. On the 8bit display I got frame skips, but only 2 after ~11min of playback (which from glancing at afl1's thread looks similar to what's current on those builds).

    Thank you kszaq. I found that v4 of multi-instance decoding had other changes (for when disabled) that were causing those playback bugs. Even when I got full nougat video_dev working and got rid of some of peak3d's redundant changes, I still wasn't able to get smooth playback on affected files with multi-instance decoding disabled.

    As such, I reverted it and depending commits, squashed them, and did a new build (fixes h264 playback issues mentioned earlier that are exacerbated on 10bit output).

    I kept the 10bit testing thread open for discussion on it, but can close it if requested now that it's moved back to nougat-wip builds. I was also never able to reach the same PQ level for 10bit output on the frankenkernel + backports as this one, and had a dtsi-related output issue (needed other updates).

    Build (won't fix output for those with output issues, and still no IR remote): LibreELEC-S905.arm-8.0-devel-20170605112202-r26036-g421c0fb43.img.gz | openload

    Switched back to the full nougat kernel due to multi-instance decoding related reverts fixing playback issues on it. I was also never able to get the same level of 10 bit PQ on this kernel as the full nougat kernel. If desired, this thread could be closed and moved back to kszaq's thread -- or it could stay open as discussion primarily for 10bit output.

    This build needs the nougat-wip device tree again. Since I can't specifically test if this fixed the 10bit only output issue (since the kernel lied), it would be much appreciated if someone with video through an AVR could test.

    This also breaks the IR remote again, so CEC or another remote is recommended.

    The links were updated in OP.

    jd17 and astep

    At this point there are very few changes between this kernel and the full nougat kernel -- none that could cause this in hdmi modules at least, but dtb is another story. Because 8bit-only users were using the full nougat kernel, this doesn't seem to be shared. I don't have an AVR (with video going through) to test at the moment. When I reboot, according to kernel the video depth is 10 bit, but output is 8 (cd = ), and as such dithering and rounding are reenabled. However, this info doesn't seem trustworthy based on your reports.

    Needless to say, we're taking some changes here back to the full nougat kernel very shortly, and switching focus back to it.

    I did more nougat backports, and was able to bring in the h264 stutter (referred to as "slow motion") bug (topic-nougat-squash branch). This will be good to help narrow down the problem on the full nougat kernel at a later point :)

    I'm not yet sure, but I didn't intentionally hardcode 10bit output if so. You can run echo '444,8bit' > /sys/class/amhdmitx/amhdmitx0/attr from GUI to get back to stock behavior.

    Quote from jd17

    What 4k flicker are you referring to?

    On some 4k output on the marshmallow kernel there was a slight flicker.