Tips on Motion Detection


We just overhauled the motion detection engine in Cayuga; the results were promising (better than the older 4.2 recorders, and with new cameras and a good integrator, we can run a lot more cameras on the same box). I still believe that motion detection should be done on the edge. But for those who refuse, the new recorders are a lot better.

Motion Detection on the Edge

I think server side motion detection ought to be the last resort (I also think that the VMS should make the choice transparent, so that if a camera has decent motion detection the VMS will simply set up the camera to do it on the edge.)

If the VMS is not able to do this transparently, then most systems will allow you to set it up manually. Usually a royal pain in the ass, but c’est la vie.

Server side motion detection can be very taxing on the CPU. Obviously depending on the accuracy required, both in terms of the number of pixels processed, and how often the detection takes place. Generally, lowering the accuracy will also lower the strain on the CPU.

Motion detection on the edge incurs no additional CPU load – regardless of the accuracy. So if your system is running hot (due to motion detection), then consider moving the detection to the edge. Edge detection may offer more options, and perform better (or worse, so test before deployment), depending on the camera type.

If you are going to do server side motion detection, consider if the motion detection can happen on a secondary stream of lower resolution (and perhaps lower frame-rate too). This obviously requires more bandwidth on the network, but it might be worth the trade-off.

Be very careful when “overbooking” a server. You may often be able to fit more cameras on one server by recording only when there is motion. Since the disk IO can represent a bottleneck, the assumption is that not all cameras will have motion at the same time, and so if only 30% of the cameras are recorded at the same time, the disk IO may not represent a bottleneck. Unfortunately, a lot of motion detectors are susceptible triggering on account of noise in the image. At night, when the light is sparse, the camera increases the gain (unless this is turned off). This also increases the amount of noise, and often trigger the motion detector. This causes the camera to be recorded to disk. Since most cameras all experience the same loss of light at the same time, they all get recorded. And this triggering the disk IO bottleneck and wasting space on meaningless recordings. Consider if post-recording image processing can replace AGC, a very, very unscientific suggested that we might as well do the AGC on the client.

Click for Better Fidelity

If the motion detection is used for alerting, it may be difficult or even impossible to find the right parameters. If the setup is too sensitive, you will get too many false alarms. On the other hand, making the system too in-sensitive may cause you to loose the event (if you are using the same detection to trigger recording, you may lose the event completely!). A setup that was appropriate in the winter may not be appropriate in the summer where foliage, azimuth of the sun etc may influence your sensitivity or masking settings.

For real-time alerting, I would recommend a dedicated video analytics engine, preferably installed on the camera.

Off to work…

Author: prescienta

Prescientas ruler

5 thoughts on “Tips on Motion Detection”

  1. “The assumption is that not all cameras will have motion at the same time, and so if only 30% of the cameras are recorded at the same time…”
    That’s a risky assumption. In addition to nighttime noise, outdoor cameras share wind and weather motion. In a small shop, overlapping views and the post-roll record time can make one person trigger several cameras to be recording at the same time just by walking thru.

    But aren’t cameras setup with VMD typically setup with a pre-roll record of several seconds, which means recording all the time anyway though?

    Lastly, camera side VMD, and other analytics, have the ability to run pre-compression, possibly making them more accurate by reducing triggering due to artifacting. Or is that just sales talk?

    Great post, Thanks!

    1. Agree, a 30% load is simply an “IF” assumption. Missing recordings is not the issue with VMD, the problem is mostly system overload thanks to inaccurate detection and CPU stress — that’s the issue. Most VMS calculators hide the impact that live view and VMD has on the VMS server – so it’s left to the rest of us to work it out. It’s almost laughable in this day and age, to suggest lowering the VMD accuracy to prevent CPU overload. Server-side VMD is a “sticky tape and string” solution.

      1. I couldn’t agree more, but on the other hand, I constantly receive comments from the field, that it is too cumbersome to set up detection on the edge. I think the solution to THAT problem is to make it easier to set up detection on the edge, rather than trying to make the server side motion detection better/faster/more accurate.

  2. Doing the analytics on a raw frame before compression will most likely be better than after passing it though a compression algorithm. Another advantage is that the analytics result may actually affect the compression (e.g. if there’s no relevant info, then you might chose to compress the frame more than otherwise). So not (necessarily) just a sales pitch.

    Missing recordings is fortunately a rare occurrence. but it does happen, and it is tragic and annoying when it happens. Saturating the disk IO at night is not as bad, but the many false alarms generated may actually be the reason why a someone lowers the sensitivity beyond a reasonable level.

    Sometimes a “low tech” solution is worth considering. Cheap PIR sensors are pretty reliable, and work in total darkness. So why not have the PIR sensor turn on visible light, and trigger recording (if you insist on recording only “relevant” video).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s