JustMotion/src/common.cpp

359 lines
8.2 KiB
C++
Raw Normal View History

// This file is part of Motion Watch.
// 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.
// 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.
#include "common.h"
string cleanDir(const string &path)
{
if (path[path.size() - 1] == '/')
{
return path.substr(0, path.size() - 1);
}
else
{
return path;
}
}
bool createDir(const string &dir)
{
auto ret = mkdir(dir.c_str(), 0777);
if (ret == -1)
{
return errno == EEXIST;
}
else
{
return true;
}
}
bool createDirTree(const string &full_path)
{
size_t pos = 0;
auto ret = true;
while (ret == true && pos != string::npos)
{
pos = full_path.find('/', pos + 1);
ret = createDir(full_path.substr(0, pos));
}
return ret;
}
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 cleanupEmptyDirs(const string &path)
{
if (exists(path))
{
for (auto &entry : directory_iterator(path))
{
if (entry.is_directory())
{
try
{
remove(entry.path());
}
catch (filesystem_error const &ex)
{
// non-empty dir assumed when filesystem_error is raised.
cleanupEmptyDirs(path + "/" + entry.path().filename().string());
}
}
}
}
}
vector<string> lsFilesInDir(const string &path, const string &ext)
{
vector<string> names;
if (exists(path))
{
for (auto &entry : directory_iterator(path))
{
if (entry.is_regular_file())
{
auto name = entry.path().filename().string();
if (ext.empty() || name.ends_with(ext))
{
names.push_back(name);
}
}
}
}
sort(names.begin(), names.end());
return names;
}
vector<string> lsDirsInDir(const string &path)
{
vector<string> names;
if (exists(path))
{
for (auto &entry : directory_iterator(path))
{
if (entry.is_directory())
{
names.push_back(entry.path().filename().string());
}
}
}
sort(names.begin(), names.end());
return names;
}
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 cleanupStream(const string &plsPath)
{
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
ifstream fileIn(plsPath);
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
for (string line; getline(fileIn, line); )
{
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 (line.starts_with("VIDEO_TS/"))
{
remove(line);
}
}
}
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 enforceMaxEvents(shared_t *share)
{
auto names = lsFilesInDir(".", ".mp4");
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 (names.size() > share->maxEvents)
{
// removes the playlist file extension.
auto nameOnly = names[0].substr(0, names[0].size() - 4);
auto imgFile = nameOnly + ".jpg";
auto webFile = nameOnly + ".html";
if (exists(names[0])) remove(names[0]);
if (exists(imgFile)) remove(imgFile);
if (exists(webFile)) remove(webFile);
names.erase(names.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
string genTimeStr(const char *fmt)
{
time_t rawtime;
time(&rawtime);
auto timeinfo = localtime(&rawtime);
char ret[50];
strftime(ret, 50, fmt, timeinfo);
return string(ret);
}
string genDstFile(const string &dirOut, const char *fmt, const string &ext)
{
createDirTree(cleanDir(dirOut));
return cleanDir(dirOut) + string("/") + genTimeStr(fmt) + ext;
}
void rdLine(const string &param, const string &line, string *value)
{
if (line.rfind(param.c_str(), 0) == 0)
{
*value = line.substr(param.size());
}
}
void rdLine(const string &param, const string &line, int *value)
{
if (line.rfind(param.c_str(), 0) == 0)
{
*value = strtol(line.substr(param.size()).c_str(), NULL, 10);
}
}
bool rdConf(const string &filePath, shared_t *share)
{
ifstream varFile(filePath.c_str());
if (!varFile.is_open())
{
share->retCode = ENOENT;
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
cerr << "err: config file: " << filePath << " does not exists or lack read permissions." << endl;
}
else
{
string line;
do
{
getline(varFile, line);
if (line.rfind("#", 0) != 0)
{
rdLine("cam_name = ", line, &share->camName);
rdLine("recording_stream = ", line, &share->recordUrl);
rdLine("web_root = ", line, &share->webRoot);
rdLine("web_text = ", line, &share->webTxt);
rdLine("web_bg = ", line, &share->webBg);
rdLine("web_font = ", line, &share->webFont);
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
rdLine("sch_sec = ", line, &share->schSec);
rdLine("post_cmd = ", line, &share->postCmd);
rdLine("pix_thresh = ", line, &share->pixThresh);
rdLine("img_thresh = ", line, &share->imgThresh);
rdLine("max_days = ", line, &share->maxDays);
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
rdLine("max_events = ", line, &share->maxEvents);
rdLine("max_log_size = ", line, &share->maxLogSize);
}
} while(!line.empty());
}
return share->retCode == 0;
}
bool rdConf(shared_t *share)
{
share->recordUrl.clear();
share->postCmd.clear();
share->camName.clear();
share->retCode = 0;
share->pixThresh = 50;
share->imgThresh = 800;
share->maxDays = 15;
share->maxEvents = 40;
share->maxLogSize = 50000;
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->skipCmd = false;
share->schSec = 60;
share->webRoot = "/var/www/html";
share->webBg = "#485564";
share->webTxt = "#dee5ee";
share->webFont = "courier";
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 (rdConf(share->conf, share))
{
if (share->camName.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
share->camName = path(share->conf).filename();
}
share->outDir = cleanDir(share->webRoot) + "/" + share->camName;
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
error_code ec;
createDirTree(share->outDir);
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
current_path(share->outDir, ec);
share->retCode = ec.value();
if (share->retCode != 0)
{
cerr << "err: " << ec.message() << 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
return share->retCode == 0;
}
string parseForParam(const string &arg, int argc, char** argv, bool argOnly, int &offs)
{
auto ret = string();
for (; offs < argc; ++offs)
{
auto argInParams = string(argv[offs]);
if (arg.compare(argInParams) == 0)
{
if (!argOnly)
{
offs++;
// check ahead, make sure offs + 1 won't cause out-of-range exception
if (offs <= (argc - 1))
{
ret = string(argv[offs]);
}
}
else
{
ret = string("true");
}
}
}
return ret;
}
string parseForParam(const string &arg, int argc, char** argv, bool argOnly)
{
auto notUsed = 0;
return parseForParam(arg, argc, argv, argOnly, notUsed);
}
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
string genEventPath(const string &tsPath)
{
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 (tsPath.size() > 14)
{
// removes 'VIDEO_TS/live/' from the front of the string.
auto ret = tsPath.substr(14);
return "VIDEO_TS/events/" + ret;
}
else
{
return string();
}
}
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
string genVidNameFromLive(const string &tsPath)
{
if (tsPath.size() > 17)
{
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
// removes 'VIDEO_TS/live/' from the front of the string.
auto ret = tsPath.substr(14);
auto ind = tsPath.find('/');
// removes '.ts' from the end of the string.
ret = ret.substr(0, ret.size() - 3);
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 (ind != string::npos)
{
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
// remove all '/'
ret.erase(ind, 1);
ind = ret.find('/');
}
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
return ret;
}
else
{
return string();
}
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
uint64_t genEpoch()
{
return duration_cast<seconds>(system_clock::now().time_since_epoch()).count();
}