Better motion detection?

Support and queries relating to all previous versions of ZoneMinder
overly
Posts: 36
Joined: Mon Aug 20, 2007 6:14 pm
Location: Cleveland, Ohio USA

Post by overly » Thu Jun 19, 2008 5:53 pm

overly wrote:mor,

I'm running your latest patch (motion-4) and was poking through the code with thoughts of tweaking the transparency. It was suggested at some point that a memory leak may exist and I think I may have found something.

In zm_image.cpp line 828 in Image::Blend() a debug image is created with:

Code: Select all

result = new Image( width, height, colours );
I don't see when the Image object is ever destroyed. Am I missing something or is this a potential leak?

-Ken
Nevermind - it deletes the Image object after writing out the jpeg.

Code: Select all

result->WriteJpeg(b);
delete result;
Bluecherry PV-149 4-port capture card
Topica TP-936WIR-30C camera
Cheap Harbor Freight camera
HP Athlon 64 X2 w/ 2GB
Slackware 13 - 2.6.29.6-smp kernel

mor
Posts: 45
Joined: Sat Apr 26, 2008 1:41 am

Post by mor » Thu Jun 19, 2008 10:11 pm

Entertainingly, I went through exactly the same thought process when I was searching for the leak.

Next up is to run valgrind over it.

overly
Posts: 36
Joined: Mon Aug 20, 2007 6:14 pm
Location: Cleveland, Ohio USA

Post by overly » Fri Jun 20, 2008 1:40 pm

mor,

Can you help explain what affect the settings have? I've been looking at the code but the math has been difficult to get my mind around. I guess I should have paid attention in Calculus all those years ago. Derivatives and such... yikes.

Specifically I'm looking at "Reference Image Blend" and "Transparency". If I understand correctly Reference Image Blend will dictate how quickly it learns where the noise and constant motion are, or how quickly it updates the noise mask. Larger values of RIB cause the mask image to be updated more quickly... is that correct?

I haven't been able to understand at all yet how Transparency affects the process. I'm guessing it determines how much detected motion is allowed to pass through the noise mask. Is that close at all?

Thanks for your contributions to Zoneminder.
Bluecherry PV-149 4-port capture card
Topica TP-936WIR-30C camera
Cheap Harbor Freight camera
HP Athlon 64 X2 w/ 2GB
Slackware 13 - 2.6.29.6-smp kernel

overly
Posts: 36
Joined: Mon Aug 20, 2007 6:14 pm
Location: Cleveland, Ohio USA

Post by overly » Fri Jun 20, 2008 7:56 pm

I have an idea that might help when tweaking zoneminder settings - with mor's motion patch, or otherwise.

Wouldn't it be useful to have the pixel_avg and some other info overlayed onto the image stream similar to the date/time stamp? That way when you're looking back through the capture events you can easily make judgement on how to adjust settings based what you see happening during the event. That way you can look at an event, recognize that it should or should not have triggered an event, and adjust settings accordingly to be more/less sensitive?

Perhaps a configuration option to turn it on and off?

I've looked at the code which annotates the image timestamp and it doesn't seem like it would be that hard add.
Bluecherry PV-149 4-port capture card
Topica TP-936WIR-30C camera
Cheap Harbor Freight camera
HP Athlon 64 X2 w/ 2GB
Slackware 13 - 2.6.29.6-smp kernel

jameswilson
Posts: 5109
Joined: Wed Jun 08, 2005 8:07 pm
Location: Midlands UK
Contact:

Post by jameswilson » Fri Jun 20, 2008 9:48 pm

I have mentioned before adding a live view of the analysed image, ie the red bits. That way you could easily see where the alarms were occuring.

But it seems its a nightmare to add.
James Wilson

Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk

mor
Posts: 45
Joined: Sat Apr 26, 2008 1:41 am

Post by mor » Sat Jun 21, 2008 9:35 pm

The big item on my list that looks like a fair amount of work, but a lot of value, is to just add training.

So you can go over past events and say 'false alarm', and it learns which ones are false alarms.

The key problem here is data reduction. It's impractical to try and train a bayesian network, or a neural network on the amount of data that an event generates (and it would be hideously fragile due to the undertraining), so it needs a model that reduces an event down to (say) about 10 - 25 variables.

Doing that while preserving enough signal that the network can actually learn which events are which is a fairly non-trivial problem. But an interesting one. :)

Too much to do, too little time.

My current list is order is something like:
1. Implement decimation. Carry only a 160x100 blended image which reduce the data enough that it's practical to do some more expensive maths.

2. Implement a median filter now that there's a small enough amount of data.

3. Re-structure the motion detection so that it's a plugin that receives a split of the motion stream, that it then labels behind the fact. (i.e. the plugin effectively see now +/- 15 frames or similar). This will hopefully be a relatively general architecture for other plugins.

4. Preserve the original data stream. This one is a big change. Right now , zoneminder takes JPEGs from my cameras, uncompresses them, throws them around in memory among 3 processes and then re-compresses them again. This is costly in terms of CPU and memory. I'd like to have zoneminder simply store the original JPEGs in a ring buffer, and then drop them out to disk without decompressing and recompressing when an event occurs.

This would drastically reduce memory usage, and slightly reduce CPU.

5. Valgrind. There's a memory leak in zma somewhere that I can't pin down. I'm fairly sure that my code didn't add it, it's just triggering it.

6. Use the plugin architecture to do a trainable network to further suppress false alarms.

7. Add mpeg-4 support. I've an mpeg-4 camera that I currently convert to MJPEG, but the mpeg-4 is lighter. And my future cameras are likely to be AVCHD which is even worse to deal with.

This will almost certainly require adding the ffmeg libraries. Which are horrible to deal with, so it would almost certainly take just adding the source for ffmpeg to zoneminder (which everyone else seems to do!). But it would instantly make zoneminder much more capable about dealing with video sources.

Anyway: That's my todo list. Brave ambition considering the paltry patch I've currently done. :)

(added to http://www.dgmo.org/zoneminderpatches so I can remember to keep track of it).

mor
Posts: 45
Joined: Sat Apr 26, 2008 1:41 am

Post by mor » Sat Jun 21, 2008 9:51 pm

PS: It would be helpful is people could mention what most of their false alarms come from?

My top sources are cameras changing light levels, overcast changing to/from sunlight, and large moving shadows (in that order).

My patch takes care of about 70% of the type events, but can't do 100% without damaging the sensitivity too much.

martymoose
Posts: 128
Joined: Tue Jul 12, 2005 9:59 am
Location: australia

Post by martymoose » Sun Jun 22, 2008 9:57 pm

MOR
i am just siting on the fence watch
i am a it of a newbie at present

all i can say is keep up the good work this looks very very good
the next thing would be a coder with flair to modernize the front page

the project is just getting better and better
I donated have YOU?

mor
Posts: 45
Joined: Sat Apr 26, 2008 1:41 am

Further reduce CPU utilization.

Post by mor » Mon Jun 23, 2008 7:14 am

In the usual place at http://www.dgmo.org/zoneminderpatches is patch #6. This implements decimation. The motion detection now runs using a 1/4 size image (1/2 the width, 1/2 the height).

With this patch, zma is now using less CPU than zmc, and I'm processing 45 fps on a 1.6GHz CPU @ ~ 75% CPU.

NOTE: I broke zones. Sorry. I'll fix it the next patch. The default 'All' zone works, but if you've setup a custom zone it won't work as the co-ordinate scale is wrong. I'm still undecided as to the optimal method to fix this.

timcraig
Posts: 195
Joined: Mon Dec 10, 2007 5:53 pm
Location: San Jose, CA
Contact:

Post by timcraig » Wed Jun 25, 2008 12:31 am

I installed patch-5 last Sunday night.

The performance of the new patch has been greatly improved compared to the previous patch I tried. I'm no longer have performance problems on my system:
- Pentium 4 2.8 Ghz
- 3 gigs of RAM
- PV155 with 8 analog cameras (7 running in modect/mocord mode at a combined fps of ~ 115 fps, 1 running in monitor mode)

The load is just about the same as a non-patched ZM 1.23.3. The CPU usage would average about 45%-55% on a non-patched ZM 1.23.3. With the patch the CPU usage would average 75%-95%. (Max CPU is 200% since the P4 has a hyper-thread that shows up as a 2nd processor).

The initial training of the cameras are much faster now too. The monitors start calming down and left alarm the constant state within seconds or 1 or 2 minutes.

I have 5 cameras that have trees, shadows and bushes that move on windy days. The patch has worked really well on one camera where some bushes were far away. The other 4 cameras have still get a lot of false alarms from bushes, trees and shadows. It looks like the number of false alarms has dropped a bit and the false alarm length is reduced. I used reference blend % 14 over Sunday night to Monday night, then I switched to %10 reference this morning to see if that helped. I'll try to post screen shots this and youtube videos of false alarms this weekend.

A big improvement I noticed was on a camera at my driveway. There is a big palm tree next door and it casts a shadow on my driveway. On a bright, windy day that shadow will move like crazy. Without the patch I would get events up to two hours long if I used modect. With the patch I will get false alarms all the time from the shadow, but never any longer than 2 minutes.

One thing I noticed is that capture card artifacts causes false alarms more often than an unpatched system. Sometimes I get a couple of black lines in the camera capture image (seems to be a heat issue as it is more prevalent when my ZM box is warmer). These would hardly ever set off a false alarm on a unpatched ZM (probably got ignored because of the "Filter Width/Height" setting), but with the patch the seem to set it off false alarms all the time.

I really like the patch, you've done a great job. Some "nice to haves" would be:
- some sort of motion highlighting like the old blob system
- motion scoring like before.

I think one of ZM's strongest features is the timeline screen. Motion highlighting and the motion scoring (even though it was far from perfect) really helps the timeline. When away from home (and on a limited bandwidth connection to my ZM box) the blobs really helped me see where the motion is occurring and in what direction people/car are going. The motion score was also very helpful. For example, I have a camera outside my front door looking at my doorstep area. I leave food out for stray cats and the cats tend to hang around the door alot when no one's home. So they set off alot of events that have max scores between 15-30. When people come up to my door they cause events with max scores between 65-100. So when the motion scoring, I can look at the day's events and can tell which event were probably person that went up to my door and which events were just the stray cats hanging around.

timcraig
Posts: 195
Joined: Mon Dec 10, 2007 5:53 pm
Location: San Jose, CA
Contact:

Post by timcraig » Sun Jun 29, 2008 5:50 am

Here is a link to a false alarm event.
http://www.youtube.com/watch?v=hk8g5m71KCk

The rose bushes trigger a lot of false alarms. The motion detection never seems to get trained to ignore the motion. I have the area around the roses in a zone with settings close to the "Best- low sensitivity" preset. They wouldn't set of the motion detection then but now with the patch they set it off all the time. A bed room window is behind the roses, so the pre-patch motion detection was ideal as it ignored the roses but would pick up a person getting up close to the windows.

I had another monitor that had problems where a bush would cause false alarms all the time but the problem seemed to have gone away when I have the zone cover the entire bush.

I have a problem with shadows of trees and bushes still. I think it's because the shadows are always moving based on movement of the sun. Shadows move to untrained parts of the zone and set off a false alarm. But it's still much better than before as they are only short false alarms opposed to long running ones.

Overall the patch has definitely cut down on false alarms. I'm able to store about 1 more day of video than I could before the patch (My recording monitors run modect at day time and mocord at night)

SyRenity
Posts: 301
Joined: Mon Jan 24, 2005 2:43 pm

Post by SyRenity » Thu Jul 03, 2008 9:36 am

Hi.

I have a performance question:

If "With this patch, zma is now using less CPU than zmc, and I'm processing 45 fps on a 1.6GHz CPU @ ~ 75% CPU. ", meaning analysis now actually takes less CPU then capturing.

How it's possible that Tim still gets these results? "The load is just about the same as a non-patched ZM 1.23.3. The CPU usage would average about 45%-55% on a non-patched ZM 1.23.3. With the patch the CPU usage would average 75%-95%. (Max CPU is 200% since the P4 has a hyper-thread that shows up as a 2nd processor). "

It seems that patch still brings a good overhead of 30%-40%, any idea why?

(For the record, I didn't try the patch myself yet and didn't measure it, and interested to learn from others experience).

Regards.

timcraig
Posts: 195
Joined: Mon Dec 10, 2007 5:53 pm
Location: San Jose, CA
Contact:

Post by timcraig » Fri Jul 04, 2008 12:34 am

SyRenity,

There are a number of possibilities.

If I recall correctly, mor has 3-4 cameras, I have 7. I also have 2 to 3 zones per camera (a total of 15). Even though mor is recording at more total fps than I am, the more number of cameras and zones I have could play an effect on performance.

Also CPU MHz isn't a good performance indicator. From the time of the Pentium3 to the Intel Core Duo/Core Solo, AMD processors had superior performance to Intel's in most areas despite generally having much lower clock speeds. mor's CPU can be closer on par to my Pentium4 despite my CPU's faster clock cycles.

Another possibility is there is a difference in configuration/installation setup in our ZM boxes that is playing a role on performance.

One thing I should try is disabling hyperthreading. They've found they hyperthreading recked havok on server performance as it caused a lot of cache hits. I thought hyperthreading might help ZM performance as there are plenty of side filter jobs running in the background so I had in on when I installed ZM. My zm box is in my closet and doesn't have a keyboard and monitor attached to it. I've been too lazy to drag it out of the closet and connect it to a monitor and keyboard to turn off hyperthreading in the bios.

michl080
Posts: 5
Joined: Mon Jul 14, 2008 8:25 pm
Location: Germany

Re: Further reduce CPU utilization.

Post by michl080 » Mon Jul 14, 2008 8:32 pm

> In the usual place at http://www.dgmo.org/zoneminderpatches is patch #6.

I installed patch 6 and it compiles nicely, however zma crashes with this error log:
  • Jul 14 22:16:25 zw zma_m1[18489]: INF [Average 36.452286, pixels 3676 (-4, -3, -1)]
    Jul 14 22:16:25 zw zma_m1[18489]: INF [videozoom: 337 - Gone into prealarm state]
    Jul 14 22:16:25 zw zma_m1[18489]: FAT [Attempt to overlay different sized images, expected 640x480, got 320x240]
    Jul 14 22:16:25 zw zma_m1[18489]: ERR [Got signal (Aborted), crashing]
    Jul 14 22:16:25 zw zma_m1[18489]: ERR [Signal address is (nil), from 0x110416#012]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: [0x110416]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: [0x110416]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: /lib/libc.so.6(gsignal+0x50) [0xb10660]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: /lib/libc.so.6(abort+0x188) [0xb12028]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: /usr/local/bin/zma [0x806f365]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: /usr/local/bin/zma [0x804f69e]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: /usr/local/bin/zma [0x8068d26]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: /usr/local/bin/zma [0x804a799]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: /lib/libc.so.6(__libc_start_main+0xe6) [0xafc5d6]]
    Jul 14 22:16:26 zw zma_m1[18489]: ERR [Backtrace: /usr/local/bin/zma(__gxx_personality_v0+0x20d) [0x804a401]]
    Jul 14 22:16:26 zw zma_m1[18489]: INF [Backtrace complete]
    Jul 14 22:16:26 zw zmdc[18422]: ERR ['zma -m 1' exited abnormally, exit status 6]
    Jul 14 22:16:36 zw zmdc[18422]: INF [Starting pending process, zma -m 1]
    Jul 14 22:16:36 zw zmdc[18856]: INF ['zma -m 1' started at 08/07/14 22:16:36]
    Jul 14 22:16:36 zw zmdc[18422]: INF ['zma -m 1' starting at 08/07/14 22:16:36, pid = 18856]
obviously, zma complains about the reduced image size. Any ideas?

btw., patch5 was running nicely for some time

shell-tunes
Posts: 3
Joined: Fri Jun 29, 2007 2:15 pm

Post by shell-tunes » Thu Jul 17, 2008 2:37 pm

sry i dont understand how to apply a patch
i tried
cd /usr/src/ZoneMinder-1.23.3/src/
wget http://www.dgmo.org/zoneminder-1.23.3-motion-6.patch
http://www.dgmo.org/zoneminder-1.23.3-motion-6.patch
patch -p1 < zoneminder-1.23.3-motion-6.patch

and now ?

Code: Select all

can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -u -r orig/configure working/configure
|--- orig/configure     2008-03-14 00:42:47.000000000 +1100
|+++ working/configure  2008-06-07 12:28:36.000000000 +1000
--------------------------
File to patch:
??? pls help me :-)

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests