robertoj

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?

Has anybody tried it?

I haven’t checked this forum for a week 😮 see my GitHub, step 7 for analog video and the patches https://github.com/robertojguerra/orangepi-zero-full-setup Credit to the actual authors of the patches, and to me for updating for Linux 6.1

I found that the armbian patch patch/kernel/sunxi-current/patches.armbian/drv-gpu-drm-sun4i-sun8i_mixer.c-add-h3-mixer1.patch Pre-modifies the mainline's sun8i_mixer.c, making the libreelec's patch hunk be redundant... so I need to use the userpatch instructions to try making it like LibreElec's patch. (I used the power of grep -nr "sun8i_h3_mixer1_cfg*" . 😆) Please help.... If i put a copy of patch/kernel/sunxi-current/drv-gpu-drm-sun4i-sun8i_mixer.c-add-h3-mixer1.patch in userpatches/kernel/archive/sunxi-6.1/ and make a single edit, would it skip the application of the original armbian patch? Or do I need to move it to another folder? (I see now that both patches are applied) 😆 update: I edited the LibreElec patch again, to only fix 3 parameters in the mixer config struct result: same instability in Kodi… I have not tested lxde yet. i need more ideas to fix the video output in lxde

no difference with the lima and gpu_schedule kernel modules. Still scraped-down pixels … but… I installed kodi… and it works (and crashes after 5 minutes) remember to “modprobe Lima” first It doesn't really crash... it just gets hung-up for a while. Fortunately, I can also start it from the ssh session, and it starts on the composite output. However, when I control-C and kill it, I get back to working on SSH, but the composite doesn't get the bash prompt... anyone knows how to return the bash to the composite console? update: I tihnk I need to fix the libreelec patch to actually apply this hunk, because it has 2 very important settings that are not being applied: @@ -600,6 +625,15 @@ static const struct sun8i_mixer_cfg sun8i_h3_mixer0_cfg = { .vi_num = 1, }; +static const struct sun8i_mixer_cfg sun8i_h3_mixer1_cfg = { + .ccsc = 1, <--- mainline linux shows "CCSC_MIXER1_LAYOUT", which equates to the same thing: "1" + .mod_rate = 432000000, + .scaler_mask = 0x3, <--- this is 0xf in mainline linux 6.1 after armbian.patch*, but the libreelec patch indicates 0x3, and add scanline_yuv element... I need to follow libreelec's decision + .scanline_yuv = 2048, + .ui_num = 1, + .vi_num = 1, +}; + *patch/kernel/sunxi-current/patches.armbian/drv-gpu-drm-sun4i-sun8i_mixer.c-add-h3-mixer1.patch

The only other thing I haven't tried is to match all the linux compilation options found in the LibreElec Allwinner folder... for example, compile the lima.ko and gpu_sched.ko, which are present in LibreElec (seen in lsmod) As a reminder for myself: lima is under menuconfig/device drivers/graphics support/ And gpu_sched doesn't show up anywhere... but I found here that it probably gets compiled automatically with lima https://www.librehat.com/building-linux-kernel-on-odroid-u3/

Ok there's more progress: I took the zzz-tv-cvbs.patch and copied 3 hunks: the new file sun8i-h3-tve.dts, the orangepizero dts patch, and the orangepi-pc.dts patch, into a new additional patch. Then the compilation finished 100%. I was able to connect with ssh, run armbian-config, system, hardware. And I saw the tve dtb overlay option I selected it, rebooted, and after a while I saw the login prompt in my composite TV (with overscan and ghosting problem) I tried "apt install lxde". Reboot. But I only had the text console "startlxde" Gtk-WARNING **: {time}: cannot open display: Maybe I am very close... but maybe I am very far. update: "apt install task-lxde-desktop", reboot... and I was welcomed by the lxde login screen BUT it was the same "smeared down from the mouse cursor" experience as I had before trying the LibreElec patch. Perhaps the zzzz-tv-cvbs.patch's DTS is different from the libreelec dts... since it was the only part that wasn't sourced from the libreelec patch.

update: there was an un-needed hunk in this patch, for Linux 6.1... one declaration was being done again, but mainline already had it It compiled 100% and created the armbian filesystem img... so I tried it... but the h3-tve.dtbo (device tree blob overlay) was not created. I remembered that I added another patch that was only to build the "dtbo" (see in my response in the other thread about CVBS) The patch applied correctly, BUT it failed during compilation: make[3]: *** No rule to make target 'arch/arm/boot/dts/overlay/sun8i-h3-tve.dtbo', needed by 'arch/arm/boot/dts/overlay/'. Stop. I investigated why the zzzz-tv-cvbs.patch worked and this libreelec patch did not... There are some hunks in the zzzz patch that do not exist in the librelec patch, for example this new file: diff --git a/arch/arm/boot/dts/overlay/sun8i-h3-tve.dts b/arch/arm/boot/dts/overlay/sun8i-h3-tve.dts new file mode 100644 index 000000000..07ba7ba71 --- /dev/null +++ b/arch/arm/boot/dts/overlay/sun8i-h3-tve.dts ... While I do this work... maybe someone will comment, if they have experience... maybe LibreElec has another patch that adds this file?

Instead of fixing based on the patch I updated, I decided I need to make this patch: https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Allwinner/patches/linux/0036-wip-h3-h5-cvbs.patch Be applicable in the armbian userpatches folder I created the folder build/userpatches/kernel/archive/sunxi-6.1 and put the patch there (I knew the path because I looked at the destination of build/patch/kernel/sunxi-current symbolic link ) Now compile.sh is "Preparing bare kernel git tree" taking a long time... I will let it do its thing update: I am getting improved_git try 1 failed... several times... is it something transitory with the github server? update: now using a token as required by github... but it cant find repo https://github.com/morrownr/8821cu-20210118/ I can see https://github.com/morrownr/8821cu-20210916 Exists... how can I try it? update: i ran "git pull" and the script had a fix for this problem update: I see that the libreelec tv patch was applied with no complaints... but is there a "output/debug/patching.log" in the new compile.sh? (23.05-trunk) update: compilation error... so I will need to correct this patch for use in linux 6.1 drivers/gpu/drm/sun4i/sun8i_mixer.c:754:37: error: redefinition of 'sun8i_h3_mixer1_cfg' [🔨] 754 | static const struct sun8i_mixer_cfg sun8i_h3_mixer1_cfg = { [🔨] | ^~~~~~~~~~~~~~~~~~~ [🔨] drivers/gpu/drm/sun4i/sun8i_mixer.c:746:37: note: previous definition of 'sun8i_h3_mixer1_cfg' with type 'const struct sun8i_mixer_cfg' [🔨] 746 | static const struct sun8i_mixer_cfg sun8i_h3_mixer1_cfg = { [🔨] | ^~~~~~~~~~~~~~~~~~~

So I was able to apply the cvbs tve patch in armbian, Linux 5.15.93. The tv signal is being generated by the orange pi zero. however, when I start lxde, all the pixels below the mouse cursor become “washed down”… best if I show you… also I have another orangepi zero running LibreElec, with Linux 5.10 (orange pi 2 image works well with the opi-zero)… what settings should I look in LibreElec or Kodi, to make improve my situation in Armbian?

I just updated the zzzz.tv-cvbs.patch to be applied correctly in Armbian 23.02.0, Linux 5.15.93. Only the last hunk needed to be corrected You need to copy this patch file in ~/build/userpatches/kernel/archive/sunxi-5.15 so that the Armbian build script uses the patch zzzz-tv-cvbs-5.15.93-sunxi.patch I added the additional patch that gleam2003 posted on january 2022... Then, armbian-config, system, hardware finally shows "tve" Activate it and reboot. Composite out works Now onto fixing the resolution

I am trying to apply this zzzz-tv-cvbs.patch in the armbian build system... Should I copy it to the userpatches directory? to userpatches/sunxi-current? to userpatches/sunxi-current/5.15? It seems like ./compile.sh has ignored the patch file in the 3 places I have put it in. Guybrush: have you tried "DISPLAY=:0 xrandr --output Composite-1 --mode NTSC"?

I had to read your comment again... I understand that you made the current LibreElec to work on the OrangePi Zero. But I need armbian to accept that patch in the Armbian build directory. I just created a Jammy VM, and installed the armbian build directory and browsed through the linux kernel source. The effected files seem like they are going to accept the hunks with no problem. Now I am going to learn how to apply the patch in the current armbian

Do you mean that you used the patch published in LibreElec, and applied it in the Armbian build system (Bullseye right?). I tried an old image with Linux 4.xx and LXDE desktop... it was fine. I think it would be productive with a small screen and to develop a kiosk.