encoding-tips.txt

uclinux下mplayer的源码

Some important URLs:
~~~~~~~~~~~~~~~~~~~~
http://mplayerhq.hu/~michael/codec-features.html               <- lavc vs. divx5 vs. xvid
http://www.ee.oulu.fi/~tuukkat/mplayer/tests/rguyom.ath.cx/    <- lavc benchmarks, options
http://ffdshow.sourceforge.net/tikiwiki/tiki-view_articles.php <- lavc for win32 :)
http://www.bunkus.org/dvdripping4linux/index.html              <- a nice tutorial
http://forum.zhentarim.net/viewtopic.php?p=237                 <- lavc option comparison
http://www.ee.oulu.fi/~tuukkat/mplayer/tests/readme.html       <- series of benchmarks
http://thread.gmane.org/gmane.comp.video.mencoder.user/1196    <- free codecs shoutout and recommended encoding settings


================================================================================


FIXING A/V SYNC WHEN ENCODING

I know this is a popular topic on the list, so I thought I'd share a
few comments on my experience fixing a/v sync. As everyone seems to
know, mencoder unfortunately doesn't have a -delay option. But that
doesn't mean you can't fix a/v sync. There are a couple ways to still
do it.

In example 1, we'll suppose you want to re-encode the audio anyway.
This will be essential if your source audio isn't mp3, e.g. for DVD's
or nasty avi files with divx/wma audio. This approach makes things
much easier.

Step 1: Dump the audio with mplayer -ao pcm -nowaveheader. There are
various options that can be used to speed this up, most notably -vo
null, -vc null, and/or -hardframedrop. -benchmark also seemed to help
in the past. :)

Step 2: Figure out what -delay value syncs the audio right in mplayer.
If this number is positive, use a command like the following:

dd if=audiodump.wav bs=1764 skip=[delay] | lame -x - out.mp3

where [delay] is replaced by your delay amount in hundredths of a
second (1/10 the value you use with mplayer). Otherwise, if delay is
negative, use a command like this:

( dd if=/dev/zero bs=1764 skip=[delay] ; cat audiodump.wav ) | lame -x - out.mp3

Don't include the minus (-) sign in delay. Also, keep in mind you'll
have to change the 1764 number and provide additional options to lame
if your audio stream isn't 44100/16bit/little-endian/stereo.

Step 3: Use mencoder to remux your new mp3 file with the movie:

mencoder -audiofile out.mp3 -oac copy ...

You can either copy video as-is (with -ovc copy) or re-encode it at
the same time you merge in the audio like this.

Finally, as a variation on this method (makes things a good bit faster
and doesn't use tons of temporary disk space) you can merge steps 1
and 2 by making a named pipe called "audiodump.wav" (type mkfifo
audiodump.wav) and have mplayer write the audio to it at the same time
you're running lame to encode.

Now for example 2. This time we won't re-encode audio at all. Just
dump the mp3 stream from the avi file with mplayer -dumpaudio. Then,
you have to cut and paste the raw mp3 stream a bit...

If delay is negative, things are easier. Just use lame to encode
silence for the duration of delay, at the same samplerate and
samplesize used in your avi file. Then, do something like:

cat silence.mp3 stream.dump > out.mp3
mencoder -audiofile out.mp3 -oac copy ...

On the other hand, if delay is positive, you'll need to crop off part
of the mp3 from the beginning. If it's (at least roughly) CBR this is
easy -- just take off the first (bitrate*delay/8) bytes of the file.
You can use the excellent dd tool, or just your favorite
binary-friendly text editor to do this. Otherwise, you'll have to
experiment with cutting off different amounts. You can test with
mplayer -audiofile before actually spending time remuxing/encoding
with mencoder to make sure you cut the right amount.

I hope this has all been informative. If anyone would like to clean
this message up a bit and make it into part of the docs, feel free. Of
course mencoder should eventually just get -delay. :)

Rich


================================================================================


ENCODING QUALITY - OR WHY AUTOMATISM IS BAD.

Hi everyone.

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 \
  -vf crop=716:572:2:2,scale=640:480

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 '-vf 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@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.