ZoneMinder Forums

I merged the latest changes to the fork's master branch just this morning. Hopefully there will be no issues. The mmal decoder is now native and does not need ffmpeg's h264_mmal decoder. In the future, if ZM starts supporting RGB565, the shared memory requirements per pixel data would save 8 bits ...

Here is a howto for building this. It's an earlier version of the fork which does not use mmal component connections. I thought I'd work on a simpler version. Before you invest time or effort or hardware in this, understand that it may not work. Do so at your own risk. :) 1. Install Raspbian Lite ...

Drats. Thats not it. So I disabled the use of vc.ril.isp for now and restored the use of swscale for hardware side. Motion detection does work for both software and hardware decode. The dowscale part before the hardware encoder works, as well as the use of the Options field in the Source tab for the ...

I think that is it. I'll see if I can get it to work with holding directbuffer but zeroing it out with memset. Finally, it is becoming more useable and practical.

Chris

Fingers crossed but I think I may have found the reason for frame sequence being messed up. I looked at an event that triggered this morning and it had frames from an event last night. I think maybe its due to the directbuffer being held. I set that to false and in the events that I checked so far ...

I deleted motion_vectors_pipeline but created motion_vectors_connect. That motion_vectors_connect branch uses mmal connections between components instead of two separate pipelines like in motion_vectors. The last update on motion_vectors was heavily commented for reference. motion_vectors_connect is ...

I'll probably take a break for a few weeks. A lot of the work is already in the motion_vectors branch. It's not clean yet. But its got basic functionality. I suggest that you guys look at the code first and see if there is anything worth merging. I could always be "persuaded" to continue but I can't ...

This is my first time working on an open source project and first time using github and truthfully, I did not check the docs for code structure requirements. And I did make significant changes in a lot of the source code. Hopefully it is not too big of a mess to sort out. At least the mechanics ...

I think the alignment trap errors are gone. I've made progress with hardware swscale replacement. The mmal splitter component can do format conversions so I am using that to convert to RGBA, RGB24, YUV420 (grayscale obtained by getting only the luma). The mmal resizer component only supports RGBA ...

I think I discovered the bug. The mvect_buffer that is used to store the motion_vector data is being destroyed when a monitor is killed when the image_buffer array is deleted as a normal step in the termination of a monitor ( when manual shutdown or restart is done in systemctl or if the zone minder ...

I have some monitors capturing and analysing at 25 frames/sec while others at 14 frames/sec. Same camera types with fps set at 25/sec in the camera. Is the framerate derived from system load, that is, if things take longer to complete, then zoneminder reduces the capture and analyse rate? Thanks ...

I thought I fixed the alignment trap issue but I am not sure now if it even is related to the motion vector code. I have put in the latest changes that use memcpy instead of pointers for serial access to the uint8_t buffer in zm_ffmpeg_camera.cpp and zm_zone.cpp. The alignment trap is only triggered ...

10 hours running without triggering the alignment trap. I think maybe that it is gone (fingers crossed). I will pull the changes back to the motion_vectors branch. Will be working on reducing the memory requirements of hardware decode since it really needs a smaller buffer than software decode. All ...

I am running into the alignment trap maybe once every few hours in dmesg. Do you have time to look at the code to see where it might be coming from? I am trying to read up on this. I created a branch align_fix to test whether I could just save things byte by byte instead of using the motion_vector ...

Actually decoding 6 streams now in hardware at 640x360 each. I had to reduce the size of the motion_vector struct to 2 bytes. It can be modified in the future to add magnitude in x and y. For now, I just want to see what the hardware can do. The bottleneck now is the cumulative CPU utilization. I am ...