[MPlayer-users] Call for volunteers (was: Re: [MPlayer-mwn] Just wondering...)
Martin Pavon
martin_199ar at yahoo.com.ar
Sun Dec 15 20:23:40 CET 2002
On Sat, Dec 14, 2002 at 03:31:30PM +0100, Diego Biurrun wrote:
> Excellent idea indeed, so here goes out a call for volunteers:
>
> If you like our player and would like to contribute something back but
> don't have much time or relevant skills, why not write up a short
> summary of a thread on mplayer-users you found useful? Please send it
> to mplayer-mwn or one of the developers like me or Alex. This should
> not be a lot of work and it does not have to be perfect, we will fix
> it up, don't worry.
> Thanks
>
> Diego
>
Hi Diego !!!
I'had made a quick cut & paste of interestings answers for my use. I don't
know if this is what you want; but may be a begin.
Regards,
Martín
PS: The first tip is a part of a mail from Moritz Bunkus, there are two
perl scripts quoted, may be someone can add them to contrib (if moritz
says that is OK of course)
PS 2: Since I cut parts of the mails, I don't know if is a good idea
preserve the name of the authors, or ask for their OK or ...
--
Martín Pavón
martin_199ar at yahoo.com.ar
http://mate.dm.uba.ar/~mpavon/
-------------- next part --------------
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 \
-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 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)
===========
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, andTo 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.
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?).
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 -vop 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. Key frames are significantly larger than P or B frames, so the
less key frames 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 TVout). 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
More information about the MPlayer-users
mailing list