• Content Count

  • Joined

  • Last visited

1 Follower

About divis1969

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Banana PI. A20. Initially this topic was posted in the appropriate forum. The question was: why do I need to freeze it from technical POV. I do understand your team have limitations on support. The device I'm going to play with is mostly used for testing purposes, so if I completely fail with upgrade, I will do a clean install. And thanks for the great job. Do you mean do-release-upgrade or manual source list change? I see there is some way to enable the 3rd party update along with the system upgrade (https://ubuntu.com/blog/how-to-upgrade-from-ubun
  2. Isn't it better to install ubuntu-release-upgrader-core and use the do-release-upgrade instead of manual procedure? Can/Should I freeze kernel upgdade with it? Why do I need to freeze it, btw?
  3. Is there any recommendations how to upgrade Armbian from Ubuntu Bionic to Ubuntu Focal?
  4. Thanks for the tip! BTW, I've got a crash stack for a segmentation fault I've mentioned above: Thread 1 "ffmpeg" received signal SIGSEGV, Segmentation fault. tiled_to_planar () at tiled_yuv.S:86 86 vld1.8 {d0 - d3}, [SRC :256], TSIZE (gdb) bt #0 tiled_to_planar () at tiled_yuv.S:86 #1 0xb6fc25b0 in copy_surface_to_image (driver_data=driver_data@entry=0x466960, surface_object=surface_object@entry=0x469f48, image=image@entry=0xbeffda44) at image.c:159 #2 0xb6fc280e in RequestDeriveImage (context=<optimized out>, surface_id=67108864, image=0xbeffda44) at
  5. I've tried to ask a question in IRC channel (#cedrus on freenode) but did not get an answer (or maybe I've missed it while I was offline, do not know where to get backlog). If you mean to update a library by myself, I do not have any experience with H264 (or other video codecs). The goal was to get a quick estimation whether cedrus is good enough for video surveillance application.
  6. Re-encoding from 25fps to 5fps (sw-to-sw and hw-to-sw) are almost identical though the second case takes more time (copying hw buffers?): $ time ffmpeg -hwaccel vaapi -hwaccel_device /dev/video0 -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -c:v libx264 -r 5 -an stream.mp4 ... real 6m45.657s user 10m44.271s sys 0m13.720s $ time ffmpeg -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -c:v libx264 -r 5 -an stream_sw.mp4 ... real 6m20.538s user 10m19.009s sys 0m3.729s The video produced with hw decoder has small artifacts at the bottom-right corner.
  7. I have reverted the following commits: 341772b82a3b media: cedrus: Specify H264 startcode and decoding mode 8cae93e09011 media: uapi: h264: Add the concept of start code 5604be66a568 media: uapi: h264: Add the concept of decoding mode Now I can run decoding of H264: $ export LIBVA_DRIVER_NAME=v4l2_request $ time ffmpeg -hwaccel vaapi -hwaccel_device /dev/video0 -hwaccel_output_format vaapi -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -f null /dev/null ... real 0m15.255s user 0m5.651s sys 0m1.693s Average speed is ~5.3x, fps ~130 There are some errors at the e
  8. I've found that the issue with h264 codec is caused by the size of the struct v4l2_ctrl_h264_slice_params defined in include/media/h264-ctrls.h (kernel) and include/h264-ctrls.h (libva-v4l2-request). Kernel's version adds one more field start_byte_offset with commit commit 5604be66a56867a784e162299a48c214921ffa1b Author: Boris Brezillon <boris.brezillon@collabora.com> Date: Fri Aug 16 13:01:24 2019 -0300 media: uapi: h264: Add the concept of decoding mode I did not find any changes in libva-v4l2-request that match this change in kernel. I'm going to revert the ab
  9. There was no /etc/default/cpufrequtils in my case but /etc/default/cpufrequtils.dpkg-old instead. I've copied it to /etc/default/cpufrequtils, replaced 'ondemand' to 'performance' and rebooted a device. $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance Uptime is 23 hours at the moment.
  10. I'm also observing similar issue (device is not accessible via ssh after some time - from few hours to couple days). This happened with kernels 5.3.x (don't remember exactly which one I've installed) and the same 5.4.35 (I'm using Ubuntu).
  11. Yes, I did. If was long time ago and I found kerberosio more attractive. There was also a performace issue with ZM on bananapi that time. I've tested ZM recently again (on bananapi m3) and it seems using less CPU than kerberosio while movement detection. So, I would switch to ZM if it will be able to handle >1 cameras. But I decided to first play with HW decoding on bananapi prior to migrating to ZM. ----- Here are the results of my attempt to use cedrus. - I've built libva-v4l2-request. There were few issues with it. It requires libva-dev and libdrm-dev, I've install
  12. Hi, Did anybody play with Cedrus on the recent kernels? I'm going to play with it on Bananapi m1, kernel 5.4 and Ubuntu Bionic. Should I just got step-by-step using this instructions http://linux-sunxi.org/Sunxi-Cedrus ? The goal is to evaluate whether this is suitable solution for video surveillnace. I'd used kerberosio with an IP camera for couple years and this does not work good with motion detection.
  13. Well, I did not find the exact reason why there was no kernel logs. Most likely I've removed SD card from card reader without proper ejecting. I've spent some time creating a suitable development environment (I've found Armbian is not userdeveloper-friendy) and finally was able to figure out the reason of the boot failure. That is a patch/kernel/sunxi-current/0111-mfd-axp20x-Add-AC-power-supply-cell-for-AXP813.patch which adds a duplicate entry axp20x-ac-power-supply into a cell list of axp20x MFD device. I've renamed this patch to *.disabled, rebuilt the kernel and it ha
  14. Well, I've built the Armbian and tried to run it from SD. Unfortunately, it enters boot loop. I've attached the log from console. I'm not familiar with u-boot, it looks like u-boot is loaded from SD, but all the boot scripts were taken from mmc (I did not remove my previous OS from it). Note that I've set verbosity to 7 and console to serial in SD's /boot/armbianEnv.txt and the same should still persist in the mmc's /boot/armbianEnv.txt, but there is no logs from kernel boot. Weird... Can I prevent u-boot to read boot scripts from emmc? minicom-5.3.9.log
  15. I'm not sure. Perhaps I had enabled this manually, or I had started from dev build a long time ago... Sudo apt upgrade had upgraded the kernel as well. First time I had just recovered from this by booting from sd card and modifying links at emmc /boot for kernel and dtb and copying initram from sd. This time I've first collected this log. Well, hopefully I will have some time to debug it.