The Grumpy Editor's video journey, part 1

The fact of the matter, however, is that your editor does not always get the final vote, especially in any area related to the raising of children. So your editor's household contains two video cameras - one ancient, one less so - and a set of tapes with no end of priceless memories. Alcohol may have dimmed the experience of some of those early musical performances and such, but video tapes are forever.

Except, of course, that they are not. In particular, the older camera, being the only device in the house which can play those old 8mm analog tapes, is starting to make some very strange noises. The kind of noises which generally come just before an extended session dedicated to the extrication of a terminally crinkled tape which has just been firmly wrapped around and embedded within a surprising amount of severely-jammed helical scan hardware. The spouse and the grandparents have all let it be known that this is not an acceptable course of events, so your editor has been tasked with saving all of this legacy data.

One could, of course, go to a local merchant who, for an amount of money obtainable via an hour or two of consulting work, would transfer this data safely to some sort of optical digital media, where it would be guaranteed to survive for at least a few months. Or one could spend an order of magnitude more time figuring out how to do the work on a Linux system without the intervention of said merchant. Needless to say, your editor never thought twice - something which explains a number of difficult situations in which he has found himself over the years.

This article is the first of (probably) three which describe your editor's odyssey through the hazards of video processing on Linux. The topic this time around is the capture of video data - how does one get imagery from a video tape onto a disk drive? The second segment will look at video editing, turning a disk full of home movies into something moderately more professional in appearance. Then the final installment will go into DVD authoring, otherwise known as the process of getting all that old footage into the hands (and players) of the grandparents.

The older camera is an analog-only device, necessitating the use of some sort of analog-to-digital conversion on the way into the computer. As it happens, your editor is in possession of a Hauppauge WinTV PVR-250 card which, one would think, is ideally suited to this task. Hauppauge is known for working with the free software community, with the effect that its hardware is well supported by the IVTV driver which, after a long development process, was merged into the 2.6.22 kernel. So, one would think, grabbing the data from this device should be easy. And it is, though it took your editor some time to figure out how.

As it turns out, there are very few video capture applications for Linux. And there is nothing which is really aimed at people trying to bring in data from analog cameras. One could use a PVR system like MythTV or Freevo for this purpose, but they are not really intended for this use case. Your editor, who has been through the process of setting up MythTV in the past, chose not to take this approach.

One possible candidate was dvgrab, a tool which is part of the Kino project. This tool, however, is intended for use with FireWire-attached video cameras - we will see how well it works in that mode shortly. There is also a -v4l2 option which claims to capture via Video4Linux2, seemingly ideal for this purpose. Alas, dvgrab is written to use the V4L2 streaming mode, and, amazingly, the IVTV driver does not support that mode. So dvgrab refuses to work with the Hauppauge devices. A look at the code suggests that convincing it to use the V4L2 read/write mode should not be too hard, but that was beyond the scope of your editor's ambitions at this time.

As an aside, this sort of glitch seems to be a common problem with the Video4Linux2 API. V4L2 is well suited to letting applications drive video hardware to the very fullest extent of its capabilities, but that flexibility comes at the cost of forcing quite a bit of complexity onto the application side. A truly flexible V4L2 application must be prepared to cope with a wide variety of hardware and to operate in very different ways depending on what it finds. Most application developers do not make that effort, with the result that incompatibilities between applications and specific video devices are distressingly common. The V4L2 API is, in some ways, similar to the approach taken by X11, with some similar results: there was a long period where many applications performed badly when the display was not running in an 8-bit pseudocolor mode. X11 has worked out in the end; hopefully the same will happen with V4L2.

Another possibility was mencoder, a tool which is packaged with mplayer. Your editor does not doubt that mencoder is capable of acquiring a video stream from this device, converting it into any format one could imagine, and, while it's at it, changing the camera angle and improving the musical talents of the children being filmed. But anybody who has read the mplayer/mencoder man page knows that it is a masterpiece of its kind - a work written to a length that less verbose authors (Neal Stephenson, say) could only dream about - though Stephenson does do a better job of keeping the plot moving.

The length of the manual reflects the complexity of the tool. A typical mencoder command seems to run to about four terminal lines - and that's for a relatively wide terminal. An example from the mencoder documentation reads like this:

    mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd  -vf \
             scale=480:480,harddup -srate 44100 -af lavcresample=44100 -lavcopts \
             vcodec=mpeg2video:mbd=2:keyint=18:vrc_buf_size=917:vrc_minrate=600:\
             vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224 \
	     -ofps 30000/1001 -o movie.mpg movie.avi

The end result is that nobody who has not developed significant expertise in video technology, codecs, formats, and more will be able to create one of these commands. Mencoder is a highly capable tool, but approaching it for a task like this is reminiscent of trying to get to the corner store starting with a build-your-own-automobile kit. There are just too many pieces (incomprehensible pieces at that) to put together.

Then, there is transcode. The man page for this utility formats up to a good 50 pages, so it is not the simplest tool either. This problem space, it would appear, forces the creation of complex interfaces. Transcode has a V4L2 input module, which should do the trick, but, like the dvgrab version, it requires streaming I/O capability. So transcode, too, fails to work for this purpose; your editor is starting to think that it might be time to hack a bit on the IVTV driver.

Another candidate was cinelerra - a video editing tool which we will see again in future installments. Your editor tried cinelerra on a few different platforms, using both binary distributions and building from source. Suffice to say that building cinelerra from source is not something to attempt when one is short on time or short on temper. Cinelerra has a record mode, but it requires the V4L2 streaming capability. Of course, it does not bother to check whether that feature is available or not, with the result that attempts to record video yield only silent blackness. Cinelerra is a vastly powerful editing tool, but it was not usable for this task.

So how did your editor finally succeed in getting the analog video data to disk? The first step was to locate the highly-useful v4l2-ctl application which, seemingly, is only available from the V4L-DVB code repository. This tool provides command-line access to the extensive set of V4L2 ioctl() calls, enabling detailed configuration of the device. In particular, your editor made use of it to switch the device to its composite video input.

The second step, then, is decidedly low-tech:

    cp /dev/video priceless-video-data.mpg

The end result is a file containing just the video and audio data desired, in a form which, as it turns out, can be burned directly to DVD. There is no preview of incoming data, no computer-based camera control, no little flashing counters. But it works.

The current state of the art for video camcorders is to provide digital data via an IEEE 1394 (FireWire) port. When one has this sort of device, life is rather easier - though it seems that there really is only one game in town. That game is kino - a video editing tool - and its associated dvgrab tool. Either tool will work for capture from a digital video device. They can control the camera, split the incoming data into scenes, and generally make the process painless. Technology does actually get better sometimes. Kino and dvgrab will only store data in the DV format, necessitating a transcoding operation before writing DVDs, but that is a minor difficulty.

Your editor has learned a few things from this process. One is that the IVTV driver needs some work. But the real lesson is that working with video data under Linux involves dealing with a level of complexity that is far beyond what most people have any desire to understand. And this complexity hits hardest at the very front end: trying to get video data onto the system and into a workable format. Your editor suspects that most people who run into this wall quickly give up and buy a proprietary system for this kind of work. In other words, there's a whole world full of creative people doing interesting things with video, and Linux, despite having many of the basic capabilities these people need, is not an option for them.

Meanwhile, your editor has a disk full of video imagery - and a healthy appreciation for just how nice the storage explosion of the last few years has been. Now it's just a matter of bashing all of that data into a useful form for grandparental distribution - a process which looks like it might just take a bit of time. Stay tuned for your editor's video editing experience, due to appear on these pages within the next few weeks.