[MPlayer-users] RFC: docs update for "how to create a high quality DVD rip"

[D Richard Felker III]

On Sun, Jun 06, 2004 at 03:31:43PM -0400, Jason Tackaberry wrote:
> In the current documentation, section 7.11 explains how to create a high
> quality DVD rip.  This section was contributed by Samuli Kärkkäinen
> based on an email I'd sent to a friend some time ago.  I've learned a
> few things since then, and find this text is badly in need of an update.
> 
> Before submitting to the MPlayer docs team, I'd like to hear some
> feedback from you guys.  Ping especially Rich, so that he might point
> out any technical errors in his usual, ehm, terse but informative
> manner.

:)

I'm in the process of writing a revised encoding guide too.

> You can read the new section here:
> 
> 	http://sault.org/~tack/menc-feat-dvd-mpeg4.html

3pass mode should NEVER be used, don't even mention that it exists.

Leaving audio as AC3 is often a very stupid idea, especially if it's
only stereo or if you want to rip a long movie. You won't hear the
difference between 96 kbit vorbis and 448 kbit ac3 unless there's lots
of music.

Scaling is good, not bad, when used properly. Your attempt to remain
"as close to the original dvd as possible" is misguided. As long as
you're using a fixed bitrate, scaling down a bit will lose MUCH less
quality than the higher mpeg quantizers will lose.

Your hqdn3d settings are way too light. The defauls seem about
optimal.

If you only care about constant quantizer and/or insane bitrates, I
guess your guide is ok, but IMO it sucks to switch discs 4 times while
watching a movie. And what sucks even more is the bad discontinuities
where a bit of audio or video gets lost or duplicated between the
multiple parts!

> One point I detail is the fact that image dimensions should be a
> multiple of 16.  I've read this in numerous places, and it seems to be
> conventional wisdom.  Unfortunately, I'm not entirely clear on why this
> is the case.  Some inferences:
> 
>      1. If, say, the height offset is a multiple of 16 plus 4 pixels,
>         the latest row of macroblocks will need to be padded with 12
>         rows of pixels, which wastes bits.
>      2. libavcodec sees the padded pixels as black, and so wastes bits
>         preserving a sharp edge that is never seen.
>      3. Some windows (and possibly linux) players can't deal with
>         resolutions not divisible by 16 and crash or show visual errors.
> 
> Now, as far as 1 and 2 are concerned, is this any worse than cropping
> away perfectly good pixels, or scaling video up to the nearest multiple
> of 16?

Yes.

> If so, why?

Because artifacts and higher quantizers are worse than losing a few
irrelevant (probably noisy anyway) pixels at the image edges.

> Or, what's the _real_ reason for the multiple-of-16
> rule?

It's a mix or the information-theoretic problem (wasting space
encoding a whole macroblock for partial data), a mathematical problem
(poor convergence of fourier series near a discontinuity), and
probably also motion estimation issues.

> Secondly, the crop y-offset should be a multiple of 4 if the video is
> interlaced or telecined, but is this still true if deinterlace or pullup
> appears in the filter chain before crop?  It seems to me that after
> deinterlace/pullup, any multiple of 2 is fine, but sometimes these
> things can be elusive so I don't want to make that claim for sure
> without confirmation.

Correct. After deinterlace or pullup you don't have interlaced viceo
anymore, do you? Nope. So rules for interlaced video don't apply.

Rich