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

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@21763 b3059339-0415-0410-9bf9-f77b7e298cf2

1 files changed, 354 insertions, 360 deletions

diff --git a/DOCS/xml/ru/encoding-guide.xml b/DOCS/xml/ru/encoding-guide.xml
index 54f860203b..be21e2f893 100644
--- a/DOCS/xml/ru/encoding-guide.xml
+++ b/DOCS/xml/ru/encoding-guide.xml
@@ -3671,295 +3671,292 @@ Xvid поддерживает профили кодирования через �
 
 
 <sect1 id="menc-feat-x264">
-<title>Encoding with the <systemitem class="library">x264</systemitem> codec</title>
+<title>Кодирование кодеком <systemitem class="library">x264</systemitem></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>.
+<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>Encoding options of x264</title>
+<title>Опции кодирования 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.
+Начните, пожалуйста с просмотра раздела 
+<systemitem class="library">x264</systemitem> 
+man страницы <application>MPlayer</application>'а.
+Этот раздел предполагается быть дополнением к странице man.
+Здесь вы найдете быстрые подсказки о том, какие опции чаще всего интересуют
+большинство людей. Страница man более лаконична, но также более полна и порой
+намного лучше преподносит технические детали.
 </para>
 
 
 <sect3 id="menc-feat-x264-encoding-options-intro">
-<title>Introduction</title>
+<title>Введение</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.
+Перед тем как продолжить, вам придется понять, что это руководство использует
+только одну метрику качества: глобальный PSNR.
+Краткое описание того, что такое PSNR, смотрите в
+<ulink url="http://en.wikipedia.org/wiki/PSNR">статье Википедии о PSNR</ulink>.
+Глобальный PSNR - это последнее значение PSNR, выводимое на консоль, когда в
+<option>x264encopts</option> включена опция <option>psnr</option>.
+Каждый раз, когда вы читаете утверждения о PSNR, за ними скрывается
+предположение, что используются одинаковые значения битпотока.
 </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.
+Почти все комментарии этого руководства предполагают, что вы используете два
+прохода.
+Есть две основные причины использовать двухпроходное кодирование при сравнении
+опций.
+Во-первых, использование двух проходов увеличивает PSNR примерно на 1дБ,
+что является очень хорошим значением.
+Во-вторых, тестирование опций прямым сравнением качества при однопроходном
+кодировании вводит основной сбивающий фактор: зачастую битпоток значительно
+меняется при каждом кодировании.
+Не всегда можно с легкостью сказать, изменилось ли качество в основном за счет
+изменения опций, или оно по большей части отражает случайные изменения
+в полученном битпотоке.
 </para>
 </sect3>
 
 
 <sect3 id="menc-feat-x264-encoding-options-speedvquality">
-<title>Options which primarily affect speed and quality</title>
+<title>Опции, затрагивающие, в основном, скорость и качество</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.
+  Из всех опций, позволяющих выбирать между скоростью и качеством, 
+  <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> 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).
+  <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> 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</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>.
-  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.
+  К сожалению, улучшение очень быстро сходит на нет.
+  От <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>Note:</title>
+  <note><title>Замечание:</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.
+  Увеличение <option>frameref</option> до чрезмерно высоких значений 
+  <emphasis role="bold">может</emphasis> и
+  <emphasis role="bold">обычно наносит</emphasis>
+  вред эффективности кодирования, если CABAC отключен.
+  С задействованным CABAC (настройка по-умолчанию), возможность установки 
+  <option>frameref</option> "слишком высоким" на данный момент выглядит слишком
+  далекой, чтобы об этом беспокоиться, а в будущем оптимизации могут вообще
+  убрать такую возможность.
   </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>
+  Если вас заботит скорость, разумным компромиссом будет использовать низкие
+  значения <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>:
-  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%.
+  Эта опция используется для выбора метода оценки движения.
+  Изменение этой опции оказывает прямое влияние на соотношение
+  скорость-качество. <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> uses an exhaustive search that is too slow for
-  practical use.
+  <option>me=esa</option> использует исчерпывающий поиск, который работает
+  слишком медленно для практического применения.
   </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.
+  Эта опция задействует использование сегментов 8x4, 4x8 и 4x4 в предсказанных
+  макроблоках (в дополнение к стандартным).
+  Ее включение приведет к довольно постоянной 10%-15% потере в скорости.
+  Эта опция практически бесполезна для исходного материала, содержащего только
+  небольшое движение, тем не менее, для некоторого высокодинамичного,
+  особенно с большим количеством мелких движущихся объектов, следует ожидать
+  прироста в 0.1дБ.
 </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.
+  Если вы занимались кодированием с другими кодеками, то могли заметить, что
+  B-кадры не всегда полезны.
+  В H.264 это изменилось: есть новые техники и типы блоков, возможные в B-кадрах.
+  Обычно, даже примитивный алгоритм выбора B-кадров может дать значимую
+  выгоду для PSNR.
+  Интересно заметить, что использование B-кадров обычно отчасти ускоряет второй
+  проход, а также может ускорить однопроходное кодирование, если отключено
+  адаптивное принятие решения о B-кадрах.
   </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.
+  С отключенным адаптивным принятием решения о 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>:
-  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.
+  Когда эта опция включена, кодировщик будет использовать разумно 
+  быстрый процесс принятия решения для уменьшения количества 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>:
-  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.
+  С тем же успехом вы можете включить эту опцию, если используете >=2 B-кадров;
+  вы получите небольшое улучшение качества без потери в скорости, как и говорит
+  man руководство.
+  Имейте в виду, что такое видео не может быть прочитано основанными на
+  libavcodec декодерами, созданными ранее, чем примерно 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.
+  В обычных случаях эта опция не дает большого улучшения.
+  Однако, в проявляющихся или затухающих сценах взвешенное предсказание дает
+  довольно большую экономию битпотока.
+  В MPEG-4 ASP затухание обычно лучше кодируется последовательностью дорогих
+  I-кадров; используя взвешенное предсказание в B-кадрах делает возможным
+  преобразовать хотя бы часть из них в значительно более маленькие B-Кадры.
+  Потери в скорости кодирования минимальны, поскольку не требуется делать
+  дополнительные принятия решений.
+  <!-- FIXME is translation correct -->
+  Вдобавок, вопреки возможным предположениям, взвешенное предсказание не так
+  сильно влияет на требования декодера к CPU, все остальное же полностью совпадает.
   </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.
+  К сожалению, текущий алгоритм адаптивного принятия решений о B-Кадрах имеет
+  твердую склонность к избеганию использования B-кадров при затуханиях.
+  До тех пор, пока это не изменится, хорошей идеей, возможно, будет добавить 
+  <option>nob_adapt</option> к x264encopts, если предполагаете, что затухания
+  будут иметь сильный эффект на ваш конкретный видеоклип.
   </para>
 </listitem>
 </itemizedlist>
@@ -3967,177 +3964,176 @@ random differences in the achieved bitrate.
 
 
 <sect3 id="menc-feat-x264-encoding-options-misc-preferences">
-<title>Options pertaining to miscellaneous preferences</title>
+<title>Опции, относящиеся к различным предпочтениям</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.
+  <emphasis role="bold">Двухпроходное кодирование</emphasis>:
+  Выше советовалось всегда использовать кдирование в два прохода, но все же
+  существуют причины этого не делать. Например, если вы захватываете TV
+  трансляцию и кодируете в реальном времени, придется использовать однопроходный
+  режим. К тому же один проход очевидно быстрее, чем два; если вы используете
+  точно такой же набор опций в обоих случаях, двухпроходной режим медленнее
+  вдвое.
   </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.
+  Все же существует очень хорошие причины использовать кодирование в два
+  прохода. Во-первых, управление битпотоком при однопроходного режима не
+  является телепатом и часто делает необоснованный выбор, потому что не может
+  видеть общую картину. Например, предположим, что вы имеете двухминутное видео,
+  состоящее из двух независимых частей. Первая половина - очень динамичная
+  сцена, продолжающаяся 60 секунд и требующая сама по себе битпоток примерно
+  2500 кбит/сек, чтобы прилично выглядеть. Сразу за ней следует менее
+  требовательная 60-секундная сцена, которая хорошо выглядит при 300 кбит/сек.
+  Предположим, вы запросили битпоток 14000 кбит/сек; в теории этого достаточно
+  для удовлетворения потребностей обеих сцен.
+  В этом случае управление битпотоком в однопроходном режиме сделает пару "ошибок".
+  Во-первых, оно установит битпоток в 1400 кбит/сек для обеих частей. Первая
+  часть может оказаться чрезмерно квантованной, что приведет к
+  недопустимому и неоправданно блочному изображению. Вторая часть будет
+  недостаточно квантованной; она может выглядеть отлично, но цена битпотока для
+  этого качества будет полностью неоправданной.
+  Чего намного труднее избежать, так это проблемы перехода между двумя
+  сценами. В первых секундах малодинамичной части квантователь будет чрезвычайно
+  превышен, потому что управление битпотоком все еще ожидает встретить такие же 
+  требования к битпотоку как и в первой части. Этот "ошибочный период" с
+  чрезвычайно превышенным квантованием будет выглядеть раздражающе неприятно и
+  использовать на самом деле меньше, чем 300 кбит/сек, требуемых ему для того,
+  чтобы прилично выглядеть. Существуют способы смягчить эффект от подобных
+  подводных камней однопроходного режима, но они могут иметь склонность к
+  усилению неверного предсказания битпотока.
   </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.
+  Многопроходное кодирование может предложить огромные преимущества по сравнению
+  с однопроходным. Используя статистику, собранную при первом проходе, 
+  кодировщик может оценить, с разумной точностью, "стоимость" (в битах)
+  кодирования любого заданного кадра при любом заданном квантователе.
+  Это дела