Making MPEG Movies with Axis Network Cameras

Axis network cameras have no built-in MPEG support, but with a little effort it is still possible to create MPEG movies using them.

One of the earliest companies to realize the commercial value of Linux for embedded applications was a Swedish company by the name of Axis Communications. Founded in 1984, they specialize in network-attached peripherals and produce, among other interesting products, a line of network-addressable cameras. There are several models offering various features with differing performance characteristics, but they all produce compressed JPEG images. These images can be viewed live, directly from the cameras themselves or via intermediary web servers in order to offload high hit rates to more powerful hardware. Although these cameras don't contain an inherent ability to produce MPEG movies, their images can be archived on another system and turned into MPEG movies utilizing freely available software-MPEG encoders.

When Axis introduced their network cameras in November 1996 with the Axis NetEye 200, they weren't running embedded Linux yet. Rather, they employed an Axis proprietary instruction-routing scheme called OSYS running on their ETRAX 4 chip design. By the summer of 1998 however, Axis was already on its way to completing their eLinux/ETRAX port for use as the basis of all future products. As a result, eLinux/ETRAX is now the engine behind all their current products.

In June 2000, they released the Axis 2100 network camera containing the new ETRAX 100 chip, Axis' fifth-generation, optimized system-on-a-chip design that includes a 100MIPS 32-bit RISC CPU, 10/100Mbps Ethernet controller, advanced DMA functionality and a wide range of I/O interfaces. These cameras use a ¼ inch Sony progressive scan RGB CCD for image capture and incorporate the new Axis ARTPEC-1 chip providing hardware JPEG compression, delivering up to ten frames per second.

The Axis 2100 camera as well as the more full-featured Axis 2120 camera released October 2000 both run eLinux/ETRAX, Axis' port of the 2.0.38 Linux kernel with uClinux patches for MMU-less processors. This kernel includes Axis' Journaling Flash File System (JFFS), a log-structured filesystem designed to be used on Flash-ROM chips that remains consistent even through power-downs and crashes, thus obviating the need for fsck. The eLinux/ETRAX kernel also includes a Bluetooth stack, and although the 2100 series cameras don't support Bluetooth themselves, it is worth noting since Axis would be more than happy to have you use an eLinux/ETRAX solution for your next project. They offer a prototyping developer board, are willing to customize it to suit and their eLinux/ETRAX distribution along with accompanying documentation is available on their developer's web site at http://developer.axis.com/.

Setting up the Environment

I recently installed a couple Axis 2100 network cameras for a client wanting to monitor his business from home. I put in a channel-bonded, 2BRI ISDN line with compression, providing a network connection of about 300Kbps between his home and his business. Once the cameras and the network connection were in place, he could easily monitor activity at his business via a web browser from his workstation at home. This was great for viewing activity in real time, but he also needed the ability to view the day's activity later. To accomplish this, I configured the cameras also to archive images to the hard drive of a nearby Linux server and wrote a couple Perl scripts to create MPEG movies from these images once a day. One script makes MPEG-1 movies, the other makes MPEG-2 movies, and both are discussed here.

Since these cameras don't have the ability to make MPEG movies themselves, most of the actual moviemaking activity takes place on a nearby Linux server. This is where the JPEG snapshots from the Axis network cameras are archived and later turned into MPEG movies. Although it should not need mentioning, this server requires plenty of free disk space because working with large numbers of image files consumes disk space at an astonishing rate. Furthermore, a number of factors affect the amount of disk space required. The dimensions of the images archived and the amount of compression used on them greatly affects the size of each image. The frequency with which new images are archived and the length of the movie created from them also greatly affects the amount of space required for image archival. All of these factors, along with the options used during the MPEG encoding process itself, affect the size of the resulting MPEG file. Multiply all of this by the number of cameras the images are archived from and it becomes evident that a little careful planning up front goes a long way toward minimizing disk-space headaches later on.

Another factor to consider is that software-MPEG encoding is an extremely processor-intensive activity. The Linux server used for the encoding process therefore needs to have a sufficient amount of horsepower to handle this job. The actual amount of horsepower needed is dependent on the same factors mentioned above regarding disk-space requirements, so proper planning here, as always, is the most important ingredient of sustained success.

Once the Linux server is ready, the Axis network cameras need to be configured to archive their JPEG images, numbered sequentially, to a directory on this server. The images can be pushed from the cameras utilizing their own FTP facilities, or they can be pulled off by a program running on the Linux server. While I am still experimenting with the best method to achieve this, I am currently using a program developed by Axis for their 200 series cameras that is no longer officially supported by them. The program is called eye_get, and while it doesn't seem to be available directly from Axis anymore, the source code for it is currently available at http://ftp.mayn.de/pub/unix/webcam/tools/axcam1.32.tgz.

The eye_get program compiles easily on Linux and comes with a nice man page. It is fairly flexible with many options, including the ability to pull images from multiple sources when using a configuration file. I'm currently using /etc/eye_get.conf as a configuration file with the following contents:

-s0 -r/cgi-bin/image320x240.jpg -f
-s0 -r/cgi-bin/image320x240.jpg -f -ma admin@gnutec.com cam2

Each line of the configuration file configures image archiving from a separate Axis network camera. The -s option tells eye_get how often to retrieve images in seconds, and using an argument of 0, tells it to retrieve images continuously as fast as resources will allow. The -r option specifies the name of the image file to retrieve, and the -t option specifies where to put this file and what to call it. The -t option modifies the name of the stored image file according to the arguments given. Using arguments d and n tell eye_get to insert the current date and sequential number of the retrieved image into its name, such that the fourth image retrieved on February 3, 2001 from cam1, for example, would be named cam1_010203_4.jpg. The -l option specifies a file to use for logging, and the -mh and -ma options specify an SMTP server and e-mail address respectively for use in error notification.

At the start of each business day, eye_get is run via cron with the following command:

/usr/local/bin/eye_get -i /etc/eye_get.conf >/dev/null &

At the end of each business day, it is stopped via cron with the following command:

kill `ps ax|grep [e]ye_get | awk '{print $1}'`
This provides the set of date-stamped, sequentially numbered JPEG images from each Axis network camera used to create MPEG movies of daily activity.

______________________