Motion: Your Eye in the Sky for Computer Room Surveillance
Again, the final command must be run as root. After all of this completes, you will have a /usr/local/bin/motion executable on your system.
Refer to the Motion Guide (see Resources) if you encounter any problems building or installing Motion. Some of the guide is outdated, but it contains a useful explanation of how to install and operate Motion.
Motion runs as a dæmon, constantly analyzing and storing video. It is controlled by a configuration file, per the standard UNIX paradigm. Copy the file motion-dist.conf from the source directory to /etc/motion.conf, and edit a few parameters. The first thing you need to change is the netcam_url setting. Motion retrieves JPEG images from the camera through this URL. For the Axis 2100 camera, this takes the form http://netcam.example.com/axis-cgi/jpg/image.cgi?resolution=640x480. When you set the netcam_url variable in motion.conf, all the settings pertaining to directly connected video cameras, such as video device, rotate, height and width, are ignored.
You should be aware of one limitation between netcams and standard video capture devices. Motion at this time knows how to request images from netcams only one JPEG snapshot at a time. The overhead of this limits your video to a maximum of 12–15 frames per second (fps). Some work has been done to pull the images from the cameras in motion-jpeg streams, but that effort is not yet complete. In practice, 10 or 12fps is perfectly adequate for surveilling a room.
You need to decide where to keep your Motion-generated videos. I generally use the directory /var/log/vcr on my Linux server. The location you use depends on your disk-space situation. Ideally, you should create a new filesystem exclusively for the Motion videos in order to avoid filling your root or /var filesystem with video files. This directory is set with the variable target_dir in motion.conf.
Next, decide on the type of video you want to create. Motion 3.1.16 supports MPEG1, MPEG4 and MS-MPEG4. MPEG1 has the advantage of being a simple and well supported format. However, MPEG4 offers better video and better compression. The final format, MS-MPEG4, is understood by Microsoft Windows Media Player without any special plugins.
One warning: MPEG4 and MS-MPEG4 support were introduced in Motion 3.1.16, so they have not been tested as extensively as MPEG1 video has been. I have found MS-MPEG4 to work fine, however, and it is much easier for Windows users to view. MPlayer or any other modern video player can be used to watch video in any format on Linux systems.
The video type is controlled by the motion.conf variable ffmpeg_video_codec.
This should be enough basic configuration for you to start using Motion. You should check that output_normal is off; otherwise, JPEG images of all the frames are stored in target_dir. This may be useful later on for debugging, but right now it is unnecessary clutter.
Run Motion from the command line, as root, with the command /usr/local/bin/motion. Motion should start up and continue running. If it aborts immediately, there probably is an error in your config file. Follow the error messages to troubleshoot. Once you have it fixed so that Motion starts and continues to run, generate some input. Walk in front of the camera or, better yet, have an assistant do it. Remember to turn the lights on in your server room, or the camera might not pick up much action.
As the activity in front of the camera starts, Motion begins to generate an output file. After the activity stops, check your targer_dir for the resulting output file. Examine the file with your video player. The video may appear jerky because of the limitations of pulling the still images from the netcam. Motion fills in the missing frames so that the video runs at normal speed, and it may have the stop-motion quality you see on convenience store cameras. If everything looks good, it's time to set up Motion to run on system startup.
To make Motion run on every system boot, set up an init script. On Red Hat-based systems, copy motion.init from the Motion source directory to /etc/init.d/motion and run, as root:
# /sbin/chkconfig --add motion # /sbin/chkconfig motion on
Then, test that the initscript works by running it manually with /etc/init.d/motion start. Finally, if you are paranoid, reboot the system and verify that motion is up and running after system boot.
Like any good Linux program, Motion has many tuning variable. The best advice when you tune Motion is to change one variable, restart Motion and test. Some of the configuration variables can have non-obvious interactions with one another.
As a first step, you might want to turn on the locate and text_changes motion.conf variables. Locate draws a box around the motion detected in each frame, and text_changes prints the number of changed pixels in each image in the corner of the image. These two settings allow you to determine where Motion thinks the motion in the image is, and how much motion there is—how many pixels have changed in the image.
Right off the bat, I recognized I probably placed my camera in the wrong spot in my server room. The room has a window that looks into another office space. It took me a while to figure out why I was getting so many tiny Motion movies when the only change would be a slight brightening and dimming of the room. I finally realized that occasionally a light-colored door in the other room would open and reflect light through the window into my server room. Then, that light would reflect off a shiny metal air-conditioning unit into the camera. So even though the camera couldn't see the window at all, light bouncing through it would produce occasional spurious results.
In retrospect, I should have mounted the camera to point away from possible external light sources and away from shiny metal surfaces. However, I decided to leave it where it was, because that really was the best view of what was going on in the room. Instead of moving the camera, I adjusted Motion to compensate.
The first thing I did was create a mask file. This simply is a black-and-white image the same size as the camera output images, 640×480 for the Axis camera. Any black areas are ignored by Motion. I created this file in The GIMP and blacked out the area corresponding to the metal surfaces of the A/C unit. Unfortunately, Motion is picky about this file; you must save it as a raw, not ASCII, portable graymap (PGM) file.
Motion doesn't like PGM files because they are generated by The GIMP. If you use one, Motion starts but then exits a few moments later with the message:
This is not a ppm file, starts with 'P6'
A few minutes of source code digging revealed the fix. Motion expects the PGM file version number at the start of the file to be P5, not P6. Edit your mask file and change the magic number at the start from P6 to P5. You can edit this file safely in vi. After that change, Motion loads the mask file without incident.
This reduced, but did not eliminate, the empty motion capture videos. I then moved on to other adjustments. I tried turning the light switch variable, which the comments in motion.conf indicate might help filter out sudden light changes. I found this to be ineffective. I also experimented with lowering the threshold, the number of changed pixels required to trigger motion detection. The text_changes output is useful for this as it prints the number of changed pixels on each motion output frame. If too many bogus movies are output by Motion, you can try to raise the threshold to a number higher than what's printed by text_changes.
Ultimately, the best tweak I found was to increase motion_minimum_frames. This is the number of frames that must contain motion before Motion starts generating a movie. I set this variable to three and found that most of my spurious movies from the light changing disappeared. Most of those movies were only a few frames long, because the light level change happened quickly. Conversely, real motion-capture events tended to be many frames long. Thus, if you see many tiny movies with a duration of one second or so, my advice is to increase motion_minimum_frames to at least three and possibly more.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide