I am thinking of hosting all videos/images on a dedicated in-house computer.
I am reading that you need to purchase a plan in order to remotely access your cameras.
T or F?
Also, is the above true for looking at past images ie from 20 minutes ago?
oh, wait, Stewart did post one solution ICRealtime.
Any others?
If you have a good Internet connection, you can host the whole setup yourself with zero software or subscription costs. The last one I set up used Motion running on (I think) Debian, although it could have been some other Linux. That was about seven years ago, though, so there may be better options now. Or not.
A quick search for "linux surveillance camera software" will bring up dozens of options, including about half a dozen (Motion still being one of them) that come up repeatedly as top choices. I just glanced at, but didn't completely read the results. It does seem that some are completely free (as in speech and beer), others are commercial but inexpensive, and still others depend on how you're using them.
I have considered doing this off and on for the past few years. If I ever get around to doing it and don't use a ready-made solution, I almost certainly will build it on top of Debian Linux. That's partly because of my familiarity with it, partly because it's free, but mainly because it's just a good platform for this sort of mission. It's efficient, stable, versatile, and has modest hardware requirements of its own (although the resources needed to process video will also have to be considered). It's ideally suited for deployments where you need the server to do one thing very reliably and very well, 24/7, for months at a time, with little attention.
I might also build the DVR on on some other Linux if the surveillance software preferred another flavor; but if the choice were all mine, I'd use Debian for this sort of single-purpose machine.
As for the hardware, in the past I've mainly used old PCs for single-purpose Linux servers of any kind. I often used old laptops to save a little electricity. Nowadays, I'd also look at some of the beefier Raspberry Pi boards. That's also why I'd only
almost certainly use Debian. There are special OS builds for Raspberry Pi that might make more sense using that hardware. There may even be a pre-compiled image designed specifically for surveillance cameras. So I'd do some research.
Raspberry Pi can also run many other operating systems, including many Linux flavors, Android, and others, by the way. Most of them seem to be minimal builds to which the user adds only those packages that they need, which is a very good way to go about building a single-purpose machine, especially using resource-limited hardware. But it's more work.
And that's what it all comes down to: How much work you're willing to put put into it. This is one task for which literally all of the software you'll need is available for free, and much of it is essentially identical to that which is pre-installed on commercial surveillance DVRs. So you can do it all for free (except for the hardware), with zero software or ongoing service costs. Or you could pay for a service that limits your labor to plugging the thing in and connecting the components, in return for a monthly fee. It's really up to you.
A few other things to bear in mind:
1. Surveillance puts extreme demands on the storage media. If you use SD cards, you need to go with high-end ones that are designed for that sort of extreme use. Also be prepared for them to fail, which even the best cards will over time.
2. If I built a machine for this purpose, I'd be inclined to at least
consider mirrored HDD drives depending on the I/O requirements, both because of the cost difference and because of the limited write cycles of SSD drives. I can pick up half a dozen decent identical HDD drives from Micro Center for the cost of one SSD drive, mirror two of them, and just replace them as they fail. But I'd have to research it before making that decision, as well as consider the total I/O requirements and the power consumption. I'm not prepared to say which option would be "better" at this time.
3. Don't neglect bitrate and compression when considering cameras. To get a decent picture at 1080p, you'll need a
minimum bitrate of 5Mbps using H.264 (which is most common on lower-priced cameras), or 2.5 Mbps if using H.265 (usually used only in higher-end cameras because of the licensing fees). Those are minimums. If you want to be able to read the license plate of the car the thief used or the tattoos on his arms, double those bitrates (at least).
4. Also remember that the total combined bitrate of all the cameras affects the DVR's resource needs in terms of processor power, RAM, and I/O.
5. You really don't want to be broadcasting all that video over the Interwebs all the time. ISPs frown on that. Most surveillance camera software either "pushes" an alert to the mobile device or an email address when motion is detected above whatever threshold you set, or only starts the Web stream when requested by a client browser or app.
6. Remember that motion is motion. Trees swaying in the wind, deer, the mailman, and so forth are motion. Most surveillance camera software allows you to set a total motion threshold as well as completely ignore parts of every camera's raster (such as trees) to avoid false triggers.
7. Different cameras and software detect motion differently. If you're thinking about cameras with, for example, PIR motion detection, make sure it's configured in a way that the DVR software can use it to its best advantage.
If the camera doesn't do its own motion detection at all, then the software has to do it. Usually it does this by simply looking at the total number of pixel changes, but there are some more advanced methods that look at the whole raster. I've never found them to be any better in practical terms. But maybe that's changed.
8. You may need either a static IP or a dynamic DNS service if you're not using a paid monitoring service. Or not. Some software sends a link with the current IP with the alert mail. I suppose software that pushes to a mobile app does the same, but invisibly.
9. Your ISP may block the ports commonly used for remote monitoring. All of the software I know of allows you to change the default port to some other unassigned port.
10. You'll have to have a vague grasp of IP addresses, ports, and port forwarding to configure your router to accept the connection.
Rich
