Posts by offbeat

    I don't even think I need it as the passive cooling with the Argon One is so good...

    Generally yes, you don't really need fan with this case, unless you load your RPi4 CPU to 100% for hours, which is unlikely in case of typical LibreElec box.

    My rather heavily loaded (load average: 1.71, 1.22, 1.04) RPi4 running Frigate NVR in docker goes higher than 55C, and I've set fan curve to start at 65C. Such little fan is annoying too, so you'd better keep it off unless really needed.

    But there is another reason to install and configure argoned: it correctly sets up Argon internal microcontroller/PMIC, which allows you to completely power off RPi4 resulting like ~0W power usage, and the turn it on using either infrared remote or power button.

    Failed at step EXEC spawning /storage/sbin/argononed: Exec format error

    You've probably built it on x64 workstation.

    Their build system doesn't support cross-compiling, you have to build it on RPi4 running either PiOS or Ubuntu, 32bit because LibreElec still only supports 32bit userspace programs.

    [Question] Is it prossible to cross-compile? How? (#21) · Issues · DarkElvenAngel / Argon One Daemon · GitLab
    Like the title says, I want to be able to cross-compile for one of the supported OSes without building inside the target OS itself. For example...
    gitlab.com

    Also, Beelink GS1 gigabit ethernet is still unstable and timeouts under load. I'm using heartbeat shell script to reload driver on connection loss, but it messes up CIFS mounts and Kodi.

    Any way to report it upstream, without going through mailing lists?

    Latest master is broken on Beelink GS1: kernel is booting but no MMC devices are detected, resulting "Could not mount" error and drop to debug shell.

    Rather painful bisecting session of download/flash/boot nightly images points to regression between LibreELEC-H6.arm-11.0-nightly-20221008-0af4c55-beelink-gs1.img.gz and LibreELEC-H6.arm-11.0-nightly-20221008-1d2cd1d-beelink-gs1.img.gz

    My wild guess is this commit could cause it "3ed35a87b6 (jernejsk/aw_atf) Allwinner: atf: update power patch"

    Is there any to customize OpenSSH server configuration in LibreELEC?

    I mean either override /etc/ssh/sshd_config as a whole, or by including additional snippets.

    Need to customize ssh port, as well as tighten encryption algorithms.

    Default configuration is rather lax, ssh-audit gives following recomendations:

    3. Cedrus needs to be more resilient to stream errors (mostly missing references for B and P frames)

    Oh yes, from my personal experience, SAT stream quality goes from 100% bit-perfect to unwatchable mess of pixels, even with all the DVB error correction algorithms. Thunderstorms, snowstorms... can't beat physics.

    H264 and H265 decoders as well as TS container parser just has to be resilient as hell, able to consume pretty much garbage input without crashing. Drop frames and move on.

    Actually, if ffmpeg decoding with -f null - works, I think issue might be in display driver or misreporting actual buffer information, like size or stride.

    ffmpeg -f null - doesn't work for these HEVC samples, not display output involved.

    But tested with EGL rendering, just in case, iommu still faults.

    should improve VP9 decoding speed

    ffmpeg VP9 decoding test shows some improvement, but not much, can't reach 30fps for 4K HDR sample.

    Code
    ffmpeg -hide_banner -hwaccel drm -hwaccel_output_format drm_prime -i COSTA.RICA.vp9.2160p60.HDR.mkv  -f null -
    
    frame= 1644 fps= 28 q=-0.0 Lsize=N/A time=00:00:27.46 bitrate=N/A speed=0.47x 

    Maybe bottleneck is elsewhere, or VP9 decoder clocks aren't set to 576MHz.
    I see 552MHz for both decoders in clk_summary, if it can be trusted.

    Code
    /sys/kernel/debug/clk/clk_summary
        pll-ve                            0        1        0   552000000          0     0  50000         N
           vp9                            0        1        0   552000000          0     0  50000         N
           ve                             0        0        0   552000000          0     0  50000         N


    hopefully lower issues with Cedrus based decoding

    IOMMU still crashes on my HEVC .ts samples

    Code
    ffmpeg -hide_banner -hwaccel drm -hwaccel_output_format drm_prime -i NASA.x265.2160p60.ts -f null -
    
    [   60.534272] sun50i-iommu 30f0000.iommu: Page fault for 0x000000000001c000 (master 1, dir rd)
    [   60.534309] IOMMU: Level 1 page error
    [   62.557439] cedrus 1c0e000.video-codec: frame processing timed out!

    I would also like to know if HDR works for you.

    Yes, HDR output works, my monitor does switch modes!
    Colors look very similar for both SDR and HDR versions of Costa.Rica VP9 sample.
    But obviosly 8-bit output, heavy banding in gradients while playing HDR.

    Here are photos of monitor OSD with some technical data.

    HDR:

    SDR:

    I updated my iommu branch, if you're interested

    Thank you, no more drm_gem errors!

    Retested my NASA and F1 .ts HEVC samples. Interesting thing, all three samples fault IOMMU when fed through ffmpeg command line at max speed, but only F1 faults when played on normal speed through Kodi.


    Will test HDR metadata tomorrow, when I get to monitor.

    I suppose you're testing this on non-HDR capable screen? During writing 10-bit HDMI output support, I noticed that HW does proper downscale from 10-bit to 8-bit, but that is probably just averaging. There is HW for applying HDR tonemapping, but I have no idea how to use it nor how to integrate it in DRM framework.

    Yes, my H6 box is connected to 12-year old 1080p SDR TV, used to be rather high-end. According to EDID it supports 10bit and 12bit colors, but its definitely way too ancient for HDR.

    Can test on modern HDR capable monitor if needed, but guess not much point until H6 HDMI driver gains ability to send HDR metadata to display.

    can try this patch to make VP9 10-bit work (downscaled to 8-bit)

    Tested this patch on both master(cma=1024M) and iommu branch.

    Looking good, not a single error in logs!
    Works for every 8bit and 10bit VP9 sample I've got, all from Youtube anyway.
    10bit HDR plays with washed out colors, but thats probably expected, H6 HDMI hardware tonemapping most likely isn't implemented yet.

    Also tested bare decoding speed with ffmpeg commandline:

    Code
    ffmpeg -hide_banner -hwaccel drm -hwaccel_output_format drm_prime -i sample.mkv  -f null -

    Typical 4K 8bit VP9 decodes at ~32 FPS, and 4K 10bit HDR is slower at ~24FPS. Probably ffmpeg decode path isn't 100% optimized yet.
    Allwinner datasheet only promises "VP9 Profile 0/2 4K@30fps", so 4K@60 most likely isn't achievable on H6.

    I'd say this VP9 fix patch should go to master, nice job!