Jump to content
jeromephone

best way to setup motion recording

Recommended Posts

I am trying to reduce CPU load and am wondering what is the best way to set up IP cameras

 

Does it matter what the motion detection setting on the camera is (MFD-130) this is an all IP system.

 

I set the motion detection at the NVR but wondered if the camera is sending video all the time reguardless of what the motion detection settings on the camera are.

 

I am trying to reduce network traffic and CPU usage.

Share this post


Link to post
Share on other sites

The camera always sends video data regardless of whether or not motion is occurring or motion detection is set in the camera. The in-camera motion detection comes into play by setting a flag in the data stream saying MOTION IS HAPPENING. If the NVR can read that flag then it doesn't have to re-examine the stream to know that motion is happening. Then the NVR can either record the stream if isn't set to record everything or mark the sections of the video record that have motion if it is set to record everything all the time.

 

Some software will mark recorded chunks of video with motion flags in the timeline so you can tell that, say, there were three separate motion events in one chunk that got recorded for motion, rather than having to watch the whole thing for movement if it got started for a useless event like a cat running thirty seconds before a prowler is also recorded. You'd miss the prowler if you were just scanning the first few seconds of each clip.

 

I haven't played with the Geovision cams and IP software, but if the motion detection is set in the camera then hopefully the Geovision NVR software is smart enough to not reanalyze the stream. That and displaying the video is generally what takes the most CPU power, not saving the stream to disk regardless of whether there was motion or not. I'd expect network traffic from cam to switch to computer to stay relatively constant (depending on CBR vs VBR, etc) and not drop to zero even if there was little or no motion detected by the cameras. The cams should be sending data constantly but the decision of whether to analyze it for motion, record it, display it, or completely ignore it would be made in the NVR software.

 

For instance, Blue Iris always re-analyzes video data regardless of MD settings in the camera because it doesn't "listen" for the camera's decision that significant motion is happening. Network traffic from the cams to the NVR software (BI, GeoVision, or whatever) should be nearly constant so that even if neither camera nor software think that motion is happening the video can be displayed on a monitor anyway. Never say never, but I think that even most software with separate viewing and recording clients and no in-software motion detection (relies completely on the camera to make that decision) receives video data constantly even when the viewing client isn't running because the cam broadcasts the video data and motion-is-or-isn't-happening data flags concurrently. The cameras would have to receive a signal from the recording software to start sending video data after the camera sends a signal that motion is occurring for that kind of bandwidth saving to happen.

 

So, to answer your question, set motion detection up in the cameras. If the NVR software supports in-camera motion detection with those particular cameras then it shouldn't burn cpu cycles doing something that has already been done. I doubt there's anything you can do to save bandwidth besides changing compression, resolution, and bitrate settings, etc. Broadcasting from the cams through the network should be continuous.

Share this post


Link to post
Share on other sites

Motion detection on the cam is used for built-in IO/alerts/local SD card recording features, afaik the GV system always analyzes the video at the NVR, so setting up the on-cam motion detection is not going to save any cpu cycles.

 

For bandwidth:

 

-The new 'region-of-interest' feature in the latest 2.09 firmware allows you to set different quality levels for specific portions of the image. For example, a portion of a scene with 'wasted pixels', such as area above a doorway, or the sky outdoors, could be set to a low quality level to save bandwidth and disk space.

 

-the new firmware seems to have a more efficient H264 codec, noticed ~18mbps decrease at the NVR after upgrading a system with 28 cams(mostly 1.3MP) from 2.01 to 2.09.

 

-GV IP cams are set at 30fps by default, IMO 10-15fps is enough for most general indoor surveillance. Lower FPS will also help CPU usage.

 

 

For CPU usage:

 

-'GPU decoding' feature(Sandy Bridge or Ivy Bridge CPUs) considerably cuts down CPU usage, but its requirements are very specific- see User's Manual.

 

-NVR setting 'Live View Key Frame Only' saves a lot of CPU time, but be aware this also limits frame rate for Webcam/DMMultiview clients.

 

-Dual-streaming with 'On Demand Display' setting allows the NVR to use the lower resolution sub-stream for live view. Caveat with dual-streaming is it will increase your bandwidth usage if you are currently using only single-stream, but 'On Demand' does save a lot of CPU time.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×