[MPlayer-DOCS] more x264 encoding guide updates
Jeff Clagg
snacky at ikaruga.co.uk
Sun Jul 3 07:31:20 CEST 2005
First I would like to apologize to anyone who is irritated by my mix of
content, organizational, cosmetic and/or completely pointless changes
(depending on your perspective). If you would like a quick-and-easy text
view of the final results, see
http://ikaruga.co.uk/~snacky/menc-feat-x264.txt
Main changes:
- Reorganized things, options are now divided into "speed vs quality"
and "other" (more or less). subq is now where it belongs.
- subq=6 is documented
- explanation of what 2-pass really does, and why you'd better use it
- mention 3-pass (and the fact that it usually doesn't help)
- documented qcomp
- documented keyint (not like it needed any more explanation, though)
- deblocking parameter tweaking no longer categorized as options that
"affect speed and quality ;)
- updated example cpu requirements for decoding, in codecs.xml
(720x480 @ 1500kbps 50%->35%, for my CPU)
Some things left out:
- bitrate ;)
- nodeblock: not recommended and doesn't belong in this guide.
- nocabac: ditto
- ratetol: I thought I understood what this does, but now I know I
don't. If this is worth adding, it should be added by someone who can
give concrete, verifiable, and accurate suggestions.
- vbv_maxrate, vbv_bufsize: Probably useful for putting a cap on
decoding requirements, but I never bothered to find some example
settings that are useful on common processors. If nobody ever does
that, this issue can be revisited when/if popular hardware decoders
come into use.
- ip_factor, pb_factor: Should probably go in some day.
- qblur: defaults look fine to me and I don't care to mess with it. If
someone thinks this is worth exploring, they should speak up.
- zones: This should be added eventually.
- most macroblock partition analysis flags ((no)i4x4, (no)i8x8,
(no)8x8mv,...): Seems like minor tweaking in most cases, the defaults
are fine for most uses, and this would clutter up the subq section with
even more tangents than it already is already, because these options
interact heavily with subq.
- 8x8dct: This does belong in some day, but as it usually only gains
0.05db, it seems a bit like clutter more than anything else.
- me_range: very little value to adjusting this, imo. Would mostly just
clutter up the guide further.
- chroma_me: miniscule effect
- chroma_qp_offset: potential gains not large enough to go in this guide
- level_idc: probably shouldn't be put in until we find hardware
decoders or something that require it
- threads: (would probably just copy the manpage word for word)
- any discussion of levels/profiles. In practice, none of us should care
- as long as mplayer supports the features used... If some popular
decoders come out which make this discussion relevant, then it should
get its own section maybe.
Another issue: vbv options, qcomp, ip_factor/pb_factor, and keyint (and
analogous keywords for the other libraries) probably all deserve their
own codec-independent discussion. Then, the lavc, xvid, and x264 guides
can all refer to the general discussion, maybe with some slight caveats
for codec-specific stuff.
-------------- next part --------------
Index: DOCS/xml/en/mencoder.xml
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v
retrieving revision 1.72
diff -u -r1.72 mencoder.xml
--- DOCS/xml/en/mencoder.xml 23 Jun 2005 17:25:53 -0000 1.72
+++ DOCS/xml/en/mencoder.xml 3 Jul 2005 04:36:35 -0000
@@ -2119,32 +2119,44 @@
set up <application>MEncoder</application> to support it</link>.
</para>
-<sect2 id="menc-feat-x264-intro">
-<title>What options should I use to get the best results?</title>
+<sect2 id="menc-feat-x264-encoding-options">
+<title>Encoding options of x264</title>
<para>
Please begin by reviewing the
<systemitem class="library">x264</systemitem> section of
<application>MPlayer</application>'s man page.
- This section is intended to be a supplement to the man page.
+ This section is intended to be a supplement to the man page. Here you
+ will find quick hints about which options are most likely to interest
+ most people. The man page is more terse, but also more exhaustive, and
+ it sometimes offers much better technical detail.
</para>
+<sect3 id="menc-feat-x264-encoding-options-intro">
+<title>Introduction</title>
+<para>This guide considers two major categories of encoding options:</para>
+
<orderedlist>
-<title>There are mainly three types of considerations when choosing encoding
- options:</title>
- <listitem><para>Trading off encoding time vs. quality</para></listitem>
- <listitem><para>Frame type decision options</para></listitem>
- <listitem><para>Ratecontrol and quantization decision options</para></listitem>
+ <listitem><para>Options which mainly trade off encoding time vs. quality
+ </para></listitem>
+ <listitem><para>Options which may be useful for fulfilling various personal
+ preferences and special requirements</para></listitem>
</orderedlist>
<para>
- This guide is mostly concerned with the first class of options.
- The other two types often have more to do with personal
- preferences and individual requirements.
+ Ultimately, only you can decide which options are best for your
+ purposes. The decision for the first class of options is the simplest:
+ you only have to decide whether you think the quality differences
+ justify the speed differences. For the second class of options,
+ preferences may be far more subjective, and more factors may be
+ involved. Note that some of the "personal preferences and special
+ requirements" options can still have large impacts on speed or quality,
+ but that isn't what they're primarily useful for. A couple of the
+ "personal preference" options may even cause changes that look better
+ to some people, but look worse to others.
</para>
-
<para>
- Before continuing, please note that this guide uses only one
+ Before continuing, you need to understand that this guide uses only one
quality metric: global PSNR.
For a brief explanation of what PSNR is, see
<ulink url="http://en.wikipedia.org/wiki/PSNR">the Wikipedia article on PSNR</ulink>.
@@ -2153,51 +2165,58 @@
Any time you read a claim about PSNR, one of the assumptions
behind the claim is that equal bitrates are used.
</para>
-
<para>
- Nearly all of this guide's comments assume you are using
- two pass.
- When comparing options, there are two major reasons for using
- two pass encoding.
- First, using two pass often gains around 1dB PSNR, which is a
- very big difference.
- Secondly, testing options by doing direct quality comparisons
- with one pass encodes is a dubious proposition because bitrate
- often varies significantly with each encode.
- It is not always easy to tell whether quality changes are due
- mainly to changed options, or if they mostly reflect
- differences in the achieved bitrate.
+ Nearly all of this guide's comments assume you are using two pass.
+ When comparing options, there are two major reasons for using two pass
+ encoding. First, using two pass often gains around 1dB PSNR, which
+ is a very big difference. Secondly, testing options by doing direct
+ quality comparisons with one pass encodes introduces a major confounding
+ factor: bitrate often varies significantly with each encode. It is not
+ always easy to tell whether quality changes are due mainly to changed
+ options, or if they mostly reflect essentially random differences in
+ the achieved bitrate.
</para>
-<para>
+</sect3>
+
+<sect3 id="menc-feat-x264-encoding-options-speedvquality">
+<title>Options which primarily affect speed and quality</title>
+
+<itemizedlist>
+<listitem><para>
+ <emphasis role="bold">subq</emphasis>:
Of the options which allow you to trade off speed for quality,
- <option>subq</option> and <option>frameref</option> are usually
+ <option>subq</option> and <option>frameref</option> (see below) are usually
by far the most important.
If you are interested in tweaking either speed or quality, these
are the first options you should consider.
-</para>
-
-<para>
On the speed dimension, the <option>frameref</option> and
<option>subq</option> options interact with each other fairly
strongly.
Experience shows that, with one reference frame,
- <option>subq=5</option> takes about 35% more time than
+ <option>subq=5</option> (the default setting) takes about 35% more time than
<option>subq=1</option>.
With 6 reference frames, the penalty grows to over 60%.
<option>subq</option>'s effect on PSNR seems fairly constant
regardless of the number of reference frames.
- Typically, <option>subq=5</option> gains 0.2-0.5 dB
- global PSNR over <option>subq=1</option>.
+ Typically, <option>subq=5</option> achieves 0.2-0.5 dB higher global
+ PSNR in comparison to <option>subq=1</option>.
This is usually enough to be visible.
</para>
-
-</sect2>
-
-<sect2 id="menc-feat-x264-encoding-options">
-<title>Encoding options of x264</title>
-
-<itemizedlist>
+<para>
+ <option>subq=6</option> is the slowest, highest quality mode.
+ In comparison to <option>subq=5</option>, it usually gains 0.1-0.4 dB
+ global PSNR with speed costs varying from 25%-100%, in comparison to
+ <option>subq=5</option>.
+ Unlike other levels of <option>subq</option>, the behavior of
+ <option>subq=6</option> doesn't depend much on <option>frameref</option>
+ and <option>me</option>. Instead, the effectiveness of <option>subq=6
+ </option> depends mostly upon the number of B-frames used. In normal
+ usage, this means <option>subq=6</option> has a large impact on both speed
+ and quality in complex, high motion scenes, but it may not have much effect
+ in low-motion scenes. Note that it is still recommended to always set
+ <option>bframes</option> to something other than zero (see below).
+</para></listitem>
<listitem><para>
<emphasis role="bold">frameref</emphasis>:
<option>frameref</option> is set to 1 by default, but this
@@ -2223,7 +2242,7 @@
will improve global PSNR by a tiny 0.02dB over
<option>frameref=6</option>, at a speed cost of 15%-20%.
At such high <option>frameref</option> values, the only really
- good thing that can be said is that increasing even further will
+ good thing that can be said is that increasing it even further will
almost certainly never <emphasis role="bold">harm</emphasis>
PSNR, but the additional quality benefits are barely even
measurable, let alone perceptible.
@@ -2261,7 +2280,6 @@
This issue is probably extremely rare in live action video material,
but it does sometimes come up in video game captures.
</para></listitem>
-
<listitem><para>
<emphasis role="bold">me</emphasis>:
This option is for choosing the motion estimation search method.
@@ -2282,7 +2300,6 @@
practical use.
</para>
</listitem>
-
<listitem><para>
<emphasis role="bold">4x4mv</emphasis>:
This option enables the use of 8x4, 4x8 and 4x4 subpartitions in
@@ -2293,18 +2310,15 @@
about 0.1dB can be expected.
</para>
</listitem>
-
<listitem><para>
<emphasis role="bold">bframes</emphasis>:
- The usefulness of B-frames is questionable in most other codecs
- you may be used to.
- In H.264, this has changed: there are new techniques and block
- types that are possible in B-frames.
- Usually, even a naive B-frame choice algorithm can have a
- significant PSNR benefit.
- It is interesting to note that using B-frames usually speeds up
- the second pass somewhat, and may also speed up a single pass
- encode if adaptive B-frame decision is turned off.
+ If you are used to encoding with other codecs, you may have found
+ that B-frames are not always useful. In H.264, this has changed:
+ there are new techniques and block types that are possible in B-frames.
+ Usually, even a naive B-frame choice algorithm can have a significant
+ PSNR benefit. It is interesting to note that using B-frames usually
+ speeds up the second pass somewhat, and may also speed up a single
+ pass encode if adaptive B-frame decision is turned off.
</para>
<para>
With adaptive B-frame decision turned off
@@ -2317,14 +2331,13 @@
The encoder rarely chooses to use more than 3 or 4 B-frames;
setting this option any higher will have little effect.
</para></listitem>
-
<listitem><para>
<emphasis role="bold">b_adapt</emphasis>:
Note: This is on by default.
</para>
<para>
- With this option enabled, the encoder will use some simple
- heuristics to reduce the number of B-frames used in scenes that
+ With this option enabled, the encoder will use a reasonably fast
+ decision process to reduce the number of B-frames used in scenes that
might not benefit from them as much.
You can use <option>b_bias</option> to tweak how B-frame-happy
the encoder is.
@@ -2336,7 +2349,6 @@
<option>b_adapt</option> and <option>b_bias</option> have no
effect on subsequent passes.
</para></listitem>
-
<listitem><para>
<emphasis role="bold">b_pyramid</emphasis>:
You might as well enable this option if you are using >=2 B-frames;
@@ -2345,7 +2357,6 @@
Note that these videos cannot be read by libavcodec-based decoders
older than about March 5, 2005.
</para></listitem>
-
<listitem><para>
<emphasis role="bold">weight_b</emphasis>:
In typical cases, there is not much gain with this option.
@@ -2353,8 +2364,8 @@
prediction gives rather large bitrate savings.
In MPEG-4 ASP, a fade-to-black is usually best coded as a series
of expensive I-frames; using weighted prediction in B-frames
- makes it possible to turn at least some of these into much more
- reasonably-sized B-frames.
+ makes it possible to turn at least some of these into much smaller
+ B-frames.
Encoding time cost is minimal, as no extra decisions need to be made.
Also, contrary to what some people seem to guess, the decoder
CPU requirements are not much affected by weighted prediction,
@@ -2365,10 +2376,115 @@
has a strong tendency to avoid B-frames during fades.
Until this changes, it may be a good idea to add
<option>nob_adapt</option> to your x264encopts, if you expect
- fades to have a significant effect in your particular video
+ fades to have a large effect in your particular video
clip.
</para></listitem>
+</itemizedlist>
+</sect3>
+<sect3 id="menc-feat-x264-encoding-options-misc-preferences">
+<title>Options pertaining to miscellaneous preferences</title>
+<itemizedlist>
+<listitem><para>
+ <emphasis role="bold">2-pass</emphasis>:
+ Above, it was suggested to always use 2-pass, but there are still reasons
+ for not using it. For instance, if you are capturing live TV and encoding
+ in realtime, you are forced to use single-pass. Also, one pass is
+ obviously faster than two passes; in the case that you use the exact same
+ set of options on both passes, 2-pass is almost twice as slow.
+</para>
+<para>
+ Still, there are very good reasons for using 2-pass. For one thing,
+ single-pass ratecontrol isn't psychic, and it often makes unreasonable
+ choices because it can't see the big picture. For example, suppose
+ you have a two-minute video consisting of two distinct halves.
+ The first half is a very high-motion scene lasting 60 seconds which, in
+ isolation, requires about 2500kbps in order to look decent. Immediately
+ following it is a much less demanding 60-second scene that looks good at
+ 300kbps. Suppose you ask for 1400kbps on the theory that this is enough
+ to accomodate both scenes. Single pass ratecontrol will make a couple of
+ "mistakes" in such a case. First of all, it will target 1400kbps in both
+ segments. The first segment may end up heavily overquantized, causing
+ it to look unacceptably and unreasonably blocky. The second segment will
+ be heavily underquantized; it may look perfect, but the bitrate cost of
+ that perfection will be completely unreasonable. What's even harder to
+ avoid is the problem at the transition between the two scenes. The first
+ seconds of the low motion half will be hugely over-quantized, because
+ the ratecontrol is still expecting the kind of bitrate requirements
+ it met in the first half of the video. This "error period" of heavily
+ over-quantized low motion will look jarringly bad, and will actually
+ use less than the 300kbps it would have taken to make it look decent.
+ There are ways to mitigate the pitfalls of single-pass encoding, but
+ they may tend to increase bitrate misprediction.
+</para>
+<para>
+ Multipass ratecontrol can offer huge advantages over single-pass.
+ Using the statistics gathered from the first pass encode, the encoder
+ can estimate, with reasonable accuracy, the "cost" (in bits) of
+ encoding any given frame, at any given quantizer. This allows for
+ a much more rational, better planned allocation of bits between the
+ expensive (high-motion) and cheap (low-motion) scenes. See
+ <option>qcomp</option> below for some ideas on how to tweak this
+ allocation to your liking.
+</para>
+<para>
+ Moreover, two passes need not take twice as long as one pass. You can
+ tweak the options in the first pass for higher speed and lower quality.
+ If you choose your options well, you can get a very fast first pass.
+ The resulting quality in the second pass will be slightly lower because size
+ prediction is less accurate, but the quality difference is normally much
+ too small to be visible. Try, for example, adding
+ <option>subq=1:frameref=1</option> to the first pass
+ <option>x264encopts</option>. Then, on the second pass, use slower,
+ higher-quality options:
+ <option>subq=6:frameref=15:4x4mv:me=3</option>
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">3-pass</emphasis>?
+ x264 offers the ability to make an arbitrary number of consecutive passes.
+ If you specify <option>pass=1</option> on the first pass, then use
+ <option>pass=3</option> on a subsequent pass, the subsequent pass will both
+ read the statistics from the previous pass, and write its own statistics.
+ An additional pass following this one will have a very good base from which
+ to make highly accurate predictions of framesizes at a chosen quantizer.
+ In practice, the overall quality gain from this is usually close to zero,
+ and quite possibly a third pass will result in slightly worse global PSNR
+ than the pass before it. In typical usage, 3-pass is most helpful when you
+ get either bad bitrate prediction or bad looking scene transitions when
+ using 2-pass. This is somewhat likely to happen on extremely short clips.
+ There are also a few special cases in which 3-pass is handy for advanced
+ users, but for brevity, this guide omits discussing those special cases.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">qcomp</emphasis>:
+ <option>qcomp</option> trades off the number of bits allocated
+ to "expensive" high-motion versus "cheap" low-motion frames. At
+ one extreme, <option>qcomp=0</option> aims for true constant
+ bitrate. Typically this would make high-motion scenes look completely
+ awful, while low-motion scenes would probably look absolutely
+ perfect, but would also use many times more bitrate than they
+ would need in order to look merely excellent. At the other extreme,
+ <option>qcomp=1</option> achieves nearly constant quantization parameter
+ (QP). Constant QP doesn't look bad, but most people think it's more
+ reasonable to shave some bitrate off of the extremely expensive scenes
+ (where the loss of quality isn't as noticeable) and reallocate it to
+ the scenes that are easier to encode at excellent quality.
+ <option>qcomp</option> is set to 0.6 by default, which may be slightly
+ low for many peoples' taste (0.7-0.8 are also commonly used).
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">keyint</emphasis>:
+ <option>keyint</option> is solely for trading off file seekability against
+ coding efficiency. By default, <option>keyint</option> is set to 250. In
+ 25fps material, this guarantees the ability to seek to within 10 seconds
+ precision. If you think it would be important and useful to be able to
+ seek within 5 seconds of precision, set <option>keyint=125</option>;
+ this will hurt quality/bitrate slightly. If you care only about quality
+ and not about seekability, you can set it to much higher values
+ (understanding that there are diminishing returns which may become
+ vanishingly low, or even zero). The video stream will still have seekable
+ points as long as there are some scene changes.
+</para></listitem>
<listitem><para>
<emphasis role="bold">deblockalpha, deblockbeta</emphasis>:
This topic is going to be a bit controversial.
@@ -2434,8 +2550,13 @@
It will almost certainly look better than the results you
would have gotten just by fiddling with the deblocking filter.
</para></listitem>
+
</itemizedlist>
+
+</sect3>
+
</sect2>
+
</sect1>
<sect1 id="menc-feat-xvid">
@@ -2451,8 +2572,8 @@
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.
+ <link linkend="menc-feat-x264-encoding-options-intro">the first part</link>
+ of that guide.
</para>
Index: DOCS/xml/en/codecs.xml
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/xml/en/codecs.xml,v
retrieving revision 1.67
diff -u -r1.67 codecs.xml
--- DOCS/xml/en/codecs.xml 30 Jun 2005 19:53:24 -0000 1.67
+++ DOCS/xml/en/codecs.xml 3 Jul 2005 04:36:36 -0000
@@ -575,9 +575,9 @@
The gains from using H.264 do not come for free: Decoding H.264
streams seems to have steep CPU and memory requirements.
For instance, on a 1733 MHz Athlon, a 1500kbps H.264 video uses
- around 50% CPU to decode.
- By comparison, decoding a 1500kbps MPEG-4 ASP stream requires
- around 10% CPU.
+ around 35% CPU to decode.
+ By comparison, decoding a DVD-resolution 1500kbps MPEG-4 ASP stream
+ requires around 10% CPU.
This means that decoding high-definition streams is almost out of
the question for most users.
It also means that even a decent DVD rip may sometimes stutter on
More information about the MPlayer-DOCS
mailing list