14:31 <blathijs> Hey folks. I'm working with an Orange PI wit a H3 chip, and looking to get hardware-accelerated video decoding working, ideally with vlc. I've looked around the web, and it seems that there has been quite some work on this a few years back, and AFAIU the libcedrus approach is deprecated, but v4l2-requests kernel support is present in unpatched kernels now. However, I'm struggling

14:31 <blathijs> with the userspace part. It seems that libva-v4l2-requests is pretty much unmaintained (though there are some PRs and forks to update it with later kernel API changes that I can compile, but do not seem to work). It also seems that ffmpeg can talk to v4l2 directly with patches, but I think those have not been merged upstream yet. Similarly for gstreamer, I think.

14:32 <blathijs> Anyone that has some experience and/or advice about a route to take here? I would prefer vlc (which currently means through libva, I think?), but can also consider switching to ffmpeg or gstreamer if needed.

14:35 <aggi> blathijs: consider opengl for acceleration

14:37 <blathijs> aggi: Do you mean for rendering/scaling, or also decoding?

14:39 <aggi> blathijs: good question. mplayer and/or vlc can enable "acceleration", with opengl as a choice, which almost always offloads video processing onto GPU, not sure about decoding.

14:41 <blathijs> TBH, I'm not looking for hardware decoding per se, if I can get smooth video with software decoding, that would also be fine :-)

14:42 <blathijs> Let me look into what "acceleration" means for VLC. I had the impression that it might be enabled by default here (armbian), since it does try to use vdpau and vaapi without additional options already

14:43 <aggi> btw. i still maintain directfb (abandoned since 2013), for CPU-only video-rendering with legacy mplayer on framebuffer; which is good enough for DVD playback with a cortex a53 ;)

14:45 <aggi> for exactly this reason: the library and extension chaos, and the fact CPU can do it instead; no special drivers needed except /dev/fb0

14:45 <aggi> no drmkms either, although kernel nowadays provides /dev/fb on top of drmkms

15:29 <jernej> aggi: mali can't do any video decoding

15:29 <jernej> blathijs: unfortunately, userspace support is pretty chaotic, as you already noticed

15:30 <jernej> latest gstreamer git should already work pretty well

15:30 <jernej> (no patching needed)

15:31 <jernej> it was intended to be released as 1.20 last October but there is obviously a hold up

15:31 <jernej> in short, next stable gstreamer will support video decoding pretty well

15:32 <jernej> ffmpeg patches work in combination with mpv, but only in gbm mode (no desktop environment running)

15:33 <jernej> ffmpeg patches were originally developed for Kodi, but that combination also works only in gbm mode

15:37 <blathijs> jernej: Ah, that sounds good. Compiling gstreamer from git unmodified is something I can certainly manage (even more so if it's only temporary). I'll have to convert my own software (that drives vlc based on button pressed and some custom logic) to gstreamer then maybe, but that's also doable. Any idea if that works with kernel 5.13, or needs something newer?

15:38 <jernej> note, there is no technical reason why ffmpeg patches & Cedrus can't be used on desktop environment, it's just that devs are mostly interested in gbm mode, at very least in Kodi case

15:38 <jernej> blathijs: which codec?

15:39 <jernej> anyway, use latest kernel if possible

15:40 <blathijs> H264 currently, though I can change if needed. AFAIU H264 was supported since 5.10, and HEVC is not yet public API in 5.13, but I'm not sure if gstreamer relies on it being available anyway. As for latest kernel, I'm currently using armbian images, which have 5.10 and 5.13 available.

15:41 <blathijs> Well, I don't have any interest in a desktop environment, I'm coming from a rpi setup where I run vlc on the framebuffer anyway (having to run X would actually be a downside of the libva-vlc2-requests based setup)

15:43 <jernej> 5.13 might be usable for H264, 5.10 is certainly not

15:44 <jernej> HEVC is pretty good with 5.16, but still not complete, so kernel and userspace patches are needed to add missing functionality

15:45 <jernej> I'm not sure if H264 become usable with 5.13 or 5.14

15:49 <jernej> seems like H264 and VP8 should work with 5.13 and MPEG2 with 5.14

15:49 <jernej> but if there are any issues, try latest stable kernel

15:50 <blathijs> Ok, I'll try 5.13, since that's what I have now, and see if I can get a newer kernel if it does not work. Any suggestion on wether to prefer cerbero or gst-build/meson for building gstreamer? Seems cerbero is more self-contained and allows easy cross-compiling, so I'm inclined to try that one first.

15:51 <jernej> I used gst-build/meson and worked just fine. I have never used cerbero...

15:52 <jernej> that was on arch rootfs, no idea about armbian

15:54 <blathijs> Yeah, reading on it seems gst-build is also fine, and it can run without installing which is also convenient. Not sure if it can cross-build, but I can also just build on the target directly for now.