Decided to switch using opencv's builtin pixel diff motion detection via
absdiff and thresh. Doing this should increase efficiency instead of
using the home brewed pixel loops and threads.
Added a web interface of sorts by having html files output along with
the video clips. These files are designed to link together with the
assumption that the output directory is a web root like /var/www/html
that apache2 uses. The interface is crude at best but at least allow
playback of recorded footage.
Added max_clips config variable that can limit the amount of motion
events that can recorded to storage on a single day.
AI object detection via yolov5 didn't work out too well, in fact it was
crashing the detection threads for whatever reason. I could deep dive
why it was crashing but I think the better solution is to bring back
optical flow detection at the block level. the advantage of this over
object detection is the fact that a block doesn't need to have a whole
object in it.
re-formed the stats output and moved it out of the motion detect
function.
block pixel diff counts will now no longer stop at the threshold at each
block. it will now count the entire block and output the results in the
stats. the code now also pick the block with the highest pixDiff instead
of stopping at the first block with a high pixDiff.
added object detection code base on yolov5 machine vision model. also
added a stat file so motion and object detection values can be monitored
in real time if used with the 'watch' command.
Added a -v command line option to display the application's current
version.
The application version is now defined in a single a const value called
APP_VER so bumping the version number now means updating this single
value in common.h.
Versioning scheme will now be major.minor.[test_rev]. test_rev will be
t1, 2, 3, etc... as updates are pushed to the test branch. all code
pushes to master shall bump major or minor and then remove test_rev.
Removed the detect loop's motion latching affect so it ONLY calls wrOut
if the video clip contains motion.
Fixed a bug in the recording loop that fail to create the needed sub-dir
before calling FFMPEG.
Broken down the code into multiple files instead having it all in
main.cpp.
Also detached recording from detection by having them now run in
separate threads instead of having motion detection inline with
recording. this will hopefully make it so there is less missed motion
events due to processing overhead.
The recording loop now take advantage of FFMPEG's "-f segment" option
instead of generating the clips implicitly in separated FFMPEG calls.
again, all in hope to reduce missed motion events.
This application have the tendency to detect motion of small insects.
to prevent this it was determined with there will need to be some means
of identifying objects via machine vision. there is an object detection
function but it doesn't currently do anything at this time. this is
something that I will be working on in the near future.
created a test branch in the repository. all early, testing code will
now go in this branch going forward. only fully tested, stable code will
be committed to master going forward.
Video clips recorded from the camera are no longer append, instead the
clips are kept as is and then linked together in a playlist file in the
output_dir. this makes it much more efficient and easier to maintain
code.
Also discovered that ffmpeg have a tendency to stall mid execution of
recording from the rtsp stream every now and then. added a work around
in the form of calling ffmpeg via the timeout command instead of
directly so it will force kill ffmpeg if it goes longer than the
expected BUF_SZ.
Increased BUF_SZ to 10 secs.
Added a clause in the recording loop that will make it write out a
second clip if motion was detected.
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.
