diff options
author | voroshil <voroshil@b3059339-0415-0410-9bf9-f77b7e298cf2> | 2006-12-24 11:21:08 +0000 |
---|---|---|
committer | voroshil <voroshil@b3059339-0415-0410-9bf9-f77b7e298cf2> | 2006-12-24 11:21:08 +0000 |
commit | e5dae6e87f2002449acf8b4f4f86a00b57ad6fed (patch) | |
tree | 4f048b89603efc2a941e467a830f56e8a97be28b /DOCS/xml | |
parent | 4ccaabcc2847f62d7de49451c34e3abc9c653e89 (diff) | |
download | mpv-e5dae6e87f2002449acf8b4f4f86a00b57ad6fed.tar.bz2 mpv-e5dae6e87f2002449acf8b4f4f86a00b57ad6fed.tar.xz |
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
Diffstat (limited to 'DOCS/xml')
-rw-r--r-- | DOCS/xml/ru/encoding-guide.xml | 714 |
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. + Многопроходное кодирование может предложить огромные преимущества по сравнению |