[MPlayer-translations] r21763 - trunk/DOCS/xml/ru/encoding-guide.xml
voroshil
subversion at mplayerhq.hu
Sun Dec 24 12:21:33 CET 2006
Author: voroshil
Date: Sun Dec 24 12:21:08 2006
New Revision: 21763
Modified:
trunk/DOCS/xml/ru/encoding-guide.xml
Log:
Translation of menc-feat-x264 sect1 in encoding-guide.xml
Modified: trunk/DOCS/xml/ru/encoding-guide.xml
==============================================================================
--- trunk/DOCS/xml/ru/encoding-guide.xml (original)
+++ trunk/DOCS/xml/ru/encoding-guide.xml Sun Dec 24 12:21:08 2006
@@ -3671,295 +3671,292 @@
<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.
- </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.
+ К сожалению, улучшение очень быстро сходит на нет.
+ От <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>
- 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.
- </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-кадры не всегда полезны.
+ В 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>:
- 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.
- </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.
+ В обычных случаях эта опция не дает большого улучшения.
+ Однако, в проявляющихся или затухающих сценах взвешенное предсказание дает
+ довольно большую экономию битпотока.
+ В MPEG-4 ASP затухание обычно лучше кодируется последовательностью дорогих
+ I-кадров; используя взвешенное предсказание в B-кадрах делает возможным
+ преобразовать хотя бы часть из них в значительно более маленькие B-Кадры.
+ Потери в скорости кодирования минимальны, поскольку не требуется делать
+ дополнительные принятия решений.
+ <!-- FIXME is translation correct -->
+ Вдобавок, вопреки возможным предположениям, взвешенное предсказание не так
+ сильно влияет на требования декодера к CPU, все остальное же полностью совпадает.
+ </para>
+ <para>
+ К сожалению, текущий алгоритм адаптивного принятия решений о B-Кадрах имеет
+ твердую склонность к избеганию использования B-кадров при затуханиях.
+ До тех пор, пока это не изменится, хорошей идеей, возможно, будет добавить
+ <option>nob_adapt</option> к x264encopts, если предполагаете, что затухания
+ будут иметь сильный эффект на ваш конкретный видеоклип.
</para>
</listitem>
</itemizedlist>
@@ -3967,177 +3964,176 @@
<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.
- </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:
+ <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">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.
+ <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> 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).
+ <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> 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.
+ <option>keyint</option> - единственная возможность выбора между удобством
+ перемещения по файлу и эффективностью кодирования. По-умолчанию
+ <option>keyint</option> установлена в 250. В материале с 25fps это гарантирует
+ возможность перемещения с точностью до 10 секунд. Если вы считаете, что более
+ важным и полезным будет перемещение с точностью до 5 секунд, установите
+ <option>keyint=125</option>; это немного ухудшит качество/битпоток. Если вы
+ заботитесь только о качестве, но не о перемещаемости, вы можете установить
+ значение этой опции в более высокое значение (понимая, что улучшение будет
+ убывающим, вплоть до исчезающе малого или даже нулевого). Видео поток
+ по-прежнему будет иметь точки перемещения, пока в нем есть какие-то изменения
+ сцен.
</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.
+ 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>
@@ -4147,50 +4143,48 @@
<!-- ********** -->
<sect2 id="menc-feat-x264-example-settings">
-<title>Encoding setting examples</title>
+<title>Примеры настроек кодирования</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.
+Все настройки кодирования проверялись на тестовом видео 720x448 @30000/1001 fps
+с целевым битпотоком 900кбит/сек, на машине AMD-64 3400+ с 2400 МГц и 64-х битном режиме.
+Для каждой настройки кодирования указаны измеренная скорость кодирования (в
+кадрах в секунду) и потеря PSNR (в дБ) по сравнению с настройкой "очень высокое
+качество". Поймите, пожалуйста, что в зависимости от вашего материала, типа
+машины, прогресса разработки вы можете получить сильно отличающиеся результаты.
</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>
+ <entry>Описание</entry>
+ <entry>Опции кодирования</entry>
+ <entry>скорость (в fps)</entry>
+ <entry>Относительная потеря PSNR (в дБ)</entry>
</row>
</thead>
<tbody>
<row>
- <entry>Very high quality</entry>
+ <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>High quality</entry>
+ <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>Fast</entry>
+ <entry>Быстро</entry>
<entry><option>subq=4:bframes=2:b_pyramid:weight_b</option></entry>
<entry>17fps</entry>
<entry>-1.48dB</entry>
More information about the MPlayer-translations
mailing list