[MPlayer-DOCS] XviD encoding guide

Guillaume POIRIER poirierg at gmail.com
Wed Jun 22 14:14:27 CEST 2005


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.

Cheers,
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's 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>
   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 do not necessarily mean
   that the picture will looks better, but tells you that it is
   closer to the original.
   Turning it off will noticeably speed-up encoding if you need speed.
</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 while this may lead to more blocking artifacts.
   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 this 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 sensibility 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>,
   so 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 you only possibility to
   increase compressibility through using B-frames.
</para></listitem>

<listitem><para>
 <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.
   You should always leave it on as its impact on quality is very
   sensible, but if you're looking for speed, only disable it if 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>
   Default setting is best in pretty much all cases, and 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 spend
   elsewhere, raising overall quality.
   Therefore, only go as low as 5, and only as a last resort.
</para></listitem>

<listitem><para>
 <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).
   This slows down encoding by 5-10% but improves quite a bit visual
   quality 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>




More information about the MPlayer-DOCS mailing list