Making Digital Movies on Linux

by Florin Andrei

To start, check out whether the digital camcorder is compatible with Linux. The short answer is, if it has an IEEE1394 connector, it probably is compatible. If you're not sure, go to, click on Compatibility and then Camera. If the camcorder is not IEEE1394-enabled, you're out of luck. Although analog video capturing still is possible and works well for many people, it is beyond the scope of this article.

Once you've established the compatibility, you need an IEEE1394 card on your computer. Most of the cheap and not-so-new cards work with Linux, but check the IEEE1394 site, looking at the Compatibility page, which has Chipset and Host Adapter tables.

You definitely need plenty of free disk space. The DV format used by IEEE1394 camcorders requires approximately 15GB for each hour (slightly variable), and you need a couple more gigabytes for processing. You don't need an extraordinarily fast hard drive to capture the movie, though. Modern hardware that easily can do 4MBps of sustained write and still have some headroom left is enough. It is highly recommended that DMA on IDE drives is enabled, if your system supports it. XFS seems to be the fastest when capturing video, but other popular filesystems work just fine.

A fast CPU isn't necessary to capture the movie from the camcorder. When you transcode the movie to another video format, however, there is no such thing as a too-fast CPU.

Necessary Software and Installation Tips

Making all the software work together is perhaps the most difficult part of this job, and the order of installation is important. Some of these applications are included in various distributions, so take a look at your Linux installation CD before downloading. If you don't find what you need on the installation CD, download all the software listed in the Resources section at the end of this article.

You definitely need an IEEE1394-enabled kernel, otherwise your IEEE1394 adapter will not work. The distribution I'm using (Red Hat 8.0) already has all the required drivers in the kernel. If your distribution does not have this, you may have to patch the kernel; see the IEEE1394 site for patches and instructions. This is the live list of IEEE1394 modules on my system:

raw1394               9208   0  (unused)
ohci1394             20076   0  (unused)
ieee1394             46988   0  [raw1394 ohci1394]

These are the relevant IEEE1394 lines from my modules.conf file. They may or may not work for you, I provide them only as a hint:

alias char-major-171 raw1394
alias ieee1394-controller ohci1394
post-install ohci1394 /sbin/insmod raw1394

The libraw1394 library is a must-have, because all IEEE1394 software is based on it. dvgrab, the command-line application that actually captures the movie, also is required. Kino, an application that can capture movies and do some preprocessing, is nice to have but not mandatory. See the IEEE1394 site for all of these applications.

If you plan to convert movies to the DivX format, you need a DivX codec. The one I'm using is the binary-only codec provided by The examples provided in this article are based on this codec. Another DivX codec is XviD, which is a free software (GPL) DivX implementation that provides good quality and speed. If you plan to use it, be aware that some command-line examples provided here might need small changes-read man transcode. Intercodec compatibility in the DivX world is good, and I'm looking forward to a not-so-distant future when I'll switch all my tools to XviD.

If you want to convert your movies to the SVCD format, you need mjpegtools, available at The application that actually converts the captured movie into a format suited for CD-burning is called transcode. Its name is quite appropriate, because to transcode means to convert from one file format to another. If you're using an RPM-based distribution, I advise you not to download and install RPM packages, due to many library and codec mismatches between systems; instead, grab the tarball and do an rpm -ta or rpmbuild -ta. These commands generate an RPM package that is perfectly suited for your system; install it instead of a ready-made package. If you install a new codec or library and transcode depends on it, you will have to rebuild transcode anyway (see

To edit your DivX AVI files and do some post-processing, I recommend using Avidemux. It is a simple yet well designed video-editing tool focused on the AVI container format. Don't be surprised to see DV AVI and DivX AVI too. The container is the same, AVI, but the content is different-different video and/or audio codecs. That's why when you say "I've got an AVI file", you are not saying much. You must specify the codec(s) to describe the file fully.

Finally, to watch the results (DivX, SVCD) and to debug the intermediary steps, you need a media player. The one I recommend is xine. It knows almost every media format, including DVD and proprietary formats, such as QuickTime, Real and Windows Media, and it has a plugin for Mozilla and the other browsers. xine has several user interfaces that are actual player applications. Some are native KDE applications, others are GNOME applications, yet others are desktop-independent, so choose one that best suits your needs.

Remember, when installing multimedia software, observe the three-step rule: codecs then libraries and applications last. This is not a very strict and rigid rule, but it is useful to keep in mind when you start installing the required software.

Setting the Stage

Do some planning prior to capturing and processing the movies, otherwise you'll end up chasing multi-GB files all over the hard drive. The following is the method I use to organize my digital workshop.

In my home directory, I create the ~/dv directory, where I keep everything: scripts, captured files and converted movies. In ~/dv, I keep a few scripts with helpful names: grab, conv-divx, conv-svcd, burn-svcd and so forth.

Every movie is a separate subdirectory in ~/dv, such as ~/dv/party. The scripts in ~/dv accept one parameter, which is the name of the movie subdirectory. For example, ./grab party to capture the movie that I've named Party, and then ./conv-divx party to convert it to DivX.

Each movie directory has a few subdirectories of its own, such as, ~/dv/party/dv to keep the captured files, ~dv/party/divx to keep the DivX files and ~dv/party/svcd to keep the SVCD files. Here's this file layout in a clearer form:

|-- burn-svcd*
|-- conv-divx*
|-- conv-svcd*
|-- grab*
`-- party/
    |-- divx/
    |-- dv/
    `-- svcd/

All of the following scripts and examples in this article assume the file layout described above.

Lights, Camera, Capture!

Load a Digital8 cassette in your camcorder. Connect the camcorder to the computer using the IEEE1394 cable. Power up the camcorder in VCR mode (to play movies) and rewind to the beginning. Now run the grab script (Listing 1) in the ~/dv directory, with the desired name of the movie directory as a parameter, such as ./grab party.

Listing 1. The grab script captures content from the camcorder to disk.

if [ ! $1 ]; then
  echo "Usage: $0 dirname"
mkdir -v ${name} || exit
pushd ${name}
mkdir -v dv || exit
pushd dv
dvgrab --autosplit --frames ${frmax} \
  --format dv2 ${name}-

This script creates a directory for your movie, creates the dv/ subdir and starts to capture the movie. It autosplits the DV AVI files to keep them small (8,000 frames is roughly equivalent to 965MB on my video gear). Another split occurs at every scene change, so some files may be shorter. See man dvgrab for details.

You must start the script before pressing the Play button on the camcorder. You must Ctrl-C the script after the camcorder finishes playing. Do not try to edit anything while capturing, because you cannot do it reliably. Simply capture the entire cassette to the PC in one session. I'll tell you how to edit things out immediately, if that's what you want to do.

If your hard drive is too slow or if you do some other disk-intensive work while capturing, which I don't recommend, some frames may be lost. In that case, dvgrab notifies you, and you have to recapture the entire movie.

You can use Kino to do some preprocessing on the DV files, usually to delete scenes. Although I do not recommend it, you also can use Kino to convert the files to another format, but better tools for that are discussed below. Also, Kino, instead of dvgrab, can be used to capture the movie, but the simplicity of the latter and the fact that it's easily scriptable make it a better tool for the job in most cases.

Transcode to SVCD

The advantage of this format is you can play SVCD disks on most existing standalone DVD players. The disadvantage is poor image quality. But, overall, SVCD is the recommended format if you plan to watch your movies on TV and not on a computer. See Listing 2 for the script conv-svcd, which performs the conversion for you.

Listing 2. conv-svcd converts the capture files to SVCD.

if [ ! $1 ]; then
  echo "Usage: $0 dirname"
#### Standard SVCD, up to 43min / 700MB CD
bitrate=""; format="4"
#### User-rate SVCD, up to 60min / 700MB CD
#### (reduce bitrate if mplex tries to split file)
# bitrate="-w 1580"; format="5"
pushd ${name}
mkdir -v svcd || exit
pushd svcd
transcode -i ../dv \
  -V -B 0,15,16 ${bitrate} \
  -F ${format},"-a 2 -I 1 -S ${maxfs}" \
  -b 128 -E 44100 -J resample \
  -y mpeg2enc,mp2enc -o ${name} \
  --print_status 10
mplex -f ${format} -o ${name}.mpg ${name}.m2v \
vcdimager -t svcd --add-dir=SEGMENT \

To understand the transcode parameters, please read man transcode. I also provide a brief explanation here. The parameters on the first line of Listing 2 (-i ../dv) are related to the input. transcode can take a whole directory as input, provided that all files are similar.

The second and third lines describe the processing of the video stream. The image size in the original DV video stream, in NTSC format, is 720 × 480 pixels; the pixels are not square, so the DV image corresponds to only 640 × 480 pixels-a player must rescale it on the fly. The default SVCD image size in NTSC is 480 × 480, also with non-square pixels; it corresponds to an on-the-fly rescaled image of 640 × 480. So, we need to rescale the image from 720 × 480 to 480 × 480 and that's what the -B 0,15,16 input does. It rescales 0 × 16 pixels on the vertical size (0, no rescaling) and 15 × 16 pixels on the horizontal size (that's 240).

The -F parameter uses double quotes to pass parameters to mpeg2enc (see man mpeg2enc), which is an mjpegtools utility used by transcode to generate the output MPEG-2 stream. Literally, -F 4 means generate SVCD compliant video, and -F 5 means generate something close to SVCD but not exactly.

The fourth transcode line contains parameters related to sound processing. The fifth line specifies the output codecs and the output filenames.

The result of running transcode is a couple of files: the video stream and the audio stream that you need to combine into a single MPEG2 file. mplex, the next command in the script, does that and creates an .mpg file (the SVCD-compliant MPEG2 file). Verify the MPEG file with xine before burning the CD.

In the end, vcdimager takes the MPEG file and creates a CD image in SVCD format that is ready to be burned onto a blank CD. The CD burning is shown in Listing 3, the burn-svcd script.

Listing 3. burn-svcd burns SVCD video to standard CD-R media.

if [ ! $1 ]; then
  echo "Usage: $0 dirname"
speed="32"        # change to match your CD-writer
dev="0,0,0"       # change to match your CD-writer
drv="generic-mmc" # change to match your CD-writer
pushd ${name}
pushd svcd
# you may need to add sudo before cdrdao
cdrdao write --device ${dev} --driver ${drv} \
  --keepimage --speed ${speed} -v 1 videocd.cue

With the indicated parameters, you can create standard SVCD disks. If you use 700MB blank CDs, which are better than 650MB for video, you can store up to 43 minutes of video on one disk. If you use 30-minute DV cassettes (like I do), that's okay, but if you use the popular 60-minute cassettes, you might have a problem.

Three methods are possible for dealing with the time issue. One solution is to split the movie into two pieces and burn them on separate CDs. To do that, you can split the DV files before running transcode and process them in two batches. This is the method I prefer. The second solution is to generate nonstandard SVCDs by reducing the video bitrate. Simply uncomment the other parameters in the conv-svcd script (User-rate instead of Standard). Image quality decreases dramatically, however, and the SVCD may be less compatible with some standalone DVD players. In the third method, you still would generate standard SVCD. Instead of reducing the bitrate, though, you would use the auto-split capabilities of mpeg2enc and mplex to generate multiple SVCDs from one 60-minute cassette. See the documentation; I won't discuss this method here.

Be aware; the SVCD disks are written in a way that is different from the classic ISO9660 CDs-the disk sector is larger. So a 700MB blank CD can accept up to 793MB when written in SVCD format, the size of the videocd.bin file created by vcdimager.

conv-svcd generates interlaced SVCD material, which means the movie will look funny when watched on a computer (rapidly moving objects will "grow hair" horizontally). But if you watch the movie on a TV, the way the SVCDs should be watched, it actually will look better if you leave it interlaced. TV displays, as opposed to computers, already are interlaced and display interlaced movies better.

In theory, this script should work without changes for NTSC material (North America) and PAL (Europe), but it was tested mainly with NTSC. If there are any problems with PAL, go to, and click on VCD/(S)VCD/DVD under Examples.

Transcode to DivX

If you plan to watch movies mostly on a computer display, use DivX as a destination format. This format has the advantage of better image quality at the same file size. However, you are not able to play these movies on classic standalone DVD players. See Listing 4 for the conv-divx script. There are a few differences from Listing 2.

Listing 4. conv-divx transcodes to DiVX.

if [ ! $1 ]; then
  echo "Usage: $0 dirname"
################### NTSC ###################
#### 700MB / 30min, 720x480 --> 640x480 ####
bitrate="2900"; rescale="0,5,16"
#### 700MB / 60min, 720x480 --> 448x336 ####
# bitrate="1400"; rescale="9,17,16"
#################### PAL ###################
#### 700MB / 30min, 720x576 --> 640x480 ####
# bitrate="2900"; rescale="6,5,16"
#### 700MB / 60min, 720x576 --> 448x336 ####
# bitrate="1400"; rescale="15,17,16"
pushd ${name}
mkdir -v divx || exit
pushd divx
transcode -i ../dv \
  -w ${bitrate} -k -z -B ${rescale} -R 1 \
  -J smartdeinter=diffmode=2:highq=1:cubic=1 \
  -y divx5,null -o /dev/null \
  --print_status 10
transcode -i ../dv \
  -w ${bitrate} -k -z -B ${rescale} -R 2 \
  -J smartdeinter=diffmode=2:highq=1:cubic=1 \
  -b 128,0,0 \
  -y divx5 -o ${name}.avi \
  --print_status 10

Transcoding the video is performed in two steps. In the first step, the video codec (DivX) makes some notes in a temporary file. The actual video stream is generated during the second step, based on the notes made previously. The audio stream is transcoded only during the second step. The two-step technique is used to improve image quality.

The image then is de-interlaced using the smartdeinter filter. However, this really slows down the transcoding process. If you think it's too slow, and you can live with a small decrease in quality, use -J smartdeinter (no diffmode or other subparameters) and see what happens.

The -k and -z parameters are required for my camcorder, but they may not be the right thing for yours. Consult man transcode, and read about -l in case you need it.

The bitrate (2,900kbps) and image size are fine-tuned to fill a 700MB CD with a 30-minute movie, while yielding a near-DVD quality file. This is what I prefer when using DivX.

If you use 60-minute cassettes, you can split the final AVI (see below) and burn it onto two CDs. Or, you can use the commented $bitrate and $rescale values, which lower the video bitrate and also reduce the final image size. If you don't reduce the image size when you reduce the bitrate significantly, your movie becomes bit-deprived and looks smudged and foggy. Those of you using the PAL format should enable the other parameters in the script (the PAL group).

If you want to edit, split or process the DivX AVI afterwards, you can do so with Avidemux. The application is quite easy to use. One thing to remember: if you split an AVI into multiple pieces, each piece from the second to the last must begin at a keyframe; otherwise the quality of the image will suffer. Avidemux provides an easy way to find and mark keyframes. Also, see the avisplit and avimerge utilities in the transcode package.

After everything's finished, you can burn your DivX AVIs onto normal CDs. To create an ISO9660 image, write it onto a blank CD. This is common knowledge, so I won't provide the details.

What, No DVD?

Although transcode can create DVD-compliant MPEG-2, and although some Linux applications can use some DVD writers, the free DVD tools for Linux are not quite mature yet. It's doable, and you can generate some simple DVD content, but there are no bells and whistles. If you want to experiment, see and


Avidemux-graphical video processing application (can process DivX AVI files):

Binary-Only DivX Codec (not needed for SVCD):

cdrecord-prodvd-another DVD recording tool:

dvdrtools-create and write DVDs on Linux:

Image Aspect Ratio Quick Guide:

Information about various image sizes:

Lame-MP3 codec and tools (required for DivX only):

libdv-digital8/DV library (required by transcode):

MAD-MP3 decoder (required by Avidemux):

mjpegtools-powerful tools to process MPEG-2 and other media formats (required for SVCD only):

Open-source DivX codec (not needed for SVCD):

The Ultimate Resource for IEEE1394 on Linux:

transcode-complex and powerful multimedia processing application:

vcdimager-create and analyze VCD and SVCD disk images (use v0.7.12 or later):

xine-feature-rich multimedia player:

Florin Andrei is a senior network analyst with the network security team at SGI (Silicon Graphics). He lives with his wife and son in Mountain View, California. He's been a Linux enthusiast since the days when all the Linux install kits came on floppies.

Load Disqus comments