Greetings fellow developers on dev.to
1. Introduction
Today I am mentioning a topic why is neccessary when owning your own small business, or protecting your by using installing surveillance cameras.
The cameras which you install to protect your possession do mostly offer no more than a video source, which is persisted on any type of hard drive (in marketing they would say "secure data server") inside of your shop or home and will only be inspected if something happened.
Some more modern surveillance technologies do also offer motion detection.
Thus the motion detection may somehow be used to update the cameras orientation, as often seen in Action Movies. The camera may follow the motion by a certain degree thus the original field of view is still in sight but the motion can be captured too.
But don't you think the motion detection could be used better?
This and more will be the topic of this post and also of this series, which I create to also promote the GitHub project survAPI, which is under development to offer some more functionality to your existing surveillance and also give the ability of motion detection and a lot more to cheaper cameras, so you can configure which features your camera will be using.
2. Network cameras
There are a lot of different types of cameras.
Some examples are:
- IP Security Camera
- Analog MPX Security Camera
- Analog MPX Wireless Security Camera
- Wire-Free Security Camera Wiring
- Wi-Fi Security Camera Wiring
All of them do have different architectures in capturing and persisting video material and survAPI tries to find a generalized interface to work with any type of camera as a middle-ware.
Problem:
This security software has to become a module in security networks which is located between the actual video input device and the DVR if the video input device is not wireless or NVR if the video input device is wireless.
An example would be the classical IP Security Camera:
In this system of an IP Security Camera you will find a cable which connects the NVR and the video input device by using power-over-ethernet (POE) technology to "provide both power and video transmission".
This setup leaves no space for an external software which directly controls the video input stream. This problem is architectural and has to be solved by this software to achieve the highest possible compatibility.
Solution:
1. Backwards Integration:
When using the Backwards Integration, the software should be run on a server which is directly connected to the DVR/NVR and will rewatch the video material recorded, filter unimportant video information and redirect it either to the DVR/NVR or to the server to reduce the amount of data saved.
2. Automated Video Analysis:
Using this method, the software is run on a server just as in the previous example. The software will then rewatch the video information received from the DVR/NVR and collect timestamps which flag video intervals in which target objects could be detected. You can then either keep your videos as they are or use the time stamps to remove unimportant sequences.
More solutions have to come, but at the moment there is no idea to manipulate the video input stream between the video input device and the DVR/NVR, which would be the ultimate use-case for this software, since video fragments in which nothing happened (no motion detected, also no objects) would not be persisted and the amount of produced video material would be much smaller than on usual surveillance systems.
3. Goal
And this is exactly what SurvAPI tries to achieve: Become a middle-ware which is able to directly read the input stream from a surveillance camera and only send them to the DVR/NVR if something "relevant" happens.
But what does "relevant" mean? Well, this is your decision. SurvAPI uses CocoSSD which is a Computer Vision Neural Network and trained to detection a list of different objects. SurvAPI will only step in if any of the personally chosen-objects (if configured) are detected in a certain surveillance camera. Otherwise no data will be persisted or if you still want to persist everything no timestamps will be saved to the database.
Thus you will receive a lot of control over how your surveillance does work and also a toolkit which enables to filter a lot of unneccessary data produced by the camera before or after persistence.
This will definitely reduce the cost of hard-drives since the server does persist less amount of data than on a regular setup.
SurvAPI will also enable you to use cheaper (regular) cameras, install them and since it attaches to the camera the AI tools offered by SurvAPI will then analyze the videos and you do not need to buy very expensive cameras to have those tools.
SurvAPI is also able to use the detected time stamps and video fragments for Data Analysis.
Why don't you use your surveillance to notify if a customer leaves of enters your store?
Why don't you use your surveillance to measure the distribution of customers visiting your store?
You could also use the surveillance to do long-term statistics and find out how the amount of customers develops or a long period.
Measure the effect of certain events and use the produced data for more reasons,
BUT DON'T WASTE SURVEILLANCE ONLY AS A RESOURCE OF SECURITY
ATTACH A MIDDLE-WARE AND MAKE MORE USE OF YOUR CAMERAS
4. Still work in progres
SurvAPI is still work in progress.
This post was only the first part of a longer series which will explain the development of SurvAPI step by step.
In the next part I will show the architecture and the UI of the current version of SurvAPI
There was a longer break on the project but the work will now be continued and you are free to check out the project using the following URL:
I would love to get ⭐️ on the project if you like the idea and if you are also interested in the future of this project.
I would also appreciate follows on my GitHub account MarcoSteinke on GitHub
Top comments (0)