encoding-tips.txt

uclinux下mplayer的源码

> 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


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