[MPlayer-DOCS] XviD encoding guide

[Guillaume POIRIER]

Hi,

On 6/23/05, The Wanderer <inverseparadox at comcast.net> wrote:
> Guillaume POIRIER wrote:
> 
> > Hello everyone,
> > Please find in this mail the first part of XviD's encoding guide. It
> > lacks the description of more advanced options of MPEG-4 ASP, the
> > PSNR and speed delta to expect from each option (which would require
> > me to run some benchmarks, but I'm time-shorted right now, so I'll do
> > that later), and some encoding examples.
> >
> > I think that this is a decent starting point, so here it is, for
> > review and inclusion in our main doc.
> 
> Well, I wasn't going to get to this for a few days (since it seemed
> large at a glance - I no longer know why, but it did), because of quirks
> of my work schedule - but I was sitting here looking for things to do to
> postpone going to bed, and you mentioned my name so here I am. ^_^

:-) Thanks. I'll remember that next time I need you, I just need to
shout your name, like "Beetle Juice", or light up a big light with
your name on it, like "Batman".
:-)))


> (After writing: That was just as much of a job as I'd expected it to be.
> Still, that just meant it needed to be done that much more, eh?)

:-)


> >  <emphasis role="bold">vhq</emphasis>
> >    Default setting may be safely used for every encode, while higher
> >    settings always help PSNR, but are significantly slower.
> 
> Hmp. Looks like I may have been wrong all this time about what "vhq"
> actually means - I took it to be an acronym for "very high quality",
> intended to signify that "this option improves quality per unit
> filesize", but if the description in the XviD section of the man page
> (which I actually hadn't read before) is accurate then it appears to
> stand for something like "vertical/horizontal quantizer", which would be
> much different.

I'm not sure what it could mean other than Very High Quality. One guy
told me that this option and the algorithm behind it has been
originally taken from lavc, and to the best of my knowledge, in lavc
it means Very High Quality.

Anyway, I updated the description paragraph to explain a bit what it does.

[..]

> >  <emphasis role="bold">trellis</emphasis>
> >    Optimizes the motion estimation and allows significant bit saving
> >    which would be spent elsewhere on the video, raising overall visual
> >    quality.
> 
> As this stands it says that bit saving would be spent on video - and it
> sounds odd to me to say that "saving" would (apparently implying, would
> otherwise) be "spent". I don't see any fixes which don't involve
> rephrasing the entire sentence and/or considerably simplifying its
> technical aspect; I thought I had one such rephrasing fix a moment ago,
> but it doesn't come to mind, so if you can suggest one - or something
> less intrusive - please feel free.

I re-wrote part of that paragraph, which description was false anyway.
Thanks to you pointing it out, it's now hopefully fixed.


[..]
> >  <emphasis role="bold">chroma_me</emphasis>
> >    Improves motion estimation by taking the chroma (the color)
> >    information into account, when <option>me_quality</option> alone
> >    only uses luma (greyscale).
> 
> Repetition of "the" w.r.t. "chroma" and "color"; I'd probably drop the
> one in the parentheses.
> 
> Does this option have the described effect only at times when me_quality
> is only using luma? If not, then the word you probably want is
> "whereas".

I'm not sure what you mean here, but what I'm trying to say is that
chroma_me add the chroma plane into account, when if only me_quality
is enabled, only luma is  taken into account.

Now the question here might be: what happens if I enable chroma_me and
reduce me_quality. My answer would be: "don't".


> Other than that, looks good, except for one general comment: most of the
> option sections start with a one-sentence (or fragment-sentence)
> description of what the option does, but the "vhq" option begins with a
> comment about the option's default. For general consistency it should
> probably be changed to parallel the others.

This is hopefully now all fixed.

Here is then the updated doc, which I'll commit tonight, along with
every new suggestion that might be sent meanwhile.

Regards,
Guillaume

<sect1 id="menc-feat-xvid">
<title>Encoding with the <systemitem class="library">XviD</systemitem>
codec</title>
<para>
  <systemitem class="library">XviD</systemitem> is a free library for
  encoding MPEG-4 ASP video streams.
 Before starting to encode, you need to <link linkend="xvid">
  set up <application>MEncoder</application> to support it</link>.
</para>
<para>
 This guide mainly aims at featuring the same kind of information
 as x264's encoding guide.
 Therefore, please begin by reading
 <link linkend="menc-feat-x264-intro">the first part</link> of that
 guide.
</para>

<sect2 id="menc-feat-xvid-intro">
<title>What options should I use to get the best results?</title>

<para>
 Please begin by reviewing the
  <systemitem class="library">XviD</systemitem> section of
  <application>MPlayer</application>'s man page.
 This section is intended to be a supplement to the man page.
</para>
<para>
  The XviD default settings are already a good trade-off between
 speed and quality, therefore you can safely stick to them if
 the following section puzzles you.
</para>
</sect2>

<sect2 id="menc-feat-xvid-encoding-options">
<title>Encoding options of <systemitem class="library">XviD</systemitem></title>

<itemizedlist>

<listitem><para>
  <emphasis role="bold">vhq</emphasis>
   This setting affects the macroblock decision algorithm, where the
   higher the setting, the more the wiser the decision.
   The default setting may be safely used for every encode, while
   higher settings always help PSNR but are significantly slower.
   Please note that a better PSNR does not necessarily mean
   that the picture will look better, but tells you that it is
   closer to the original.
   Turning it off will noticeably speed up encoding; if speed is
   critical for you, the tradeoff may be worth it.
</para></listitem>

<listitem><para>
  <emphasis role="bold">bvhq</emphasis>
   This does the same job as vhq, but does it on B-frames.
   It has a negligible impact on speed, and slightly improves quality
   (around +0.1dB PSNR).
</para></listitem>

<listitem><para>
 <emphasis role="bold">max_bframes</emphasis>
   A higher number of consecutive allowed B-frames usually improves
   compressibility, although it may also lead to more blocking artifacts.
   The default setting is a good trade-off between compressibility and
   quality, but you may increase it up to 3 if you're bitrate-starved.
   You may also decrease it to 1 or 0 if you're aiming at perfect
   quality, though in that case you should make sure your
   target bitrate is high enough to ensure that the encoder doesn't
   have to increase quantizers to reach it.
</para></listitem>

<listitem><para>
 <emphasis role="bold">bf_threshold</emphasis>
   This controls the B-frame sensitivity of the encoder, where a higher
   value leads to more B-frames being used (and vice versa).
   This setting is to be used together with <option>max_bframes</option>;
   if you are bitrate-starved, you should increase both
   <option>max_bframes</option> and <option>bf_threshold</option>,
   while you may increase <option>max_bframes</option> and reduce
   <option>bf_threshold</option> so that the encoder may use more
   B-frames in places that only <emphasis role="bold">really</emphasis>
   need them.
   A low number of <option>max_bframes</option> and a high value of
   <option>bf_threshold</option> is probably not a wise choice as it
   will force the encoder to put B-frames in places that would not
   benefit from them, therefore reducing visual quality.
   However, if you need to be compatible with standalone players that
   only supports old DivX profiles (which only supports up to 1
   consecutive B-frame), this would be your only way to
   increase compressibility through using B-frames.
</para></listitem>

<listitem><para>
 <emphasis role="bold">trellis</emphasis>
   Optimizes the quantization process to get a optimal tradeoff
   between PSNR and bitrate, which allows significant bit saving.
   These bit will in return be spent elsewhere on the video,
   raising overall visual quality.
   You should always leave it on as its impact on quality is very
   sensible.
   Even if you're looking for speed, don't disable it until you
   have turned down <option>vhq</option> and all other more
   CPU-hungry options to the minimum.
</para></listitem>

<listitem><para>
 <emphasis role="bold">cartoon</emphasis>
   Designed to better encode cartoon content, and has no impact on
   speed as it just tunes the mode decision heuristics for this type
   of content.
</para></listitem>

<listitem><para>
 <emphasis role="bold">me_quality</emphasis>
   This setting is to control the precision of the motion estimation.
   The higher <option>me_quality</option>, the more
   precise the estimation of the original motion will be, and the
   better the resulting clip will capture the original motion.
 </para>
 <para>
   The default setting is best in all cases;
   thus it's not recommended to turn it down unless you're
   really looking for speed, as all the bits saved by a good motion
   estimation would be spent elsewhere, raising overall quality.
   Therefore, don't go any lower than 5, and even that only as a last
   resort.
</para></listitem>

<listitem><para>
 <emphasis role="bold">chroma_me</emphasis>
   Improves motion estimation by also taking the chroma (color)
   information into account, whereas <option>me_quality</option>
   alone only uses luma (greyscale).
   This slows down encoding by 5-10% but improves visual quality
   quite a bit by reducing blocking effect.
   If you're looking for speed, you should disable this option before
   starting to consider reducing <option>me_quality</option>.
</para></listitem>
</itemizedlist>
</sect2>