sgjava

This is a good review of security software for Linux https://blog.jasonantman.com/2018/05/linux-surveillance-camera-software-evaluation. The funny thing is this guy went with Motion which is terrible and the reason I wrote https://github.com/sgjava/motiondetector. This time however I'm probably going down the Java route as I have a lot of the pieces already written in another project. I want intelligent motion detection, object classification (CV), etc. The core stuff is most important. The viewer, etc. is not really that important at this point. Any ways, I'm playing with https://

I'll post a link later where various Linux compatible software was evaluated. I found a Java ffmpeg wrapper. I have built this stuff from scratch before and all these packages suck at the core functions. Health checks, etc. needs to be done, etc.

OK, so if you know me I don't wait around for answers. I took an old h264 camera Edimax Triple Mode Plug-n-View Internet IP Camera Supports PoE Function 1.3MP H.264 Mode and E-Cloud Technologynology (IC-3100P) updated the firmware and loaded up an Odroid XU4 since ffmpeg uses hardware encode/decode out of the box. The trick is to not decode/encode the stream and save to a mkv container. 1280x1024 @ 15 fps uses < 2% cpu. What I can do is use the MJPEG stream at like 3 FPS for motion and computer vision processing. I didn't want to code anything, so I'll start looking at security software nex

I've built my own security cameras for about 8 years (using computer vision, ML, etc.), but now I want to do something off the shelf so to speak. I just wired my attic to my office with cat 6 cable and my house is wired with cat5e, More than likely the cameras will be plugged directly into the SBC from the attic via PoE. My question is which SBC would be able to handle hardware H265 decoding using 4K cameras at 30 fps? That's about 27 Mbps per camera times 4 cameras. iperf test from my attic showed 961 Mbps using ODroid XU4. So my questions are: Which SBC can handle H265 hardware decod

@martinayotte I'm doing it this way https://github.com/sgjava/patchbian since the build creates the patch for you and a test image at the same time.

@martinayotteI understand the patch part, but usually you make the change somewhere like build/cache/sources/linux-odroidxu4/odroid-5.4.y/arch/arm/boot/dts/exynos5420-pinctrl.dtsi (for XU3/XU4) and a patch is generated in output/patch. This is the step I'm missing. Almost there, thanks for your help do far.

@martinayotteOK, I figured out the syntax for each pinctrl using phandle to identify. So next question is how do I make this part of build process, so it gets applied automatically in img? Duo: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3-pinctrl"; fragment@0 { target = <0x0b>; __overlay__ { gpio-line-names = "", "", "", "", "GPIOA4 DTX", "GPIOA5 DRX", "", "", "", "", "", "GPIOA11 SCL", "GPIOA12 SDA", "GPIOA13 CS", "GPIOA14 CLK", "GPIOA15 MO", "GPIOA16 MI", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", ""

How does it know which pinctrl to place the line names?

Yes, I'm wondering is that another fragment section in one file or another file?

No worries, I still need to find a way to cover both pin controllers? It appears compatible strings are different.

Ah wrong location. You need to put dtbo in /boot/dtb/overlay, not /boot/dts/overlay as you suggested above.

@martinayotte OK, tried this and no luck on duo: ls /boot/dts/overlay/ sun8i-h3-gpio-line-names.dtbo cat /boot/armbianEnv.txt verbosity=1 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 rootdev=UUID=d1e6e420-cd58-46c8-aa52-0f8cd59dabb7 rootfstype=ext4 overlays=gpio-line-names usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u cat sun8i-h3-gpio-line-names.dts /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@1 { target = <&pio>; __overlay__ { gpio-line-names = "", "", "", "", "GPIOA4 DTX", "GPIOA5

@martinayotte do you have an example for /boot/armbianEnv.txt gpio-line-names? This is generated board specific, correct? How would I do it that way for Duo? I'll try my grep-fu and google-fu in the meantime. I assume you are talking about loading the overlay from armbianEnv.txt i.e. https://docs.armbian.com/User-Guide_Allwinner_overlays

@martinayotteI finally got my VM cranking and build pulled down. Looking around based on what you said wouldn't something duo specific be better off in something like ./patch/kernel/sunxi-dev/board-h2plus-nanopi-duo-add-device.patch? I still need to look at Makefile, but this should only impact Duo.

OK, let me try that. Working on a new build VM today.