hege

Pardon me for asking silly questions, but why doesn't armbian just maintain one master clone of the upstream git repository with branches set up to track all upstream branches for the boards, then just fetch from the master branch locally? I am trying to create a patch based on the Collabora WIP patches for V4L2 HEVC work, and dealing with the build script re-fetching the mainline kernel from the master repository is just too much. So I have cloned the tree myself into my home dir, and changed lib/configuration.sh MAINLINE_KERNEL_SOURCE to point at the $HOME/linux-source/.git directory. Armbian then takes over and does the full clone locally, and I can tweak/rebase my local copy as needed, without needing to change OFFLINE_WORK and dealing with refetching different current/edge versions.

I had similar problem with my Rockpi4-B. Sound extremely distorted all of a sudden. Alsamixer not able to change settings on hdmi audio. I installed pulseaudio and changed volume on the pulseaudio backend to 30% and that fixed the sound. Not sure how this could happen since the hdmi audio is supposed to use PCM to output sound and not analog signals that could be blown out?!

I don't work on RK drivers, so I'm not sure if this is some kernel/driver quirk or userspace issue Thanks -- turns out the current limit is 16 as defined by https://github.com/jernejsk/FFmpeg/blob/v4l2-request-hwaccel-4.4/libavcodec/v4l2_request_hevc.c#L24. I increased that in my ffmpeg build to 32 and that made HEVC work with moonlight-qt! At I was able to stream for a few minutes; I didn't see much difference between HEVC and H.264 in moonlight streaming (and had no luck forcing HDR), so for now I went back to the better supported H.264 codec. I'll definitely give this another try once the kernel APIs + userspace code stabilizes.

Sounds like a mess 🙂 I was able to boot a patched armbian kernel that has the v4l2 kernel patches, and built a patched ffmpeg. Moonlight-qt now starts and attempts to initialize HEVC, and gets pretty far. Right now it's failing with "v4l2_request_hevc_set_controls: unsupported max slices, 32". Full logs are at https://pastebin.com/3j96JcMs. Is this something that moonlight is doing wrong? FWIW I built ffmpeg with: ./configure --enable-v4l2-request --enable-libdrm --enable-libv4l2 --enable-libudev I guess I should try some file decoding first to see if it even works. It's quite possible that I messed up the kernel patch because I had to manually pick which files/hunks to apply from the libreelec patchset since I didn't want to break any armbian patches.

Thanks jernej, I was just playing with your patches for pre-5.18 kernels and it all worked very well up to commit https://github.com/jernejsk/FFmpeg/commit/1cd61e5730acc12c39c964bcf13c73a54203a390. I saw the patches for 5.18, but I was not able to make my armbian rock4 work with 5.18 kernel due to missing realtek drivers. I was able to make the kernel compile and and boot but the ffmpeg code did not see the private kernel headers after installing the headers package. And then I noticed that my docker bridge networking is somehow broken, so I gave up and wait for 5.18 to land in armbian for rockchip64. Granted, this was with 5.18-rc7 and I had been deleting a bunch of patches to make it all compile so it's very likely I messed it up as I'm new to the armbian build process... Do you have an idea when upstream ffmpeg will incorporate all these patches?

I believe Kernel 5.18 (just landed today) will have VP9 and Hevc support on rk3399 via v4l2request api. There are ffmpeg patches that make use of it. I tried making it work, but couldn't manage to build the kernel headers properly for 5.18. Once patches catch up to 5.18 and upstream ffmpeg get through the patchset, it's possible that finally everything will just work. That being said, h264 already works pretty well even with armbian mainline 5.15 kernel and patched ffmpeg. It all works very well with moonlight-qt, streaming 4k at 80-100mpbs bandwidth with reasonable cpu usage on a rockpi-4b.

I've been hit with zram/journald problems too. In the end I ended up disabling zram altogether. Journald by default stores log messages in ram (in /var/run/systemd/journal which is using the tmpfs at /run), and only flushes them to /var/log/journal every 5 minutes by default (+flushing every emergency log events as they occur). I disabled journald logging to syslog, which means my /var/log is now on eMMC, but still not written at too high of a rate to cause wear. I believe with the correct journald settings, zram will become completely unnecessary.