major changes to the motion detection scheme and re-introduced
multi-threading. this further sped up the motion detection to a point
that it can now be called in line with the recording loop without
loosing any extra camera footage due to heavy cpu usage.
pixels are now read in blocks to further increase efficiency and to
filter out movements of small objects. the footage clip size is now
hard coded to 3 seconds instead of it being external adjustable.
changed the way footage with motion is now stored. its now down to
single level files with the current date. if footage of the same date
already exists, new footage will be appended to it.
the version number shall be updated going forward.
removed all threads from the application as there is no used for them at
at this time. instead, the application will now operate on a single
event loop and now directly utilize use ffmpeg to record video footage
instead of opencv's implementation.
old code pulled tons of frames the detection stream at full speed,
wasting a lot of cpu cycles. instead it will now pull frames in a steady
speed at the new detect_fps value. doing this significantly reduced cpu
usage and can potentially further reduce cpu usage for end users by
pulling the fps value lower then the default.
The app will now count the amount of secs to record post motion
detection instead of the amount of frames. Split the main loop timer
with the motion timer in separate threads to make that happen. The
parameter was added to the config file.
Recording fps is now adjustable.
decided to change frame comparison functions again from optical flow to
a home brewed function that compares gray levels in the pixels of each
frame. significant differences in gray levels between the frames can
potentially trigger a motion event.
also moved away command line arguments to an external config file to set
app parameters.
created a README file to get this project ready for general open source
release.
all current experimentation with the code leads up to this point
for optical flow motion detection. the code as it stands will
input frames in pairs and then compare each pair of frames for
any significant changes in the optical flow distance between
points.
experiments have shown that this actual does work fairly well;
however there is significant amounts of CPU usage and video
encoding options are not flexible at all. the code still picks
up false positives but I have high confidence something that
can be adjusted through external parameters which I will
impliment in the future.
