I have been playing around with the webcam firmware that was the subject of my last post and have a number of random notes that I should put up here on using it.
Power-on and Power off
The NSLU2 running OpenWRT has some odd characteristics. First, it will not automatically turn on when power is applied, and you can’t make it do so without modifying the hardware (see here for a lengthy discussion of how to do so). You have to press the power-on button to get it to start up. Thats true of the NSLU2 generally and not OpenWRTs fault. Second, under OpenWRT, pressing the power button again won’t turn it off. Thats something that isn’t implemented, yet, in OpenWRT. Pressing the reset button will turn it off, but thats kind of awkward. Logging in (see below) and issuing the “poweroff” command will do so too.
I’m looking into ways of reducing the boot time from the present 55 seconds from power-on to first image, but I don’t expect to get it down to less than 30 seconds.
In my first post I skated lightly over the question of why the QuickCam is running at 960×720 if its supposed to be capable of doing 1600×1200. The answer turns out to be a bit complicated. The QuickCam can generate images in two formats, an uncompressed one known as YUY2, and a compressed form, M-JPEG. Compressing the images is quite hard work for the camera, and at the maximum resolution it simply can’t do it, either because it takes too long or it doesn’t have enough onboard RAM. And the difference in size between the compressed and uncompressed images is pretty huge, as you can see in the following table. These are all the available image formats >= 640×480 for the Pro 9000:
The problem with the YUY2 format is that its simply huge and generates 12-20 Mbytes/second. We can’t move this over 100Mbit Ethernet, which will do 10-12 MBytes/second, tops. Even if we did, browsers don’t understand it. It is possible to ask MJPG-streamer to read YUY2 and do the compression to MJPEG itself, but its hard work for the NSLU2 as well. At 1600×1200 it generates one image about every five seconds and seems to buffer about six images, so what you see is thirty seconds in the past. It also falls over with segmentation faults fairly frequently (less frequently with lower quality images). So full resolution is pretty much limited to snapshots (another subject I want to get into). The 960×720 JPEGs direct from the camera are pretty heavily compressed and the quality of the picture does suffer a bit. Less severe compression doesn’t seem to be available from the camera, but I’m hoping I can find a way of getting it.
The Pro 9000 has a variable focus control. This is unusual on webcams, and allows it to focus on objects as little as 4-5 cm away. The MJPG-streamer software has an option that automates focusing, but having experimented with it I have not activated it in the firmware build. The reason for this is that the default focus seems to manage perfectly well between about 30cm and infinity, and the auto-focus is a bit painful to watch. It operates by checking the sharpness of the picture every ten seconds or so. If the sharpness deteriorates, it triggers a procedure that runs through the whole range of focus settings, and then picks the sharpest one. This works, but it can take at least ten seconds, and is easily fooled by movement. Unless you need this facility, its probably best left turned off.
Note that the manual focus controls in MJPG-streamer work just fine and let you focus down to a few centimeters.
Modifying the camera
If you want to know how to take the Pro 9000 apart, mount it in a box, and do things like attach a large lens to it you can photograph, say, craters on the moon, look no further than here
Low-level firmware access
If you have some Linux experience and want to get in and add packages or change settings, you can telnet into the firmware and edit the configuration files with vi. The firmware will advise you to set a secure root password, and thereafter you will need to log in using ssh and that password (this is, incidentally, essential if you are going to make the camera visible to the Internet at all). To switch to a static IP at 192.168.1.2, for example, you would edit /etc/config/network and change the line
option proto dhcp
option proto static option ipaddr 192.168.1.2 option netmask 255.255.255.0
The startup commands that run MJPG-streamer are in /etc/init.d/done. MJPG-streamer takes the following parameters:
-i | –input “< input-plugin.so > [parameters]”
-o | –output “< output-plugin.so > [parameters]”
[-h | –help ]……..: display this help
[-v | –version ]…..: display version information
[-b | –background]…: fork to the background, daemon mode
The UVC input plugin, input_uvc.so, takes these parameters:
[-d | –device ]…….: video device to open (your camera)
[-r | –resolution ]…: the resolution of the video device, can be one of the following strings:
QSIF QCIF CGA QVGA CIF VGA SVGA XGA SXGA
or a custom value like 640×480
[-f | –fps ]……….: frames per second
[-y | –yuv ]……….: enable YUYV format and disable MJPEG mode
[-q | –quality ]……: JPEG compression quality in percent (activates YUYV format, disables MJPEG)
[-m | –minimum_size ].: drop frames smaller then this limit, useful if the webcam produces small-sized garbage frames which may happen under low light conditions
[-n | –no_dynctrl ]…: do not initialise dynctrls of Linux-UVC driver
The output HTTP plugin, output_http.so, takes these parameters:
[-w | –www ]………..: folder that contains webpages in a flat hierarchy (no subfolders)
[-p | –port ]……….: TCP port for this HTTP server
[-c | –credentials ]…: ask for “username:password” on connect
[-n | –nocommands ]….: disable execution of commands
The file output plugin, output_file.so, takes:
[-f | –folder ]……..: folder to save pictures
[-d | –delay ]………: delay after saving pictures in ms
[-b | –bytes ]………: save only on change in picture-size
[-c | –command ]…….: execute command after saving picture
And the autofocus output plugin, output_autofocus.so takes just
[-d | –delay ]………: delay after saving pictures in ms