JustMotion/src/main.cpp

202 lines
5.5 KiB
C++
Raw Normal View History

// This file is part of Motion Watch.
2022-04-14 09:45:54 -04:00
// Motion Watch is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
2022-04-14 09:45:54 -04:00
// Motion Watch is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
2022-04-14 09:45:54 -04:00
#include "mo_detect.h"
#include "logger.h"
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
#include "web.h"
void timer(shared_t *share)
{
while (share->retCode == 0)
{
sleep(1);
share->postInd += 1;
share->evInd += 1;
}
}
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
void detectMo(shared_t *share)
2022-04-14 09:45:54 -04:00
{
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
while (share->retCode == 0)
{
sleep(2);
detectMoInStream("stream.m3u8", share);
}
}
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
void eventLoop(shared_t *share)
{
while (share->retCode == 0)
{
if (!share->recList.empty())
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
{
auto event = share->recList[0];
try
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
{
recLog("attempting write out of event: " + event.evName, share);
createDirTree("events");
if (wrOutVod(event, share))
{
genHTMLvod(event.evName);
if (exists("events"))
{
imwrite(string("events/" + event.evName + ".jpg").c_str(), event.thumbnail);
}
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
}
}
catch (filesystem_error &ex)
{
recLog(string("err: ") + ex.what(), share);
}
share->recList.erase(share->recList.begin());
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
}
sleep(10);
}
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
}
void upkeep(shared_t *share)
{
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
while (share->retCode == 0)
{
createDirTree("live");
createDirTree("events");
createDirTree("logs");
enforceMaxLogSize(string("logs/") + REC_LOG_NAME, share);
enforceMaxLogSize(string("logs/") + DET_LOG_NAME, share);
enforceMaxLogSize(string("logs/") + UPK_LOG_NAME, share);
dumpLogs(string("logs/") + REC_LOG_NAME, share->recLog);
dumpLogs(string("logs/") + DET_LOG_NAME, share->detLog);
dumpLogs(string("logs/") + UPK_LOG_NAME, share->upkLog);
share->recLog.clear();
share->detLog.clear();
share->upkLog.clear();
initLogFrontPages(share);
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
enforceMaxEvents(share);
genHTMLul(".", share->camName, share);
upkLog("camera specific webroot page updated: " + share->outDir + "/index.html", share);
if (!exists("/tmp/mow-lock"))
{
system("touch /tmp/mow-lock");
genCSS(share);
genHTMLul(share->webRoot, string(APP_NAME) + " " + string(APP_VER), share);
remove("/tmp/mow-lock");
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
upkLog("webroot page updated: " + cleanDir(share->webRoot) + "/index.html", share);
}
else
{
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
upkLog("skipping update of the webroot page, it is busy.", share);
}
sleep(10);
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
}
}
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
void recLoop(shared_t *share)
{
while (share->retCode == 0)
{
if (exists("live"))
{
remove_all("live");
}
auto cmd = "ffmpeg -hide_banner -rtsp_transport tcp -timeout 3000000 -i " +
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
share->recordUrl +
" -strftime 1" +
" -strftime_mkdir 1" +
" -hls_segment_filename 'live/%Y-%j-%H-%M-%S.ts'" +
" -hls_flags delete_segments" +
" -y -vcodec copy" +
" -f hls -hls_time 2 -hls_list_size 1000" +
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
" stream.m3u8";
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
recLog("ffmpeg_run: " + cmd, share);
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
auto retCode = system(cmd.c_str());
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
recLog("ffmpeg_retcode: " + to_string(retCode), share);
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
if (retCode != 0)
{
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
recLog("err: ffmpeg returned non zero, indicating failure. please check stderr output.", share);
}
sleep(10);
}
}
int main(int argc, char** argv)
{
struct shared_t sharedRes;
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
sharedRes.conf = parseForParam("-c", argc, argv, false);
if (parseForParam("-h", argc, argv, true) == "true")
2022-04-14 09:45:54 -04:00
{
cout << "Motion Watch " << APP_VER << endl << endl;
cout << "Usage: mow <argument>" << endl << endl;
cout << "-h : display usage information about this application." << endl;
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
cout << "-c : path to the config file." << endl;
cout << "-v : display the current version." << endl << endl;
}
else if (parseForParam("-v", argc, argv, true) == "true")
{
cout << APP_VER << endl;
2022-04-14 09:45:54 -04:00
}
else if (sharedRes.conf.empty())
2022-04-14 09:45:54 -04:00
{
cerr << "err: no config file(s) were given in -c" << endl;
2022-04-14 09:45:54 -04:00
}
else
{
sharedRes.retCode = 0;
sharedRes.maxScore = 0;
sharedRes.postInd = 0;
sharedRes.evInd = 0;
sharedRes.skipCmd = false;
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
rdConf(&sharedRes);
auto thr1 = thread(recLoop, &sharedRes);
auto thr2 = thread(upkeep, &sharedRes);
auto thr3 = thread(detectMo, &sharedRes);
auto thr4 = thread(eventLoop, &sharedRes);
auto thr5 = thread(timer, &sharedRes);
v2.0.t1 Completely reformed the internal workings of the application code. I brought back multi-threaded functions so there is now 5 separate threads for different tasks. recLoop() - this function calls ffmpeg to begin recording footage from the defined camera and stores the footage in hls format. It is designed to keep running for as long as the application is running and if it does stop for whatever reason, it will attempt to auto re-start. upkeep() - this function does regular cleanup and enforcement of maxDays maxLogSize and maxEvents without the need to stop recording or detecting motion. detectMo() - this function reads directly from recLoop's hls output and list all footage that has motion in it. motion detection no longer has to wait for the clip to finish recording thanks to the use of .ts containers for the video clips. this makes the motion detection for less cpu intensive now that it will now operate at the camera's fps (slower). eventLoop() - this function reads the motion list from detectMo and copies the footage pointed out by the list to an events folder, also in hls format. schLoop() - this function runs an optional user defined external command every amount of seconds defined in sch_sec. this command temporary stops motion detection without actually terminating the thread. It will also not run the command at the scheduled time if motion was detected. Benefits to this reform: - far less cpu intensive operation - multi-threaded architecture for better asynchronous operation - it has support for live streaming now that hls is being used - a buff_dir is no longer necessary
2023-03-05 16:07:07 -05:00
thr1.join();
thr2.join();
thr3.join();
thr4.join();
thr5.join();
2022-04-14 09:45:54 -04:00
return sharedRes.retCode;
2022-04-14 09:45:54 -04:00
}
return EINVAL;
2022-04-14 09:45:54 -04:00
}