Development

LPC: What's happening with webcams

September 25, 2008

This article was contributed by Don Marti

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.

Comments (19 posted)

LAME ain't lame no more

By Forrest Cook
September 30, 2008

LAME (Lame Ain't an MP3 Encoder) is a long running open-source MP3 encoder project. From the About LAME document: "...LAME is the source code for a fully LGPL'd MP3 encoder, with speed and quality to rival and often surpass all commercial competitors. LAME is an educational tool to be used for learning about MP3 encoding. The goal of the LAME project is to use the open source model to improve the psycho acoustics, noise shaping and speed of MP3. LAME is not for everyone - it is distributed as source code only and requires the ability to use a C compiler. However, many popular ripping and encoding programs include the LAME encoding engine..."

The LAME project has announced the first release in several years: "After rough[ly] two years of development, the LAME project has released a new version (3.98.2) of the best-known Open Source MP3 encoder. All users are encouraged to use it, see new improvements regarding the previous releases and send feedback for the project."

LAME has a long and interesting development history. From the LAME home page: "LAME development started around mid-1998. Mike Cheng started it as a patch against the 8hz-MP3 encoder sources. After some quality concerns raised by others, he decided to start from scratch based on the dist10 sources. His goal was only to speed up the dist10 sources, and leave its quality untouched. That branch (a patch against the reference sources) became Lame 2.0, and only on Lame 3.81 did we replaced of all dist10 code, making LAME no more only a patch. The project quickly became a team project. Mike Cheng eventually left leadership and started working on tooLame, an MP2 encoder. Mark Taylor became leader and started pursuing increased quality in addition to better speed. He can be considered the initiator of the LAME project in its current form. He released version 3.0 featuring gpsycho, a new psychoacoustic model he developed. In early 2003 Mark left project leadership, and since then the project has been lead through the cooperation of the active developers (currently 4 individuals)." Numerous additional developers have contributed to the project.

The slightly out of date project version history documents the changes to the code since September 1998. Improvements added to version 3.98 (started in May, 2007) include:

Numerous bug fixes were implemented.
A lot of code cleanup was done.
Support was added for newer versions of various libraries.
Many build system improvements were done.
The RPM specification was updated.
Numerous changes were made to the lame front end switches.
New VBR code, derived from the NSPSY psymodel, was added.
There were changes to the new VBR psymodel.
The out of bits strategy for the newer VBR code was overhauled.
PCM WAVE_FORMAT_EXTENSIBLE support was added.
Support for ID3v2 total track count was added.
ID3v2 TLEN support was added.
The ATH adjustment was improved for low volume cases.
A new SSE version of the FFT code was used.
A flush option was added for flushing the output stream in lame.exe.
The FFTSSE and FFT3DNOW assembler code was back ported from the Lame4 branch.

Building the newest version of LAME on an Ubuntu 8.04.1 LTS (Hardy Heron) i386 system was straightforward. An older Ubuntu package of LAME was first removed from the system using the Synaptic package manager. The LAME version 3.98.2 source code was downloaded, unzipped and untared. The configure script was run, no missing dependencies were found. The usual make and make install steps were done. A few test case .wav files were encoded with the command lame file.wav file.mp3 and the files were played with the SoX play command as well as the closed-source RealPlayer application. Everything worked as expected, and sounded as good as one can expect for an MP3 file.

Overall, the latest changes to LAME fall into the category of maintenance or the addition of mostly user-transparent features. It is good news that this important piece of software is going into another phase of active development.

Comments (1 posted)

System Applications

Database Software

PostgreSQL 8.3.4 released

Version 8.3.4 of PostgreSQL has been announced. "This release contains a variety of fixes from 8.3.3." See the release notes for more information.

Comments (none posted)

PostgreSQL Weekly News

The September 28, 2008 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.

Development

System Applications

Database Software

Embedded Systems

Interoperability

Mail Software

Networking Tools

Virtualization Software

Web Site Development

Desktop Applications

Audio Applications

Data Visualization

Desktop Environments

Desktop Publishing

Electronics

Financial Applications

Graphics

GUI Packages

Imaging Applications

Mail Clients

Medical Applications

Multimedia

Music Applications

Office Applications

Office Suites

PDA Software

Science

Web Browsers

Languages and Tools

Caml

Python

Tcl/Tk

Version Control