(Original, February 2005)(Updated, August 2006, new script keeps audio/video sync and creates VOBSUB subtitle files)(Updated, August 2007, patch contributed from Benjamin Pineau for latest versions of mplayer and mkvmerge)

1. Introduction

The issue of taking DVD backups has been
a matter of controversy, over both legal and technical
issues. I have been monitoring the latter kind (the technical)
ever since I was a student. Some of my free time is still spent
in following the technical innovations in the area, trying to
keep up with the best possible way of transcoding MPEG2 (a.k.a
DVD), in terms of balancing quality of the output with speed of
transcoding.

For the last couple of years, I had settled on using:

XVID for video

Ogg Vorbis for audio

Matroska for multiplexing

...through the usage of excellent open source tools
(transcode, oggenc, mkvmerge). I even contributed some code to
the transcode project for handling NTSC
telecined DVDs.
The reasons for these choices were simple:

No codec was better than XVID in all the codec comparisons.
It was one of the best in terms of quality, and it was also the
fastest.

Ogg Vorbis was also a no-brainer: even at 96 Kbits per
second, Ogg Vorbis audio quality is comparable to MP3
128Kbps!

Matroska, finally, is the OPTIMAL container: overhead is
only 0.25 percent of the final size and you can multiplex
everything (video, audio, text and VOBSUB subtitles) in one
file (AVI is hideous, with an overhead of 24 bytes per -- frame
-- yuck).

Recently, however, one of the parameters changed: MPEG4 has
now been obsoleted in terms of quality/bitrate by a new codec:
H264.
To give you an idea of what can be accomplished, utilizing open
source implementations, one can now encode 2,5 hours of
acceptable audiovisual quality in just one 700MB CD!

I found some spare time, so I'll show you how to do it -- the
relevant information up to now is kinda sketchy (to put it mildly
:‑) However, I will only describe the crux of it, and no, please
don't start asking me stuff. This is only for people who have a
working knowledge of both UNIX and video matters, so if you don't
know what an aspect ratio is, or why 0.2 bits per pixel is the
lowest limit of acceptable MPEG4 quality, stop reading this now
(while you're ahead :‑).
Sorry, but making a living writing software takes almost all of
my time.

P.S. You 'll also get a Perl script to assist the work.

2. Prerequisites

I'm only doing this as a hobby, so I
won't research into any other versions of the tools: use the same
version that I am, or adapt the Perl script yourself.

mplayer/mencoderMplayer 1.0pre8 with x264 support. If you compile it yourself,
you'll first need to get x264, through a subversion repository
(svn co svn://svn.videolan.org/x264/trunk x264).

3. Encoding

Even though I have been using 'transcode' for
most of my hobby tests, it doesn't support H264 (not yet). Hence,
we are forgetting about distributed encodes (for now :‑) and are
going to do it through the significant other, mencoder.

We'll tackle a rather advanced example, transcoding an NTSC
telecined Dolby trailer, called dolby-city.vob. You can
google the filename, it will immediately show up. Its rather big
for plain modems though (27MB), so you can try to follow through
these instructions with your preferred VOB anyway.

Naturally, if you want to encode DVD data, you'll have to
store the unencrypted MPEG2 data somewhere; I'm assuming you know
how to circumvent the CSS encryption to get to the MPEG2 data you
want. mplayer -dumpstream dvd://1 can lead to legal
troubles in certain countries, so make sure you are not breaking
any laws doing it...

Most of what follows is automated through a Perl script I
made, but since you are reading this I'm guessing you want to
know the details :‑)
Click here to skip explanations
and just use the script.

Let's assume that your MPEG2 data are stored in a directory
called video:

tcscan provides the normalization factor we need for
our audio encoding process: usually, DVD audio has quite a dynamic
range, so it needs some boosting for our transcoding. Now that
tcscan has given us what we need, we'll encode the audio,
normalizing it in the process.

3.2.1. Cropping

Navigate in the movie through the cursor/PgUp/PgDn keys to
make sure you've fed the filter all it needs to see from your
movie. In the end, abort mplayer and check the output for
the last of the "crop area" lines:

3.2.2. Interlacing

Interlacing is a different beast. Fire
mplayer again, navigate to a part in the movie with lots
of action, and hit the DOT key (.). This will pause the
movie, and each time you hit it again, it will step exactly one
frame. If the frames you see this way are clean, you don't need
any deinterlacer ; if they appear to be "combed", you do. I could
rant about the way to deinterlace for hours, but basically,
you'll either be content with something as simple as

heaven:/var/tmp/video$ mplayer -vf pp=lb ...

or, if its an NTSC telecined one, with

heaven:/var/tmp/video$ mplayer -vf detc -ofps 23.976 ...

The latter one is the one you need for the dolby-city
trailer. It is a telecined beast, so it needs one heck of a filter
to get back to progressive.

3.2.3. Scaling

Finally, we 'll probably have to scale the
video. How do we decide whether we want to, or not?

Mencoder's documentation suggests against this; the authors
feel that frame scaling is too much tampering with the original
video, and that this is bad. They are over-reacting; we are doing
this to squeeze more data in less storage, and doing this at the
extreme level we want to simply REQUIRES scaling (unless we are
targeting video bitrates more than 1MBit/sec, but then, why
bother with H264 and not stick to MPEG4?)

To cut a very long story short, it was pointless to encode
with MPEG4 - i.e. XVID, DIVX, or ffmpeg - to bitrates less than
0.2 bits per pixel. With H264, this changes: we can go lower,
e.g. 0.125 bits per pixel and still get acceptable quality.

In dolby-city.vob, the original frame size is 720x480
pixels, at a (progressive, after deinterlacing) frame rate of
23.976 fps. This means that we would need at least

720 x 480 x 23,976 x 0,125 = 1035763,2 bits per second

... if we were to avoid scaling. This bitrate is too high, we
can't even fit a 2 hour movie in a 700MB CD with this rate.
Since our movie has a 4:3 aspect ratio, we can simply scale to a
smaller window, like

512 x 384 x 23,976 x 0,125 = 589234,176 bits per second

Notice that at this bitrate, we would be able
to fit 2.5 hours of movie time in one 700MB CD, since

...which would fit nicely in our 700MB target size (thanks to
Matroska's near zero cost multiplexing).
Notice also that we chose multiples of 16 for our frame sizes:
this is not a whim, it's a requirement of almost all codecs.

3.2.4. Using all filters

So, to actually do this, we'll
use three mencoder filters:

-vf crop=704:464:8:8,detc,scale=512:384

The reason we are first cropping, then deinterlacing and
finally scaling, should be obvious.
We can now complete the sequence with the H264 encoding
parameters.

I won't bother explaining why you should always use two
passes, just read the relevant info (or trust me):

4. Multiplexing

You might need to synchronize video and audio; check the
manpage for mkvmerge and learn how to use the -y switch. Or better yet,
use the script: it utilizes mencoder in a way that guarantees video
and audio will be in sync.

5. Using the script

You might
consider the previous steps tiresome.
You are right; they are; and if you make one mistake along the
line, you could end up spending CPU time for unacceptable
results.

That's why I coded a very simple Perl script that glues
together all that you've seen.
Download it here and use it like
this: (Update, August 2007: Thanks to Benjamin Pineau, if you are
using the latest versions of mplayer and mkvmerge, you can download a
patch here to support them)

heaven:/var/tmp/video$ vobs2mkv.pl dolby-city.vob 3 Perfect.mkv

...which requests an encoding of the dolby-city.vob
movie, and a generation of file Perfect.mkv with a
size around 3 MBytes.
Follow the prompts it shows; they should be self explanatory.
If they are not, hey, check the code! I only use simple aspects
of Perl, so you should be able to figure out what goes on
(it works for me with all the files I tried).

It also attempts
to rip any MPEG2 subtitles existing in the stream to VOBSUB files,
thus allowing a "perfect" rip; optimal video/audio/subtitle encoding.

This is the output (including the answers I gave) for
'dolby-city.vob':

6. Comparison with MPEG4

Since the script allows you to select the codec used, try encoding your own
videos around 0.125 bits per pixel with both MPEG4 and H.264. You won't be
needing any screenshots for proof - your eyes will tell you that there's
only one obstacle for widespread H.264 adoption: encoding speed. Currently,
it is 2-5 times slower than MPEG4 encoding (depending on video type and
CPU used). Let's hope x264 coders will improve the codec's speed over time.

The comments on this website require the use of JavaScript. Perhaps your browser isn't
JavaScript capable or the script is not being run for another reason. If you're
interested in reading the comments or leaving a comment behind please try again with a
different browser or from a different connection.