comparison DOCS/xml/ru/encoding-guide.xml @ 21866:a029a7ea0971

spelling, wording patch from Andrew Savchenko bircoph at mail dot ru with small fixes

21865:ccf368143acd

<?xml version="1.0" encoding="utf-8"?>
<!-- synced with r21849  -->
<chapter id="encoding-guide">
<title>Кодирование с <application>MEncoder</application></title>

<sect1 id="menc-feat-dvd-mpeg4">
<title>Создание высококачественного MPEG-4 ("DivX") рипа из DVD фильма</title>

  MPEG-подобное сжатие очень чувствительно к преобразованиям
  частотных интервалов, в частности, к дискретному косинусному 
  преобразованию (DCT), которое аналогично преобразованию Фурье.
  Этот вид сжатия эффективен для представления образов и сглаженных
  переходов, но у него возникают проблемы с острыми краями.
<!-- FIXME: для слова ringing я тоже не нашёл краткого однозначного 
     перевода; лучшее, что приходит на ум - это "размывание краёв",
     ясное дело, что причиной является отбрасывание малых гармоник,
     в результате чего вместо точки возникает затухающая окружность,
     но вот как это кратко выразить... -->
  Для кодирования последних Вам нужно гораздо больше битов, а иначе
  у Вас появится артефакт, известный как размывание краёв
  (англ. ringing).
  </para>

  <para>
  Частотные преобразования (DCT) выполняются независимо для каждого
  макроблока (на самом деле, для каждого блока), так что эта проблема

различное качество.
Так происходит потому, что сжатие зависит от визуальных свойств видео.
Например, аниме и живая съемка имеют сильно отличающиеся свойства и,
поэтому, требуют разные опции для получения оптимального результата.
Хорошая новость состоит в том, что некоторые опции, такие как 
<option>mbd=2</option>, <option>trell</option>, и <option>v4mv</option> могут
быть опущены.
Детальное описание основных опций кодирования смотрите ниже.
</para>

<itemizedlist>
<title>Опции для настройки:</title>

  Хорошими значениями являются -1 для быстрого кодирования или 2-4 — для 
  медленного.
</para></listitem>
<listitem><para>
  <emphasis role="bold">predia</emphasis>: предпроход поиска движения.
  Не так важен, как dia. Хорошими являются значения от 1 (по-умолчанию) до 4.
  Требует preme=2, чтобы быть действительно полезным.
</para></listitem>
<listitem><para>
  <emphasis role="bold">cmp, subcmp, precmp</emphasis>: Функция сравнения для
  поиска движения.
  Поэкспериментируйте со значениями 0 (по-умолчанию), 2 (hadamard), 3 (dct), и 6
  (соотношение сигнал-шум).
  0 &mdash; самый быстрый и достаточен для precmp.
  В случае cmp и subcmp 2 является хорошим для аниме, а 3 для живой съемки.
  6 может оказаться лучше, а может и нет, но он медленнее.
</para></listitem>
<listitem><para>
  <emphasis role="bold">last_pred</emphasis>: Количество предсказателей
  движения, берущихся из предыдущего кадра.

  (хорошо — 6, может быть даже 4); vqmin=1 также может помочь.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qns</emphasis>: очень медленно, особенно в комбинации с qprd.
  Эта опция укажет кодировщику минимизировать шум от артефактов сжатия вместо
  создания закодированного видео, полностью идентичного исходному.
  Не используйте ее, если только не перепробовали настроить все, что было 
  возможно, а результат все таки недостаточно хорош.
</para></listitem>
<listitem><para>
  <emphasis role="bold">vqcomp</emphasis>: Настраивает управление битпотоком.
  Какие значения являются хорошими зависит от фильма.
  Если хотите, можете без опаски оставить значение по-умолчанию.
  Уменьшение vqcomp отдает больше бит в сцены с низкой сложностью, увеличение
  его передает биты в очень сложные сцены (по-умолчанию: 0.5, диапазон: 0-1.
  рекомендуемый диапазон: 0.5-0.7).
</para></listitem>
<listitem><para>
  <emphasis role="bold">vlelim, vcelim</emphasis>: Устанавливает порог
  отбрасывания одиночного коэффициента для яркостной и цветностной плоскостей.
  Они кодируются независимо во всех MPEG-похожих алгоритмах.
  Идея этих опций заключается в использованию некоторой хорошей эвристики для
  определения момента, когда изменения в блоке ниже указанного Вами порога, и что его
  стоит кодировать как "блок без изменений". 
  Это сохраняет быти и, возможно, ускоряет кодирование. 
  vlelim=-4 и vcelim=9 выглядят неплохими для живой съемки, но, скорее всего, не
  помогут для аниме; при кодировании анимации Вам, возможно, следует оставить
  эту опцию неизменной.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qpel</emphasis>: Четверьтпиксельная оценка движения.
  По-умолчанию, MPEG-4 использует полупиксельную точность для оценки движения,
  следовательно, эта опция вносит дополнительные накладные рахсоды, поскольку
  сохраняет больше информации в закодированном файле.
  Улучшение/ухудшение степени сжатия зависит от фильма, но обычно эта опция не
  очень эффективна для аниме.
  qpel всегда вносит значительный вклад в CPU время декодирования (+25% на
  практике).
</para></listitem>
<listitem><para>
  <emphasis role="bold">psnr</emphasis>: не влияет на сам процесс кодирования,
  но выводит в файл тип/размер/качество каждого кадра, а также итоговый
  PSNR (Peak Signal to Noise Ratio, пиковое отношения сигнала к шуму) в конце
  прцесса.
</para></listitem>
</itemizedlist>

<itemizedlist>
<title>Опции, с которыми играть не стоит:</title>
<listitem><para>
  <emphasis role="bold">vme</emphasis>: Значение по-умолчанию является лучшим.
</para></listitem>
<listitem><para>
  <emphasis role="bold">lumi_mask, dark_mask</emphasis>: Психовизуальное
  адаптивное квантование.
  Не стоит играть с этими опциями, если заботитесь о качестве.
  Разумные значения могут быть эффективными в Вашем случае, но имейте в виду,
  что это весьма субъективно.
</para></listitem>
<listitem><para>
  <emphasis role="bold">scplx_mask</emphasis>: Пытается предотвратить появление
  квадратиков, но постобработка делает это лучше.
</para></listitem>
</itemizedlist>
</sect2>

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

<tbody>
<row>
  <entry>Очень высокое качество</entry>
  <entry><option>vcodec=mpeg4:mbd=2:mv0:trell:v4mv:cbp:last_pred=3:predia=2:dia=2:vmax_b_frames=2:vb_strategy=1:precmp=2:cmp=2:subcmp=2:preme=2:qns=2</option></entry>
  <entry>6fps</entry>
  <entry>0dB</entry>
</row>
<row>
  <entry>Высокое качество</entry>
  <entry><option>vcodec=mpeg4:mbd=2:trell:v4mv:last_pred=2:dia=-1:vmax_b_frames=2:vb_strategy=1:cmp=3:subcmp=3:precmp=0:vqcomp=0.6:turbo</option></entry>
  <entry>15fps</entry>
  <entry>-0.5dB</entry>
</row>
<row>
  <entry>Быстрое</entry>
  <entry><option>vcodec=mpeg4:mbd=2:trell:v4mv:turbo</option></entry>
  <entry>42fps</entry>
  <entry>-0.74dB</entry>
</row>
<row>
  <entry>Реального времени</entry>
  <entry><option>vcodec=mpeg4:mbd=2:turbo</option></entry>
  <entry>54fps</entry>
  <entry>-1.21dB</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>

<para>
После запуска <option>mplayer dvd://1</option> мы следуем процессу, детально
описанному в разделе <link linkend="menc-feat-telecine">Как работать с телесином
и чересстрочностью в NTSC DVD</link>, и выясняем, что это 24000/1001 fps
прогрессивное видео, а значит использовать фильтры обратного телесина,
такие как <option>pullup</option> или <option>filmdint</option> не нужно.
</para>

<para>
Далее, мы хотим определить верные границы обрезания, поэтому используем фильтр 
cropdetect:
<screen>mplayer dvd://1 -vf cropdetect</screen>
Убедитесь, что переместились к полностью заполненному кадру (например,
к светлой сцене), Вы должны увидеть в консоли <application>MPlayer</application>:
<screen>crop area: X: 0..719  Y: 57..419  (-vf crop=720:362:0:58)</screen>
Затем снова воспроизводим фильм с этим фильтром для проверки его корректности:
<screen>mplayer dvd://1 -vf crop=720:362:0:58</screen>
И убеждаемся, что все выглядит прекрасно. Далее, проверяем, что ширина и высота
делятся на 16. С шириной все в порядке, а с высотой &mdash; нет. 

деталей, хотя это, возможно, окажется незаметным. Масштабирование изображения в
сторону увеличения даст худшее качество (если Вы не увеличиваете битпоток).
Обрезка же полностью выбросит те пикселы. Это компромисс, идти на который или нет,
придется решать в каждом частном случае. Например, если DVD видео было создано
для телевидения, Вы можете захотеть избежать вертикального масштабирования,
поскольку частота строчной развертки [line sampling] соответствует тому, как содержимое
изначально записывалось.
</para>

<para>
При проверке видим, что наш фильм имеет немного движения и большое количество

лучшее качество, чем стандартная. Вы можете поэкспериментировать с этим параметром
(возможные значения смотрите на man странице), поскольку разные функции могут
давать разный прирост в качестве в зависимости от исходного материала.
Например, если Вы замечаете, что <systemitem class="library">libavcodec</systemitem>
производит слишком много блочных артефактов (квадратиков), то можете попытаться
выбрать экспериментальный NSSE в качестве функции сравнения при помощи опциеи <option>*cmp=10</option>.
</para>

<para>
Для этого фильма полученный AVI будет 138 минут длинной и размером около 3Гб.
И, поскольку Вы сказали, что размер файла значения не имеет, это вполне
приемлемый результат. Однако, если все-таки хотите получить меньший размер файла, 
можете попробовать уменьшить битпоток. Увеличение битпотока имеет снижающийся эффект, 
поэтому, хотя мы можем ясно видеть улучшение от 1800Кбит/сек до 20000Кбит/сек, оно 
может быть не столь заметно выше 20000Кбит/сек.
</para>

<para>
Так как мы пропустили исходное видео через фильтр удаления шума, то, возможно,
захочется вернуть какую-то его часть во время воспроизведения.

<application>MPlayer</application>.
Этот раздел предполагается как дополнение к man странице.
</para>

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

<itemizedlist>
<listitem><para>
  <emphasis role="bold">vhq</emphasis>
  Эта опция влияет на алгоритм принятия решений о макроблоке, чем выше значение, тем
  мудрее будут решения.
  Значение по-умолчанию можно без опаски использовать для любого кодирования, в
  то время, как более высокие значения улучшат PSNR, но будут работать значительно
  медленнее.
  Заметьте, пожалуйста, что лучший PSNR не обязательно означает лучше выглядящую
  картинку, но говорит, что она ближе к оригиналу.
  Отключение этой опции заметно ускоряет кодирование; это может быть достойным
  компромиссом, если скорость Вам критична.

<listitem><para>
  <emphasis role="bold">max_bframes</emphasis>
  Большее число допустимых последовательных B-кадров обычно улучшает
  сжимаемость, хотя оно может также привести к большему количеству блочных
  артефактов (квадратиков).
  Значение по-умолчанию &mdash; хороший выбор между сжимаемостью и качеством, но Вы
  можете увеличить его до 3, если стеснены величиной битпотока.
  Вы также можете уменьшить это значение до 1 или 0, если печетесь об отличном качестве,
  впрочем в этом случае Вы должны убедиться, что целевой битпоток достаточно высок,
  дабы кодировщик не увеличивал значение квантователя, сохраняя нужную величину
  битпотока.
</para></listitem>
<listitem><para>
  <emphasis role="bold">bf_threshold</emphasis>
  Управляет чувствительностью кодировщика к B-кадрам, где большие значения
  приводят к использованию большего количество B-кадров (и наоборот).
  Опция должна использоваться совместно с <option>max_bframes</option>;
  если Вы стеснены величиной битпотока, то должны увеличить и 
  <option>max_bframes</option>, и <option>bf_threshold</option>,
  в том время как увеличение <option>max_bframes</option> и уменьшение
  <option>bf_threshold</option> позволят кодировщику использовать больше

  Чем выше <option>me_quality</option>, тем точнее будет оценка оригинального
  движения и тем лучше получающийся отрывок будет фиксировать оригинальное движение.
  </para>

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

</para></listitem>
<listitem><para>
  <emphasis role="bold">chroma_opt</emphasis>
  Эта опция служит для увеличения качества цветного изображения вокруг чисто черных/белых
  границ вместо улучшения сжатия. Она также может помочь против
  эффекта красных ступенек ["red stairs" effect].
</para></listitem>
<listitem><para>
  <emphasis role="bold">lumi_mask</emphasis>
  Пытается отдать меньший битпоток областям изображения, которые 
  человеческий глаз не в состоянии увидеть достаточно хорошо, что

  если он яркий, или является TFT монитором).
</para></listitem>
<listitem>
  <para>
  <emphasis role="bold">qpel</emphasis>
  Увеличивает количество предполагаемых векторов движения, повышая точность
  оценки движения с полупиксельной до четверьтпиксельной.
  Идея состоит в том, чтобы найти лучшие векторы движения, которые взамен
  уменьшат битпоток (тем самым увеличивая качество).
  Однако, векторы движения с четверьтпиксельной точностью требуют большего
  количества дополнительных бит для кодирования, а векторы-кандидаты не всегда
  дают (значительно) лучшие результаты.
  Почти всегда кодек тратит дополнительные биты на повышенную точность
  впустую, а в взамен получает или вообще ничего, или небольшое увеличение качества.
  К сожалению, нет способа предсказать возможные улучшения от <option>qpel</option>, 
  так что Вам придется сделать кодирование с ней и без нее, чтобы знать
  наверняка.
  </para>
  
  <para>
  <option>qpel</option> может привести к удвоенному времени кодирования и
  требует, как минимум, на 25% большей мощности при декодировании.
  Она поддерживается не всеми аппаратными проигрывателями.
  </para>
</listitem>
<listitem><para>
  <emphasis role="bold">gmc</emphasis>
  Пытается сэкономить биты в сценах с приближением, используя один вектор
  движения для всего кадра. Это почти всегда увеличивает PSNR, но заметно
  замедляет кодирование (так же как и декодирование).
  Поэтому Вас следует использовать ее, только когда Вы включили 
  <option>vhq</option> на максимум.
  GMC <systemitem class="library">Xvid</systemitem>'а является более сложным,

  <entry>1</entry>
  <entry>2</entry>
  <entry>3</entry>
  <entry>4</entry>
  <entry>5</entry>
  <entry>Handheld</entry>
  <entry>Портативный NTSC</entry>
  <entry>Портативный PAL</entry>
  <entry>Домашний кинотеатр NTSC</entry>
  <entry>Домашний кинотеатр PAL</entry>
  <entry>HDTV</entry>

  <entry></entry>
  <entry></entry>
  <entry></entry>
</row>
<row>
  <entry>Global motion compensation</entry>
  <entry></entry>
  <entry></entry>
  <entry></entry>
  <entry></entry>
  <entry>X</entry>

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

<informaltable frame="all">
<tgroup cols="4">
<thead>

<tbody>
<row>
  <entry>Очень высокое качество</entry>
  <entry><option>chroma_opt:vhq=4:bvhq=1:quant_type=mpeg</option></entry>
  <entry>16fps</entry>
  <entry>0dB</entry>
</row>
<row>
  <entry>Высокое качество</entry>
  <entry><option>vhq=2:bvhq=1:chroma_opt:quant_type=mpeg</option></entry>
  <entry>18fps</entry>
  <entry>-0.1dB</entry>
</row>
<row>
  <entry>Быстрое</entry>
  <entry><option>turbo:vhq=0</option></entry>
  <entry>28fps</entry>
  <entry>-0.69dB</entry>
</row>
<row>
  <entry>Реального времени</entry>
  <entry><option>turbo:nochroma_me:notrellis:max_bframes=0:vhq=0</option></entry>
  <entry>38fps</entry>
  <entry>-1.48dB</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>

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

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

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

<para>

  самые важные.
  Если Вы заинтересованы в тонкой настройке либо скорости, либо качества, 
  эти две — первое, с чего Вам стоит начать.
  С точки зрения скорости, опции <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>
  

  <option>subq=6</option> &mdash; это самый медленный режим с лучшим качеством.
  Если сравнивать с <option>subq=5</option>, он обычно дает на 0.1-0.4 дБ
  больший глобальный PSNR ценой потери 25%-100% скорости.
  В отличие от остальных уровней <option>subq</option>, поведение 
  <option>subq=6</option> не так сильно зависит от <option>frameref</option>
  и <option>me</option>.  Вместо этого, эффективность <option>subq=6
  </option> по большей части зависит от количества используемых B-кадров. При
  обычном использовании это означает, что <option>subq=6</option> в сложных,
  высокодинамичных сценах имеет большое влияние как на скорость, так и на
  качество, но в сценах с малым количествах движения она не имеет такого
  эффекта. Имейте в виду, что по-прежнему рекомендуется всегда устанавливать 
  <option>bframes</option> в значение, отличное от нуля (смотрите далее).
  </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">frameref</emphasis>:
  <option>frameref</option> по-умолчанию установлена в 1, но это не значит, что
  ее стоит устанавливать в 1.
  Только увеличение <option>frameref</option> до 2 дает прирост PSNR примерно
  на 0.15дБ за счет уменьшения скорости на 5-10%; похоже, что это неплохая цена.
  <option>frameref=3</option> дает примерно 0.25dB PSNR сверх
  <option>frameref=1</option>, что должно быть видимой разницей.
  <option>frameref=3</option> медленнее примерно на 15%, чем
  <option>frameref=1</option>.
  К сожалению, улучшение очень быстро сходит на нет.
  От <option>frameref=6</option> можно ожидать прироста PSNR лишь на 

  <para>
  Увеличение <option>frameref</option> до чрезмерно высоких значений 
  <emphasis role="bold">может</emphasis> и
  <emphasis role="bold">обычно наносит</emphasis>
  вред эффективности кодирования, если CABAC отключен.
  С задействованным CABAC (настройка по-умолчанию), возможность установки 
  <option>frameref</option> "слишком высоким" на данный момент выглядит слишком
  далекой, чтобы об этом беспокоиться, а в будущем оптимизации могут вообще
  убрать такую возможность.
  </para></note>
  <para>
  Если Вас заботит скорость, разумным компромиссом будет использовать низкие
  значения <option>subq</option> и <option>frameref</option> в первом проходе, а
  <!-- FIXME  is translation correct ? -->
  затем увеличить из во втором: Вы, возможно, потеряете вплоть до 0.1дБ PSNR,
  что может быть достаточно малым значением, чтобы его заметить.
  Однако, различные значения <option>frameref</option> могут 
  иногда повлиять на решение о выборе типа кадра.
  Скорее всего, это довольно редкие крайние случаи, но если Вы хотите быть точно
  уверенными, подумайте, содержит ли Ваше видео полноэкранные
  <!-- FIXME is translation correct? -->
  периодически вспыхивающие изображения или очень большие паузы, которые могут стать
  причиной принудительной вставки I-кадра.
  Настройте <option>frameref</option> в первом проходе так, чтобы 
  она была достаточно большой, чтобы содержать длительность цикла вспыхивания
  (или паузы).
  Например, если сцены вспыхивает и гаснет в течении двух кадров из трех,
  установите <option>frameref</option> равным 3 или выше.
  Эта проблема, возможно, очень редко появляется для живой съемки, но она иногда
  появляется при записи видео игр.
 </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">me</emphasis>:
  Эта опция используется для выбора метода оценки движения.
  Изменение этой опции оказывает прямое влияние на соотношение
  скорость-качество. <option>me=dia</option> лишь на несколько процентов
  быстрее, чем поиск по-умолчанию ценой не больше 0.1дБ глобального PSNR. 
  Значение по-умолчанию (<option>me=hex</option>) разумный выбор между скоростью
  и качеством. <option>me=umh</option> немного, вплоть до 0.1дБ, улучшает
  глобальный PSNR, соответствующее падение скорости зависит меняется и 
  зависит от <option>frameref</option>.  С высокими значениями 
  <option>frameref</option> (например, 12 или около того), <option>me=umh</option>
  примерно на 40% медленнее, чем настройка по-умолчанию <option> me=hex</option>.
  С <option>frameref=3</option>, падение скорости уменьшается до 25%-30%.
  </para>
  <para>
  <option>me=esa</option> использует исчерпывающий поиск, который работает
  слишком медленно для практического применения.

  <emphasis role="bold">partitions=all</emphasis>:
  Эта опция задействует использование сегментов 8x4, 4x8 и 4x4 в предсказанных
  макроблоках (в дополнение к стандартным).
  Ее включение приведет к довольно постоянной 10%-15% потере в скорости.
  Эта опция практически бесполезна для исходного материала, содержащего только
  небольшое движение, тем не менее, для некоторого высокодинамичного,
  особенно с большим количеством мелких движущихся объектов, следует ожидать
  прироста в 0.1дБ.
</para></listitem>
<listitem>
  <para>
  <emphasis role="bold">bframes</emphasis>:
  Если Вы занимались кодированием с другими кодеками, то могли заметить, что

  проход, а также может ускорить однопроходное кодирование, если отключено
  адаптивное принятие решения о B-кадрах.
  </para>
  <para>
  С отключенным адаптивным принятием решения о B-кадрах
  (<option>x264encopts</option>'ой <option>nob_adapt</option>),
  оптимальное значение этой опции обычно не превышает 
  <option>bframes=1</option>, иначе пострадают высокодинамичные сцены.
  С включенным адаптивным принятием решения о B-кадрах (поведение по-умолчанию),
  можно безопасно использовать более высокие значения; кодировщик уменьшит
  количество B-кадров в сценах, где они повредят сжатию.
  Кодировщик редко решает использовать больше, чем 3 или 4 B-кадра;
  установка этой опции в любое более высокое значение не будет иметь большого
  эффекта.
  </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">b_adapt</emphasis>:
  Заметьте: она включена по-умолчанию.
  </para>
  <para>
  Когда эта опция включена, кодировщик будет использовать разумно 
  быстрый процесс принятия решения для уменьшения количества B-кадров,
  используемых в сценах, которые от этого не сильно выиграют.
  Вы можете использовать <option>b_bias</option> для тонкой настройки того,
  насколько "счастлив" будет кодировщик использованию B-кадров.
  Потеря в скорости при использовании адаптивных B-кадров на данный момент,
  пожалуй, умереннее, но таково же и потенциальное улучшение качества.
  Тем не менее, хуже от этого обычно не становится.
  Заметьте, что эта опция влияет на скорость и решение о типе кадра только в первом
  проходе.
  <option>b_adapt</option> и <option>b_bias</option> не имеют эффекта в
  последующих проходах.

  <emphasis role="bold">weight_b</emphasis>:
  В обычных случаях эта опция не дает большого улучшения.
  Однако, в проявляющихся или затухающих сценах взвешенное предсказание дает
  довольно большую экономию битпотока.
  В MPEG-4 ASP затухание обычно лучше кодируется последовательностью дорогих
  I-кадров; используя взвешенное предсказание в B-кадрах делает возможным
  преобразовать хотя бы часть из них в значительно более маленькие B-Кадры.
  Потери в скорости кодирования минимальны, поскольку не требуется делать
  дополнительные принятия решений.
  <!-- FIXME is translation correct -->
  Вдобавок, вопреки возможным предположениям, взвешенное предсказание не так
  сильно влияет на требования декодера к CPU, все остальное же полностью совпадает.
  </para>
  <para>
  К сожалению, текущий алгоритм адаптивного принятия решений о B-Кадрах имеет
  твердую склонность к избеганию использования B-кадров при затуханиях.
  До тех пор, пока это не изменится, хорошей идеей, возможно, будет добавить 
  <option>nob_adapt</option> к x264encopts, если предполагаете, что затухания
  будут иметь сильный эффект на Ваш конкретный видеоклип.
  </para>
</listitem>
</itemizedlist>
</sect3>

<title>Опции, относящиеся к различным предпочтениям</title>
<itemizedlist>
<listitem>
  <para>
  <emphasis role="bold">Двухпроходное кодирование</emphasis>:
  Выше советовалось всегда использовать кдирование в два прохода, но все же
  существуют причины этого не делать. Например, если Вы захватываете TV
  трансляцию и кодируете в реальном времени, придется использовать однопроходный
  режим. К тому же один проход очевидно быстрее, чем два; если Вы используете
  точно такой же набор опций в обоих случаях, двухпроходной режим медленнее
  вдвое.
  </para>
  <para>
  Все же существует очень хорошие причины использовать кодирование в два
  прохода. Во-первых, управление битпотоком при однопроходного режима не
  является телепатом и часто делает необоснованный выбор, потому что не может
  видеть общую картину. Например, предположим, что Вы имеете двухминутное видео,
  состоящее из двух независимых частей. Первая половина &mdash; очень динамичная
  сцена, продолжающаяся 60 секунд и требующая сама по себе битпоток примерно
  2500 кбит/сек, чтобы прилично выглядеть. Сразу за ней следует менее
  требовательная 60-секундная сцена, которая хорошо выглядит при 300 кбит/сек.
  Предположим, Вы запросили битпоток 14000 кбит/сек; в теории этого достаточно
  для удовлетворения потребностей обеих сцен.
  В этом случае управление битпотоком в однопроходном режиме сделает пару "ошибок".
  Во-первых, оно установит битпоток в 1400 кбит/сек для обеих частей. Первая
  часть может оказаться чрезмерно квантованной, что приведет к
  недопустимому и неоправданно блочному изображению. Вторая часть будет
  недостаточно квантованной; она может выглядеть отлично, но цена битпотока для
  этого качества будет полностью неоправданной.
  Чего намного труднее избежать, так это проблемы перехода между двумя
  сценами. В первых секундах малодинамичной части квантователь будет чрезвычайно
  превышен, потому что управление битпотоком все еще ожидает встретить такие же 
  требования к битпотоку как и в первой части. Этот "ошибочный период" с
  чрезвычайно превышенным квантованием будет выглядеть раздражающе неприятно и

<listitem><para>
  <emphasis role="bold">Кодирование в три прохода</emphasis>?
  x264 предоставляет возможность делать желаемое количество последовательных
  проходов. Если Вы указали <option>pass=1</option> при первом проходе,
  используйте затем <option>pass=3</option> в последующем проходе, этот проход
  будет одновременно читать статистику предыдущего прохода и записывать ее
  собственную. Дополнительный проход, следующий за этим, будет иметь очень
  хорошую основу для осуществления очень точных предсказаний размеров кадров при
  выбранном квантователе. На практике, общее улучшение качества от использования
  этого режима близко к нулю и, вполне возможно, третий проход приведет к
  немного худшему глобальному PSNR, чем у предыдущего прохода.
  При обычном использовании три прохода помогают, если Вы при двух проходах
  получаете либо плохое предсказание битпотока, либо плохо выглядящие переходы
  между сценами. Это в точности то, что наверняка будет происходить на очень
  коротких клипах. Существуют также особые случаи, когда три (или более)
  проходом удобны для продвинутых пользователей, но, для краткости, это
  руководство не включает в себя описание этих особых случаев.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qcomp</emphasis>:
  <option>qcomp</option> управляет соотношением количества бит, отданных
  "дорогим" высокодинамичным и "дешевым" малодинамичным кадрам. Один крайний
  случай, <option>qcomp=0</option>, предназначен для истинно постоянного
  битпотока. Обычно это сделает высокодинамичные сцены выглядящими просто
  ужасно, в то время как малодинамичные сцены будут, возможно, выглядеть
  отлично, но при этом будут использовать во много раз больший битпоток, чем им
  необходимо, чтобы выглядеть просто великолепно.
  Другая крайность, <option>qcomp=1</option>, добивается примерно одинакового
  параметра квантования (QP). Постоянный QP не выглядит ужасно, но большинство
  людей думают, что более разумно частично снизить битпоток в сильно
  дорогих сценах (где потеря качества не очень заметна) и перераспределить их в
  сцены, которые легче закодировать с отличным качеством.
  <option>qcomp</option> по-умолчанию установлена в 0.6, что по мнению многих
  людей может быть несколько мало (также часто используется 0.7-0.8).
</para></listitem>
<listitem><para>
  <emphasis role="bold">keyint</emphasis>:
  <option>keyint</option> &mdash; единственная возможность выбора между удобством

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

  <para>
  Похоже, многие думают, что хорошей идеей является значительное уменьшение силы
  воздействия фильтра деблокинга (читай, -3).
  Это, однако, почти никогда не является хорошей идеей, и, люди, это делающие, в большинстве
  случаев не совсем хорошо понимают, как работает удаление
  блочности по-умолчанию.
  </para>
  <para>
  Первая и самая важная вещь, которую нужно знать о in-loop фильтре удаления
  блочности состоит в том, что пороговые значения по-умолчанию практически
  всегда PSNR-оптимальны.
  В редких случаях, где они неоптимальны, идеальное смещение будет плюс минус 1.
  Изменение параметров деблокинга на большие значения фактически гарантирует
  ухудшение PSNR.
  Усиление фильтра размажет больше деталей; ослабление &mdash; оставит больше квадратиков.

  Это происходит потому, что ореолы имеют склонность выглядеть как детали или
  шум. Зрительное восприятие легко замечает отсутствие деталей, но ему не так
  легко обратить внимание на неверно изображенный шум.
  Когда речь идет о субъективном качестве, шум и детали в некоторой степени
  взаимозаменяемы.
  Уменьшая силу фильтра удаления блочности, Вы скорее всего увеличиваете ошибку,
  добавляя ореолы, но глаз этого не замечает, поскольку он путает артефакты с
  деталями.
  </para>
  <para>
  Однако, это <emphasis role="bold">по-прежнему</emphasis> не оправдывает

<tbody>
<row>
  <entry>Очень высокое качество</entry>
  <entry><option>subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>6fps</entry>
  <entry>0dB</entry>
</row>
<row>
  <entry>Высокое качество</entry>
  <entry><option>subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>13fps</entry>
  <entry>-0.89dB</entry>
</row>
<row>
  <entry>Быстро</entry>
  <entry><option>subq=4:bframes=2:b_pyramid:weight_b</option></entry>
  <entry>17fps</entry>
  <entry>-1.48dB</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>

21866:a029a7ea0971

<?xml version="1.0" encoding="utf-8"?>
<!-- synced with r21849 -->
<chapter id="encoding-guide">
<title>Кодирование с <application>MEncoder</application></title>

<sect1 id="menc-feat-dvd-mpeg4">
<title>Создание высококачественного MPEG-4 ("DivX") рипа из DVD фильма</title>

  MPEG-подобное сжатие очень чувствительно к преобразованиям
  частотных интервалов, в частности, к дискретному косинусному 
  преобразованию (DCT), которое аналогично преобразованию Фурье.
  Этот вид сжатия эффективен для представления образов и сглаженных
  переходов, но у него возникают проблемы с острыми краями.
  Для кодирования последних Вам нужно гораздо больше битов, а иначе
  у Вас появится артефакт, известный как ореолы.
  </para>

  <para>
  Частотные преобразования (DCT) выполняются независимо для каждого
  макроблока (на самом деле, для каждого блока), так что эта проблема

различное качество.
Так происходит потому, что сжатие зависит от визуальных свойств видео.
Например, аниме и живая съемка имеют сильно отличающиеся свойства и,
поэтому, требуют разные опции для получения оптимального результата.
Хорошая новость состоит в том, что некоторые опции, такие как 
<option>mbd=2</option>, <option>trell</option> и <option>v4mv</option>, 
никогда не следует опускать.
Детальное описание основных опций кодирования смотрите ниже.
</para>

<itemizedlist>
<title>Опции для настройки:</title>

  Хорошими значениями являются -1 для быстрого кодирования или 2-4 — для 
  медленного.
</para></listitem>
<listitem><para>
  <emphasis role="bold">predia</emphasis>: предпроход поиска движения.
  Не так важен, как dia. Хорошими являются значения от 1 (по умолчанию) до 4.
  Требует preme=2, чтобы быть действительно полезным.
</para></listitem>
<listitem><para>
  <emphasis role="bold">cmp, subcmp, precmp</emphasis>: Функция сравнения для
  поиска движения.
  Поэкспериментируйте со значениями 0 (по умолчанию), 2 (hadamard), 3 (dct), и 6
  (соотношение сигнал-шум).
  0 &mdash; самый быстрый и достаточен для precmp.
  В случае cmp и subcmp, 2 является хорошим для аниме, а 3 для живой съемки.
  6 может оказаться лучше, а может и нет, но он медленнее.
</para></listitem>
<listitem><para>
  <emphasis role="bold">last_pred</emphasis>: Количество предсказателей
  движения, берущихся из предыдущего кадра.

  (хорошо — 6, может быть даже 4); vqmin=1 также может помочь.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qns</emphasis>: очень медленно, особенно в комбинации с qprd.
  Эта опция укажет кодировщику минимизировать шум от артефактов сжатия вместо
  создания закодированного видео, полностью соответствующего исходному.
  Не используйте ее, если только не перепробовали настроить все, что было 
  возможно, а результат все таки недостаточно хорош.
</para></listitem>
<listitem><para>
  <emphasis role="bold">vqcomp</emphasis>: Настраивает управление битпотоком.
  Какие значения являются хорошими, зависит от фильма.
  Если хотите, можете без опаски оставить значение по умолчанию.
  Уменьшение vqcomp отдает больше бит в сцены с низкой сложностью, увеличение
  его передает биты в очень сложные сцены (по умолчанию: 0.5, диапазон: 0-1.
  рекомендуемый диапазон: 0.5-0.7).
</para></listitem>
<listitem><para>
  <emphasis role="bold">vlelim, vcelim</emphasis>: Устанавливает порог
  отбрасывания одиночного коэффициента для яркостной и цветностной плоскостей.
  Они кодируются независимо во всех MPEG-похожих алгоритмах.
  Идея этих опций заключается в использованию некоторой хорошей эвристики для
  определения момента, когда изменения в блоке ниже указанного Вами порога, и что его
  стоит кодировать как "блок без изменений". 
  Это сохраняет биты и, возможно, ускоряет кодирование. 
  vlelim=-4 и vcelim=9 выглядят неплохими для живой съемки, но, скорее всего, не
  помогут для аниме; при кодировании анимации Вам, возможно, следует оставить
  эту опцию неизменной.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qpel</emphasis>: Четверьтпиксельная оценка движения.
  По-умолчанию, MPEG-4 использует полупиксельную точность для поиска движения,
  следовательно, эта опция вносит дополнительные накладные расходы, поскольку
  сохраняет больше информации в закодированном файле.
  Улучшение/ухудшение степени сжатия зависит от фильма, но обычно эта опция не
  очень эффективна для аниме.
  qpel всегда вносит значительный вклад в CPU время декодирования (+25% на
  практике).
</para></listitem>
<listitem><para>
  <emphasis role="bold">psnr</emphasis>: не влияет на сам процесс кодирования,
  но выводит в файл тип/размер/качество каждого кадра, а также итоговый
  PSNR (Peak Signal to Noise Ratio, пиковое отношения сигнала к шуму) в конце
  процесса.
</para></listitem>
</itemizedlist>

<itemizedlist>
<title>Опции, с которыми играть не стоит:</title>
<listitem><para>
  <emphasis role="bold">vme</emphasis>: Значение по умолчанию является лучшим.
</para></listitem>
<listitem><para>
  <emphasis role="bold">lumi_mask, dark_mask</emphasis>: Психовизуальное
  адаптивное квантование.
  Не стоит играть с этими опциями, если заботитесь о качестве.
  Разумные значения могут быть эффективными в Вашем случае, но имейте в виду,
  что это весьма субъективно.
</para></listitem>
<listitem><para>
  <emphasis role="bold">scplx_mask</emphasis>: Пытается предотвратить появление
  квадратиков, но лучше выполнить постобработку.
</para></listitem>
</itemizedlist>
</sect2>

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

<tbody>
<row>
  <entry>Очень высокое качество</entry>
  <entry><option>vcodec=mpeg4:mbd=2:mv0:trell:v4mv:cbp:last_pred=3:predia=2:dia=2:vmax_b_frames=2:vb_strategy=1:precmp=2:cmp=2:subcmp=2:preme=2:qns=2</option></entry>
  <entry>6fps</entry>
  <entry>0дБ</entry>
</row>
<row>
  <entry>Высокое качество</entry>
  <entry><option>vcodec=mpeg4:mbd=2:trell:v4mv:last_pred=2:dia=-1:vmax_b_frames=2:vb_strategy=1:cmp=3:subcmp=3:precmp=0:vqcomp=0.6:turbo</option></entry>
  <entry>15fps</entry>
  <entry>-0.5дБ</entry>
</row>
<row>
  <entry>Быстрое</entry>
  <entry><option>vcodec=mpeg4:mbd=2:trell:v4mv:turbo</option></entry>
  <entry>42fps</entry>
  <entry>-0.74дБ</entry>
</row>
<row>
  <entry>Реального времени</entry>
  <entry><option>vcodec=mpeg4:mbd=2:turbo</option></entry>
  <entry>54fps</entry>
  <entry>-1.21дБ</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>

<para>
После запуска <option>mplayer dvd://1</option> мы следуем процессу, детально
описанному в разделе <link linkend="menc-feat-telecine">Как работать с телесином
и чересстрочностью в NTSC DVD</link>, и выясняем, что это 24000/1001 fps
построчное видео, а значит, использовать фильтры обратного телесина,
такие как <option>pullup</option> или <option>filmdint</option> не нужно.
</para>

<para id="menc-feat-dvd-mpeg4-example-crop">
Далее, мы хотим определить верные границы обрезания, поэтому используем фильтр 
cropdetect:
<screen>mplayer dvd://1 -vf cropdetect</screen>
Убедитесь, что переместились к полностью заполненному кадру (например,
к светлой сцене после пропущенных начальных титров и логотипов), 
Вы должны увидеть в консоли <application>MPlayer</application>:
<screen>crop area: X: 0..719  Y: 57..419  (-vf crop=720:362:0:58)</screen>
Затем снова воспроизводим фильм с этим фильтром для проверки его корректности:
<screen>mplayer dvd://1 -vf crop=720:362:0:58</screen>
И убеждаемся, что все выглядит прекрасно. Далее, проверяем, что ширина и высота
делятся на 16. С шириной все в порядке, а с высотой &mdash; нет. 

деталей, хотя это, возможно, окажется незаметным. Масштабирование изображения в
сторону увеличения даст худшее качество (если Вы не увеличиваете битпоток).
Обрезка же полностью выбросит те пикселы. Это компромисс, идти на который или нет,
придется решать в каждом частном случае. Например, если DVD видео было создано
для телевидения, Вы можете захотеть избежать вертикального масштабирования,
поскольку дискретизация строк соответствует тому, как содержимое
изначально записывалось.
</para>

<para>
При проверке видим, что наш фильм имеет немного движения и большое количество

лучшее качество, чем стандартная. Вы можете поэкспериментировать с этим параметром
(возможные значения смотрите на man странице), поскольку разные функции могут
давать разный прирост в качестве в зависимости от исходного материала.
Например, если Вы замечаете, что <systemitem class="library">libavcodec</systemitem>
производит слишком много блочных артефактов (квадратиков), то можете попытаться
выбрать экспериментальный NSSE в качестве функции сравнения при помощи опции 
<option>*cmp=10</option>.
</para>

<para>
Для этого фильма полученный AVI будет 138 минут длинной и размером около 3Гб.
И, поскольку Вы сказали, что размер файла значения не имеет, это вполне
приемлемый результат. Однако, если все-таки хотите получить меньший размер файла, 
можете попробовать уменьшить битпоток. Увеличение битпотока имеет снижающийся эффект, 
поэтому, хотя мы можем ясно видеть улучшение от 1800Кбит/сек до 2000Кбит/сек, оно 
может быть не столь заметно выше 2000Кбит/сек.
</para>

<para>
Так как мы пропустили исходное видео через фильтр удаления шума, то, возможно,
захочется вернуть какую-то его часть во время воспроизведения.

<application>MPlayer</application>.
Этот раздел предполагается как дополнение к man странице.
</para>

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

<itemizedlist>
<listitem><para>
  <emphasis role="bold">vhq</emphasis>
  Эта опция влияет на алгоритм принятия решений о макроблоке, чем выше значение, тем
  мудрее будут решения.
  Значение по умолчанию можно без опаски использовать для любого кодирования, в
  то время, как более высокие значения всегда улучшат PSNR, но будут работать значительно
  медленнее.
  Заметьте, пожалуйста, что лучший PSNR не обязательно означает лучше выглядящую
  картинку, но говорит, что она ближе к оригиналу.
  Отключение этой опции заметно ускоряет кодирование; это может быть достойным
  компромиссом, если скорость Вам критична.

<listitem><para>
  <emphasis role="bold">max_bframes</emphasis>
  Большее число допустимых последовательных B-кадров обычно улучшает
  сжимаемость, хотя оно может также привести к большему количеству блочных
  артефактов (квадратиков).
  Значение по умолчанию &mdash; хороший выбор между сжимаемостью и качеством, но Вы
  можете увеличить его до 3, если стеснены величиной битпотока.
  Вы также можете уменьшить это значение до 1 или 0, если печетесь об отличном качестве,
  впрочем в этом случае Вы должны убедиться, что целевой битпоток достаточно высок,
  дабы кодировщик не увеличивал значение квантователя, сохраняя нужную величину
  битпотока.
</para></listitem>
<listitem><para>
  <emphasis role="bold">bf_threshold</emphasis>
  Управляет чувствительностью кодировщика к B-кадрам, где большие значения
  приводят к использованию большего количества B-кадров (и наоборот).
  Опция должна использоваться совместно с <option>max_bframes</option>;
  если Вы стеснены величиной битпотока, то должны увеличить и 
  <option>max_bframes</option>, и <option>bf_threshold</option>,
  в том время как увеличение <option>max_bframes</option> и уменьшение
  <option>bf_threshold</option> позволят кодировщику использовать больше

  Чем выше <option>me_quality</option>, тем точнее будет оценка оригинального
  движения и тем лучше получающийся отрывок будет фиксировать оригинальное движение.
  </para>

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

</para></listitem>
<listitem><para>
  <emphasis role="bold">chroma_opt</emphasis>
  Эта опция служит для увеличения качества цветного изображения вокруг чисто черных/белых
  границ вместо улучшения сжатия. Она также может помочь против
  эффекта "красных ступенек".
</para></listitem>
<listitem><para>
  <emphasis role="bold">lumi_mask</emphasis>
  Пытается отдать меньший битпоток областям изображения, которые 
  человеческий глаз не в состоянии увидеть достаточно хорошо, что

  если он яркий, или является TFT монитором).
</para></listitem>
<listitem>
  <para>
  <emphasis role="bold">qpel</emphasis>
  Увеличивает количество предполагаемых векторов движения, путём повышения 
  точности оценки движения с полупиксельной до четвертьпиксельной.
  Идея состоит в том, чтобы найти лучшие векторы движения, которые взамен
  уменьшат битпоток (тем самым увеличивая качество).
  Однако, векторы движения с четверьтпиксельной точностью требуют большего
  количества дополнительных бит для кодирования, а векторы-кандидаты не всегда
  дают (значительно) лучшие результаты.
  Достаточно часто кодек тратит дополнительные биты на повышенную точность
  впустую, а взамен получает или вообще ничего, или небольшое увеличение качества.
  К сожалению, нет способа предсказать возможные улучшения от <option>qpel</option>, 
  так что Вам придется сделать кодирование с ней и без нее, чтобы знать
  наверняка.
  </para>
  
  <para>
  <option>qpel</option> может почти удвоить время кодирования и
  требует, как минимум, на 25% большей мощности при декодировании.
  Она поддерживается не всеми аппаратными проигрывателями.
  </para>
</listitem>
<listitem><para>
  <emphasis role="bold">gmc</emphasis>
  Пытается сэкономить биты в панорамных сценах, используя один вектор
  движения для всего кадра. Это почти всегда увеличивает PSNR, но заметно
  замедляет кодирование (так же как и декодирование).
  Поэтому Вас следует использовать ее, только когда Вы включили 
  <option>vhq</option> на максимум.
  GMC <systemitem class="library">Xvid</systemitem>'а является более сложным,

  <entry>1</entry>
  <entry>2</entry>
  <entry>3</entry>
  <entry>4</entry>
  <entry>5</entry>
  <entry>Карманный</entry>
  <entry>Портативный NTSC</entry>
  <entry>Портативный PAL</entry>
  <entry>Домашний кинотеатр NTSC</entry>
  <entry>Домашний кинотеатр PAL</entry>
  <entry>HDTV</entry>

  <entry></entry>
  <entry></entry>
  <entry></entry>
</row>
<row>
  <entry>Глобальная компенсация движения</entry>
  <entry></entry>
  <entry></entry>
  <entry></entry>
  <entry></entry>
  <entry>X</entry>

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

<informaltable frame="all">
<tgroup cols="4">
<thead>

<tbody>
<row>
  <entry>Очень высокое качество</entry>
  <entry><option>chroma_opt:vhq=4:bvhq=1:quant_type=mpeg</option></entry>
  <entry>16fps</entry>
  <entry>0дБ</entry>
</row>
<row>
  <entry>Высокое качество</entry>
  <entry><option>vhq=2:bvhq=1:chroma_opt:quant_type=mpeg</option></entry>
  <entry>18fps</entry>
  <entry>-0.1дБ</entry>
</row>
<row>
  <entry>Быстрое</entry>
  <entry><option>turbo:vhq=0</option></entry>
  <entry>28fps</entry>
  <entry>-0.69дБ</entry>
</row>
<row>
  <entry>Реального времени</entry>
  <entry><option>turbo:nochroma_me:notrellis:max_bframes=0:vhq=0</option></entry>
  <entry>38fps</entry>
  <entry>-1.48дБ</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>

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

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

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

<para>

  самые важные.
  Если Вы заинтересованы в тонкой настройке либо скорости, либо качества, 
  эти две — первое, с чего Вам стоит начать.
  С точки зрения скорости, опции <option>frameref</option> и
  <option>subq</option> очень жестко взаимодействуют друг с другом.
  Опыт показывает, что с одним ссылочным кадром
  <option>subq=5</option> (настройка по умолчанию) расходует на 35% больше
  времени, чем <option>subq=1</option>.
  С 6 ссылочными кадрами эта величина достигает 60%.
  Эффект <option>subq</option> на PSNR выглядит довольно постоянным, в отличие
  от количества ссылочных кадров.
  Как правило, <option>subq=5</option> достигает значения глобального PSNR 
  на 0.2-0.5 дБ большего, чем  при <option>subq=1</option>.
  Обычно этого достаточно, чтобы заметить.
  </para>
  

  <option>subq=6</option> &mdash; это самый медленный режим с лучшим качеством.
  Если сравнивать с <option>subq=5</option>, он обычно дает на 0.1-0.4 дБ
  больший глобальный PSNR ценой потери 25%-100% скорости.
  В отличие от остальных уровней <option>subq</option>, поведение 
  <option>subq=6</option> не так сильно зависит от <option>frameref</option>
  и <option>me</option>. Вместо этого, эффективность <option>subq=6</option> 
  по большей части зависит от количества используемых B-кадров. При
  обычном использовании это означает, что <option>subq=6</option> в сложных,
  высокодинамичных сценах имеет большое влияние как на скорость, так и на
  качество, но в сценах с малым количествах движения она не имеет такого
  эффекта. Имейте в виду, что по-прежнему рекомендуется всегда устанавливать 
  <option>bframes</option> в значение, отличное от нуля (смотрите далее).
  </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">frameref</emphasis>:
  <option>frameref</option> по умолчанию установлена в 1, но это не значит, что
  ее стоит устанавливать в 1.
  Только увеличение <option>frameref</option> до 2 дает прирост PSNR примерно
  на 0.15дБ за счет уменьшения скорости на 5-10%; похоже, что это неплохая цена.
  <option>frameref=3</option> дает примерно 0.25дБ PSNR сверх
  <option>frameref=1</option>, что должно быть видимой разницей.
  <option>frameref=3</option> медленнее примерно на 15%, чем
  <option>frameref=1</option>.
  К сожалению, улучшение очень быстро сходит на нет.
  От <option>frameref=6</option> можно ожидать прироста PSNR лишь на 

  <para>
  Увеличение <option>frameref</option> до чрезмерно высоких значений 
  <emphasis role="bold">может</emphasis> и
  <emphasis role="bold">обычно наносит</emphasis>
  вред эффективности кодирования, если CABAC отключен.
  С задействованным CABAC (настройка по умолчанию), возможность установки 
  <option>frameref</option> "слишком высоким" на данный момент выглядит слишком
  далекой, чтобы об этом беспокоиться, а в будущем оптимизации могут вообще
  убрать такую возможность.
  </para></note>
  <para>
  Если Вас заботит скорость, разумным компромиссом будет использовать низкие
  значения <option>subq</option> и <option>frameref</option> в первом проходе, а
  затем увеличить их во втором. Обычно, это обладает ничтожным отрицательным
  эффектом на конечное качество: Вы, возможно, потеряете вплоть до 0.1дБ PSNR,
  что должно быть слишком малой разницей, чтобы её заметить.
  Однако, различные значения <option>frameref</option> могут 
  иногда повлиять на решение о выборе типа кадра.
  Скорее всего, это довольно редкие крайние случаи, но если Вы хотите быть точно
  уверенными, посмотрите, содержит ли Ваше видео полноэкранные
  <!-- FIXME is translation correct? -->
  периодически вспыхивающие изображения или очень большие паузы, которые могут стать
  причиной принудительной вставки I-кадра.
  Настройте <option>frameref</option> в первом проходе так, чтобы 
  она была достаточно большой для содержания длительности цикла вспыхивания
  (или паузы).
  Например, если сцены вспыхивают и гаснут между двумя изображениями в течении 
  трёх кадров, установите <option>frameref</option> равным 3 или выше.
  Эта проблема, возможно, очень редко появляется для живой съемки, но она иногда
  возникает при записи видео игр.
 </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">me</emphasis>:
  Эта опция используется для выбора метода оценки движения.
  Изменение этой опции оказывает прямое влияние на соотношение
  скорость-качество. <option>me=dia</option> лишь на несколько процентов
  быстрее, чем поиск по умолчанию, ценой не больше 0.1дБ глобального PSNR. 
  Значение по умолчанию (<option>me=hex</option>) &mdash; разумный выбор между скоростью
  и качеством. <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> использует исчерпывающий поиск, который работает
  слишком медленно для практического применения.

  <emphasis role="bold">partitions=all</emphasis>:
  Эта опция задействует использование сегментов 8x4, 4x8 и 4x4 в предсказанных
  макроблоках (в дополнение к стандартным).
  Ее включение приведет к довольно постоянной 10%-15% потере в скорости.
  Эта опция практически бесполезна для исходного материала, содержащего только
  небольшое движение, тем не менее, для некоторого высокодинамичного материала,
  особенно с большим количеством мелких движущихся объектов, следует ожидать
  прироста около 0.1дБ.
</para></listitem>
<listitem>
  <para>
  <emphasis role="bold">bframes</emphasis>:
  Если Вы занимались кодированием с другими кодеками, то могли заметить, что

  проход, а также может ускорить однопроходное кодирование, если отключено
  адаптивное принятие решения о B-кадрах.
  </para>
  <para>
  С отключенным адаптивным принятием решения о B-кадрах
  (<option>nob_adapt</option> в <option>x264encopts</option>),
  оптимальное значение этой опции обычно не превышает 
  <option>bframes=1</option>, иначе могут пострадать высокодинамичные сцены.
  С включенным адаптивным принятием решения о B-кадрах (поведение по умолчанию),
  можно безопасно использовать более высокие значения; кодировщик уменьшит
  количество B-кадров в сценах, где они повредят сжатию.
  Кодировщик редко решает использовать больше, чем 3 или 4 B-кадра;
  установка этой опции в любое более высокое значение не будет иметь большого
  эффекта.
  </para>
</listitem>
<listitem>
  <para>
  <emphasis role="bold">b_adapt</emphasis>:
  Заметьте: она включена по умолчанию.
  </para>
  <para>
  Когда эта опция включена, кодировщик будет использовать разумно 
  быстрый процесс принятия решения для уменьшения количества B-кадров,
  используемых в сценах, которые от этого не сильно выиграют.
  Вы можете использовать <option>b_bias</option> для тонкой настройки того,
  насколько "счастлив" будет кодировщик использованию B-кадров.
  Потеря в скорости при использовании адаптивных B-кадров на данный момент
  весьма невелика, но таково же и потенциальное улучшение качества.
  Тем не менее, хуже от этого обычно не становится.
  Заметьте, что эта опция влияет на скорость и решение о типе кадра только в первом
  проходе.
  <option>b_adapt</option> и <option>b_bias</option> не имеют эффекта в
  последующих проходах.

  <emphasis role="bold">weight_b</emphasis>:
  В обычных случаях эта опция не дает большого улучшения.
  Однако, в проявляющихся или затухающих сценах взвешенное предсказание дает
  довольно большую экономию битпотока.
  В MPEG-4 ASP затухание обычно лучше кодируется последовательностью дорогих
  I-кадров; использование взвешенного предсказания в B-кадрах делает возможным
  преобразовать хотя бы часть из них в значительно более меньшие B-кадры.
  Потери в скорости кодирования минимальны, поскольку не требуется делать
  дополнительные принятия решений.
  Вдобавок, вопреки расхожему мнению, взвешенное предсказание не
  сильно влияет на требования декодера к CPU при прочих равных условиях.
  </para>
  <para>
  К сожалению, текущий алгоритм адаптивного принятия решений о B-кадрах имеет
  твердую склонность к избеганию использования B-кадров при затуханиях.
  До тех пор, пока это не изменится, хорошей идеей, возможно, будет добавить 
  <option>nob_adapt</option> к x264encopts, если предполагаете, что затухания
  будут давать существенный вклад в Вашем конкретном видеоклипе.
  </para>
</listitem>
</itemizedlist>
</sect3>

<title>Опции, относящиеся к различным предпочтениям</title>
<itemizedlist>
<listitem>
  <para>
  <emphasis role="bold">Двухпроходное кодирование</emphasis>:
  Выше советовалось всегда использовать кодирование в два прохода, но все же
  существуют причины этого не делать. Например, если Вы захватываете TV
  трансляцию и кодируете в реальном времени, придется использовать однопроходный
  режим. К тому же один проход очевидно быстрее, чем два; если Вы используете
  точно такой же набор опций в обоих случаях, двухпроходной режим медленнее
  почти вдвое.
  </para>
  <para>
  Все же существует очень хорошие причины использовать кодирование в два
  прохода. Во-первых, управление битпотоком однопроходного режима не
  является телепатом и часто делает необоснованный выбор, потому что не может
  видеть общую картину. Например, предположим, что Вы имеете двухминутное видео,
  состоящее из двух независимых частей. Первая половина &mdash; очень динамичная
  сцена, продолжающаяся 60 секунд и требующая сама по себе битпоток примерно
  2500 кбит/сек, чтобы прилично выглядеть. Сразу за ней следует гораздо менее
  требовательная 60-секундная сцена, которая хорошо выглядит при 300 кбит/сек.
  Предположим, Вы запросили битпоток 1400 кбит/сек; в теории этого достаточно
  для удовлетворения потребностей обеих сцен.
  В этом случае управление битпотоком в однопроходном режиме сделает пару "ошибок".
  Во-первых, оно установит битпоток в 1400 кбит/сек для обеих частей. Первая
  часть может оказаться чрезмерно квантованной, что приведет к
  недопустимо выглядящему и неоправданно блочному изображению. Вторая часть будет
  существенно недостаточно квантованной; она может выглядеть отлично, но цена 
  битпотока для этого качества будет полностью неоправданной.
  Чего намного труднее избежать, так это проблемы перехода между двумя
  сценами. В первых секундах малодинамичной части квантователь будет чрезвычайно
  превышен, потому что управление битпотоком все еще ожидает встретить такие же 
  требования к битпотоку как и в первой части. Этот "ошибочный период" с
  чрезвычайно превышенным квантованием будет выглядеть раздражающе неприятно и

<listitem><para>
  <emphasis role="bold">Кодирование в три прохода</emphasis>?
  x264 предоставляет возможность делать желаемое количество последовательных
  проходов. Если Вы указали <option>pass=1</option> при первом проходе,
  используйте затем <option>pass=3</option> в последующем проходе, этот проход
  будет одновременно читать статистику предыдущего прохода и записывать свою 
  собственную. Дополнительный проход, следующий за этим, будет иметь очень
  хорошую основу для осуществления очень точных предсказаний размеров кадров при
  выбранном квантователе. На практике, общее улучшение качества от использования
  этого режима близко к нулю и, вполне возможно, третий проход приведет к
  немного худшему глобальному PSNR, чем у предыдущего прохода.
  При обычном использовании три прохода помогают, если Вы при двух проходах
  получаете либо плохое предсказание битпотока, либо плохо выглядящие переходы
  между сценами. Это отчасти то, что наверняка будет происходить на очень
  коротких клипах. Существуют также особые случаи, когда три (или более)
  проходом удобны для продвинутых пользователей, но, для краткости, это
  руководство не включает в себя описание этих особых случаев.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qcomp</emphasis>:
  <option>qcomp</option> управляет соотношением количества бит, отданных
  "дорогим" высокодинамичным и "дешевым" малодинамичным кадрам. Один крайний
  случай: <option>qcomp=0</option>, предназначен для истинно постоянного
  битпотока. Обычно это сделает высокодинамичные сцены выглядящими просто
  ужасно, в то время как малодинамичные сцены будут, возможно, выглядеть
  абсолютно великолепно, но при этом будут использовать во много раз больший 
  битпоток, чем им необходимо, чтобы выглядеть лишь превосходно.
  Другая крайность: <option>qcomp=1</option>, добивается примерно одинакового
  параметра квантования (QP). Постоянный QP не выглядит плохо, но большинство
  людей думают, что более разумно частично снизить битпоток в сильно
  дорогих сценах (где потеря качества не очень заметна) и перераспределить их в
  сцены, которые легче закодировать с отличным качеством.
  <option>qcomp</option> по умолчанию установлена в 0.6, что по мнению многих
  людей может быть несколько мало (также часто используется 0.7-0.8).
</para></listitem>
<listitem><para>
  <emphasis role="bold">keyint</emphasis>:
  <option>keyint</option> &mdash; единственная возможность выбора между удобством

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

  <para>
  Похоже, многие думают, что хорошей идеей является значительное уменьшение силы
  воздействия фильтра деблокинга (читай, -3).
  Это, однако, почти никогда не является хорошей идеей, и, люди, это делающие, в большинстве
  случаев не совсем хорошо понимают, как работает удаление
  блочности по умолчанию.
  </para>
  <para>
  <!-- FIXME: Можно ли как-то перевести in-loop? -->
  Первая и самая важная вещь, которую нужно знать о in-loop фильтре удаления
  блочности состоит в том, что пороговые значения по умолчанию практически
  всегда PSNR-оптимальны.
  В редких случаях, где они неоптимальны, идеальное смещение будет плюс минус 1.
  Изменение параметров деблокинга на большие значения фактически гарантирует
  ухудшение PSNR.
  Усиление фильтра размажет больше деталей; ослабление &mdash; оставит больше квадратиков.

  Это происходит потому, что ореолы имеют склонность выглядеть как детали или
  шум. Зрительное восприятие легко замечает отсутствие деталей, но ему не так
  легко обратить внимание на неверно изображенный шум.
  Когда речь идет о субъективном качестве, шум и детали в некоторой степени
  взаимозаменяемы.
  Уменьшая силу фильтра удаления блочности, Вы, скорее всего, увеличиваете ошибку,
  добавляя ореолы, но глаз этого не замечает, поскольку он путает артефакты с
  деталями.
  </para>
  <para>
  Однако, это <emphasis role="bold">по-прежнему</emphasis> не оправдывает

<tbody>
<row>
  <entry>Очень высокое качество</entry>
  <entry><option>subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>6fps</entry>
  <entry>0дБ</entry>
</row>
<row>
  <entry>Высокое качество</entry>
  <entry><option>subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>13fps</entry>
  <entry>-0.89дБ</entry>
</row>
<row>
  <entry>Быстро</entry>
  <entry><option>subq=4:bframes=2:b_pyramid:weight_b</option></entry>
  <entry>17fps</entry>
  <entry>-1.48дБ</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>