Stop recording causing change in brightness, triggering false motion detection

[a-l-e-x-d-s-9]

In internal motion detection (not tested on external) mode, when the camera stop recording, there is a change in brightness of whole picture, looks like some automatic adjustment, that causing the software to detect huge jump in changes, and trigger another motion detection. It create a constant loop of detection of movement and video recording, and so forth, although nothing is really moving. If I set "Change Frames to start" to 5+ it usually smoother this odd brightness adjustment interference, but I'd like to use more fine motions detection trigger. Changing "Exposure Mode" and "White Balance" from auto to certain type, didn't really do anything. The motion change detected due to this brightness oddity, is usually counted in many thousands and spread over 4~ frames. It usually happens in the transition hours, in mornings and evenings. I see this behaviour both on Wheezy and Jessie, and SW v6.0.9 through v6.0.19.

[roberttidey]

I haven't seen that myself and I use internal motion detection all the time. It might be related to specific camera settings as some of these take a few frames to settle down. Also morning and evening will be trickier periods as compensation could produce more dramatic shifts during stops and starts. What Noise level settings are you using? I recommend using the 2nd algorithm technique where Noise is set to 1000 plus which then introduces a rolling average filter into the detection pipeline.

I'll also look at having a hold-off setting in the motion detection so that a new trigger can't occur until after a few frames of a stop. This would give it an extra time to settle down, although at the expense of picking up a new trigger very quickly. Normally the still frames to stop setting is effective in combining close motion events into a single recording.

[a-l-e-x-d-s-9]

@roberttidey I made a few measurements. My Motion Settings are: In the Camera Settings I have changed annotation ( to see motion change and idle frames): %Y.%M.%D %h:%m:%s %c %f Also Rotation set to 180 degrees. The rest of the settings are set to default values (Exposure Mode/White Balance = Auto, I tried to change it, but it hasn't influenced this problem).

Here is a screen capture of the preview video, that I made, just so you can see that the brightness of the picture actually changes, although there is no change in lighting or any motion, in the real world: https://www.youtube.com/watch?v=rt7T2fsqBHM

I looked at motion change values (with annotation %c), frame by frame, at couple of typical videos produced that way, from the beginning of the video: Video 1: 2, 2, 2, 2, 2, 2, 574, 107, 13, 0, ... stable around 0 ... Video 2: 4, 4, 4, 4, 4, 4, 679, 74, 13, 2, 0, ... stable around 0 ...

From what I see this problem can be initiated by certain real change in lighting, that triggers motion detection and video recording. Then when video recording stops, it just remembers that it was brighter sometime back, changing the brightness of the picture, and triggering false motion detection cycle, each time.

If I set the "Change Frames to start" to 4, it prevents motion detection in this case. But it makes the whole motion detection process too rough for my purposes, pretty sure that other people would like to use more fine detection too.

Regarding the 2nd algorithm technique, I tried to use it before, with noise set to: 1002, 1004, 1010, and threshold set to: 8, 10, 12. But even if I'm jumping just in front to the camera, it doesn't detect any motion. I see motion change value at 0, and no video recorded. Tested with the latest software and a few versions back. But it's probably another unrelated issue.

I can reproduce this problem on 3 independent Raspberry Pi 2, with various software versions: v6.0.9-v6.0.19, running on Wheezy and Jessie. Actually on all of my regular cameras, haven't noticed the problem with infrared cameras.