gounthar

  • Posts

    323
  • Joined

  • Last visited

Reputation Activity

  1. Like
    gounthar reacted to ScottP in Mainline VPU   
    Hear is a lengthy reply I put on the Frigate NVR github for someone asking about hardware decoding for Frigate NVR. I would be interested if I am doing anything wrong here or I have missed a step.
     
    TL;DR It does not work reliably for me  ATM but this is the closest to working I have seen so far. Work is ongoing in linux kernel and FFmpeg, it may work reliably sometime in the future. When the kernel drivers are moved out of staging and the interface to them is stable I expect to see a pull request on the main FFmpeg git. This is a long reply with information to test because I am giving up at this point and moving to a different platform. I would be interested if you find a solution though, or that I have missed something - hence the detailed reply.
    For testing you can try this fork of ffmpeg https://github.com/jernejsk/FFmpeg It has v4l2-request and libdrm stateless VPU decoding built in using hantro and rockchip_vdec/rkvdec.
    use kernel 5.14.9, armbian is a convenient way to change kernels - sudo armbian-config -> system -> Other kernels.  FFmpeg from the above github has private headers for kernel interfaces and they are updated about a month after each release. You must install the correct userspace kernel headers, I just get the kernel source from https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.14.9.tar.xz and then do `make -j6 headers_install INSTALL_HDR_PATH=/usr`
    Do not use amrbian-config to install kernel headers - it installs the wrong version.
    Then install FFmpeg dependencies:
    `sudo apt install libudev-dev libfreetype-dev libmp3lame-dev libvorbis-dev libwebp-dev libx264-dev libx265-dev libssl-dev libdrm2 libdrm-dev pkg-config libfdk-aac-dev libopenjp2-7-dev`
    Run configure, this is a minimal set of options, frigate includes many more though, I removed many of them to build faster and save memory (I actually think there are a lot of redundant ffmpeg components in frigates default build files, some X11 frame grabber stuff and codecs nobody uses anymore, but thats for a separate discussion):
    ``` ./configure \ --enable-libdrm \ --enable-v4l2-request \ --enable-libudev \ --disable-debug \ --disable-doc \ --disable-ffplay \ --enable-shared \ --enable-libfreetype \ --enable-gpl \ --enable-libmp3lame \ --enable-libvorbis \ --enable-libwebp \ --enable-libx265 \ --enable-libx264 \ --enable-nonfree \ --enable-openssl \ --enable-libfdk_aac \ --enable-postproc \ --extra-libs=-ldl \ --prefix="${PREFIX}" \ --enable-libopenjpeg \ --extra-libs=-lpthread \ --enable-neon ```
    Then `make -j6`
    I dont know if this next bit is correct, but it works for me, I dont want to do `make install` just run the ffmpeg tests from the build directory, to run tests you must run `sudo ldconfig $PWD $PWD/lib*` first otherwise linker will not find libraries.
    If you want to try a different kernel version run `make distclean` in FFmpeg and run ./configure again. If FFmpeg fails to build it will be because private headers do not match kernel headers. errors like V4L... undefined etc
    Then you can do some tests and see if you get valid output, for example, this decodes 15s from one of my cams:
    `./ffmpeg -benchmark -loglevel debug -hwaccel drm  -i rtsp://192.168.50.144:8554/unicast  -t 15 -pix_fmt yuv420p -f rawvideo out.yuv`
    Checks to make during and after decoding: 
    Observe CPU usage, on my system rk3399 with 1.5Ghz little core and 2Ghz big core overclock I get between 17 and 25% cpu on one core, it varies if it runs on a53 little core or a72 big core. It should be better than that, I think its the way that the data is copied around in memory. Gstreamer or mpv attempt to do zero copy decoding so its more efficient. With software decoding CPU use is about 70% of one core. RK3328 does not have the two a72  cores and four a53 cores that RK3399 has, just four a53 cores so rk3328 about half as powerful as RK3399 as the a72 cores are about twice as powerful as the a53 cores.
    You should see in the debug output for ffmpeg where it tries each of the /dev/video interfaces to find the correct codec for decoding. Be warned that ffmpeg will sometimes just fall back to software decode, if that happens you will see much higher CPU usage and often ffmpeg will spawn a number of threads to use all cores in your system. Your user should be a member of the "video" group in /etc/group to access without sudo. Log snippet of that section below:
    ```[h264 @ 0xaaab06cd9070] Format drm_prime chosen by get_format(). [h264 @ 0xaaab06cd9070] Format drm_prime requires hwaccel initialisation. [h264 @ 0xaaab06cd9070] ff_v4l2_request_init: avctx=0xaaab06cd9070 hw_device_ctx=0xaaab06c549a0 hw_frames_ctx=(nil) [h264 @ 0xaaab06cd9070] v4l2_request_probe_media_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/media1 driver=hantro-vpu [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/video1 capabilities=69222400 [h264 @ 0xaaab06cd9070] v4l2_request_try_format: pixelformat 875967059 not supported for type 10 [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: try output format failed [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/video2 capabilities=69222400 [h264 @ 0xaaab06cd9070] v4l2_request_try_format: pixelformat 875967059 not supported for type 10 [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: try output format failed [h264 @ 0xaaab06cd9070] v4l2_request_probe_media_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/media0 driver=rkvdec [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/video0 capabilities=69222400 [h264 @ 0xaaab06cd9070] v4l2_request_init_context: pixelformat=842094158 width=1600 height=912 bytesperline=1600 sizeimage=2918400 num_planes=1 [h264 @ 0xaaab06cd9070] ff_v4l2_request_frame_params: avctx=0xaaab06cd9070 ctx=0xffff8804df20 hw_frames_ctx=0xffff8804faa0 hwfc=0xffff8804e530 pool=0xffff8805e910 width=1600 height=912 initial_pool_size=3 ```
    Check that the output file contains valid video data, try playing it using vlc:
    `vlc  --rawvid-fps 10 --rawvid-width 1600 --rawvid-height 900 --rawvid-chroma I420 out.yuv`
    adjust the command to what height/width/fps your cameras record in.
    If all this is working then try doing longer decodes in parallel, eg is you have 3 cams run the ffmpeg command for each of them in a separate window and increase the time. What happens to me is that at some point ffmpeg will start reporting "resource not available/busy" or similar, rebooting will make it work for a while again. 
    You can check what codecs are supported by each of the interfaces /dev/video[012] by `v4l2-ctl --all -d0` change d0 to d1 d2 etc to view the other decoders/encoders
    You can monitor the state of kernel development https://patchwork.kernel.org/project/linux-rockchip/list/  Most of the work on this is being done by Andrzej Pietrasiewicz. My suggestion is monitor  both the ffmpeg github and kernel commits/patches, find out when they rebase ffmpeg. Pull that version and install the current kernel for it plus headers and retest.
    I have all the frigate docker files already created. I basically created a new set of  dockerfiles with an arch of aarch64rockchip and added those to Makefile. I'll upload them to my github at some point, I see little point to a pull request since rockchip is a niche platform with not many users in home assistant or frigate, and it does not currently work for me reliably anyway.
    I have been trying to get this working for some time now, at kernel 5.4.* there were a bunch of kernel patches you had to apply. Nothing worked for me then. Often FFmpeg complained about the pixel format. There were some people on Armbian forums who claimed to have it working, but I had my doubts, maybe it was wishful thinking and ffmpeg was really using software decode. Most of the effort around this is for video playback so people can play 1080p and 2/4k videos on desktop and  kodi. There is little information about straight decoding to a pipe like frigate. So in research ignore stuff to do with patched libva etc.
    For now I am using an old ~2013 i5-4670 four core/thread Haswell with Nvidia GT640 GPU for Frigate and Home Assistant. For three cams at 1600*900 10fps Frigate uses 6% CPU as reported by Home Assistant supervisor. It is very stable. With that in mind and wanting to use a more power efficient system I caved and ordered a Nvidia Jetson 4GB developer kit yesterday. I have confidence I can build Frigate docker containers for that system and it has a similar hardware decoder as their GPUs, I can also try out using CUDA filters and scaling to reduce CPU load for Frigate detector. A start would be to copy the amd64nvidia dockerfiles and create aarch64nvidia arch and modify from there it should be mostly the same.
     
     
  2. Like
    gounthar reacted to barnumbirr in [Selling] Helios64   
    Hello,
     
    looking at selling my Helios64.

    Mostly looking at getting a price check (what's the device still worth) and gauging interest.

    Device is in pristine condition, standard fans were swapped for Noctua NF-A8. (standard fans will be included)
    I'd prefer to keep this EU only as shipping is going to be a pain.
  3. Like
    gounthar reacted to ScottP in Mainline VPU   
    Working for me on kernel 5.14.5 with ffmpeg https://github.com/jernejsk/FFmpeg/tree/v4l2-request-hwaccel-4.3.2 h264 1600*900 15fps stream from my cams use 17-22% of one CPU about 5% of which is pxfmt conversion because it reduces by that amount without conversion - no further kernel patches and ffmpeg dependencies all installed from default repos. This is awesome I've been wanting this for a while, my use case is Frigate NVR which is currently running on an old intel system with a nvidia gpu doing the decoding. I can now revert my nanopc t4 to the task and save some electricity. 
    My ffmpeg command that emulates approximately what Frigate does:
     
    ffmpeg  -loglevel warning -hwaccel drm -i rtsp://192.168.50.144:8554/unicast  -pix_fmt yuv420p  -f rawvideo pipe:
     
    Many thanks @jernejkwiboo and everyone else who made this possible
     
    Now need to find out why get block i/o  errors and corruption on emmc on all 5.13 and 5.14 kernels I have tried, doing testing from sdcard for now.
  4. Like
    gounthar reacted to kprasadvnsi in OrangePi Zero2 - Allwinner H616   
    Thermal sensor support for H616 SoC
     
    https://github.com/armbian/build/pull/3153
  5. Like
    gounthar reacted to Igor in Allwinner H3 audio codec on OrangePi Zero Plus2 H3   
    Likewise  

    My distribution of choice was also Slackware - IIRC v1.0 / there was not much choices at that time - in my case, Linux kernel has not even 1.0 
     
    A lot has change since.
     

    With totally limited resources we are trying to make this very complicated, purpose driven and diverse ecosystem as simple as possible.
     

    https://docs.armbian.com/User-Guide_FAQ/
    https://docs.armbian.com/#what-is-armbian
  6. Like
    gounthar reacted to Werner in Seed our torrents   
    The size requirements have been updated.
     
    Since we now share images with various desktop environments as well the size of all torrents have now grown to around 500GB.
    To become future-proof again the free space requirement has been raised to 1TB.
     
    For those who did not notice yet. It became rather simple to become an Armbian http/s mirror as well if you do not like torrent stuff: https://github.com/armbian/mirror
  7. Like
    gounthar reacted to Werner in OrangePi Zero2 - Allwinner H616   
    LIB_TAG has nothing to do with kernel branches. You should always build from master unless you know what you do or being told otherwise.
    I suggest to start over with a clean workspace since I yesterday successfully built an OPi02 bullseye legacy image without issues.
  8. Like
    gounthar reacted to kprasadvnsi in Mainline VPU   
    I am getting much better performance using your test commands. I am getting 235 fps at 5% average CPU load.
    Where should I look for patching in the mpv to get this working?
  9. Like
    gounthar reacted to usual user in Mainline VPU   
    A few days ago I also tried to build a ffmpeg with v4l2-request-hwaccel. Because my distribution already uses 4.4, I used these patches. Initially, I got similar error messages as @kprasadvnsi, but the 5.14 kernel header hint was the missing link. I also have a flawlessly compiled ffmpeg package now, but I also don't know if additional patches are needed for other mainline components or how to check the v4l2-request-hwaccel functionality.
  10. Like
    gounthar reacted to kprasadvnsi in Mainline VPU   
    FFmpeg build fine with v4l2-request-hwaccel-4.3.1-new branch. The media file bbb_sunflower_1080p_30fps_normal.mp4 decoding fine at 90fps with one A72 core at 100% uses.
     
    I have tried building MPV player with it but it doesn't look like using the VPU. A72 cores are at 30-40% and A53 are around 15-20%. How can I check if it actually using VPU?
     
    MPV playback log file.
     
    mpv_sucks.log
  11. Like
  12. Like
    gounthar reacted to Werner in Board Bring Up Station P1 rk3399, M1 rk3328   
    Kind a sucks working with a crude estimated model.... @Winguo  can you provide a STEP model for the MEZZ M2 POE expansion board?
     

  13. Like
    gounthar reacted to kprasadvnsi in OrangePi Zero2 - Allwinner H616   
    Armbian desktop running on Orange Pi Zero2 with kernel 5.13

  14. Like
    gounthar reacted to yam1 in OrangePi Zero2 - Allwinner H616   
    With the mentioned fixes applied, happy to report everything works, except hdmi, wifi, and the other 2 USBs (tested not working with added settings in armbianenv). It is quite usable now as a little x display and screen updates seem to keep up as tested using smtube mpv videos.
     
     

     
  15. Like
    gounthar reacted to balbes150 in Board Bring Up Station P2 rk3568, M2 rk3566   
    Good news. Full-fledged working images (20210827) of ArmbianTV for P2 and M2  are ready. All the equipment works in them and you can start and configure the system via an HDMI monitor and a keyboard/mouse. 
     
    M2
     
    https://disk.yandex.ru/d/OBDO8BU2y1M6ug
     
    https://users.armbian.com/balbes150/rk3566/
     
     
    P2
     
    https://disk.yandex.ru/d/neKXsYolKXgLzg
     
    https://users.armbian.com/balbes150/rk3568/
  16. Like
    gounthar reacted to iHackFX in OrangePi Zero2 - Allwinner H616   
    Hi, I recently received this board and I was able to get the docker started. Maybe someone may find it useful.
    After installing via "armbian-confix" if try to start docker service with
    $ systemctl start docker  we get this error: 
    ● docker.service - Docker Application Container Engine    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)    Active: activating (auto-restart) (Result: exit-code) since Tue 2021-08-24 20:09:34 MSK; 26ms ago      Docs: https://docs.docker.com   Process: 11947 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)  Main PID: 11947 (code=exited, status=1/FAILURE) dpkg: error handling package docker-ce (--configure):  installed docker-ce package post-installation script subprocess returned error exit status 1 In "journalctl -xe" we get the following - "Running iptables --wait -t nat -L -n failed with message: `# Warning: iptables-legacy tables present, use iptables-legacy to see them\niptables: Operation not supported.`, error: exit status 1."
    And to fix it, you need to use the following command:
    $ update-alternatives --set iptables /usr/sbin/iptables-legacy Then restart the service and docker works.
  17. Like
    gounthar reacted to jernej in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    Which is your kernel version?
     
    This is 4.3.1 branch which should work with kernel 5.13: https://github.com/jernejsk/FFmpeg/commits/v4l2-request-hwaccel-4.3.1-new
     
    gstreamer also made a ton of progress in last few days and it currently passes even more H264 conformance tests than ffmpeg. However, you need to build latest source from git.
  18. Like
    gounthar got a reaction from lanefu in How would you implement a super precise clock with a board running Armbian?   
    Interesting, but not affordable: https://www.cnet.com/tech/computing/facebook-shares-its-time-card-atomic-clock-tech-to-speed-internet-services/
  19. Like
    gounthar reacted to Dan MacDonald in 4kp30 video on Orange Pi Lite and mainline hardware acceleration   
    Hi Ubobrov
     
    You seem to be the expert on using the Cedrus decoder under Armbian so I've got a few questions that I'm hoping you would be kind enough to answer:
     
    Have you tried 4K@30fps h264 playback using cedrus/v4l2-request with mpv?
     
    Have you tried the most recent 5.10 Libreelec AW kernel patches? I'm hoping Balbes can include these in the Armbian AW kernel as standard.
     
    Have you also got an Allwinner H6 board? Your guide should also work for H6 devices. I've got a T95 Max.
     
    I noticed in your guide to building ffmpeg you disable vaapi and vdpau. Why? Was that just to save build time or do you have another reason? It may no longer be required to rebuild ffmpeg, maybe v4l2-request is enabled in the regular deb now?
     
    It looks like libvdpau-sunxi isn't required and it hasn't been updated in years so I presume its dead.
  20. Like
    gounthar reacted to calinb in Review of the PineBook Pro with Armbian   
    I just upgraded my Pinebook Pro touchpad firmware. Wow! It's especially helpful with Armbian, which lacks the extensive synclient controls of other distros that can partially mitigate the former touchpad lag and hysteresis. Even with synclient, it's a huge improvement!
    https://forum.pine64.org/showthread.php?tid=14531
     
  21. Like
    gounthar reacted to guidol in How would you implement a super precise clock with a board running Armbian?   
    @gounthar also maybe here some other idea?
    https://hackaday.com/2021/08/16/new-part-day-raspberry-pi-hat-for-ieee1588-precision-time-protocol/
  22. Like
    gounthar reacted to Werner in QUESTIONS ORANGEPI4B / GPIO /MINI-FAN   
    I don't know especially for the 4B but other models usually can be powered trough GPIO pins 2 and 6 which are shorted to the other powering option like barrel  plug or microUSB/USB-C. So the consumption is basically limited by the line resistance and the power supply.
  23. Like
    gounthar reacted to Igor in OrangePi Zero2 - Allwinner H616   
    I just successfully build and boot image with legacy u-boot and legacy kernel. A lot of dirty things around, but it works. I am unable to push things further, so anyone can proceed from here. Enabling Wifi and BT https://github.com/armbian/build/pull/2620
  24. Like
    gounthar reacted to Werner in OrangePi Zero2 - Allwinner H616   
    Mandatory for proper testing. Everyone who tinkers with SBCs should have such a thing. Also they are dirt cheap.
  25. Like
    gounthar reacted to tparys in How would you implement a super precise clock with a board running Armbian?   
    For what it's worth, Microsemi sells lots of stuff designed by Jackson Labs Technologies, which might open up the market options.
     
    Also, if you're looking for accurate clocks you can disconnect and take indoors, the term you're looking for is GPS Holdover. Just fair warning that the more accurate the clock, the longer it might take with view of the sky before it hits full accuracy (though Microsemi won't advertise that). FYI, double oven temperature compensated oscillators can get better accuracy than the some commercial grade atomic clock options, but may take up to 3 days of warmup to get to full spec..
     
    But if you're going to procure a couple and take them inside, consider a battery backup to avoid the initial training time, and make sure they get lots of sunlight before you need them.