LPC: What's happening with webcams

Christmas is coming early for webcam users. Support for hundreds of popular webcams, available from Michel Xhaard's GSPCA project, is merged for inclusion in the upcoming 2.6.27 kernel. The amount of tweaking required from the user, the distribution, or both, has been cut, and it's likely that a random webcam will now just work out of the box.

Even with the much-wanted drivers becoming part of mainstream Linux, a small matter of plumbing remains. Webcams, Hans de Goede pointed out at the Linux Plumbers Conference, produce a variety of compressed video data. "They all came up with interesting proprietary compressed video formats," he says. The out-of-tree version of GSPCA did some decoding in kernel space, but the decoding of many camera-specific custom video formats had to be ripped out, as doing that kind of work in-kernel is a Linux faux pas. That's where Hans's libv4l comes in. Announced in June, the new library (actually a set of three) does the format conversion.

While not a Red Hat employee at the time (he is now) Hans posted a "BetterWebcamSupport" feature idea on the Fedora wiki, writing, "Currently many webcams do not work with Fedora out of the box even though a Linux driver exists for them." The problem was partly fixed with the GSPCA cleanup and inclusion upstream, and partly became the rationale for libv4l. Besides the core libv4lconvert library, the package includes libv4l2, to emulate a /dev/videoX device which, transparently to the application, will deliver "sane" video formats. There's also a libv4l1 to do the same thing but for the V4L1 API.

An audience member asked why the library is separate from gstreamer, which is already set up for video transcoding. V4L2 developer Hans Verkuil responded from the audience that "it's something that you do not want to have in the kernel, but it has to be small and fast." That leaves out gstreamer as a general solution, since some webcam applications don't need gstreamer or can't afford the space it takes. Therefore, a separate library. It needs one more feature, too: vendors install camera chips however they'll fit, which means the same camera module could be right side up on one product and upside down on another. Therefore, libv4l has software support for flipping images, but it still needs the data to know when to flip: a table identifying which hardware has the camera module in which orientation.

Brandon Philips at SUSE has another piece of the puzzle, a "frame server" that lets multiple applications share the webcam—doing for the webcam what PulseAudio does for the sound hardware. You can't shoot a photo with Cheese while another app has the webcam open, as he showed in a screenshot.

You can always rely on the computer hardware industry to figure out ways to save a little money on something if it's possible to solve the problem in software. Many new webcams have motorized focus but no hardware autofocus. Autofocus is up to the host system—which means a focusing daemon needs to see the video at the same time as an end-user application. So providing access for the autofocus daemon is another reason for the frame server. Someone on the mailing list has the autofocus math that will form the guts of the daemon figured out, but it's a fairly intensive calculation and will need to be done on an occasional frame of video, not each frame.

While the original frame server idea would have one shared memory segment per system, with access for multiple users, PulseAudio developer Lennart Poettering pointed out the potential security risks of that idea from the audience. "Memory mapping across privileges is a really bad idea," he said. He suggested putting the frame server in the user session to prevent users from, at least, killing each other's webcam applications.

The webcam market is one where Linux is an afterthought if it's a thought at all. The Linux conferences aren't teeming with employees of webcam manufacturers. The support Linux does have shows that the community can still support hardware on its own when it has to.