Prepping Video For DVD And Web
Start With A Fast CPU, Good Network, And Big Disks
By Trevor Marshall
August 14, 2000
When I first started working with audio (about three decades ago) and video (two decades ago), digital technology was in its infancy.
I used an analog camera to shoot the footage, analog modules to process and edit the output, and finally sent it to analog videotape. Nowadays, the racks full of analog equipment can be replaced by software; and DV cameras that convert the images to digital at a very early stage in the processing chain have fallen to prices that are bringing them into mainstream use.
I had created some real video for my Web pages some years ago (1995, if my memory serves me correctly) and it was a slow, if inexpensive, process. But the race between AMD and Intel has produced some real advances in CPU technology during the past year, and the best of today's PCs are capable of producing video at speeds close to real time.
Choosing The CPU
Several months ago, I began to put together a PC especially for manipulating DV video content. I wanted a separate computer that could be left running in the corner, crunching on large rendering jobs (it is rendering a 15-hour SVCD task as I write this on my main computer).
I quickly found that there was still a shortage of utilities for Linux and Mac OS, and settled on Windows 98 as the OS. The CPU choice was a lot easier. I upgraded an old 13-MHz FSB motherboard with a Coppermine Pentium III 600EB. If you have a Katmai or older Pentium III or even a Pentium II, now is the time to upgrade. I am not necessarily advocating overclocking (your mileage may vary), but this article gives a good chronology of the recent changes in Intel CPU technology. I have heard the new Athlons are just about the same speed as the Coppermines, and they include the MMX and SSE instructions. Since they are certainly less expensive you might want to look at AMD-based motherboards as well.
You Need BIG, FAST, Hard Disks
Digital video files are HUGE! Each hour of digital video will take up 15 Gbytes of hard-disk space. So, to transfer a single DV tape to your computer and edit it, you will need at least 30 megabytes of disk space and probably another 15 Mbytes of scratch storage as well. It used to be that SCSI was preferred for digital video, but I chose two 7200 RPM, DMA66, IDE Maxtors, each 40 Gbytes in size. Sequential disk reading and writing clocks in at around 30 Mbytes per second.
It pays to spend a lot of your budget on disk storage. No matter how fast your CPU processes the DV data, if you are reading 15 Gbytes from a disk at 5 Mbytes per second, simple arithmetic shows that reading the file will take a minimum of 50 minutes. Don't skimp on the disk subsystem.
All the machines in my home office were networked some time ago with 10 BaseT wiring.
I soon got tired of waiting 15 minutes for a CD-R image to transfer from the video computer to the one with the CD-writer in it, and the necessity to upgrade to 100 Base T wiring was pretty obvious. Less obvious, but as it turned out more important, was the decision to throw out my Ethernet hubs and install a DSS-8+ D-Link 8-Port 10/100 Mb switch instead. Not only does a switch let 10 Base T network cards (my wife's and my daughter's) co-exist with the 100 BaseT systems, it lets data flow directly from one 100 BaseT machine to another, without the 10 BaseT data clogging the network. Now I can transfer a CD image in two minutes, quicker than my microwave can heat up a cup of coffee.
DV Camera And Capture Board
There was one overriding priority determining my camera choice. I had to have a video subsystem that handled both PAL and NTSC DV signals. I purchased a Sony TRV-900 Camcorder, with three CCDs and a superb lens system, primarily because its DV transport will record and play both PAL and NTSC formats. But it also has full manual control of aperture, white balance, and audio level -- things I have found invaluable. There is also an active user group.
I bought a Canopus DV Raptor (the special PAL/NTSC version), and it has had a solid, high-performance DV interface. It also has an analog input module (both PAL and NTSC) that, with the free PicVideo MJPEG codec, has produced several video captures for me that rival DV in quality. The Raptor does not have an analog video output DAC, and relies on the S-Video output in the TRV-900. This means I will need a second PAL camcorder if ever I have to output analog PAL, even though I can produce digital format PAL or NTSC DV tapes with the one TRV-900. Since most of my output will be to video disc or the Internet (and not to analog tape) I decided the Raptor's missing PAL analog output was not a major disadvantage for me.
Compression Algorithms Like Clean, Steady Video
When producing video for compression to MPEG formats or for transmission over the Internet, it is critical to remember that the better the quality of your input video, the better the quality of your output, and the easier it is to compress. There is nothing worse than trying to compress a noisy signal or one that contains jerky and unsteady movement.
Video is displayed on a television set in a 60 field, interlaced format. Sixty times a second the screen is drawn with half of the image, then in the next 60, the second half is drawn, just one line below the first. This allows for very smooth motion of the image, without increasing the size of the data stream. The human eye averages out the two images into an illusion of continuous, smooth motion.
Computer displays, however, are non-interlaced. A full frame is displayed 30 times a second (29.97 actually) when viewing a video that was produced in the NTSC format, or 25 times a second if it was originally PAL. The resolution is 720 x 480 pixels for NTSC operation, 720 x 576 for PAL.
If you capture from an interlaced video source merely by adding two successive fields to create each frame, and all the video-capture software seems to do it this way, any part of the video where there is movement will have a jagged edge, like a staircase. When objects that have moved between the successive fields are summed to a frame, every alternate line contains a different discrete image position, and this produces the jagged effect around the edges. This is murderous on a compressor (and doesn't look very good either).
The solution is to capture both interlaced fields (the PicVideo codec can do this) and then use software to smooth out the jagged edges. DV capture, of course, is always in interlaced format.
VirtualDub
The most useful video utility I use is also freeware, VirtualDub, from Avery Lee. I recommend you spend at least as much time familiarizing yourself with the capabilities of VirtualDub as you possibly can. It is an amazing program.
Donald Graft has written a "Smart Deinterlace" plug-in filter for VirtualDub, and it is by far the best way to process 60-Hz interlaced fields into 30-Hz frames. Donald's filter only processes pixels where movement exceeds a pre-set threshold, which is very much faster than trying to smooth the whole image.
Blur Is Good
It is important to remember that when the eye is looking at a still image, such as a photograph, it expects to see clear, sharp-edged objects. When it is looking at a movie, the eye interprets blurred edges as indicative of motion. With the transition from photographic film to electronic camcorders, many of us have forgotten that their high-speed electronic shutters produce discrete, jerky images. Not only does a video processed for "motion blur" look better to our eyes, but also the MPEG algorithms compress it more efficiently. Donald Graft's smart de-interlace filter has a "blur" mode, where a weighted average is used on three adjacent fields to calculate the output frame. This provides a motion blur very similar to photographic film. Try it and see what you think.
By far, the largest problem in handling video files in Windows is the limited size of AVI files.
With Windows 98, there is a 4-Gbyte file size limit set by the FAT32 subsystem. Although Windows NT can handle larger physical files, it doesn't help much because all the AVI utilities have inherited an artificial 1-Gbyte limit from the early video for Windows specification, or the newer 2-Gbyte limit of VFW 2.0
Larger video files (and remember that a DV video spans 15 Gbytes) must be broken into chunks. However, every software vendor seems to use a different method for doing this. Again VirtualDub can provide a solution.
VirtualDub has a superb capture module. I can capture 720 x 576 PAL video to produce 10 Mbytes of MJPEG video per second (PicVideo quality factor=18, YVUV mode) without dropping a single frame. Full screen NTSC capture (720 x 480) is even easier. VirtualDub produces a segmented AVI file, with output chunks each 2-Gbytes big. It can then read these back sequentially to produce the original time line.
FrameServing
I haven't dug into Windows' internals to see just how it works, but VirtualDub and AviSynth both have a capability called frame serving. They can take an input file, process (de-interlace) it, and send it to another program. Even if the program itself has no segmented capability, VirtualDub can feed it a large segmented file for processing. This is by far the easiest way to handle MPEG encoding of large projects.
Tsunami MPEG Encoder
You might recall that in my last column I mentioned Hiroyuki Hori's Tsunami MPEG encoder was producing results comparable with the best commercial packages. A new version, Beta 12, has been released. It now directly supports VCD, SVCD, and DVD output formats. The encoder has also been cleaned up, and I have begun to use it for all my encoding work. I find it produces MPEG II video with quantization levels only a little bit degraded from the Heuris package, but the convenience of being able to transfer the VCD and SVCD output directly to my Nero CD-R burner by far outweighs any difference in the encoding efficiencies.
What Of The Future?
Encoding of video from a camcorder into an easily transported digital format is not an easy task. There have been attempts to automate it into simple software programs, but (IMHO) they have failed. Hitachi's new DVD-RAM camcorder is a brilliant idea, but its 600-Mbyte disc will only store about 30 minutes of reasonable quality video, not nearly enough to be a practical video-input device.
Will future digital videos be produced from these "all-in-one," simple-to-use, camcorders, or from an automation of standard PC software programs into a simpler, GUI-based application? During this past month the Tsunami MPEG encoder rocketed to viability. Let's see what the coming month brings. 
