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.

It's probably more accurate to say 'mencoder reflects the complexity of digital video' rather
then just saying the tool is complicated.

It's not easy stuff. There are a lot of choices you need to make between quality and
performance and trade-offs are a natural part of everything. 

Linux tools like Mencoder or Transcoder are going to be what you need to get the best out of
your encodings. The best quality for the smallest files.. this is what their game is about. 

Otherwise you have two choices... Either take generic defaults and sacrifice quality for
usability or have very large files and throw hardware/storage at the problem. 

Cheap, Easy, Quality: Pick two. 

No doubt that mencoder is a great tool. One would only wish to have some 
command line switches, or ready-made scripts, for common tasks, like 
animating a series of images, or re-encoding a video, that can be played 
on the default Windows Media Player on my mothers computer. 

If someone knows about a "Mencoder for Dummies" site, please post it 
here.

I agree about mencoder being able to do almost anything. I learned to use it from using
mplayer, and I think that's the best way to approach it. The options are reasonably straight
forward (most of the time).

I find mencoder to be more capable than transcode / gstreamer / vlc, but none of them can do
everything, and most of them I don't know them quite well enough...

There are tons of sites on MEncoder (and MPlayer) just use google
to find them. And if you don't want to read them, you can use one
of the hundreds of the front ends to MPlayer and MEncoder most of
which are listed on the MPlayer homepage (http://www.mplayerhq.hu/design7/projects.html).

BTW: MPlayer and MEncoder are written with a capital second letter.

Did the editor consider using gstreamer?  gstreamer has all manner of command line abilities
and I find it suited to this type of task.  A starting point would be:

gst-launch v4l2src ! filesink location=out.mpg

Although you could insert more nodes in that pipeline to compress the video, or other
operations.

IIRC, my handheld camcorder provides the ability to connect an analog input, and pass the
captured video through to the IEEE 1394 port.  I used dvgrab, kino, and transcode a number of
years ago to massage some vacation video, and was generally pleased with the results.

The acedvio card from canopus works fine over firewire with dvgrab. (A$500, though - they used
to make cheaper products.) The "--format dv2" option is a good choice. Grabbed video+audio in
DV format is excellent quality, but you need to allow space for about 12 Gbyes/hour captured.
Kino works ok to edit and convert to lower bitrate mpeg2 format for DVD.

I'll be interested to know how long the grumpy editor takes to edit his captured footage. I
believe the standard conversion factor is 1 hour of editing per minute of finished product.

Another possibility is a "media bridge".  Essentially that digital camcorder minus the optics.
Video (composite or svideo) and stereo audio come in one side, dv output over firewire on the
other.  The one I have at home seems to branded as "Dazzle", but I seem to remember Sony
making them as well.

Of course, that's a new piece of hardware, and our Grumpy Editor already has the Hauppauge
card...

- mark

Sony's DV decks maybe what you are thinking of. But they generally cost more than cameras :-)

And with recent flash now supporting h264, online video sucks 40% less.

With Ubuntu Gutsy this is as easy as

    sudo aptitude install ivtv-utils

or your local GUI equivalent.

The fun thing here is that, these days, the shell actually has a hook that *tells* you what to
install when you type a command it can't find in its path.

I /think/ (but I'm not sure) that kaffeine will record from any video source it can use, and
it can use a PVR-250 card.  It's possible that the good old standby vlc also does this.

S

Jon, I have the exact same problem and have been putting it off for years. I GREATLY
appreciate reading about your experience as I'd rather put my free time to a more fruitful
use. Maybe I will have to just buy/build a MythTV box some day. The last time I looked at
paying someone to transfer the video I began a coughing fit.

Thanks for tackling this project!  

I was just thinking that it was long past time for me to convert our analog SVHS wedding
videos into something more... digital.  Then the VCR can go to the garage sale.

However, I do not yet have any kind of capture card.  Hmm, except maybe an ATI All-In-Wonder
7500 in a box somewhere?  Must look.  And one of those HDTV-PC Linux-only cards, but I don't
think it does analog capture at all.  

So my question is:  Should I buy a "Hauppauge WinTV PVR-250" and safely follow in the trail
our fearless editor has blazed?

Or is there a different card, available inexpensively (second hand on EBay) which would
capture analog video well, and perhaps support the V4L2 streaming mode?

Suggestions would be appreciated!
  

I have used a Hauppage HVR-1110 (DVB-T and analog hybrid), with one of the TV viewer software
(xdtv?).
Connect VCR to composite in and soundcard audio in. Start the viewer, select composite in,
start the VCR, select recording options on xdtv, start recording... The main problem is the
need to be able to do real-time encoding and certain file formats limitations (for example,
avi files are limited to 4GB).

$50 will get you a used TiVo on ebay.  With this and a little hacking to get you the analog
input as a channel you can record your data easily from any analog source. (You could do it
without hacking too, but it's not as clean and easy.)

The nice part is that with a little more hacking (installing TivoWeb,) you can even give it a
title and leave it available in a convenient list of other video material accessible easily
from the TiVo remote to play directly on your TV.  No PC, no monitor, watch it from the
convenience of your couch.

A little more hacking (mfs_ftp, ffmpeg) and you can extract it and convert it to many other
formats for web viewing, emailing to grandparents, saving to DVD...

$50 more for an ethernet card (turbonet) will make these tasks much quicker (especially the
extracting).

Lastly since that $50 TiVo probably has limited storage (+-30GB,) you can spend ~$100 and drop
in a 500GB drive.  Or, if you already have plenty of space on your PC, stream extra storage
there.

This may not be quite the same quality as other solutions, but if you are recording VHS or
8mm, the TiVo mpeg1 is probably already better quality (at BEST resolution) than the source.
Compression may not be quite as good, but it really won't make that much of a difference with a
500GB drive, soon you will wonder why you bothered trying to get every extra KB of
compression.  

It really is a quite convenient method which is something even the non-techies in the
household can do once you have it setup (well, as long as they can program a VCR.)

-Martin

Beware that Jan 2009, NTSC broadcast will be interrupted, that TiVo may not be valuable for
anything else after that (not a problem if you use it just for what I mentioned above.)

Is "v4l2ucp -- A universal control panel for v4l2 devices" of any value for this sort of
thing?

What to do if all I have is a laptop (with USB and firewire)? I guess I'll need an external
box of some kind then? Any suggestions?
I have a few Hi8 tapes. What resolution do they correspond to?
Very nice (and entertaining!) article, btw. 

Sorry, what are you talking about?  Taking the raw analog tape out of the video and laying it
down on a flat-bed scanner (which makes no sense), or... what?

Not quite, though I didn't spell out what would be done. My fault there, sorry. The idea is to
step a single frame at a time in the movie projector, and capture that frame as though it was
a single still. It doesn't matter whether it's direct or a reflected image. You'd use an image
captre device, like a monochrome CCD, but since we're not playing the frames at regular speed,
the capture device can operate much slower and capture much more detail. The capture device
also wants to be as far from the projector as produces more useful detail.
<p>
(This eliminates blur, allows you to get all of the detail of the frame, etc.)
<p>
If it takes 1 second to capture a still at such high resolution, you simply forward to the
next frame about once a second, and each frame becomes photographable. (The BBC used similar
techniques to produce production stills from camera footage.)
<p>
You do this once with red only light from the camera, then again with only green light, and
finally with blue light. Hence the use of a monochrome CCD. You get a higher resolution
capture, but also by blending the images, you end up with HDR stills. Not sure if there is an
animated version of OpenEXR, but there is a version of MPEG specifically for HDR. You then use
that to convert the stills into a movie.
<p>
I'm probably still skipping details, but it's a variant on how they "clean" analog movies
(which is done frame-by-frame) and then use those stills to rebuild a full movie, originally
also on tape (so they had to burn a single frame onto a single celluloid window, with very
high accuracy).

but the rest of the conversation is how to get from analog recorded vidow, not from film.

doing a freeze frame on videotape is not practical.

Thanks a lot for this article, I really look forward to the other parts. I have been looking
into video capturing and editing under Linux and as you wrote, the complexity is way too big.