comparison DOCS/xml/ru/encoding-guide.xml @ 21747:e6b16ad464e8

Translation of menc-feat-x264 sect1 in encoding-guide.xml

21746:7b88cb528d2b

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->


<sect1 id="menc-feat-x264">
<title>Encoding with the <systemitem class="library">x264</systemitem> codec</title>
<para>
<systemitem class="library">x264</systemitem> is a free library for
encoding H.264/AVC video streams.
Before starting to encode, you need to <link linkend="codec-x264-encode">
set up <application>MEncoder</application> to support it</link>.
</para>

<!-- ********** -->

<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.
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>
<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>
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 is not what they are 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, 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>.
Global PSNR is the last PSNR number reported when you include
the <option>psnr</option> option in <option>x264encopts</option>.
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 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>
</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> (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.
  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> (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> achieves 0.2-0.5 dB higher global
  PSNR in comparison <option>subq=1</option>.
  This is usually enough to be visible.
  </para>
  
  <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%.
  Unlike other levels of <option>subq</option>, the behavior of
  <option>subq=6</option> does not 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
  should not be taken to imply that it is reasonable to set it to 1.
  Merely raising <option>frameref</option> to 2 gains around
  0.15dB PSNR with a 5-10% speed penalty; this seems like a good tradeoff.
  <option>frameref=3</option> gains around 0.25dB PSNR over
  <option>frameref=1</option>, which should be a visible  difference.
  <option>frameref=3</option> is around 15% slower than
  <option>frameref=1</option>.
  Unfortunately, diminishing returns set in rapidly.
  <option>frameref=6</option> can be expected to gain only
  0.05-0.1 dB over <option>frameref=3</option> at an additional
  15% speed penalty.
  Above <option>frameref=6</option>, the quality gains are
  usually very small (although you should keep in mind throughout
  this whole discussion that it can vary quite a lot depending on your source).
  In a fairly typical case, <option>frameref=12</option>
  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 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.
  </para>
  <note><title>Note:</title>
  <para>
  Raising <option>frameref</option> to unnecessarily high values
  <emphasis role="bold">can</emphasis> and
  <emphasis role="bold">usually does</emphasis>
  hurt coding efficiency if you turn CABAC off.
  With CABAC on (the default behavior), the possibility of setting
  <option>frameref</option> "too high" currently seems too remote
  to even worry about, and in the future, optimizations may remove
  the possibility altogether.
  </para></note>
  <para>
  If you care about speed, a reasonable compromise is to use low
  <option>subq</option> and <option>frameref</option> values on
  the first pass, and then raise them on the second pass.
  Typically, this has a negligible negative effect on the final
  quality: You will probably lose well under 0.1dB PSNR, which
  should be much too small of a difference to see.
  However, different values of <option>frameref</option> can
  occasionally affect frametype decision.
  Most likely, these are rare outlying cases, but if you want to
  be pretty sure, consider whether your video has either
  fullscreen repetitive flashing patterns or very large temporary
  occlusions which might force an I-frame.
  Adjust the first-pass <option>frameref</option> so it is large
  enough to contain the duration of the flashing cycle (or occlusion).
  For example, if the scene flashes back and forth between two images
  over a duration of three frames, set the first pass
  <option>frameref</option> to 3 or higher.
  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.
  Altering this option provides a straightforward quality-vs-speed
  tradeoff. <option>me=dia</option> is only a few percent faster than
  the default search, at a cost of under 0.1dB global PSNR. The 
  default setting (<option>me=hex</option>) is a reasonable tradeoff
  between speed and quality. <option>me=umh</option> gains a little under
  0.1dB global PSNR, with a speed penalty that varies depending on
  <option>frameref</option>.  At high values of
  <option>frameref</option> (e.g. 12 or so), <option>me=umh</option>
  is about 40% slower than the default <option> me=hex</option>. With
  <option>frameref=3</option>, the speed penalty incurred drops to
  25%-30%.
  </para>
  <para>
  <option>me=esa</option> uses an exhaustive search that is too slow for
  practical use.
  </para>
</listitem>
<listitem><para>
  <emphasis role="bold">partitions=all</emphasis>:
  This option enables the use of 8x4, 4x8 and 4x4 subpartitions in
  predicted macroblocks (in addition to the default partitions).
  Enabling it results in a fairly consistent
  10%-15% loss of speed. This option is rather useless in source
  containing only low motion, however in some high-motion source,
  particularly source with lots of small moving objects, gains of
  about 0.1dB can be expected.
</para></listitem>
<listitem>
  <para>
  <emphasis role="bold">bframes</emphasis>:
  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
  (<option>x264encopts</option>'s <option>nob_adapt</option>),
  the optimal value for this setting is usually no more than
  <option>bframes=1</option>, or else high-motion scenes can suffer.
  With adaptive B-frame decision on (the default behavior), it is
  safe to use higher values; the encoder will reduce the use of
  B-frames in scenes where they would hurt compression.
  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 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.
  The speed penalty of adaptive B-frames is currently rather modest,
  but so is the potential quality gain.
  It usually does not hurt, however.
  Note that this only affects speed and frametype decision on the
  first pass.
  <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;
  as the man page says, you get a little quality improvement at no
  speed cost.
  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.
  However, in crossfades or fade-to-black scenes, weighted
  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 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,
  all else being equal.
  </para>
  <para>
  Unfortunately, the current adaptive B-frame decision algorithm
  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 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">Two pass encoding</emphasis>:
  Above, it was suggested to always use two pass encoding, 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; if you use the
  exact same set of options on both passes, two pass encoding is almost
  twice as slow.
  </para>
  <para>
  Still, there are very good reasons for using two pass encoding. For
  one thing, single pass ratecontrol is not psychic, and it often makes
  unreasonable choices because it cannot see the big picture. For example,
  suppose you have a two minute long 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 is 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 a 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:partitions=all:me=umh</option>
  </para>
</listitem>
<listitem><para>
  <emphasis role="bold">Three pass encoding</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, three passes help if you get either bad bitrate
  prediction or bad looking scene transitions when using only two passes.
  This is somewhat likely to happen on extremely short clips. There are
  also a few special cases in which three (or more) passes are 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 does not look bad, but most people think it is more
  reasonable to shave some bitrate off of the extremely expensive scenes
  (where the loss of quality is not 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">deblock</emphasis>:
  This topic is going to be a bit controversial.
  </para>
  <para>
  H.264 defines a simple deblocking procedure on I-blocks that uses
  pre-set strengths and thresholds depending on the QP of the block
  in question.
  By default, high QP blocks are filtered heavily, and low QP blocks
  are not deblocked at all.
  The pre-set strengths defined by the standard are well-chosen and
  the odds are very good that they are PSNR-optimal for whatever
  video you are trying to encode.
  The <option>deblock</option> allow you to specify offsets to the preset deblocking
  thresholds.
  </para>
  <para>
  Many people seem to think it is a good idea to lower the deblocking
  filter strength by large amounts (say, -3).
  This is however almost never a good idea, and in most cases,
  people who are doing this do not understand very well how
  deblocking works by default.
  </para>
  <para>
  The first and most important thing to know about the in-loop
  deblocking filter is that the default thresholds are almost always
  PSNR-optimal.
  In the rare cases that they are not optimal, the ideal offset is
  plus or minus 1.
  Adjusting deblocking parameters by a larger amount is almost
  guaranteed to hurt PSNR.
  Strengthening the filter will smear more details; weakening the
  filter will increase the appearance of blockiness.
  </para>
  <para>
  It is definitely a bad idea to lower the deblocking thresholds if
  your source is mainly low in spacial complexity (i.e., not a lot
  of detail or noise).
  The in-loop filter does a rather excellent job of concealing
  the artifacts that occur.
  If the source is high in spacial complexity, however, artifacts
  are less noticeable.
  This is because the ringing tends to look like detail or noise.
  Human visual perception easily notices when detail is removed,
  but it does not so easily notice when the noise is wrongly
  represented.
  When it comes to subjective quality, noise and detail are somewhat
  interchangeable.
  By lowering the deblocking filter strength, you are most likely
  increasing error by adding ringing artifacts, but the eye does
  not notice because it confuses the artifacts with detail.
  </para>
  <para>
  This <emphasis role="bold">still</emphasis> does not justify
  lowering the deblocking filter strength, however.
  You can generally get better quality noise from postprocessing.
  If your H.264 encodes look too blurry or smeared, try playing with
  <option>-vf noise</option> when you play your encoded movie.
  <option>-vf noise=8a:4a</option> should conceal most mild
  artifacting.
  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>

<!-- ********** -->

<sect2 id="menc-feat-x264-example-settings">
<title>Encoding setting examples</title>

<para>
The following settings are examples of different encoding
option combinations that affect the speed vs quality tradeoff
at the same target bitrate.
</para>

<para>
All the encoding settings were tested on a 720x448 @30000/1001 fps
video sample, the target bitrate was 900kbps, and the machine was an
AMD-64 3400+ at 2400 MHz in 64 bits mode.
Each encoding setting features the measured encoding speed (in
frames per second) and the PSNR loss (in dB) compared to the "very
high quality" setting.
Please understand that depending on your source, your machine type
and development advancements, you may get very different results.
</para>

<informaltable frame="all">
<tgroup cols="4">
<thead>
<row>
  <entry>Description</entry>
  <entry>Encoding options</entry>
  <entry>speed (in fps)</entry>
  <entry>Relative PSNR loss (in dB)</entry>
</row>
</thead>
<tbody>
<row>
  <entry>Very high quality</entry>
  <entry><option>subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>6fps</entry>
  <entry>0dB</entry>
</row>
<row>
  <entry>High quality</entry>
  <entry><option>subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>13fps</entry>
  <entry>-0.89dB</entry>
</row>
<row>
  <entry>Fast</entry>
  <entry><option>subq=4:bframes=2:b_pyramid:weight_b</option></entry>
  <entry>17fps</entry>
  <entry>-1.48dB</entry>
</row>
</tbody>

21747:e6b16ad464e8

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->


<sect1 id="menc-feat-x264">
<title>Кодирование кодеком <systemitem class="library">x264</systemitem></title>
<para>
<systemitem class="library">x264</systemitem> это свободная библиотека для
кодирование H.264/AVC видео потоков.
Перед началом кодирование вы должны <link linkend="codec-x264-encode">
настроить <application>MEncoder</application> для его поддержки</link>.
</para>

<!-- ********** -->

<sect2 id="menc-feat-x264-encoding-options">
<title>Опции кодирования x264</title>

<para>
Начните, пожалуйста с просмотра раздела 
<systemitem class="library">x264</systemitem> 
man страницы <application>MPlayer</application>'а.
Этот раздел предполагается быть дополнением к странице man.
Здесь вы найдете быстрые подсказки о том, какие опции чаще всего интересуют
большинство людей. Страница man более лаконична, но также более полна и порой
намного лучше преподносит технические детали.
</para>


<sect3 id="menc-feat-x264-encoding-options-intro">
<title>Введение</title>

<para>
Это руководство рассматривает две главные категории опций кодирования:
</para>

<orderedlist>
<listitem><para>
  Опции, в основном влияющие на соотношение скорость-качество.
</para></listitem>
<listitem><para>
  Опции, которые могут быть полезны для удовлетворения различный
  пользовательский предпочтений и специальных требований.
</para></listitem>
</orderedlist>

<para>
В конце концов, только вы можете решать какие опции являются лучшими для ваших
целей. Решение для первого класса опций очень простое:
надо только определить, считаете ли вы, что разница в качестве оправдывает разницу в
скорости.  Для второго класса опций предпочтения могут быть значительно более
субъективными и зависеть от большего числа факторов. 
Имейте в виду, что некоторые из опций категории "пользовательских предпочтений и специальных
требований" могут все же иметь большое влияние на скорость или качество,
но это не основное их предназначение.
Часть опций из "пользовательских предпочтений" могут даже привести к изменениям,
которые выглядят лучше для одних людей и хуже - для других.
</para>

<para>
Перед тем как продолжить, вам придется понять, что это руководство использует
только одну метрику качества: глобальный PSNR.
Краткое описание того, что такое PSNR, смотрите в
<ulink url="http://en.wikipedia.org/wiki/PSNR">статье Википедии о PSNR</ulink>.
Глобальный PSNR - это последнее значение PSNR, выводимое на консоль, когда в
<option>x264encopts</option> включена опция <option>psnr</option>.
Каждый раз, когда вы читаете утверждения о PSNR, за ними скрывается
предположение, что используются одинаковые значения битпотока.
</para>

<para>
Почти все комментарии этого руководства предполагают, что вы используете два
прохода.
Есть две основные причины использовать двухпроходное кодирование при сравнении
опций.
Во-первых, использование двух проходов увеличивает PSNR примерно на 1дБ,
что является очень хорошим значением.
Во-вторых, тестирование опций прямым сравнением качества при однопроходном
кодировании вводит основной сбивающий фактор: зачастую битпоток значительно
меняется при каждом кодировании.
Не всегда можно с легкостью сказать, изменилось ли качество в основном за счет
изменения опций, или оно по большей части отражает случайные изменения
в полученном битпотоке.
</para>
</sect3>


<sect3 id="menc-feat-x264-encoding-options-speedvquality">
<title>Опции, затрагивающие, в основном, скорость и качество</title> 

<itemizedlist>
<listitem>
  <para>
  <emphasis role="bold">subq</emphasis>:
  Из всех опций, позволяющих выбирать между скоростью и качеством, 
  <option>subq</option> и <option>frameref</option> (смотрите ниже), пожалуй,
  самые важные.
  Если вы заинтересованы в тонкой настройке либо скорости, лио качества, 
  эти две  - первое, с чего вам стоит начать.
  С точки зрения скорости, опции <option>frameref</option> и
  <option>subq</option> очень жестко взаимодействуют друг с другом.
  Опыт показывает, что с одним ссылающимся кадром
  <option>subq=5</option> (настройка по-умолчанию) расходует на 35% больше
  времени, чем  <option>ubq=1</option>.
  С 6 ссылающимися кадрами эта величина достигает 60%.
  Эффект <option>subq</option> на PSNR выглядит довольно постоянным, в отличие
  от количества ссылающийся кадров.
  Как правило, <option>subq=5</option> достигает значения глобального PSNR 
  на 0.2-0.5 дБ большего, чем  при <option>subq=1</option>.
  Обычно этого достаточно, чтобы заметить.
  </para>
  
  <para>
  <option>subq=6</option> - это самый медленный режим с лучшим качеством.
  Если сравнивать с <option>subq=5</option>, он обычно дает на 0.1-0.4 дБ
  больший глобальный PSNR ценой потери 25%-100% скорости.
  В отличие от остальных уровней <option>subq</option>, поведение 
  <option>subq=6</option> не так сильно зависит от <option>frameref</option>
  и <option>me</option>.  Вместо этого, эффективность <option>subq=6
  </option> по большей части зависит от количества используемых B-кадров. При
  обычном использовании это означает, что <option>subq=6</option> в сложных,
  высокодинамичных сценах имеет большое влияние как на скорость, так и на
  качество, но в сценах с малым количествах движения она не имеет такого
  эффекта. Имейте в виду, что по-прежнему рекомендуется всегда устанавливать 
  <option>bframes</option> в значение, отличное от нуля (смотрите далее).
  </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">frameref</emphasis>:
  <option>frameref</option> по-умолчанию установлена в 1, но это не значит, что
  ее стоит устанавливать в 1.
  Только увеличение <option>frameref</option> до 2 дает прирост PSNR примерно
  на 0.15дБ за счет уменьшения скорости на 5-10%; похоже, что это неплохая цена.
  <option>frameref=3</option> дает примерно 0.25dB PSNR сверх
  <option>frameref=1</option>, что должно быть видимой разницей.
  <option>frameref=3</option> медленнее примерно на 15%, чем
  <option>frameref=1</option>.
  К сожалению, улучшение очень быстро сходит на нет.
  От <option>frameref=6</option> можно ожидать прироста PSNR лишь на 
  0.05-0.1 дБ по сравнению с <option>frameref=3</option> с дополнительной
  потерей 15% скорости.
  Выше <option>frameref=6</option> качество обычно увеличивается очень незначительно 
  (хотя на всем протяжении этой дискуссии вам следует иметь в виду, оно может
  значительно изменяться в зависимости от исходного материала).
  В довольно типичном случае <option>frameref=12</option> улучшит глобальный 
  PSNR всего на 0.02дБ по сравнению с <option>frameref=6</option>, 
  ценой 15%-20% скорости.
  При таких высоких значениях <option>frameref</option>, единственная
  действительно хорошая вешь, о которой может быть сказано, состоит в том, что
  дальнейшее ее увеличение почти никогда не будет <emphasis
  role="bold">вредить</emphasis> PSNR, но увеличение качества будет трудно даже
  измерить, не говоря уже о его заметности.
  </para>
  <note><title>Замечание:</title>
  <para>
  Увеличение <option>frameref</option> до чрезмерно высоких значений 
  <emphasis role="bold">может</emphasis> и
  <emphasis role="bold">обычно наносит</emphasis>
  вред эффективности кодирования, если CABAC отключен.
  С задействованным CABAC (настройка по-умолчанию), возможность установки 
  <option>frameref</option> "слишком высоким" на данный момент выглядит слишком
  далекой, чтобы об этом беспокоиться, а в будущем оптимизации могут вообще
  убрать такую возможность.
  </para></note>
  <para>
  Если вас заботит скорость, разумным компромиссом будет использовать низкие
  значения <option>subq</option> и <option>frameref</option> в первом проходе, а
  <!-- FIXME  is translation correct ? -->
  затем увеличить из во втором: Вы, возможно, потеряете вплоть до 0.1дБ PSNR,
  что может быть достаточно малым значением, чтобы его заметить.
  Однако, различные значения <option>frameref</option> могут 
  иногда повлиять на решение о выборе типа кадра.
  Скорее всего, это довольно редкие крайние случаи, но если вы хотите точно
  уверены, подумайте, содержит ли ваше видео полноэкранные
  <!-- FIXME is translation correct? -->
  периодически вспыхивающие изображения или очень большие паузы, которые могут стать
  причиной принудительной вставки I-кадра.
  Настройте <option>frameref</option> в первом проходе так, чтобы 
  она была достаточно большой, чтобы содержать длительность цикла вспыхивания
  (или паузы).
  Например, если сцены вспыхивает и гаснет в течении двух кадров из трех,
  установите <option>frameref</option> равным 3 или выше.
  Эта проблема, возможно, очень редко появляется для живой съемки, но она иногда
  появляется при записи видео игр.
 </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">me</emphasis>:
  Эта опция используется для выбора метода оценки движения.
  Изменение этой опции оказывает прямое влияние на соотношение
  скорость-качество. <option>me=dia</option> лишь на несколько процентов
  быстрее, чем поиск по-умолчанию ценой не больше 0.1дБ глобального PSNR. 
  Значение по-умолчанию (<option>me=hex</option>) разумный выбор между скоростью
  и качеством. <option>me=umh</option> немного, вплоть до 0.1дБ, улучшает
  глобальный PSNR, соответствующее падение скорости зависит меняется и 
  зависит от <option>frameref</option>.  С высокими значениями 
  <option>frameref</option> (например, 12 или около того), <option>me=umh</option>
  примерно на 40% медленнее, чем настройка по-умолчанию <option> me=hex</option>.
  С <option>frameref=3</option>, падение скорости уменьшается до 25%-30%.
  </para>
  <para>
  <option>me=esa</option> использует исчерпывающий поиск, который работает
  слишком медленно для практического применения.
  </para>
</listitem>
<listitem><para>
  <emphasis role="bold">partitions=all</emphasis>:
  Эта опция задействует использование сегментов 8x4, 4x8 и 4x4 в предсказанных
  макроблоках (в дополнение к стандартным).
  Ее включение приведет к довольно постоянной 10%-15% потере в скорости.
  Эта опция практически бесполезна для исходного материала, содержащего только
  небольшое движение, тем не менее, для некоторого высокодинамичного,
  особенно с большим количеством мелких движущихся объектов, следует ожидать
  прироста в 0.1дБ.
</para></listitem>
<listitem>
  <para>
  <emphasis role="bold">bframes</emphasis>:
  Если вы занимались кодированием с другими кодеками, то могли заметить, что
  B-кадры не всегда полезны.
  В H.264 это изменилось: есть новые техники и типы блоков, возможные в B-кадрах.
  Обычно, даже примитивный алгоритм выбора B-кадров может дать значимую
  выгоду для PSNR.
  Интересно заметить, что использование B-кадров обычно отчасти ускоряет второй
  проход, а также может ускорить однопроходное кодирование, если отключено
  адаптивное принятие решения о B-кадрах.
  </para>
  <para>
  С отключенным адаптивным принятием решения о B-кадрах
  (<option>x264encopts</option>'ой <option>nob_adapt</option>),
  оптимальное значение этой опции обычно не превышает 
  <option>bframes=1</option>, иначе пострадают высокодинамичные сцены.
  С включенным адаптивным принятием решения о B-кадрах (поведение по-умолчанию),
  можно безопасно использовать более высокие значения; кодировщик уменьшит
  количество B-кадров в сценах, где они повредят сжатию.
  Кодировщик редко решает использовать больше, чем 3 или 4 B-кадра;
  установка этой опции в любое более высокое значение не будет иметь большого
  эффекта.
  </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">b_adapt</emphasis>:
  Заметьте: она включена по-умолчанию.
  </para>
  <para>
  Когда эта опция включена, кодировщик будет использовать разумно 
  быстрый процесс принятия решения для уменьшения количества B-кадров,
  используемых в сценах, которые от этого не сильно выиграют.
  Вы можете использовать <option>b_bias</option> для тонкой настройки того,
  насколько "счастлив" будет кодировщик использованию B-кадров.
  Потеря в скорости при использовании адаптивных B-кадров на данный момент,
  пожалуй, умереннее, но таково же и потенциальное улучшение качества.
  Тем не менее, хуже от этого обычно не становится.
  Заметьте, что эта опция влияет на скорость и решение о типе кадра только в первом
  проходе.
  <option>b_adapt</option> и <option>b_bias</option> не имеют эффекта в
  последующих проходах.
  </para>
</listitem>
<listitem><para>
  <emphasis role="bold">b_pyramid</emphasis>:
  С тем же успехом вы можете включить эту опцию, если используете >=2 B-кадров;
  вы получите небольшое улучшение качества без потери в скорости, как и говорит
  man руководство.
  Имейте в виду, что такое видео не может быть прочитано основанными на
  libavcodec декодерами, созданными ранее, чем примерно 5 Марта 2005. 
</para></listitem>
<listitem>
  <para>
  <emphasis role="bold">weight_b</emphasis>:
  В обычных случаях эта опция не дает большого улучшения.
  Однако, в проявляющихся или затухающих сценах взвешенное предсказание дает
  довольно большую экономию битпотока.
  В MPEG-4 ASP затухание обычно лучше кодируется последовательностью дорогих
  I-кадров; используя взвешенное предсказание в B-кадрах делает возможным
  преобразовать хотя бы часть из них в значительно более маленькие B-Кадры.
  Потери в скорости кодирования минимальны, поскольку не требуется делать
  дополнительные принятия решений.
  <!-- FIXME is translation correct -->
  Вдобавок, вопреки возможным предположениям, взвешенное предсказание не так
  сильно влияет на требования декодера к CPU, все остальное же полностью совпадает.
  </para>
  <para>
  К сожалению, текущий алгоритм адаптивного принятия решений о B-Кадрах имеет
  твердую склонность к избеганию использования B-кадров при затуханиях.
  До тех пор, пока это не изменится, хорошей идеей, возможно, будет добавить 
  <option>nob_adapt</option> к x264encopts, если предполагаете, что затухания
  будут иметь сильный эффект на ваш конкретный видеоклип.
  </para>
</listitem>
</itemizedlist>
</sect3>


<sect3 id="menc-feat-x264-encoding-options-misc-preferences">
<title>Опции, относящиеся к различным предпочтениям</title>
<itemizedlist>
<listitem>
  <para>
  <emphasis role="bold">Двухпроходное кодирование</emphasis>:
  Выше советовалось всегда использовать кдирование в два прохода, но все же
  существуют причины этого не делать. Например, если вы захватываете TV
  трансляцию и кодируете в реальном времени, придется использовать однопроходный
  режим. К тому же один проход очевидно быстрее, чем два; если вы используете
  точно такой же набор опций в обоих случаях, двухпроходной режим медленнее
  вдвое.
  </para>
  <para>
  Все же существует очень хорошие причины использовать кодирование в два
  прохода. Во-первых, управление битпотоком при однопроходного режима не
  является телепатом и часто делает необоснованный выбор, потому что не может
  видеть общую картину. Например, предположим, что вы имеете двухминутное видео,
  состоящее из двух независимых частей. Первая половина - очень динамичная
  сцена, продолжающаяся 60 секунд и требующая сама по себе битпоток примерно
  2500 кбит/сек, чтобы прилично выглядеть. Сразу за ней следует менее
  требовательная 60-секундная сцена, которая хорошо выглядит при 300 кбит/сек.
  Предположим, вы запросили битпоток 14000 кбит/сек; в теории этого достаточно
  для удовлетворения потребностей обеих сцен.
  В этом случае управление битпотоком в однопроходном режиме сделает пару "ошибок".
  Во-первых, оно установит битпоток в 1400 кбит/сек для обеих частей. Первая
  часть может оказаться чрезмерно квантованной, что приведет к
  недопустимому и неоправданно блочному изображению. Вторая часть будет
  недостаточно квантованной; она может выглядеть отлично, но цена битпотока для
  этого качества будет полностью неоправданной.
  Чего намного труднее избежать, так это проблемы перехода между двумя
  сценами. В первых секундах малодинамичной части квантователь будет чрезвычайно
  превышен, потому что управление битпотоком все еще ожидает встретить такие же 
  требования к битпотоку как и в первой части. Этот "ошибочный период" с
  чрезвычайно превышенным квантованием будет выглядеть раздражающе неприятно и
  использовать на самом деле меньше, чем 300 кбит/сек, требуемых ему для того,
  чтобы прилично выглядеть. Существуют способы смягчить эффект от подобных
  подводных камней однопроходного режима, но они могут иметь склонность к
  усилению неверного предсказания битпотока.
  </para>
  <para>
  Многопроходное кодирование может предложить огромные преимущества по сравнению
  с однопроходным. Используя статистику, собранную при первом проходе, 
  кодировщик может оценить, с разумной точностью, "стоимость" (в битах)
  кодирования любого заданного кадра при любом заданном квантователе.
  Это делает возможным намного более рациональное, лучше спланированное
  распределение битов между дорогими (высокодинамичными) и дешевыми
  (малодинамичными) сценами. Смотрите <option>qcomp</option> ниже, чтобы узнать
  некоторые идеи о том, как можно это распределение настроить по вашему вкусу.
  </para>
  <para>
  Более того, два прохода занимают не двойное время по сравнению с одним.
  Вы можете настроить опции первого прохода на более быструю скорость и низкое
  качество. Если хорошо выберете опции, вы получите очень быстрый первый проход.
  Полученное качество во втором проходе будет несколько ниже, потому что
  предсказание размера менее точно, но разница в качестве обычно слишком мала,
  чтобы быть заметной. Попробуйте, например, добавить
  <option>subq=1:frameref=1</option> в <option>x264encopts</option> первого
  прохода. Затем, при втором проходе, используйте более медленные, с лучшим
  качеством опции:
  <option>subq=6:frameref=15:partitions=all:me=umh</option>
  </para>
</listitem>
<listitem><para>
  <emphasis role="bold">Кодирование в три прохода</emphasis>?
  x264 предоставляет возможность делать желаемое количество последовательных
  проходов. Если вы указали <option>pass=1</option> при первом проходе,
  используйте затем <option>pass=3</option> в последующем проходе, этот проход
  будет одновременно читать статистику предыдущего прохода и записывать ее
  собственную. Дополнительный проход, следующий за этим, будет иметь очень
  хорошую основу для осуществления очень точных предсказаний размеров кадров при
  выбранном квантователе. На практике, общее улучшение качества от использования
  этого режима близко к нулю и, вполне возможно, третий проход приведет к
  немного худшему глобальному PSNR, чем у предыдущего прохода.
  При обычном использовании три прохода помогают, если вы при двух проходах
  получаете либо плохое предсказание битпотока, либо плохо выглядящие переходы
  между сценами. Это в точности то, что наверняка будет происходить на очень
  коротких клипах. Существуют также особые случаи, когда три (или более)
  проходом удобны для продвинутых пользователей, но, для краткости, это
  руководство не включает в себя описание этих особых случаев.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qcomp</emphasis>:
  <option>qcomp</option> управляет соотношением количества бит, отданных
  "дорогим" высокодинамичным и "дешевым" малодинамичным кадрам. Один крайний
  случай, <option>qcomp=0</option>, предназначен для истинно постоянного
  битпотока. Обычно это сделает высокодинамичные сцены выглядящими просто
  ужасно, в то время как малодинамичные сцены будут, возможно, выглядеть
  отлично, но при этом будут использовать во много раз больший битпоток, чем им
  необходимо, чтобы выглядеть просто великолепно.
  Другая крайность, <option>qcomp=1</option>, добивается примерно одинакового
  параметра квантования (QP). Постоянный QP не выглядит ужасно, но большинство
  людей думают, что более разумно частично снизить битпоток в сильно
  дорогих сценах (где потеря качества не очень заметна) и перераспределить их в
  сцены, которые легче закодировать с отличным качеством.
  <option>qcomp</option> по-умолчанию установлена в 0.6, что по мнению многих
  людей может быть несколько мало (также часто используется 0.7-0.8).
</para></listitem>
<listitem><para>
  <emphasis role="bold">keyint</emphasis>:
  <option>keyint</option> - единственная возможность выбора между удобством
  перемещения по файлу и эффективностью кодирования. По-умолчанию
  <option>keyint</option> установлена в 250. В материале с 25fps это гарантирует
  возможность перемещения с точностью до 10 секунд. Если вы считаете, что более
  важным и полезным будет перемещение с точностью до 5 секунд, установите
  <option>keyint=125</option>; это немного ухудшит качество/битпоток. Если вы
  заботитесь только о качестве, но не о перемещаемости, вы можете установить
  значение этой опции в более высокое значение (понимая, что улучшение будет
  убывающим, вплоть до исчезающе малого или даже нулевого). Видео поток
  по-прежнему будет иметь точки перемещения, пока в нем есть какие-то изменения
  сцен.
</para></listitem> 
<listitem>
  <para>
  <emphasis role="bold">deblock</emphasis>:
  Этот раздел может быть несколько спорным.
  </para>
  <para>
  H.264 определяет простую процедуру удаления блочности в I-блоках, которая
  использует предустановленные степени обработки и пороговые значения в
  зависимости от QP интересующего блока.
  По-умолчанию, блоки с высоким QP обрабатываются сильнее, а в блоках с низким
  QP удаление блочности вообще не производится.
  Предустановленые степени обработки, определенные стандартом, тщательно подобраны
  и имеют хорошие шансы быть PSNR-оптимальными для любого видео, которое вы
  пытаетесь кодировать.
  Опция <option>deblock</option> позволяет указать смещения предустановленных
  пороговых значений деблокинга.
  </para>
  <para>
  Похоже, многие думают, что хорошей идеей является значительное уменьшение силы
  воздействия фильтра деблокинга (читай, -3).
  Это, однако, почти никогда не является хорошей идеей, и, люди, это делающие, в большинстве
  случаев не совсем хорошо понимают, как работает удаление
  блочности по-умолчанию.
  </para>
  <para>
  Первая и самая важная вещь, которую нужно знать о in-loop фильтре удаления
  блочности состоит в том, что пороговые значения по-умолчанию практически
  всегда PSNR-оптимальны.
  В редких случаях, где они неоптимальны, идеальное смещение будет плюс минус 1.
  Изменение параметров деблокинга на большие значения фактически гарантирует
  ухудшение PSNR.
  Усиление фильтра размажет больше деталей; ослабление - оставит больше квадратиков.
  </para>
  <para>
  По определению плохая идея уменьшать пороги деблокинга, если ваш исходный
  материал в основном имеет небольшую пространственную сложность (т.е. не имеет
  множества деталей или шума).
  In-loop фильтр делает весьма неплохую работу по сокрытию появляющихся
  артефактов. Однако, если исходный материал имеет высокую пространственную
  сложность, артефакты будут практически незаметны.
  Это происходит потому, что ореолы имеют склонность выглядеть как детали или
  шум. Зрительное восприятие легко замечает отсутствие деталей, но ему не так
  легко обратить внимание на неверно изображенный шум.
  Когда речь идет о субъективном качестве, шум и детали в некоторой степени
  взаимозаменяемы.
  Уменьшая силу фильтра удаления блочности, вы скорее всего увеличиваете ошибку,
  добавляя ореолы, но глаз этого не замечает, поскольку он путает артефакты с
  деталями.
  </para>
  <para>
  Однако, это <emphasis role="bold">по-прежнему</emphasis> не оправдывает
  уменьшение силы фильтра. Вы в большинстве случаев можете получить более
  качественный шум при помощи постобработки.
  Если результат кодирования при помощи H.264 выглядит слишком смазанным или
  размытым, попробуйте поиграть с <option>-vf noise</option>, при
  воспроизведении закодированного фильма.
  <option>-vf noise=8a:4a</option> должна скрыть большинство мелких артефактов.
  Ее результат почти наверняка будет выглядеть лучше, чем полученный при помощи
  махинаций с фильтром удаления блочности.
  </para>
</listitem>
</itemizedlist>
</sect3>
</sect2>

<!-- ********** -->

<sect2 id="menc-feat-x264-example-settings">
<title>Примеры настроек кодирования</title>

<para>
Последующие настройки - это примеры различных комбинаций опций кодирования,
которые влияют на соотношения скорость-качество при той же величине целевого
битпотока.
</para>

<para>
Все настройки кодирования проверялись на тестовом видео 720x448 @30000/1001 fps 
с целевым битпотоком 900кбит/сек, на машине AMD-64 3400+ с 2400 МГц и 64-х битном режиме.
Для каждой настройки кодирования указаны измеренная скорость кодирования (в
кадрах в секунду) и потеря PSNR (в дБ) по сравнению с настройкой "очень высокое
качество". Поймите, пожалуйста, что в зависимости от вашего материала, типа
машины, прогресса разработки вы можете получить сильно отличающиеся результаты.
</para>

<informaltable frame="all">
<tgroup cols="4">
<thead>
<row>
  <entry>Описание</entry>
  <entry>Опции кодирования</entry>
  <entry>скорость (в fps)</entry>
  <entry>Относительная потеря PSNR (в дБ)</entry>
</row>
</thead>
<tbody>
<row>
  <entry>Очень высокое качество</entry>
  <entry><option>subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>6fps</entry>
  <entry>0dB</entry>
</row>
<row>
  <entry>Высокое качество</entry>
  <entry><option>subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>13fps</entry>
  <entry>-0.89dB</entry>
</row>
<row>
  <entry>Быстро</entry>
  <entry><option>subq=4:bframes=2:b_pyramid:weight_b</option></entry>
  <entry>17fps</entry>
  <entry>-1.48dB</entry>
</row>
</tbody>