LuxRiot Blog

Video motion detection is an important video surveillance feature and is a key factor for cost-effective footage storage and archive navigation. However in order to be able to effectively take advantage of the feature, it is quite necessary to have a brief understanding of the underlying technology.

False Alarms and Lost Events

Unless implemented otherwise in hardware, video motion detection is an analysis of consequently captured video frames and comparison in order to detect mismatching areas. As a video processing algorithm, it has its accuracy and possible errors of two types: false alarm and lost event. More accurate detection is typically expected to have smaller rate for both types, however the cost of error may be different, and so are the reasons that may cause the errors.

Both types of errors have negative impact on the overall motion based surveillance, including live observation and monitoring, and effective storage and archive navigation. False alarms leads to recording of useless footage, jamming archive with useless events so that proper events become difficult to find and locate. In an environment with ring buffer recording false alarms directly affect length of video archive forcing footage to be deleted for new [false] recordings which would not be recorded if motion detection accuracy was higher. Lost even type of detection error leads to loss of footage for a scene of interest at all.

False alarms are typically caused by video feed changes that are technically changes (that is, for example, pixel brightness level changes) but human observer does not percept them as such because being able to interpret the scene he is ignoring the changes as unimportant, or even does not register as changes at all. These picture changes might include:

• image capture and/or compression noise and artifacts
• view-wide brightness and contrast changes, e.g. due to automatic white balancing (AWB) camera feature
• effects caused by nature, such as for example by wind, snow or rain
• light reflections
• very small movements in amount (area) or speed
• video interlacing artifacts

To address mentioned conditions and avoid false alarms, motion detection algorithms typically implement certain techniques and provide user configurable settings which may include:

• automatic brightness and contrast adjustment/correction
• motion detector sensitivity or another measure and threshold of motion amount to ignore small and believed to be irrelevant changes in view
• image masking to exclude unwanted regions from motion analysis
• special handling for entire view change scenarios such as camera PTZ moves

However the measures addressed to decrease false alarm error rate level may appear to be the cause of lost event error and effective of a motion detector is a trade-off between the two. The most widespread configurable setting (in many cases it is the only available setting) that enables an ability to adjust the detector is sensitivity. A more sensitive detector would register more motion, it would give more false alarms and less lost events. A less sensitive detector would register fewer events and lose more events, but the ones registered would most probably be real events, not false alarms.

Motion Detection and Video Compression

Motion detection analysis as a video processing step goes side by side with video compression and depending on choice of hardware, software and configuration settings can take place before or after video compression. Ideally, motion detection video processing should take place on uncompressed original data at video capture site because video compression (unless lossless) inevitably modifies video data in a way that worsens detection accuracy. Moreover, the higher the compression level is, the more is the effect of video compression on detection accuracy down to completely useless with tight compression levels.

Wherever possible it is advised to take advantage of “before compression” motion detection. This assumes the video capture source, frame grabber video capture board, or a network camera or video server, is capable of detecting motion and making motion detection result available to the interested application. Apart from detection accuracy, this also unloads central DVR software and allows to use CPU resources for other tasks, which becomes extremely important when a DVR manages tens of cameras. Motion detection algorithms are relatively fast but in case of network cameras DVR software would also have to decompress data to perform detection analysis and the more sophisticated the compression algorithm is (JPEG, MPEG-4, H.264) the more computationally intensive the motion detection is as a whole.

In many scenarios the desired “before compression” method is not available, which may because of including:

• video capture source is not capable of detecting motion
• video capture source is not capable of sharing motion detection information with a controlling DVR software
• DVR software is unable to utilize video capture source’s motion detection information (there is no well known and widely accepted standard on sharing motion detection data)
• video capture source’s motion detection is not sufficiently flexible in setup or unsatisfactory in accuracy

Reliable Motion Based Surveillance with LuxRiot DVR

A proper design of a motion based surveillance and recording system should start from proper choice of hardware and camera positioning to avoid capturing video with high false alarm factors in the view. It is important to realize that software will be unlikely to accurately compensate a severe mistake in layout and hardware model in first place and motion detection has to be kept in mind from the very start.

Motion detection implemented in hardware and compatible with DVR software should be preferred to DVR software motion detection unless the number of motion-enabled cameras is relatively small (including resolutions are not high) and DVR is capable of performing detection in software without maxing CPU consumption to maximum level and lowering effective capture frame rates.

If motion detection takes place after video compression, it is important to pay attention to compression level/quality settings configured at levels providing maximal acceptable image quality. JPEG or M-JPEG compression codec should be preferred if DVR software has to decompress video in order to detect motion. If CPU consumption is still an issue it is possible to decrease motion detection frequency from default 5 frames/cycles per second to 2-3 in software motion detection properties. Further decrease in motion detection frequency will significantly affect detection accuracy.

Software motion detection sensitivity is adjustable per camera and it is advised to review the setting to achieve best detection accuracy.

Motion controlled recording settings offer options to record on motion, record at full rate within a certain period of time after motion alarm, record at lower frame rate on absence of motion. The recording settings should be carefully considered against desired usage scenario and it is advised that both post-motion recording and recording without motion are enabled because of the following reasons. Recording motion only frames may result in situation when video frames recorded during shot motion interval are blurred, too dark or too light or captured an unfortunate moment of the scene. Recording a few extra video frames has barely noticeable impact on storage costs however provides additional information on motion alarm event and smooth video at the time of event. Very often this is useful and helpful during investigation of the recorded scene. Recording at low frame rate in absence of motion addresses lost event conditions. In case detection sensitivity is too low or another unexpected condition that resulted in absence of alarm from motion detection sensor, low frame rate recording still provides minimal footage for possible investigation and avoids situations when unmanaged DVR running withut human interaction is recording no footage at all because of an unanticipated problem with motion detection settings.