robertoj

I am using allwinner h3, and you are using A64… I don’t know whether cedrus.ko is right for you. Look in this thread here, whether any kernel module has created a /dev/video device that can input h264, like cedrus can. Run libreeelec again and take note of the kernel version, the kernel modules, and the “.config”, and try to rebuild armbian with those options. https://github.com/robertojguerra/orangepi-zero-full-setup/blob/main/README2.md then you would be at the same spot where I am, with the kernel being unable to display the video due to some gbm missing functionality in my kernel.

Thank you… I will try with more LibreElec patches this week. but LibreElec’s windowing system is GBM, not X11… so that’s a thing that I need to follow… somehow.

what I meant is: I want to buy an orangepi H3 with HDMI port, so that I see if there's any difference in hardware decoding. But the ultimate goal is that I get hardware decoding in analog video... it is possible, because Kodi does it. I has been a very long time since I used RedHat... I used yum ... I will see whether "dnf builddeps" has an equivalent in Debian I found in this discussion that: if ffmpeg hardware decoding works with "-f null -", but fails to present the video (my situation), then the problem might be the display driver: https://forum.libreelec.tv/thread/25283-allwinner-h6-hevc/?postID=167090#post167090 Another important variable is the way mpv was configured before compile. Anyone who got it working, check the first few lines of running MPV. For example (something I found in the mpv github):

What would be the closest orange pi to orange pi zero? Ideally it would be H3, with both HDMI and analog video.

Yes. I have applied that drmprime patch also. I think it is a drm or gbm issue now.

When kodi starts playing an h264 file with hardware decoding, the debug log looks like this (I removed lines with mjpeg and [mov because they were 99% of the lines, making noise.) Kodi's ffmpeg is using function deint_v4l2m2m_destroy_context, which is part of another patch, which I didn't have: vf_deinterlace_v4l2m2m I am compiling it now Result: mpv takes the VAAPI route, then software decoding

The previous LibreElec+Kodi, and the latest LibreElec+Kodi, with the latest linux kernel version, with the LibreElec patches (for Linux, ffmpeg, etc) run on the OrangePiZero, and provides hardware H264, in the analog video output.

Thank you. I havent tried anything today, but tomorrow I will try a lower ffmpeg version. Maybe ffmpeg 6.0 is too new for mpv (although kodi is able to use it) update: I tried it with ffmpeg 5.1.3… and i am still getting the same error in mpv: hwdec not supported drm, and falling into software decoding. is there any need to “—enable-v4l2”?… (I can’t because my Debian does not have libv4l2-dev… only libv4l-dev) i will document this better today. I will poke around kodi once again (same orangepi zero model, with the same CVBS pal/ntsc output, does hardware h264 everyday)… I would need to know what the internal ffmpeg and gbm are doing together)

Thank you... This is what I get: (running from SSH worked the same way as running from the console, without Xserver or desktop) And when I run it from within the lxde desktop manager: In both cases, the CPU use is 200% i am using Debian bookworm’s default MPV 0.35.1… what ubuntu or debian did you build with armbian-build? When you built ffmpeg with the v4l2_request patch, did you add only "--enable-v4l2-request --enable-libdrm --enable-libudev".. can you share your ffmpeg banner (the text identifying itself and the ./configure options)? Did you install ffmpeg with these instructions? https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu The special part is that ffmpeg stays in ~/bin, and many other codecs are enabled.

Jernej, I am trying the ffmpeg with just the v4l2_request patch... while the other additional patch is compiling Running ffmpeg -loglevel debug -hwaccel drm -hwaccel_output_format drm_prime -i video.mkv -f null - It looks like some decoding is happening, I see that v4l2_request is being used: I will try it with mpv mpv --hwdec=drm --hwdec-codecs=all youtube720p.mp4 decodes with CPU mpv --hwdec=gpu --hwdec-codecs=all --drm-drmprime-videoplane=primary youtube720p.mp4 decodes with CPU ffmpeg -loglevel debug -hwaccel drm -hwaccel_output_format drm_prime -i youtube720p.mp4 -vcodec copy -acodec copy -f matroska - | ffplay -i - decodes with CPU ffmpeg -loglevel debug -hwaccel drm -hwaccel_output_format drm_prime -i youtube720p.mp4 -vcodec copy -acodec copy -f h264 - | ffplay -i - decodes with CPU ffmpeg -loglevel debug -hwaccel drm -hwaccel_output_format drm_prime -i youtube720p.mp4 -vcodec copy -acodec copy -f drm_prime - | ffplay -i - does not work I keep trying

Usual user… what do you get with “vainfo” … does it matter? Are there other components at play, more required Linux patches, libraries sandwiched between Linux and ffmpeg? installing Linux-headers (armbian sunxi edge deb) before repeating ./configure and make, for ffmpeg, did nothing for me… no difference. Should it make a difference? update: I am back home, and I checked that the "hwcontext_drm: do not require drm device" patch is already included in ffmpeg 6.0... so it was already in my ffmpeg last night. In the libreelec forum, someone has added this patch: https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-drmprime/ffmpeg-001-v4l2-drmprime.patch So, I am adding this patch and compiling again. He aims to make it work for Rockchip and still hasn't been successful yet, by the way.

Negative results Test: Run (both starting from SSH without X running): From the terminal in the CVBS console I was able to make an MPV log: Tomorrow I will try with jernej's and kiwiboo's github source update: jernejs code cant compile, because the compiler thinks there's no FPU But I see some people solving this problem: https://github.com/openssl/openssl/issues/18818

OH roberto@orangepizero:~$ ffmpeg -hide_banner -decoders|grep request ... returns NOTHING Also: checking linux headers, there's only these relevant available I didn't have them installed at all... this means I need to rebuild my ffmpeg+libreelec patch... to get the v4l2_request codec? I am currently rebuilding ffmpeg, after installing the kernel-headers. Do I need to set CMA=128M in bootargs? update: after I ran ./configure, I saw: While waiting that ffmpeg compiles, I check that the latest libreelec, with linux 6.1.19, runs great, using the cedrus driver, although not in module form, but incorporated in the kernel. LibreELEC:~ # uname -a Linux LibreELEC 6.1.19 #1 SMP PREEMPT Sat Mar 18 16:09:53 UTC 2023 armv7l GNU/Linux LibreELEC:~ # dmesg |grep cedrus [ 0.784939] cedrus 1c0e000.video-codec: Device registered as /dev/video0 Checking the libreelec patches... I see that these linux files are patched: https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Allwinner/patches/linux/0061-media--cedrus--Don-t-CPU-map-source-buffers.patch https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Allwinner/patches/linux/0020-media-cedrus-Add-callback-for-buffer-cleanup.patch https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Allwinner/patches/linux/0021-media-cedrus-hevc-Improve-buffer-management.patch https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Allwinner/patches/linux/0022-media-cedrus-h264-Improve-buffer-management.patch Are they needed?

I succeeded at compiling ffmpeg 6.0 with libreelec's patch: wget https://ffmpeg.org/releases/ffmpeg-6.0.tar.bz2 wget https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch unzip and go inside ffmpeg dir patch -p1 < ffmpeg-001-v4l2-request.patch ./configure, make and install as per https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu, plus --enable-v4l2-request --enable-libdrm --enable-libudev The compilation finished with no errors Tests: I checked that my ffmpeg source had the lines of code, so it is compatible with mpv: https://github.com/Kwiboo/FFmpeg/commit/c2a9396e0c1b302a88f82d6a420111c9d495c322 Then, to test it mpv --vo=gpu --gpu-context=drm --hwdec=auto video.mkv It fails like this: Next I disabled the lightdm window desktop manager. Then to play from ssh: export DISPLAY=:0.0 I tried the same mpv command, and it played, with CPU decoding, and these video errors: And just to be sure, I share my v4l2-compliance... and my linux is 6.1.15-sunxi, with updated Debian Bookworm Is this normal?

The patch correction is to replace the hunk: with: Then, h264_slice.c compiles, but the whole make process fails this way: Should I replace ioctl with something, and close with pclose? (it looks like ioctl gets used 30 times in this file, and close 6 times) I found that the other v4l2_*.c use this line, so I will add it and try again: #include <sys/ioctl.h> Also, the complaint about close(), was because it needed #include <unistd.h> After making the change in v4l2_request.c, I ran make again, then it restarted in that same file Update: the compilation failed in the last file linking: I am going to try other versions of ffmpeg

I have posted full instructions here: https://github.com/robertojguerra/orangepi-zero-full-setup It will be better for you, because when there are improvements, you can test it immediately.

Yesterday, I was able to build the unpatched source of ffmpeg (the snapshot available in this date), and it ran fine, with CPU H264 decoding. https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu Then, I downloaded this libreelec patch. https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch with: cd ffmpeg_sources/ffmpeg patch -p1 < ffmpeg-001-v4l2-request.patch There was only 1 hunk error. patching file libavcodec/h264_slice.c Hunk #1 FAILED at 808. Hunk #2 succeeded at 861 (offset 7 lines). 1 out of 2 hunks FAILED -- saving rejects to file libavcodec/h264_slice.c.rej I am working on fixing this patch correctly.

Update: I installed armbian-bookworm. The gstreamer in that distro has the same v4l2 codecs… but can’t play the h264 because of a dkms and drm issue… I was starting it from within Lterm in LXDE. then I tried turning off lightdm (the graphical desktop), and repeated, from SSH, with export display 0 the orangepi zero became unresponsive, as if it had crashed. I will do other tests tonight. I left it building vanilla ffmpeg, as a practice run to build the patched ffmpeg.

I noticed i was using development version: https://gstreamer.freedesktop.org/documentation/installing/building-from-source-using-meson.html?gi-language=c git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git I will try again with git clone https://gitlab.freedesktop.org/gstreamer/gst-build.git

Thank you for the advice My gstreamer did not include those codecs. Now I am trying to get my meson updated, so I can compile gstreamer Same with ffmpeg... I will look for the code and patches Update: if your debian installs an old meson and ninja, install them through pip with python3 -m pip install meson python3 -m pip install ninja While doing the meson setup builddir, I found this: sudo apt install gstreamer1.0-plugins-bad roberto@orangepizero:~$ gst-inspect-1.0 | grep v4l2 v4l2codecs: v4l2slvp8dec: V4L2 Stateless VP8 Video Decoder v4l2codecs: v4l2slh264dec: V4L2 Stateless H.264 Video Decoder video4linux2: v4l2deviceprovider (GstDeviceProviderFactory) video4linux2: v4l2radio: Radio (video4linux2) Tuner video4linux2: v4l2sink: Video (video4linux2) Sink video4linux2: v4l2src: Video (video4linux2) Source Then I tried: gst-play-1.0 --use-playbin3 myvideo.mp4 But then I got: ERROR Driver did not report framing and start code method for file myvideo.mp4 ERROR debug information: ../sys/v4l2codecs/gstv4l2codec.c(134): gst_v4l2_codec_h264_dec_open () ... gst_v4l2_decoder_get_controls() failed: invalid argument Reached end of playlist update: while compiling mainline gstreamer, I got ../subprojects/FFmpeg/libavutil/arm/float_dsp_neon.S:268: Error: selected processor does not support `vpadd.f32 d0,d0,d0' in Thumb mode I think I need some special compilation options... I will look later

Thank you! Indeed, my /dev/video0 exists, but it failed the test At this point, I have zero clues about what I could do next. The origin of my *.ko's was just to use what came in armbian, and remove them from the blacklist cat /etc/modprobe.d/blacklist-orangepizero.conf #blacklist lima #blacklist sunxi_cedrus

Thank you 👍🏽 How should I check, whether my Linux would enable the hardware acceleration? My only datapoint is that I have the sunxi-cedrus.ko kernel module, and I can load it fine. what libraries are on top of it? what ffmpeg patches did you use? Is that a vanilla, or patched MPV? (sorry, probably those questions were asked already a couple of times… but … new year… gotta ask again) update: I Checked my ffmpeg and I have all the decoders and almost all the hwaccels. I am using ffmpeg 4.3.5-deb11u1 from an updated armbian 23.05 update: I tried ffplay -vcodec h264_v4l2m2m -i myfile.m4v and it gave the warnings: [h264_v4l2m2m @ 0xa4b2bca0] could not find a valid device [h264_v4l2m2m @ 0xa4b2bca0] can’t configure decoder and when I try: ffplay -hwaccel vaapi -i myfile.m4v failed to set value vaapi for option hwaccel: option not found update: I found that my ffmpeg does not have “—enable-v4l2request” in its compilation time configuration. I found these instructions, which I will follow when I have time:

Thank you 👍🏽 How should I check, whether my Linux would enable the hardware acceleration? My only datapoint is that I have the sunxi-cedrus.ko kernel module, and I can load it fine. what libraries are on top of it? what ffmpeg patches did you use? Is that a vanilla, or patched MPV? (sorry, probably those questions were asked already a couple of times… but … new year… gotta ask again)

I have been trying to get ffmpeg patched and compiled, with compilation errors. But the armbian default ffmpeg has this: ffmpeg -hide_banner -h decoder=h264 Decoder h264 [H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10]: General capabilities: dr1 delay threads Threading capabilities: frame and slice Supported hardware devices: vaapi vdpau H264 Decoder AVOptions: -enable_er <boolean> .D.V...... Enable error resilience on damaged frames (unsafe) (default auto) -x264_build <int> .D.V...... Assume this x264 version if no x264 version found in any SEI (from -1 to INT_MAX) (default -1) What should it look like, when H3-hardware acceleration is enabled? With ffplay and mpv, I am able to play a 480p H264 video with 85% CPU (across 4 cores), and a 720p H264 video with 300% CPU... so I am pretty sure it is CPU-decoded I tried gstreamer and it still decodes with the cpu: sudo apt install gstreamer1.0-x gstreamer1.0-vaapi gstreamer1.0-libav gstreamer1.0-plugins-base gstreamer1.0-plugins-base-apps gstreamer1.0-alsa gstreamer1.0-x gst-launch-1.0 playbin uri=flie:~/myfile.mp4

NICE! Thank you for testing it. By any chance, do you know how to hardware-decode and encode with the H3 and cedrus?