Your editor has never been a big fan of video cameras. They have a very
strong observer effect - they distort the social dynamics of events where
they are present. It is also sad to see vacationers who, on the rare
occasions when they get out, capture their every step on video; even when
they leave the house, they watch their lives on television. So your editor
has a strong preference for old-style, organic video memory.
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
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 \
-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
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
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.
to post comments)