[MPlayer-users] Encoding quality advices

Thu Nov 28 19:56:03 CET 2002

Hi everyone.

Encoding quality - or why automatism is bad.

Some days ago someone suggested adding some preset options to mencoder.
At that time I replied 'don't do that', and now I decided to elaborate
on that.

Warning: this is rather long, and it involves mathematics. But if you
don't want to bother with either then why are you encoding in the
first place? Go do something different!

The good news is: it's all about the bpp (bits per pixel).

The bad news is: it's not THAT easy ;)

This mail is about encoding a DVD to MPEG4. It's about the video
quality, not (primarily) about the audio quality or some other fancy
things like subtitles.

The first step is to encode the audio. Why? Well if you encode the
audio prior to the video you'll have to make the video fit onto one
(or two) CD(s). That way you can use oggenc's quality based encoding
mode which is much more sophisticated than its ABR based mode.

After encoding the audio you have a certain amount of space left to
fill with video. Let's assume the audio takes 60M (no problem with
Vorbis), and you aim at a 700M CD. This leaves you 640M for the video.
Let's further assume that the video is 100 minutes or 6000 seconds
long, encoded at 25fps (those nasty NTSC fps values give me
headaches. Adjust to your needs, of course!). This leaves you with
a video bitrate of:

                $videosize * 8 
$videobitrate = --------------
                $length * 1000

$videosize in bytes, $length in seconds, $videobitrate in kbit/s.
In my example I end up with $videobitrate = 895.

And now comes the question: how do I chose my encoding parameters
so that the results will be good? First let's take a look at a
typical mencoder line:

mencoder -dvd 1 -o /dev/null -oac copy -ovc lavc \
  -lavcopts vcodec=mpeg4:vbitrate=1000:vhq:vqmin=2:\
  vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01:vpass=1 \
  -vop scale=640:480,crop=716:572:2:2

Phew, all those parameters! Which ones should I change? NEVER leave
out 'vhq'. Never ever. 'vqmin=2' is always good if you aim for sane
settings - like 'normal length' movies on one CD, 'very long movies'
on two CDs and so on. vcodec=mpeg4 is mandatory.

The 'vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01' are parameters
suggested by D Richard Felker for non-animated movies, and they
improve quality a bit.

But the two things that have the most influence on quality are
vbitate and scale. Why? Because both together tell the codec how
many bits it may spend on each frame for each bit: and this is
the 'bpp' value (bits per pixel). It's simply defined as

         $videobitrate * 1000       
$bpp = -----------------------
       $width * $height * $fps

I've attached a small Perl script that calculates the $bpp for
a movie. You'll have to give it four parameters:
a) the cropped but unscaled resolution (use '-vop cropdetect'),
b) the encoded aspect ratio. All DVDs come at 720x576 but contain
a flag that tells the player wether it should display the DVD at
an aspect ratio of 4/3 (1.333) or at 16/9 (1.777). Have a look
at mplayer's output - there's something about 'prescaling'. That's
what you are looking for.
c) the video bitrate in kbit/s and
d) the fps.

In my example the command line and calcbpp.pl's output would look
like this (warning - long lines ahead):

mosu at anakin:~$ ./calcbpp.pl 720x440 16/9 896 25
Prescaled picture: 1023x440, AR 2.33
720x304, diff   5, new AR 2.37, AR error 1.74% scale=720:304 bpp: 0.164
704x304, diff  -1, new AR 2.32, AR error 0.50% scale=704:304 bpp: 0.167
688x288, diff   8, new AR 2.39, AR error 2.58% scale=688:288 bpp: 0.181
672x288, diff   1, new AR 2.33, AR error 0.26% scale=672:288 bpp: 0.185
656x288, diff  -6, new AR 2.28, AR error 2.17% scale=656:288 bpp: 0.190
640x272, diff   3, new AR 2.35, AR error 1.09% scale=640:272 bpp: 0.206
624x272, diff  -4, new AR 2.29, AR error 1.45% scale=624:272 bpp: 0.211
608x256, diff   5, new AR 2.38, AR error 2.01% scale=608:256 bpp: 0.230
592x256, diff  -2, new AR 2.31, AR error 0.64% scale=592:256 bpp: 0.236
576x240, diff   8, new AR 2.40, AR error 3.03% scale=576:240 bpp: 0.259
560x240, diff   1, new AR 2.33, AR error 0.26% scale=560:240 bpp: 0.267
544x240, diff  -6, new AR 2.27, AR error 2.67% scale=544:240 bpp: 0.275
528x224, diff   3, new AR 2.36, AR error 1.27% scale=528:224 bpp: 0.303
512x224, diff  -4, new AR 2.29, AR error 1.82% scale=512:224 bpp: 0.312
496x208, diff   5, new AR 2.38, AR error 2.40% scale=496:208 bpp: 0.347
480x208, diff  -2, new AR 2.31, AR error 0.85% scale=480:208 bpp: 0.359
464x192, diff   7, new AR 2.42, AR error 3.70% scale=464:192 bpp: 0.402
448x192, diff   1, new AR 2.33, AR error 0.26% scale=448:192 bpp: 0.417
432x192, diff  -6, new AR 2.25, AR error 3.43% scale=432:192 bpp: 0.432
416x176, diff   3, new AR 2.36, AR error 1.54% scale=416:176 bpp: 0.490
400x176, diff  -4, new AR 2.27, AR error 2.40% scale=400:176 bpp: 0.509
384x160, diff   5, new AR 2.40, AR error 3.03% scale=384:160 bpp: 0.583
368x160, diff  -2, new AR 2.30, AR error 1.19% scale=368:160 bpp: 0.609
352x144, diff   7, new AR 2.44, AR error 4.79% scale=352:144 bpp: 0.707
336x144, diff   0, new AR 2.33, AR error 0.26% scale=336:144 bpp: 0.741
320x144, diff  -6, new AR 2.22, AR error 4.73% scale=320:144 bpp: 0.778

A word for the $bpp. For a fictional movie which is only black and
white: if you have a $bpp of 1 then the movie would be stored
uncompressed :) For a real life movie with 24bit color depth you
need compression of course. And the $bpp can be used to make the
decision easier.

As you can see the resolutions suggested by the script are all
dividable by 16. This will make the aspect ratio slightly wrong,
but no one will notice.

Now if you want to decide which resolution (and scaling parameters)
to chose you can do that by looking at the $bpp:

< 0.10: don't do it. Please. I beg you!
< 0.15: It will look bad.
< 0.20: You will notice blocks, but it will look ok.
< 0.25: It will look really good.
> 0.25: It won't really improve visually.
> 0.30: Don't do that either - try a bigger resolution instead.

Of course these values are not absolutes! For movies with really lots
of black areas 0.15 may look very good. Action movies with only high
motion scenes on the other hand may not look perfect at 0.25. But these
values give you a great idea about which resolution to chose.

I see a lot of people always using 512 for the width and scaling
the height accordingly. For my (real-world-)example this would be
simply a waste of bandwidth. The encoder would probably not even
need the full bitrate, and the resulting file would be smaller
than my targetted 700M.

After encoding you'll do your 'quality check'. First fire up the movie
and see whether it looks good to you or not. But you can also do a
more 'scientific' analysis. The second Perl script I attached counts
the quantizers used for the encoding. Simply call it with

countquant.pl < divx2pass.log

It will print out which quantizer was used how often. If you see that
e.g. the lowest quantizer (vqmin=2) gets used for > 95% of the frames
then you can safely increase your picture size.

Well... Several people will probably disagree with me on certain 
points here, especially when it comes down to hard values (like the
$bpp categories and the percentage of the quantizers used). But
the idea is still valid.

And that's why I think that there should NOT be presets in mencoder
like the presets lame knows. 'Good quality' or 'perfect quality' are
ALWAYS relative. They always depend on a person's personal preferences.
If you want good quality then spend some time reading and - more
important - understanding what steps are involved in video encoding.
You cannot do it without mathematics. Oh well, you can, but you'll
end up with movies that could certainly look better.

Now please shoot me if you have any complaints ;)

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: calcbpp.pl
Type: application/x-perl
Size: 1317 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20021128/ed070a21/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: countquant.pl
Type: application/x-perl
Size: 651 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20021128/ed070a21/attachment-0001.bin>