This series is written by a representative of the latter group, which is comprised mostly of what might be called "productivity users" (perhaps "tinkerly productivity users?"). Though my lack of training precludes me from writing code or improving anyone else's, I can, nonetheless, try and figure out creative ways of utilizing open source programs. And again, because of my lack of expertise, though I may be capable of deploying open source programs in creative ways, my modest technical acumen hinders me from utilizing those programs in what may be the most optimal ways. The open-source character, then, of this series, consists in my presentation to the community of open source users and programmers of my own crude and halting attempts at accomplishing computing tasks, in the hope that those who are more knowledgeable than me can offer advice, alternatives, and corrections. The desired end result is the discovery, through a communal process, of optimal and/or alternate ways of accomplishing the sorts of tasks that I and other open source productivity users need to perform.

Thursday, November 14, 2013

13th installment: how slow is too slow for a motion detection security cam system?

In this post, I'll answer a question to which I hoped I'd find an answer on the internet--but I did not manage to find that answer. The question is about minimal specs for a motion-capture machine and, though my answer will have to remain somewhat imprecise owing to the fact that I did not test multiple systems, it will at least give a probable base-line for what may be the lowest-powered system one could use for the task I'm describing.

So, without further ado, on to a description of the task. Or, more specifically, I'll start off describing what precipitated the task.

For some months now, things located in public areas of the apartment building where I live--for example in the corridors or the garage--have been disappearing. I assumed it was only affecting others until I noticed that a cheap DVD player I'd put in the exercise facility here had disappeared. Then, I noticed that certain bicycle parts and tools had vanished from my garage space.

I decided I could take at least some action toward stemming the theft and perhaps catching the perpetrator, by setting up a security camera. I knew that GNU/Linux had utilities for recording from motion detection cameras, and some preliminary searching revealed that the motion program was likely to suit my needs.

It so happened that a friend had recently passed along to me a decent webcam, so all I needed to do was find a target machine on which to set up the software. An old laptop would have been ideal because of the small size, but I didn't have one available.

What I did have was an old all-in-one unit, an early LCD monitor with a built-in computer--in the person of a laptop motherboard--in its base. I even had Debian (Squeeze) already installed on that machine, since I'd set it up for my father-in-law to use when he visits. But I'd taken the machine out of service a couple of years ago, judging that, as a single-core machine with a 433 MHz Celeron and 192 megabytes of RAM, it was getting a little long in the tooth to be useful anymore. So, could this ancient machine actually be used for a motion detection security camera?

I won't in this post go into the particulars of setting up motion, which did not prove particularly challenging. But after stripping down the operating system to the basics, installing motion, and editing its configuration file for my set-up, I was able to get it to run and record on this machine.

Though the web-cam is capable of 720p recording, I had to settle for 640x480, since the older USB 1.1 ports on this machine could not handle anything approaching the bandwidth high-definition video demands. And the hard disk on this machine, at a measly 6 gigabytes, was not a good candidate for recording HD video anyway.

Once I'd disabled, per the motion documentation, alsa's snd-usb-audio module, I was off to the races with this rig. I did manage to find an 40 gigabyte hard drive for sale for $3 which, when added, upped my recording capability from about 2 months to a little over one year.

So, in case you're wondering, as of this date (late 2013), you can actually run a single* motion-sensing camera, if you're satisfied with VGA video quality and a low frame rate (I've set it to 2 per second), on a single-core 433 Celeron with as little as 192 megabytes of RAM. It will even happily run ffmpeg and stitch together the stills it captures into a video for you.

* I didn't try but am virtually certain such a machine could not handle two cameras.

1 comment:

  1. I run a setup almost exactly like yours but mine's a ZOTAC NM10-DTX ION with 2 Five Megapixel cams, 1.66 GHz Dual Core, with 4Gigs of ram and a 1 Tb Hd.
    Way more jam then yours, and if I had better cams with MJPEG support, I suspect I could have run 4 cams.
    As it is, it was cheap, and the cams were 15 bucks each. They both handle -20c winters no problem so far.

    The trick is the mjpeg support, make sure your cams have it.