Currently, any frame flagged as having motion by the driver will begin a motion event. The threshold required to trigger a flag is configurable, but this still results in a huge number of false positive motion events, often generated by very brief movement like noise or shadows. Most actual motion will be much more consistent, and last over a period longer than a single frame.
Implement a server-level threshold, where a motion event is started only after a number of frames have been flagged within a certain period. This number should be fairly low.
One suggested approach for the threshold is to trigger only when at least N% of frames in the past X seconds contain motion, where N is a low tunable value, and X is a short period of time (generally between .25 and 2 seconds?). A fraction of frames within period X should be used over a static count to avoid false negatives on low framerate devices.
Issue by curtishall Mon Aug 26 19:08:13 2013 Originally opened as https://github.com/bluecherrydvr/bluecherry-apps/issues/86
Currently, any frame flagged as having motion by the driver will begin a motion event. The threshold required to trigger a flag is configurable, but this still results in a huge number of false positive motion events, often generated by very brief movement like noise or shadows. Most actual motion will be much more consistent, and last over a period longer than a single frame.
Implement a server-level threshold, where a motion event is started only after a number of frames have been flagged within a certain period. This number should be fairly low.
One suggested approach for the threshold is to trigger only when at least N% of frames in the past X seconds contain motion, where N is a low tunable value, and X is a short period of time (generally between .25 and 2 seconds?). A fraction of frames within period X should be used over a static count to avoid false negatives on low framerate devices.
http://improve.bluecherrydvr.com/issues/955