Posts by koenkooi

Quote from johngalt

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

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?

Display More

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.

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.

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 taken kszaq's branch and cherrypicked in 3 commits:

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 Notna

Ah, that would be awesome! I wonder if it will have any positive effect (if any) on throughput speed (though I never had issues with that to begin with really) Atleast we will be able to make sure that the exploit is disabled

If you wants something to test, I have a build with it merged in: 8.0.1l-mm-samba4.6 and matching source.
Be warned:

• this is with the marshmellow kernel, not the regular 8.0.1l kernel.
• The LE setting app hasn't been updated yet, so make LE an SMB server won't work.

I'm doing this builds for my personal needs, so things I don't use might be broken, kszaqs builds are pretty much always a better choice

My build finished: s905x build with MM kernel and here's the matching source. Banding is gone, but other 4k related bugs are back. I use the 'check previous episode' addon and the popup it produces when I start a out of order episode is garbled.
I'm pretty happy with this build, but I only tested it for half an hour, maybe I'll change my mind later next week
[hr]

Quote from kszaq

Actually I have already built a version with MM kernel and all kernel updates that came along the way... but I have to test it before uploading.

Nice! I'm looking forward to that!

I'm going to try a 8.0.1l build with this patch:

diff --git a/projects/S905/options b/projects/S905/options
index c91332e..886236b 100644
--- a/projects/S905/options
+++ b/projects/S905/options
@@ -48,7 +48,7 @@
# Kernel to use. values can be:
# default: default mainline kernel
LINUX="custom"
- KERNEL_VERSION="0d8dd61"
+ KERNEL_VERSION="c850c92"
KERNEL_URL="https://github.com/kszaq/linux-amlogic-le/archive/$KERNEL_VERSION.tar.gz"
KERNEL_SOURCE_DIR="linux-amlogic-le-$KERNEL_VERSION*"
KERNEL_PATCH_DIRS="amlogic-3.14"

That brings the kernel back to 8.0.1a while keeping everything else the same. If it works I'll post it online, hopefully tomorrow.

Can you give this sample [176MiB] a try? There should be banding in the glow around the letters and in the first scene in the sky.

Quote from jd17

I will, but it is based on kszaq's build, right?
So I would compare the performance to 8.0.1k over NFS (25 skips in 26 minutes)?

Yes, it's based on kszaq's latest sources, which currently match his '8.0.1k' build. '8.0.1k' already has the increased chunksize for nfs, so if there is a difference it would be networking related. But that's on the input side, I don't think problems there lead to frameskips, but I'd love to be proven wrong

Quote from jd17

I just copied the movie to a USB3 flash drive to rule out LAN as a root cause.

Again, I started the movie and played it for 28 minutes (8.0.1k).
I had 7 skips in that time.

This is clearly less than over LAN, so my conclusion would be that NFS has am impact too.
[hr]

Can you apply this patch to afl1's build?
I had significantly less skips in that build, so your patch might just be the edge it needs?

I realized yesterday that I don't understand how LE patches work and after fixing that I found out the regular builds have 3 out of 4 chunksize patches already. So the big difference between that and the regular build is fq_codel for networking.

Can you give this build a try? Here's the matching source code. That adds the missing chunksize patch and includes PR 12110, PR 12074 and partially LE PR 713.

I backported the chunksize patches to 'krypton' here, and I have a matching build as well. That should improve throughput a bit, but I haven't tried to do proper comparisons yet. If you think networking is the bottleneck for you, can you give the above a try?

Quote from RedCat

[..]

2. In new builds: (I tested: 7.0.12k, devel, 8.0.1j, i, 8.0.1 devel)

[..]
- gui is 1080p, then gui is ok always. sd, 720p, 1080p films are ok, but 4k is flashing...

I see the same, 1080p gui/4k playback resolution doesn't work properly on s905, it does work on s905x.

Quote from mmpp

The last time I connected my boxes to a 4k monitor, kodi would run in 1080p for any content <=1080p and would only switch to 4k content >1080p, leaving any scaling from 1080p to the 4k display to the display. To my knowledge, it is not recommended to use kodi to scale SD, HD or FHD content to 4k.

Having kodi upscale mdeia to 4k is not my goal, setting the GUI to 4k is just a fast way to check for this issue. I've turned off all 'enhancements' the TV can do for upscaling, so the smudged look in 4k shouldn't be the TVs doing. A chromecast ultra hooked up the the same AVR gives very crisp 4k picture on the TV.

There are multiple post scattered among the release threads about these issues, but I haven't found any solution that works for me yet. So here's a seperate threads where people will hopefully post solutions to these issues.

The list of issues I've encountered myself so far:

• Picture quality in 4k is worse than 1080p, this is easy to spot when switching the UI to 4k and looking at the clock in the top right corner; 1080p has crisp numbers, 4k has smudged numbers. This happens on both s905 (AVR says it's doing 4k50/yuv420) and s905x (AVR says it's doing 4k50/yuv444). The suggested solution of switching to RGB mode using sysfs doesn't seem to work, same smudgy clock. In fullscreen video this smudging affects things like the BBC logo.
• Screenshots made in 4k mode are corrupted and show a different buffer e.g. end credits of the previous 1080p video.
• H265/HDR gives horrible banding on s905x. The TV does show the 'HDR' popup.
• VP9.2/HDR doesn't make the TV show the 'HDR' popup. Only tested with one sample by pointing youtube-dl to a hdr clip.

I'm also curious about workarounds, I wouldn't mind having a knob to disable HDR in kodi or a knob to disable switching to 4k. If people want to test I can provide a 1 minutes/100MiB clip of h265/hdr footage, contact me via PM for that.

At the time of writing, these bugs show up with 8.0.1h.

Since 'ssd' stands for 'solid state drive', a usb stick and SD card both are exactly that

Did you test in 64bit more, 32bit more or both?

I get this when trying to compile it myself:

Creating Amlogic ZIP update package
cp: cannot stat '/home/koen/LibreELEC.tv-8.0/projects/S905/install/update-binary': No such file or directory
Makefile:18: recipe for target 'amlpkg' failed

Quote from minimoe

No, as far as I know there aren't any.

One solution is to reboot your box once a day, to clean the memory.

Or ssh in and do 'systemctl restart kodi'.