mirror of
https://github.com/mpv-player/mpv
synced 2024-12-24 15:52:25 +00:00
7b83b07bea
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25772 b3059339-0415-0410-9bf9-f77b7e298cf2
726 lines
34 KiB
Plaintext
726 lines
34 KiB
Plaintext
|
|
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.
|
|
|
|
> The "counting the quantesizer"-thing could improve the quality of
|
|
> full automated scripts, as I understand ?
|
|
|
|
Yes, the log file analysis can be used be tools to automatically adjust
|
|
the scaling parameters (if you'd do that you'd end up with a three-pass
|
|
encoding for the video only ;)), but it can also provide answers for
|
|
you as a human. From time to time there's a question like 'hey,
|
|
mencoder creates files that are too small! I specified this bitrate and
|
|
the resulting file is 50megs short of the target file size!'. The
|
|
reason is probably that the codec already uses the minimum quantizer
|
|
for nearly all frames so it simply does not need more bits. A quick
|
|
glance at the distribution of the quantizers can be enlightening.
|
|
|
|
Another thing is that q=2 and q=3 look really good while the 'bigger'
|
|
quantizers really lose quality. So if your distribution shows the
|
|
majority of quantizers at 4 and above then you should probably decrease
|
|
the resolution (you'll definitly see block artefacts).
|
|
|
|
|
|
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)
|
|
|
|
===========
|
|
ANOTHER APPROACH: BITS PER BLOCK:
|
|
|
|
> $videobitrate * 1000
|
|
> $bpp = -----------------------
|
|
> $width * $height * $fps
|
|
|
|
Well, I came to similar equation going through different route. Only I
|
|
didn't use bits per pixel, in my case it was bits per block (BPB). The block
|
|
is 16x16 because lots of software depends on video width/height being
|
|
divisable by 16. And because I didn't like this 0.2 bit per pixel, when
|
|
bit is quite atomic ;)
|
|
|
|
So the equation was something like:
|
|
|
|
bitrate
|
|
bpb = -----------------
|
|
fps * ((width * height) / (16 * 16))
|
|
|
|
(width and height are from destination video size, and bitrate is in
|
|
bits (i.e. 900kbps is 900000))
|
|
|
|
This way it apeared that the minimum bits per block is ~40, very
|
|
good results are with ~50, and everything above 60 is a waste of bandwidth.
|
|
And what's actually funny is that it was independent of codec used. The
|
|
results were exactly the same, whether I used DIV3 (with tricky nandub's
|
|
magick), ffmpeg odivx, DivX5 on Windows or XviD.
|
|
|
|
Surprisingly there is one advantage of using nandub-DIV3 for bitrate
|
|
starved encoding: ringing almost never apears this way.
|
|
|
|
But I also found out, that the quality/BPB isn't constant for
|
|
drastically different resolutions. Smaller picture (like MPEG1 sizes)
|
|
need more BPB to look good than say typical MPEG2 resolutions.
|
|
|
|
Robert
|
|
|
|
|
|
===========
|
|
DON'T SCALE DOWN TOO MUCH
|
|
|
|
Sometimes I found that encoding to y-scaled only DVD qualty (ie 704 x
|
|
288 for a 2.85 film) gives better visual quality than a scaled-down
|
|
version even if the quantizers are significantly higher than for the
|
|
scaled-down version.
|
|
Keep in mind that blocs, fuzzy parts and generaly mpeg artefacts in a
|
|
704x288 image will be harder to spot in full-screen mode than on a
|
|
512x208 image. In fact I've see example where the same movie looks
|
|
better compressed to 704x288 with an average weighted quantizer of
|
|
~3 than the same movie scaled to 576x240 with an average weighted
|
|
quantizer of 2.4.
|
|
Btw, a print of the weighted average quantizer would be nice in
|
|
countquant.pl :)
|
|
|
|
Another point in favor of not trying to scale down too much : on hard
|
|
scaled-down movies, the MPEG codec will need to compress relatively
|
|
high frequencies rather than low frequencies and it doesn't like that
|
|
at all. You will see less and less returns while you scale down and
|
|
scale down again in desesperate need of some bandwidth :)
|
|
|
|
In my experience, don't try to go below a width of 576 without closely
|
|
watching what's going on.
|
|
|
|
--
|
|
Rémi
|
|
|
|
===========
|
|
TIPS FOR ENCODING
|
|
|
|
That being said, with video you have some tradeoffs you can make. Most
|
|
people seem to encode with really basic options, but if you play with
|
|
single coefficient elimination and luma masking settings, you can save lots
|
|
of bits, resulting in lower quantizers, which means less blockiness and
|
|
less ugly noise (ringing) around sharp borders. The tradeoff, however, is
|
|
that you'll get some "muddiness" in some parts of the image. Play around
|
|
with the settings and see for yourself. The options I typically use for
|
|
(non-animated) movies are:
|
|
|
|
vlelim=-4
|
|
vcelim=9
|
|
lumi_mask=0.05
|
|
dark_mask=0.01
|
|
|
|
If things look too muddy, making the numbers closer to 0. For anime and
|
|
other animation, the above recommendations may not be so good.
|
|
|
|
Another option that may be useful is allowing four motion vectors per
|
|
macroblock (v4mv). This will increase encoding time quite a bit, and
|
|
last I checked it wasn't compatible with B frames. AFAIK, specifying
|
|
v4mv should never reduce quality, but it may prevent some old junky
|
|
versions of DivX from decoding it (can anyone conform?). Another issue
|
|
might be increased cpu time needed for decoding (again, can anyone
|
|
confirm?).
|
|
|
|
To get more fair distribution of bits between low-detail and
|
|
high-detail scenes, you should probably try increasing vqcomp from the
|
|
default (0.5) to something in the range 0.6-0.8.
|
|
|
|
Of course you also want to make sure you crop ALL of the black border and
|
|
any half-black pixels at the edge of the image, and make sure the final
|
|
image dimensions after cropping and scaling are multiples of 16. Failing to
|
|
do so will drastically reduce quality.
|
|
|
|
Finally, if you can't seem to get good results, you can try scaling the
|
|
movie down a bit smaller or applying a weak gaussian blur to reduce the
|
|
amount of detail.
|
|
|
|
Now, my personal success story! I just recently managed to fit a beautiful
|
|
encode of Kundun (well over 2 hours long, but not too many high-motion
|
|
scenes) on one cd at 640x304, with 66 kbit/sec abr ogg audio, using the
|
|
options I described above. So, IMHO it's definitely possible to get very
|
|
good results with libavcodec (certainly MUCH better than all the idiot
|
|
"release groups" using DivX3 make), as long as you take some time to play
|
|
around with the options.
|
|
|
|
|
|
Rich
|
|
|
|
============
|
|
ABOUT VLELIM, VCELIM, LUMI_MASK AND DARK_MASK PART I: LUMA & CHROMA
|
|
|
|
|
|
The l/c in vlelim and vcelim stands for luma (brightness plane) and chroma
|
|
(color planes). These are encoded separately in all mpeg-like algorithms.
|
|
Anyway, the idea behind these options is (at least from what I understand)
|
|
to use some good heuristics to determine when the change in a block is less
|
|
than the threshold you specify, and in such a case, to just encode the
|
|
block as "no change". This saves bits and perhaps speeds up encoding. Using
|
|
a negative value for either one means the same thing as the corresponding
|
|
positive value, but the DC coefficient is also considered. Unfortunately
|
|
I'm not familiar enough with the mpeg terminology to know what this means
|
|
(my first guess would be that it's the constant term from the DCT), but it
|
|
probably makes the encoder less likely to apply single coefficient
|
|
elimination in cases where it would look bad. It's presumably recommended
|
|
to use negative values for luma (which is more noticable) and positive for
|
|
chroma.
|
|
|
|
The other options -- lumi_mask and dark_mask -- control how the quantizer
|
|
is adjusted for really dark or bright regions of the picture. You're
|
|
probably already at least a bit familiar with the concept of quantizers
|
|
(qscale, lower = more precision, higher quality, but more bits needed to
|
|
encode). What not everyone seems to know is that the quantizer you see
|
|
(e.g. in the 2pass logs) is just an average for the whole frame, and lower
|
|
or higher quantizers may in fact be used in parts of the picture with more
|
|
or less detail. Increasing the values of lumi_mask and dark_mask will cause
|
|
lavc to aggressively increase the quantizer in very dark or very bright
|
|
regions of the picture (which are presumably not as noticable to the human
|
|
eye) in order to save bits for use elsewhere.
|
|
|
|
Rich
|
|
|
|
===================
|
|
ABOUT VLELIM, VCELIM, LUMI_MASK AND DARK_MASK PART II: VQSCALE
|
|
|
|
OK, a quick explanation. The quantizer you set with vqscale=N is the
|
|
per-frame quantizer parameter (aka qp). However, with mpeg4 it's
|
|
allowed (and recommended!) for the encoder to vary the quantizer on a
|
|
per-macroblock (mb) basis (as I understand it, macroblocks are 16x16
|
|
regions composed of 4 8x8 luma blocks and 2 8x8 chroma blocks, u and
|
|
v). To do this, lavc scores each mb with a complexity value and
|
|
weights the quantizer accordingly. However, you can control this
|
|
behavior somewhat with scplx_mask, tcplx_mask, dark_mask, and
|
|
lumi_mask.
|
|
|
|
scplx_mask -- raise quantizer on mb's with lots of spacial complexity.
|
|
Spacial complexity is measured by variance of the texture (this is
|
|
just the actual image for I blocks and the difference from the
|
|
previous coded frame for P blocks).
|
|
|
|
tcplx_mask -- raise quantizer on mb's with lots of temporal
|
|
complexity. Temporal complexity is measured according to motion
|
|
vectors.
|
|
|
|
dark_mask -- raise quantizer on very dark mb's.
|
|
|
|
lumi_mask -- raise quantizer on very bright mb's.
|
|
Somewhere around 0-0.15 is a safe range for these values, IMHO. You
|
|
might try as high as 0.25 or 0.3. You should probably never go over
|
|
0.5 or so.
|
|
|
|
Now, about naq. When you adjust the quantizers on a per-mb basis like
|
|
this (called adaptive quantization), you might decrease or (more
|
|
likely) increase the average quantizer used, so that it no longer
|
|
matches the requested average quantizer (qp) for the frame. This will
|
|
result in weird things happening with the bitrate, at least from my
|
|
experience. What naq does is "normalize adaptive quantization". That
|
|
is, after the above masking parameters are applied on a per-mb basis,
|
|
the quantizers of all the blocks are rescaled so that the average
|
|
stays fixed at the desired qp.
|
|
|
|
So, if I used vqscale=4 with naq and fairly large values for the
|
|
masking parameters, I might be likely to see lots of frames using
|
|
qscale 2,3,4,5,6,7 across different macroblocks as needed, but with
|
|
the average sticking around 4. However, I haven't actually tested such
|
|
a setup yet, so it's just speculation right now.
|
|
|
|
Have fun playing around with it.
|
|
|
|
Rich
|
|
|
|
|
|
================================================================================
|
|
|
|
|
|
TIPS FOR ENCODING OLD BLACK & WHITE MOVIES:
|
|
|
|
I found myself that 4:3 B&W old movies are very hard to compress well. In
|
|
addition to the 4:3 aspect ratio which eats lots of bits, those movies are
|
|
typically very "noisy", which doesn't help at all. Anyway :
|
|
|
|
> After a few tries I am
|
|
> still a little bit disappointed with the video quality. Since it is a
|
|
> "dark" movies, there is a lot of black on the pictures, and on the
|
|
> encoded avi I can see a lot of annoying "mpeg squares". I am using
|
|
> avifile codec, but the best I think is to give you the command line I
|
|
> used to encode a preview of the result:
|
|
|
|
>
|
|
> First pass:
|
|
> mencoder TITLE01-ANGLE1.VOB -oac copy -ovc lavc -lavcopts
|
|
> vcodec=mpeg4:vhq:vpass=1:vbitrate=800:keyint=48 -ofps 23.976 -npp lb
|
|
> -ss 2:00 -endpos 0:30 -vf scale -zoom -xy 640 -o movie.avi
|
|
|
|
1) keyint=48 is way too low. The default value is 250, this is in *frames*
|
|
not seconds. Keyframes are significantly larger than P or B frames, so the
|
|
less keyframes you have, better the overall movie will be. (huh, like Yoda
|
|
I speak ;). Try keyint=300 or 350. Don't go beyond that if you want
|
|
relatively precise seeking.
|
|
|
|
2) you may want to play with vlelim and vcelim options. This can gives you
|
|
a significant "quality" boost. Try one of these couples :
|
|
|
|
vlelim=-2:vcelim=3
|
|
vlelim=-3:vcelim=5
|
|
vlelim=-4:vcelim=7
|
|
(and yes, there's a minus)
|
|
|
|
3) crop & rescale the movie before passing it to the codec. First crop the
|
|
movie to not encode black bars if there's any. For a 1h40mn movie
|
|
compressed to a 700 MB file, I would try something between 512x384 and
|
|
480x320. Don't go below that if you want something relatively sharp when
|
|
viewed fullscreen.
|
|
|
|
4) I would recommend using the Ogg Vorbis audio codec with the .ogm
|
|
container format. Ogg Vorbis compress audio better than MP3. On a typical
|
|
old, mono-only audio stream, a 45 kbits/s Vorbis stream is ok. How to
|
|
extract & compress an audio stream from a ripped DVD (mplayer dvd://1
|
|
-dumpstream) :
|
|
|
|
rm -f audiodump.pcm ; mkfifo -m 600 audiodump.pcm
|
|
mplayer -quiet -vc null -vo null -aid 128 -ao pcm -nowaveheader stream.dump &
|
|
oggenc --raw --raw-bits=16 --raw-chan=2 --raw-rate=48000 -q 1 -o audio-us.ogg
|
|
+audiodump.pcm &
|
|
wait
|
|
|
|
For a nice set of utilities to manager the .ogm format, see Moritz Bunkus'
|
|
ogmtools (google is your friend).
|
|
|
|
5) use the "v4mv" option. This could gives you a few more bits at the
|
|
expense of a slightly longer encoding. This is a "lossless" option, I mean
|
|
with this option you don't throw away some video information, it just
|
|
selects a more precise motion estimation method. Be warned that on some
|
|
very un-typical scenes this option may gives you a longer file than
|
|
without, although it's very rare and on a whole film I think it's always a
|
|
win.
|
|
|
|
6) you can try the new luminance & darkness masking code. Play
|
|
with the "lumi_mask" and "dark_mask" options. I would recommend using
|
|
something like :
|
|
lumi_mask=0.07:dark_mask=0.10:naq:
|
|
lumi_mask=0.10:dark_mask=0.12:naq:
|
|
lumi_mask=0.12:dark_mask=0.15:naq
|
|
lumi_mask=0.13:dark_mask=0.16:naq:
|
|
Be warned that these options are really experimental and the result
|
|
could be very good or very bad depending on your visualization device
|
|
(computer CRT, TV or TFT screen). Don't push too hard these options.
|
|
|
|
> Second pass:
|
|
> the same with vpass=2
|
|
|
|
7) I've found that lavc gives better results when the first pass is done
|
|
with "vqscale=2" instead of a target bitrate. The statistics collected
|
|
seems to be more precise. YMMV.
|
|
|
|
> I am new to mencoder, so please tell me any idea you have even if it
|
|
> obvious. I also tried the "gray" option of lavc, to encode B&W only,
|
|
> but strangely it gives me "pink" squares from time to time.
|
|
|
|
Yes, I've seen that too. Playing the resulting file with "-lavdopts gray"
|
|
fix the problem but it's not very nice ...
|
|
|
|
> So if you could tell me what option of mencoder or lavc I should be
|
|
> looking at to lower the number of "squares" on the image, it would be
|
|
> great. The version of mencoder i use is 0.90pre8 on a macos x PPC
|
|
> platform. I guess I would have the same problem by encoding anime
|
|
> movies, where there are a lot of region of the image with the same
|
|
> color. So if you managed to solve this problem...
|
|
|
|
You could also try the "mpeg_quant" flag. It selects a different set of
|
|
quantizers and produce somewhat sharper pictures and less blocks on large
|
|
zones with the same or similar luminance, at the expense of some bits.
|
|
|
|
> This is completely off topic, but do you know how I can create good
|
|
> subtitles from vobsub subtitles ? I checked the -dumpmpsub option of
|
|
> mplayer, but is there a way to do it really fast (ie without having to
|
|
> play the whole movie) ?
|
|
|
|
I didn't find a way under *nix to produce reasonably good text subtitles
|
|
from vobsubs. OCR *nix softwares seems either not suited to the task, not
|
|
powerful enough or both. I'm extracting the vobsub subtitles and simply use
|
|
them with the .ogm
|
|
|
|
/ .avi :
|
|
1) rip the DVD to harddisk with "mplayer dvd://1 -dumpstream"
|
|
2) mount the DVD and copy the .ifo file
|
|
2) extract all vobsubs to one single file with something like :
|
|
|
|
for f in 0 1 2 3 4 5 6 7 8 9 10 11 ; do \
|
|
mencoder -ovc copy -oac copy -o /dev/null -sid $f -vobsubout sous-titres
|
|
+-vobsuboutindex $f -ifo vts_01_0.ifo stream.dump
|
|
done
|
|
|
|
(and yes, I've a DVD with 12 subtitles)
|
|
--
|
|
Rémi
|
|
|
|
|
|
================================================================================
|
|
|
|
|
|
TIPS FOR SMOKE & CLOUDS
|
|
|
|
Q: I'm trying to encode Dante's Peak and I'm having problems with clouds,
|
|
fog and smoke: They don't look fine (they look very bad if I watch the
|
|
movie in TV-out). There are some artifacts, white clouds looks as snow
|
|
mountains, there are things likes hip in the colors so one can see frontier
|
|
curves between white and light gray and dark gray ... (I don't know if you
|
|
can understand me, I want to mean that the colors don't change smoothly)
|
|
In particular I'm using vqscale=2:vhq:v4mv
|
|
|
|
A: Try adding "vqcomp=0.7:vqblur=0.2:mpeg_quant" to lavcopts.
|
|
|
|
Q: I tried your suggestion and it improved the image a little ... but not
|
|
enough. I was playing with different options and I couldn't find the way.
|
|
I suppose that the vob is not so good (watching it in TV trough the
|
|
computer looks better than my encoding, but it isn't a lot of better).
|
|
|
|
A: Yes, those scenes with qscale=2 looks terrible :-(
|
|
|
|
Try with vqmin=1 in addition to mpeg_quant:vlelim=-4:vcelim=-7 (and maybe
|
|
with "-sws 10 -ssf ls=1" to sharpen a bit the image) and read about vqmin=1
|
|
in DOCS/tech/libavc-options.txt.
|
|
|
|
If after the whole movie is encoded you still see the same problem, it will
|
|
means that the second pass didn't picked-up q=1 for this scene. Force q=1
|
|
with the "vrc_override" option.
|
|
|
|
Q: By the way, is there a special difficult in encode clouds or smoke?
|
|
|
|
A: I would say it depends on the sharpness of these clouds / smokes and the
|
|
fact that they are mostly black/white/grey or colored. The codec will do
|
|
the right thing with vqmin=2 for example on a cigarette smoke (sharp) or on
|
|
a red/yellow cloud (explosion, cloud of fire). But may not with a grey and
|
|
very fuzzy cloud like in the chocolat scene. Note that I don't know exactly
|
|
why ;)
|
|
|
|
A = Rémi
|
|
|
|
|
|
================================================================================
|
|
|
|
|
|
TIPS FOR TWEAKING RATECONTROL
|
|
|
|
(For the purpose of this explanation, consider "2nd pass" to be any beyond
|
|
the 1st. The algorithm is run only on P-frames; I- and B-frames use QPs
|
|
based on the adjacent P. While x264's 2pass ratecontrol is based on lavc's,
|
|
it has diverged somewhat and not all of this is valid for x264.)
|
|
|
|
Consider the default ratecontrol equation in lavc: "tex^qComp".
|
|
At the beginning of the 2nd pass, rc_eq is evaluated for each frame, and
|
|
the result is the number of bits allocated to that frame (multiplied by
|
|
some constant as needed to match the total requested bitrate).
|
|
|
|
"tex" is the complexity of a frame, i.e. the estimated number of bits it
|
|
would take to encode at a given quantizer. (If the 1st pass was CQP and
|
|
not turbo, then we know tex exactly. Otherwise it is calculated by
|
|
multiplying the 1st pass's bits by the QP of that frame. But that's not
|
|
why CQP is potentially good; more on that later.)
|
|
"qComp" is just a constant. It has no effect outside the rc_eq, and is
|
|
directly set by the vqcomp parameter.
|
|
|
|
If vqcomp=1, then rc_eq=tex^1=tex, so 2pass allocates to each frame the
|
|
number of bits needed to encode them all at the same QP.
|
|
If vqcomp=0, then rc_eq=tex^0=1, so 2pass allocates the same number of
|
|
bits to each frame, i.e. CBR. (Actually, this is worse than 1pass CBR in
|
|
terms of quality; CBR can vary within its allowed buffer size, while
|
|
vqcomp=0 tries to make each frame exactly the same size.)
|
|
If vqcomp=0.5, then rc_eq=sqrt(tex), so the allocation is somewhere
|
|
between CBR and CQP. High complexity frames get somewhat lower quality
|
|
than low complexity, but still more bits.
|
|
|
|
While the actual selection of a good value of vqcomp is experimental, the
|
|
following underlying factors determine the result:
|
|
Arguing towards CQP: You want the movie to be somewhere approaching
|
|
constant quality; oscillating quality is even more annoying than constant
|
|
low quality. (However, constant quality does not mean constant PSNR nor
|
|
constant QP. Details are less noticeable in high-motion scenes, so you can
|
|
get away with somewhat higher QP in high-complexity frames for the same
|
|
perceived quality.)
|
|
Arguing towards CBR: You get more quality per bit if you spend those bits
|
|
in frames where motion compensation works well (which tends to be
|
|
correlated with "tex"): A given artifact may stick around several seconds
|
|
in a low-motion scene, and you only have to fix it in one frame to improve
|
|
the quality of the whole sequence.
|
|
|
|
Now for why the 1st pass ratecontrol method matters:
|
|
The number of bits at constant quant is as good a measure of complexity as
|
|
any other simple formula for the purpose of allocating bits. But it's not
|
|
perfect for predicting which QP will produce the desired number of bits.
|
|
Bits are approximately inversely proportional to QP, but the exact scaling
|
|
is non-linear, and depends on the amount of detail/noise, the complexity of
|
|
motion, the quality of previous frames, and other stuff not measured by the
|
|
ratecontrol. So it predicts best when the QP used for a given frame in the
|
|
2nd pass is close to the QP used in the 1st pass. When the prediction is
|
|
wrong, lavc needs to distribute the surplus or deficit of bits among future
|
|
frames, which means that they too deviate from the planned distribution.
|
|
Obviously, with vqcomp=1 you can get the 1st pass QPs very close by using
|
|
CQP, and with vqcomp=0 a CBR 1st pass is very close. But with vqcomp=0.5
|
|
it's more ambiguous. The accepted wisdom is that CBR is better for
|
|
vqcomp=0.5, mostly because you then don't have to guess a QP in advance.
|
|
But with vqcomp=0.6 or 0.7, the 2nd pass QPs vary less, so a CQP 1st pass
|
|
(with the right QP) will be a better predictor than CBR.
|
|
|
|
To make it more confusing, 1pass CBR uses the same rc_eq with a different
|
|
meaning. In CBR, we don't have a real encode to estimate from, so "tex" is
|
|
calculated from the full-pixel precision motion-compensation residual.
|
|
While the number of bits allocated to a given frame is decided by the rc_eq
|
|
just like in 2nd pass, the target bitrate is constant (instead of being the
|
|
sum of per-frame rc_eq values). So the scaling factor (which is constant in
|
|
2nd pass) now varies in order to keep the local average bitrate near the
|
|
CBR target. So vqcomp does affect CBR, though it only determines the local
|
|
allocation of bits, not the long-term allocation.
|
|
|
|
--Loren Merritt
|