Jump to content


  • Posts

  • Joined

  • Last visited


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The patch was very recently added in 5.11.6. I'm not sure how you install the kernel after the fact—I simply built a new bootable image with armbian-build (choosing sunxi-dev as the kernel with ./compile.sh EXPERT="yes") and flashed that to µSD.
  2. It must be 5.11, so you need to build from source. Something I forgot to mention (going to edit the post now): the kernel must be built with this patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7072db89572135f28cad65f15877bf7e67cf2ff8 It's been accepted for upstreaming and will be included in 5.11 later, but up until 5.11.3 at least, you need to include it as a userpatch.
  3. Thanks to the very patient support from jernej and ndufresne on the linux-sunxi IRC channel, I could confirm that GStreamer 1.19+ works out of the box on the 5.11 kernel (sunxi-dev), tested with Hirsute and Bullseye, at least on the H3/Orange Pi PC. (I haven't been able to build or run a 5.11 image on a H6 device, so I couldn't test it there yet.) Kernel: Build 5.11.y with this patch, must be included as a userpatch. 5.11.6 includes it from the getgo, but below that you need to add it yourself: <jernej> PPA: kernel 5.11.6 is released with Cedrus patch Requirements: sudo apt update sudo apt install meson ninja-build pkg-config libmount-dev libglib2.0-dev libgudev-1.0-dev libxml2-dev libasound2-dev Building & installing GStreamer: git clone https://gitlab.freedesktop.org/gstreamer/gst-build.git cd gst-build meson -Dgst-plugins-bad:v4l2codecs=enabled -Dgst-plugins-base:playback=enabled -Dgst-plugins-base:alsa=enabled build ninja -C build cd build sudo meson install sudo /sbin/ldconfig -v You can play videos from the command line to the framebuffer. At least on the OPiPC there is a problem where it doesn't automatically play on the correct DRM layer and the video is hidden. To fix this, it needs to be ran once per boot with “plane-properties=s,zpos=3”: gst-play-1.0 --use-playbin3 --videosink="kmssink plane-properties=s,zpos=3" video.file Afterwards it should be fine with just gst-play-1.0 --use-playbin3 input.video (until the next reboot). h.264 (except for 10-bit, which the hardware cannot handle) decodes smoothly with CPU load across all cores around 2%–5%. Thanks; the OP was edited accordingly.
  4. It seems to be system-specific. Pine H64 B + Hirsute: doesn't build. Pine H64 B + Bullseye: doesn't build. Pine H64 B + Focal: builds, doesn't install OPiPC + Hirsute: builds. OPiPC+ + Bullseye: builds. (All sunxi-dev) EDIT: Rock64 + Bullseye: doesn't build. (dev as well)
  5. I'm having the same problem, trying to build sunxi-dev/5.11 images or Pine H64 B: Displaying message: ERROR in function install_deb_chroot image-helpers.sh:148 err Displaying message: Installation of /root/armbian-zsh_21.05.0-trunk_all.deb failed pineh64-b hirsute no sunxi64 err Displaying message: Process terminated info zsh (5.8-6) wird eingerichtet ... tmux (3.1c-1) wird eingerichtet ... armbian-zsh (21.05.0-trunk) wird eingerichtet ... Trigger für man-db (2.9.4-2) werden verarbeitet ... Trigger für libc-bin (2.33-0ubuntu2) werden verarbeitet ... qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) dpkg: Fehler beim Bearbeiten des Paketes libc-bin (--configure): »installiertes libc-bin-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 139 zurück Fehler traten auf beim Bearbeiten von: libc-bin E: Sub-process /usr/bin/dpkg returned an error code (1) Built everything from source, tried both desktop and CLI images (the above logs are from that attempt), both Hirsute. EDIT: Same with Bullseye.
  6. Thanks for your reply. That's the idea. I've edited the post, corrected erroneous statements and added your information. (And added some of the information on GStreamer from IRC.)
  7. I've taken peeks at threads related to hardware decoding (of H.264 and HEVC, mainly) on Allwinner and Rockchip platforms on and off, sometimes dabbled in trying and failing to implement solutions recommended there. Being a complete amateur, I find the topic very opaque and confusing, with various different components that need to interface with each other, be patched in sync, and sometimes change drastically between kernel versions, etc. Today I sat down and read up on these subjects, scouring wikis, documentation, this forum, and assorted other sources to try and understand how this works. In this post I will attempt to compile what I've learned on the different software components involved, their relationships, their current status, and solutions to the problem. I hope people more knowledgeable will correct me when I get something wrong or cite outdated information. Stuff which I am highly uncertain of I will print in italics. (This post is going to focus on mainline implementations of Cedrus/Allwinner, I haven't looked into Hantro/Rkvdec/Rockchip specifics yet. I will speak only of H.264 and H.265/HEVC; I don't understand the high/low stuff and didn't pay attention to other codecs.) Components: Basics: Video codecs like H.264, H.265/HEVC, MPEG-2, etc. are standardised methods which serve to more efficiently encode and decode videos, reducing their filesize. Software en-/decoding is very CPU-intensive. Modern GPUS and ARM SoCs therefore contain specialised hardware (VPUs) to delegate these tasks to. Working hardware decoding is particularly important for underpowered ARM CPUs. Drivers: Topmost in the stack are the VPU drivers. These are Sunxi-Cedrus/Cedrus V4L2 M2M and Cedar [Is this the legacy one?] on Allwinner; Hantro and Rkvdec on Rockchip. These are all still in development, but Cedrus already fully supports H.264, and partially supports HEVC, and is already usable in the mainline kernel. APIs: In order for anything (userspace APIs, libraries) to make use of the VPU drivers, you need backends/APIs. For Cedrus, there is the unmaintained libva-v4l2-request backend which implements VA-API, the legacy VDPAU implementation libvdpau-sunxi, and as of kernel version 5.11, H.264 has been merged into the uAPI headers. Different applications may make recourse to one or another of these APIs. Libraries: FFmpeg and GStreamer. provide libraries and APIs of their own to other applications but can (importantly!) also output directly to the framebuffer. FFmpeg must be patched to access either libva-v4l2-request or the Cedrus driver headers. GStreamer directly accesses kernel headers since 1.18 (works on 5.9, not on 5.10; 1.20 will support 5.11.) Media players: mpv and depends on FFmpeg for hardware acceleration (and must be patched together with it). VLC can be set to access libva-v4l2-request directly. Kodi 19.0+ supports hardware acceleration out of the box without any out-of-tree patches. Display server: An additional complication is drawing the output of any of the above on screen. Most successful implementations I've seen bypass X11 and either output directly to the framebuffer or force a plane/display layer on top of any X windows. Wayland apparently makes this easier by allowing applications to use their own DRM planes, but this hasn't been explored much yet. Kodi 19.0 works with all three windowing systems (X, Wayland, and gbm). Codec status: Taken from the LibreElec thread (which reflects LibreElec's status and is ahead of what works elsewhere, but outlines hardware limitations): Approaches: Many people have managed to make it work on their machines using different approaches. Note that some of these solutions are one or two years old, and kernel developments since may have changed the situation. Ordered from newer to older: LibreElec – kernel + ffmpeg + Kodi: LibreElec is a Just-Enough-OS with the sole purpose of running Kodi, a media player. It's at the bleeding edge and usually implements codecs and features well before mainline or other distros. It achieves this by heavily patching everything up and down the stack, from the Linux kernel over FFmpeg to Kodi itself. These patches could all be applied to an Armbian build, but there are a lot of them, they're poorly documented, and you'd need to dig into their github to understand what they all do. LibreElec runs Kodi directly without a desktop. kodi-gbm is a package that can be installed on Armbian and functions similarly. Key contributors to the project are @jernej and @Kwiboo, who sometimes post about their work here (and have been very helpful with questions, thank you). @balbes150 includes some of LibreElec's patches in his Armbian-TV builds, but I don't know which. Kodi 19.0: LibreElec patches + mpv: @megous – Kernel 5.11 + GStreamer: This implementation, done here on a PinePhone (A64), patches the 5.9 kernel and uses a recent version of GStreamer (1.18 and up), whose output is rendered directly to a DRM plane via kmssink. (No X or Wayland.) GStreamer 1.18 works with the 5.9 kernel. It does not work with 5.10, because of numerous changes to the kernel headers in this version. In 5.11 the H.264 headers were moved into the uAPI; the master branch of GStreamer reflects this, but there haven't been any releases with these patches yet. It'll probably be in repositories with GStreamer 1.20; until then you can build it from source. @Sash0k – patched libva-v4l2-request + VLC: This updates bootlin's libva-v4l2-request and follows the Sunxi wiki's instructions for enabling VLC to make use of it. It works on the desktop. This only works for H.264 and breaks HEVC. When I tried to replicate this approach on a recent Armbian build, I discovered that the h264.c files in the kernel (that libva-v4l2-request draws on) have changed considerably between 5.8 and 5.10, and I lack the understanding to reconcile libva-v4l2-request with them. @ubobrov – old kernel + libcedrus + libvdpau-sunxi + ffmpeg + mpv: This approach, which supports encoding decoding of H.264 uses the libvdpau-sunxi API and ports the legacy driver to mainline as a loadable kernel module and if I understand it correctly, ubobrov ported a legacy feature to mainline. In the post quoted below the kernel is 4.20, but the same method has been successfully applied to 5.7.8 by another user. It requires that the board's device tree be patched, as documented in ubobrov's github repository. The summary seems to be that none of the current implementations on Allwinner boards really play nice with X or desktop sessions, and it's best to output directly to the framebuffer. Kwiboo has forked FFmpeg and mpv to make good use of new and unstable kernel features/hardware acceleration which will take a while to make their way upstream. The recent 5.11 move of stateless H.264 out of staging and into the uAPI should facilitate further developments. I intend to try some of these things in the nearer future. Thanks to everyone who works on mainlining all of this VPU stuff, and to users here who contribute solutions and readily & patiently answer questions (Jernej especially). I hope I didn't post any falsehoods out of ignorance, and welcome any corrections. Other related threads here: https://forum.armbian.com/topic/11551-4kp30-video-on-orange-pi-lite-and-mainline-hardware-acceleration/ https://forum.armbian.com/topic/16804-orange-pi-pc-h3-armbian-focal-5104-sunxi-av-tv-out-cvbs-enable/page/2/ https://forum.armbian.com/topic/11184-hardware-graphicvideo-acceleration-in-h3-mainline/ https://forum.armbian.com/topic/13622-mainline-vpu/
  8. Is there an overview of additional features included in these builds, or are they equivalent to the latest Armbian releases for H6 SBCs, just for TV boxes?
  9. I asked about this in the #linux-sunxi channel some time last year. I believe it was @Icenowy who was actually sitting on a mainline patch to enable TV out, but there was presently no way to detect whether there is a cable inserted in the AV socket, or whether it's hooked up to a TV, and there is too little demand for the feature for anyone to bother.
  10. P.P.A.

    Mainline VPU

    After my last post here, I successfully applied @xmixahlx's linux-5.8-rc4-hwaccel_20200709.diff to balbes150's Armbian Build fork (as a userpatch). For various reasons I was unable to test it properly though. 5.8 having been officially released, I would like to start over and re-trace your steps and patch the kernel the same way you did with 5.7 and 5.8-rc, mainly in order to enable 10-bit HEVC decoding. I read the entirety of this thread and the two at the Pine64; please tell me if I got all of this right: The first patches you applied were the ones from LibreELEC's kernel at https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/linux/default – currently these would be: Next, you created further patches by diffing vanilla kernel(+patches to get it up to 5.8-rc4)+libreelec patches against @Kwiboo's WIP linux-rockchip fork at https://github.com/Kwiboo/linux-rockchip in order to get his latest improvements that haven't made it into LibreElec yet (like H.265 decoding). The linuxtv-rkvdec-work-in-progress master is already on 5.9-rc1 though – would this create conflicts (or force me to patch the kernel to be diffed against up to 5.9-rc1 as well, which I would rather avoid), and should I use these individual 5.8 branches instead? What should be done about the kernel config? Should I just look at your pbp patch's config and enable the relevant bits (like CONFIG_VIDEO_ROCKCHIP_VDEC) accordingly in my own? (If it isn't obvious, I'm very new to all of this.) If the kernel compiles with the LibreELEC patches and the Kwiboo diffs, the next step is compiling FFmpeg 4.3 from https://github.com/Kwiboo/FFmpeg/tree/v4l2-request-hwaccel-4.3.1-rkvdec and finally mpv with the appropriate patch, or Kodi if that doesn't work. (Hopefully I'm able to do all this within armbian-build using userpatches, seeing how rockchip64-dev seems to be on 5.8.y now.)
  11. I see; thanks for your detailed response. VAAPI is of interest to me since IIRC it's what jellyfin interfaces with to provide transcoding to clients, but it's more of an abstract interest since I just watch everything on my desktop anyway. In this context I'm pleased to hear that getting mpv to work may not be so difficult after all. When I have time, I'm going to try and look into into how mpv interfaces with ffmpeg.
  12. Am I understanding it correctly that it works as follows? LibreElec patches the kernel to make use of the SoC's VPU. (Some of these patches make their way upstream eventually, but that's a slow process.) It also forks ffmpeg, which is patched to recognise these new kernel features & to make use of them. Kodi then refers to ffmpeg to access them. What would be necessary for players other than Kodi—mpv or VLC for example—to benefit from this as well? And what is the role of libva, VAAPI, and these other things in this process?
  13. If you only want to use Kodi, take a look at LibreElec: https://forum.libreelec.tv/thread/17565-nightly-images-for-a20-a64-h3-h5-and-h6-boards/ It's got more hardware decoding features than mainline or Armbian thanks to various custom patches for both the kernel and Kodi, but it doesn't do anything other than run Kodi.
  14. Xunlong is putting out another batch of H5 devices at the end of the month. Is there any particular reason to go with a H5 board these days? As I understand it, the advantage it has over the H3 are the gigabit ethernet and the 64-bit architecture, while being a bit more mature on mainline and Armbian than the H6 or similar Rockchips?
  15. I tried out my Rock Pi 4B with a custom-built 5.8.0-rc6 kernel based on @balbes150 armbian-build fork, and despite my monitor supporting a resolution of 1920x1200, the maximum I could select was 1920x1080. http://ix.io/2siM Once I've tried the official Armbian images and balbes150's own build, I'm going to edit this post/reply again with whether any of them fix this problem.
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines