[MPlayer-translations] r21884 - trunk/DOCS/xml/ru/encoding-guide.xml
voroshil
subversion at mplayerhq.hu
Fri Jan 12 12:01:12 CET 2007
Author: voroshil
Date: Fri Jan 12 12:01:11 2007
New Revision: 21884
Modified:
trunk/DOCS/xml/ru/encoding-guide.xml
Log:
spelling, wording
patch from Andrew Savchenko bircoph at mail dot ru with small fixes
Modified: trunk/DOCS/xml/ru/encoding-guide.xml
==============================================================================
--- trunk/DOCS/xml/ru/encoding-guide.xml (original)
+++ trunk/DOCS/xml/ru/encoding-guide.xml Fri Jan 12 12:01:11 2007
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="utf-8"?>
-<!-- synced with r21849 -->
+<!-- synced with r21849 -->
<chapter id="encoding-guide">
<title>Кодирование с <application>MEncoder</application></title>
@@ -494,14 +494,8 @@
преобразованию (DCT), которое аналогично преобразованию Фурье.
Этот вид сжатия эффективен для представления образов и сглаженных
переходов, но у него возникают проблемы с острыми краями.
-<!-- FIXME: для слова ringing я тоже не нашёл краткого однозначного
- перевода; лучшее, что приходит на ум - это "размывание краёв",
- ясное дело, что причиной является отбрасывание малых гармоник,
- в результате чего вместо точки возникает затухающая окружность,
- но вот как это кратко выразить... -->
Для кодирования последних Вам нужно гораздо больше битов, а иначе
- у Вас появится артефакт, известный как размывание краёв
- (англ. ringing).
+ у Вас появится артефакт, известный как ореолы.
</para>
<para>
@@ -2773,8 +2767,8 @@
Например, аниме и живая съемка имеют сильно отличающиеся свойства и,
поэтому, требуют разные опции для получения оптимального результата.
Хорошая новость состоит в том, что некоторые опции, такие как
-<option>mbd=2</option>, <option>trell</option>, и <option>v4mv</option> могут
-быть опущены.
+<option>mbd=2</option>, <option>trell</option> и <option>v4mv</option>,
+никогда не следует опускать.
Детальное описание основных опций кодирования смотрите ниже.
</para>
@@ -2804,16 +2798,16 @@
</para></listitem>
<listitem><para>
<emphasis role="bold">predia</emphasis>: предпроход поиска движения.
- Не так важен, как dia. Хорошими являются значения от 1 (по-умолчанию) до 4.
+ Не так важен, как dia. Хорошими являются значения от 1 (по умолчанию) до 4.
Требует preme=2, чтобы быть действительно полезным.
</para></listitem>
<listitem><para>
<emphasis role="bold">cmp, subcmp, precmp</emphasis>: Функция сравнения для
поиска движения.
- Поэкспериментируйте со значениями 0 (по-умолчанию), 2 (hadamard), 3 (dct), и 6
+ Поэкспериментируйте со значениями 0 (по умолчанию), 2 (hadamard), 3 (dct), и 6
(соотношение сигнал-шум).
0 — самый быстрый и достаточен для precmp.
- В случае cmp и subcmp 2 является хорошим для аниме, а 3 для живой съемки.
+ В случае cmp и subcmp, 2 является хорошим для аниме, а 3 для живой съемки.
6 может оказаться лучше, а может и нет, но он медленнее.
</para></listitem>
<listitem><para>
@@ -2837,16 +2831,16 @@
<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-1.
рекомендуемый диапазон: 0.5-0.7).
</para></listitem>
<listitem><para>
@@ -2856,15 +2850,15 @@
Идея этих опций заключается в использованию некоторой хорошей эвристики для
определения момента, когда изменения в блоке ниже указанного Вами порога, и что его
стоит кодировать как "блок без изменений".
- Это сохраняет быти и, возможно, ускоряет кодирование.
+ Это сохраняет биты и, возможно, ускоряет кодирование.
vlelim=-4 и vcelim=9 выглядят неплохими для живой съемки, но, скорее всего, не
помогут для аниме; при кодировании анимации Вам, возможно, следует оставить
эту опцию неизменной.
</para></listitem>
<listitem><para>
<emphasis role="bold">qpel</emphasis>: Четверьтпиксельная оценка движения.
- По-умолчанию, MPEG-4 использует полупиксельную точность для оценки движения,
- следовательно, эта опция вносит дополнительные накладные рахсоды, поскольку
+ По-умолчанию, MPEG-4 использует полупиксельную точность для поиска движения,
+ следовательно, эта опция вносит дополнительные накладные расходы, поскольку
сохраняет больше информации в закодированном файле.
Улучшение/ухудшение степени сжатия зависит от фильма, но обычно эта опция не
очень эффективна для аниме.
@@ -2875,14 +2869,14 @@
<emphasis role="bold">psnr</emphasis>: не влияет на сам процесс кодирования,
но выводит в файл тип/размер/качество каждого кадра, а также итоговый
PSNR (Peak Signal to Noise Ratio, пиковое отношения сигнала к шуму) в конце
- прцесса.
+ процесса.
</para></listitem>
</itemizedlist>
<itemizedlist>
<title>Опции, с которыми играть не стоит:</title>
<listitem><para>
- <emphasis role="bold">vme</emphasis>: Значение по-умолчанию является лучшим.
+ <emphasis role="bold">vme</emphasis>: Значение по умолчанию является лучшим.
</para></listitem>
<listitem><para>
<emphasis role="bold">lumi_mask, dark_mask</emphasis>: Психовизуальное
@@ -2893,7 +2887,7 @@
</para></listitem>
<listitem><para>
<emphasis role="bold">scplx_mask</emphasis>: Пытается предотвратить появление
- квадратиков, но постобработка делает это лучше.
+ квадратиков, но лучше выполнить постобработку.
</para></listitem>
</itemizedlist>
</sect2>
@@ -2934,25 +2928,25 @@
<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>
+ <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.5dB</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.74dB</entry>
+ <entry>-0.74дБ</entry>
</row>
<row>
<entry>Реального времени</entry>
<entry><option>vcodec=mpeg4:mbd=2:turbo</option></entry>
<entry>54fps</entry>
- <entry>-1.21dB</entry>
+ <entry>-1.21дБ</entry>
</row>
</tbody>
</tgroup>
@@ -3050,16 +3044,17 @@
После запуска <option>mplayer dvd://1</option> мы следуем процессу, детально
описанному в разделе <link linkend="menc-feat-telecine">Как работать с телесином
и чересстрочностью в NTSC DVD</link>, и выясняем, что это 24000/1001 fps
-прогрессивное видео, а значит использовать фильтры обратного телесина,
+построчное видео, а значит, использовать фильтры обратного телесина,
такие как <option>pullup</option> или <option>filmdint</option> не нужно.
</para>
-<para>
+<para id="menc-feat-dvd-mpeg4-example-crop">
Далее, мы хотим определить верные границы обрезания, поэтому используем фильтр
cropdetect:
<screen>mplayer dvd://1 -vf cropdetect</screen>
Убедитесь, что переместились к полностью заполненному кадру (например,
-к светлой сцене), Вы должны увидеть в консоли <application>MPlayer</application>:
+к светлой сцене после пропущенных начальных титров и логотипов),
+Вы должны увидеть в консоли <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>
@@ -3098,7 +3093,7 @@
Обрезка же полностью выбросит те пикселы. Это компромисс, идти на который или нет,
придется решать в каждом частном случае. Например, если DVD видео было создано
для телевидения, Вы можете захотеть избежать вертикального масштабирования,
-поскольку частота строчной развертки [line sampling] соответствует тому, как содержимое
+поскольку дискретизация строк соответствует тому, как содержимое
изначально записывалось.
</para>
@@ -3132,7 +3127,8 @@
давать разный прирост в качестве в зависимости от исходного материала.
Например, если Вы замечаете, что <systemitem class="library">libavcodec</systemitem>
производит слишком много блочных артефактов (квадратиков), то можете попытаться
-выбрать экспериментальный NSSE в качестве функции сравнения при помощи опциеи <option>*cmp=10</option>.
+выбрать экспериментальный NSSE в качестве функции сравнения при помощи опции
+<option>*cmp=10</option>.
</para>
<para>
@@ -3140,8 +3136,8 @@
И, поскольку Вы сказали, что размер файла значения не имеет, это вполне
приемлемый результат. Однако, если все-таки хотите получить меньший размер файла,
можете попробовать уменьшить битпоток. Увеличение битпотока имеет снижающийся эффект,
-поэтому, хотя мы можем ясно видеть улучшение от 1800Кбит/сек до 20000Кбит/сек, оно
-может быть не столь заметно выше 20000Кбит/сек.
+поэтому, хотя мы можем ясно видеть улучшение от 1800Кбит/сек до 2000Кбит/сек, оно
+может быть не столь заметно выше 2000Кбит/сек.
</para>
<para>
@@ -3195,7 +3191,7 @@
</para>
<para>
-Настройки по-умолчанию Xvid уже являются хорошим выбором между скоростью и
+Настройки по умолчанию Xvid уже являются хорошим выбором между скоростью и
качеством, поэтому Вы можете без опасений придерживаться их, если следующий
раздел Вас озадачивает.
</para>
@@ -3211,8 +3207,8 @@
<emphasis role="bold">vhq</emphasis>
Эта опция влияет на алгоритм принятия решений о макроблоке, чем выше значение, тем
мудрее будут решения.
- Значение по-умолчанию можно без опаски использовать для любого кодирования, в
- то время, как более высокие значения улучшат PSNR, но будут работать значительно
+ Значение по умолчанию можно без опаски использовать для любого кодирования, в
+ то время, как более высокие значения всегда улучшат PSNR, но будут работать значительно
медленнее.
Заметьте, пожалуйста, что лучший PSNR не обязательно означает лучше выглядящую
картинку, но говорит, что она ближе к оригиналу.
@@ -3230,7 +3226,7 @@
Большее число допустимых последовательных B-кадров обычно улучшает
сжимаемость, хотя оно может также привести к большему количеству блочных
артефактов (квадратиков).
- Значение по-умолчанию — хороший выбор между сжимаемостью и качеством, но Вы
+ Значение по умолчанию — хороший выбор между сжимаемостью и качеством, но Вы
можете увеличить его до 3, если стеснены величиной битпотока.
Вы также можете уменьшить это значение до 1 или 0, если печетесь об отличном качестве,
впрочем в этом случае Вы должны убедиться, что целевой битпоток достаточно высок,
@@ -3240,7 +3236,7 @@
<listitem><para>
<emphasis role="bold">bf_threshold</emphasis>
Управляет чувствительностью кодировщика к B-кадрам, где большие значения
- приводят к использованию большего количество B-кадров (и наоборот).
+ приводят к использованию большего количества B-кадров (и наоборот).
Опция должна использоваться совместно с <option>max_bframes</option>;
если Вы стеснены величиной битпотока, то должны увеличить и
<option>max_bframes</option>, и <option>bf_threshold</option>,
@@ -3290,7 +3286,7 @@
</para>
<para>
- Настройка по-умолчанию лучше во всех случаях, поэтому не рекомендуется ее
+ Настройка по умолчанию лучше во всех случаях, поэтому не рекомендуется ее
выключать, если только Вы действительно не гонитесь за скоростью, поскольку
биты, сэкономленные хорошей оценкой движения, могут быть использованы
где-нибудь еще, увеличивая общее качество.
@@ -3311,7 +3307,7 @@
<emphasis role="bold">chroma_opt</emphasis>
Эта опция служит для увеличения качества цветного изображения вокруг чисто черных/белых
границ вместо улучшения сжатия. Она также может помочь против
- эффекта красных ступенек ["red stairs" effect].
+ эффекта "красных ступенек".
</para></listitem>
<listitem><para>
<emphasis role="bold">lumi_mask</emphasis>
@@ -3326,29 +3322,29 @@
<listitem>
<para>
<emphasis role="bold">qpel</emphasis>
- Увеличивает количество предполагаемых векторов движения, повышая точность
- оценки движения с полупиксельной до четверьтпиксельной.
+ Увеличивает количество предполагаемых векторов движения, путём повышения
+ точности оценки движения с полупиксельной до четвертьпиксельной.
Идея состоит в том, чтобы найти лучшие векторы движения, которые взамен
уменьшат битпоток (тем самым увеличивая качество).
Однако, векторы движения с четверьтпиксельной точностью требуют большего
количества дополнительных бит для кодирования, а векторы-кандидаты не всегда
дают (значительно) лучшие результаты.
- Почти всегда кодек тратит дополнительные биты на повышенную точность
- впустую, а в взамен получает или вообще ничего, или небольшое увеличение качества.
+ Достаточно часто кодек тратит дополнительные биты на повышенную точность
+ впустую, а взамен получает или вообще ничего, или небольшое увеличение качества.
К сожалению, нет способа предсказать возможные улучшения от <option>qpel</option>,
так что Вам придется сделать кодирование с ней и без нее, чтобы знать
наверняка.
</para>
<para>
- <option>qpel</option> может привести к удвоенному времени кодирования и
+ <option>qpel</option> может почти удвоить время кодирования и
требует, как минимум, на 25% большей мощности при декодировании.
Она поддерживается не всеми аппаратными проигрывателями.
</para>
</listitem>
<listitem><para>
<emphasis role="bold">gmc</emphasis>
- Пытается сэкономить биты в сценах с приближением, используя один вектор
+ Пытается сэкономить биты в панорамных сценах, используя один вектор
движения для всего кадра. Это почти всегда увеличивает PSNR, но заметно
замедляет кодирование (так же как и декодирование).
Поэтому Вас следует использовать ее, только когда Вы включили
@@ -3414,7 +3410,7 @@
<entry>3</entry>
<entry>4</entry>
<entry>5</entry>
- <entry>Handheld</entry>
+ <entry>Карманный</entry>
<entry>Портативный NTSC</entry>
<entry>Портативный PAL</entry>
<entry>Домашний кинотеатр NTSC</entry>
@@ -3612,7 +3608,7 @@
<entry></entry>
</row>
<row>
- <entry>Global motion compensation</entry>
+ <entry>Глобальная компенсация движения</entry>
<entry></entry>
<entry></entry>
<entry></entry>
@@ -3652,7 +3648,7 @@
Для каждой настройки кодирования указаны измеренная скорость кодирования (в
кадрах в секунду) и потеря PSNR (в дБ) по сравнению с настройкой "очень высокое
качество". Поймите, пожалуйста, что в зависимости от Вашего материала, типа
-машины, прогресса разработки Вы можете получить сильно отличающиеся результаты.
+машины, прогресса разработки, Вы можете получить сильно отличающиеся результаты.
</para>
<informaltable frame="all">
@@ -3666,25 +3662,25 @@
<entry>Очень высокое качество</entry>
<entry><option>chroma_opt:vhq=4:bvhq=1:quant_type=mpeg</option></entry>
<entry>16fps</entry>
- <entry>0dB</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.1dB</entry>
+ <entry>-0.1дБ</entry>
</row>
<row>
<entry>Быстрое</entry>
<entry><option>turbo:vhq=0</option></entry>
<entry>28fps</entry>
- <entry>-0.69dB</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.48dB</entry>
+ <entry>-1.48дБ</entry>
</row>
</tbody>
</tgroup>
@@ -3699,9 +3695,9 @@
<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">
+<systemitem class="library">x264</systemitem> — это свободная библиотека для
+кодирования H.264/AVC видео потоков.
+Перед началом кодирования Вы должны <link linkend="codec-x264-encode">
настроить <application>MEncoder</application> для его поддержки</link>.
</para>
@@ -3733,7 +3729,7 @@
Опции, в основном влияющие на соотношение скорость-качество.
</para></listitem>
<listitem><para>
- Опции, которые могут быть полезны для удовлетворения различный
+ Опции, которые могут быть полезны для удовлетворения различных
пользовательский предпочтений и специальных требований.
</para></listitem>
</orderedlist>
@@ -3793,12 +3789,12 @@
эти две — первое, с чего Вам стоит начать.
С точки зрения скорости, опции <option>frameref</option> и
<option>subq</option> очень жестко взаимодействуют друг с другом.
- Опыт показывает, что с одним ссылающимся кадром
- <option>subq=5</option> (настройка по-умолчанию) расходует на 35% больше
- времени, чем <option>ubq=1</option>.
- С 6 ссылающимися кадрами эта величина достигает 60%.
+ Опыт показывает, что с одним ссылочным кадром
+ <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>.
Обычно этого достаточно, чтобы заметить.
@@ -3810,8 +3806,8 @@
больший глобальный PSNR ценой потери 25%-100% скорости.
В отличие от остальных уровней <option>subq</option>, поведение
<option>subq=6</option> не так сильно зависит от <option>frameref</option>
- и <option>me</option>. Вместо этого, эффективность <option>subq=6
- </option> по большей части зависит от количества используемых B-кадров. При
+ и <option>me</option>. Вместо этого, эффективность <option>subq=6</option>
+ по большей части зависит от количества используемых B-кадров. При
обычном использовании это означает, что <option>subq=6</option> в сложных,
высокодинамичных сценах имеет большое влияние как на скорость, так и на
качество, но в сценах с малым количествах движения она не имеет такого
@@ -3822,11 +3818,11 @@
<listitem>
<para>
<emphasis role="bold">frameref</emphasis>:
- <option>frameref</option> по-умолчанию установлена в 1, но это не значит, что
+ <option>frameref</option> по умолчанию установлена в 1, но это не значит, что
ее стоит устанавливать в 1.
Только увеличение <option>frameref</option> до 2 дает прирост PSNR примерно
на 0.15дБ за счет уменьшения скорости на 5-10%; похоже, что это неплохая цена.
- <option>frameref=3</option> дает примерно 0.25dB PSNR сверх
+ <option>frameref=3</option> дает примерно 0.25дБ PSNR сверх
<option>frameref=1</option>, что должно быть видимой разницей.
<option>frameref=3</option> медленнее примерно на 15%, чем
<option>frameref=1</option>.
@@ -3852,7 +3848,7 @@
<emphasis role="bold">может</emphasis> и
<emphasis role="bold">обычно наносит</emphasis>
вред эффективности кодирования, если CABAC отключен.
- С задействованным CABAC (настройка по-умолчанию), возможность установки
+ С задействованным CABAC (настройка по умолчанию), возможность установки
<option>frameref</option> "слишком высоким" на данный момент выглядит слишком
далекой, чтобы об этом беспокоиться, а в будущем оптимизации могут вообще
убрать такую возможность.
@@ -3860,23 +3856,23 @@
<para>
Если Вас заботит скорость, разумным компромиссом будет использовать низкие
значения <option>subq</option> и <option>frameref</option> в первом проходе, а
- <!-- FIXME is translation correct ? -->
- затем увеличить из во втором: Вы, возможно, потеряете вплоть до 0.1дБ PSNR,
- что может быть достаточно малым значением, чтобы его заметить.
+ затем увеличить их во втором. Обычно, это обладает ничтожным отрицательным
+ эффектом на конечное качество: Вы, возможно, потеряете вплоть до 0.1дБ PSNR,
+ что должно быть слишком малой разницей, чтобы её заметить.
Однако, различные значения <option>frameref</option> могут
иногда повлиять на решение о выборе типа кадра.
Скорее всего, это довольно редкие крайние случаи, но если Вы хотите быть точно
- уверенными, подумайте, содержит ли Ваше видео полноэкранные
+ уверенными, посмотрите, содержит ли Ваше видео полноэкранные
<!-- FIXME is translation correct? -->
периодически вспыхивающие изображения или очень большие паузы, которые могут стать
причиной принудительной вставки I-кадра.
Настройте <option>frameref</option> в первом проходе так, чтобы
- она была достаточно большой, чтобы содержать длительность цикла вспыхивания
+ она была достаточно большой для содержания длительности цикла вспыхивания
(или паузы).
- Например, если сцены вспыхивает и гаснет в течении двух кадров из трех,
- установите <option>frameref</option> равным 3 или выше.
+ Например, если сцены вспыхивают и гаснут между двумя изображениями в течении
+ трёх кадров, установите <option>frameref</option> равным 3 или выше.
Эта проблема, возможно, очень редко появляется для живой съемки, но она иногда
- появляется при записи видео игр.
+ возникает при записи видео игр.
</para>
</listitem>
<listitem>
@@ -3885,13 +3881,13 @@
Эта опция используется для выбора метода оценки движения.
Изменение этой опции оказывает прямое влияние на соотношение
скорость-качество. <option>me=dia</option> лишь на несколько процентов
- быстрее, чем поиск по-умолчанию ценой не больше 0.1дБ глобального PSNR.
- Значение по-умолчанию (<option>me=hex</option>) разумный выбор между скоростью
+ быстрее, чем поиск по умолчанию, ценой не больше 0.1дБ глобального PSNR.
+ Значение по умолчанию (<option>me=hex</option>) — разумный выбор между скоростью
и качеством. <option>me=umh</option> немного, вплоть до 0.1дБ, улучшает
- глобальный PSNR, соответствующее падение скорости зависит меняется и
- зависит от <option>frameref</option>. С высокими значениями
+ глобальный PSNR, соответствующее падение скорости меняется в
+ зависимости от <option>frameref</option>. С высокими значениями
<option>frameref</option> (например, 12 или около того), <option>me=umh</option>
- примерно на 40% медленнее, чем настройка по-умолчанию <option> me=hex</option>.
+ примерно на 40% медленнее, чем настройка по умолчанию <option>me=hex</option>.
С <option>frameref=3</option>, падение скорости уменьшается до 25%-30%.
</para>
<para>
@@ -3905,9 +3901,9 @@
макроблоках (в дополнение к стандартным).
Ее включение приведет к довольно постоянной 10%-15% потере в скорости.
Эта опция практически бесполезна для исходного материала, содержащего только
- небольшое движение, тем не менее, для некоторого высокодинамичного,
+ небольшое движение, тем не менее, для некоторого высокодинамичного материала,
особенно с большим количеством мелких движущихся объектов, следует ожидать
- прироста в 0.1дБ.
+ прироста около 0.1дБ.
</para></listitem>
<listitem>
<para>
@@ -3923,10 +3919,10 @@
</para>
<para>
С отключенным адаптивным принятием решения о B-кадрах
- (<option>x264encopts</option>'ой <option>nob_adapt</option>),
+ (<option>nob_adapt</option> в <option>x264encopts</option>),
оптимальное значение этой опции обычно не превышает
- <option>bframes=1</option>, иначе пострадают высокодинамичные сцены.
- С включенным адаптивным принятием решения о B-кадрах (поведение по-умолчанию),
+ <option>bframes=1</option>, иначе могут пострадать высокодинамичные сцены.
+ С включенным адаптивным принятием решения о B-кадрах (поведение по умолчанию),
можно безопасно использовать более высокие значения; кодировщик уменьшит
количество B-кадров в сценах, где они повредят сжатию.
Кодировщик редко решает использовать больше, чем 3 или 4 B-кадра;
@@ -3937,7 +3933,7 @@
<listitem>
<para>
<emphasis role="bold">b_adapt</emphasis>:
- Заметьте: она включена по-умолчанию.
+ Заметьте: она включена по умолчанию.
</para>
<para>
Когда эта опция включена, кодировщик будет использовать разумно
@@ -3945,8 +3941,8 @@
используемых в сценах, которые от этого не сильно выиграют.
Вы можете использовать <option>b_bias</option> для тонкой настройки того,
насколько "счастлив" будет кодировщик использованию B-кадров.
- Потеря в скорости при использовании адаптивных B-кадров на данный момент,
- пожалуй, умереннее, но таково же и потенциальное улучшение качества.
+ Потеря в скорости при использовании адаптивных B-кадров на данный момент
+ весьма невелика, но таково же и потенциальное улучшение качества.
Тем не менее, хуже от этого обычно не становится.
Заметьте, что эта опция влияет на скорость и решение о типе кадра только в первом
проходе.
@@ -3969,20 +3965,19 @@
Однако, в проявляющихся или затухающих сценах взвешенное предсказание дает
довольно большую экономию битпотока.
В MPEG-4 ASP затухание обычно лучше кодируется последовательностью дорогих
- I-кадров; используя взвешенное предсказание в B-кадрах делает возможным
- преобразовать хотя бы часть из них в значительно более маленькие B-Кадры.
+ I-кадров; использование взвешенного предсказания в B-кадрах делает возможным
+ преобразовать хотя бы часть из них в значительно более меньшие B-кадры.
Потери в скорости кодирования минимальны, поскольку не требуется делать
дополнительные принятия решений.
- <!-- FIXME is translation correct -->
- Вдобавок, вопреки возможным предположениям, взвешенное предсказание не так
- сильно влияет на требования декодера к CPU, все остальное же полностью совпадает.
+ Вдобавок, вопреки расхожему мнению, взвешенное предсказание не
+ сильно влияет на требования декодера к CPU при прочих равных условиях.
</para>
<para>
- К сожалению, текущий алгоритм адаптивного принятия решений о B-Кадрах имеет
+ К сожалению, текущий алгоритм адаптивного принятия решений о B-кадрах имеет
твердую склонность к избеганию использования B-кадров при затуханиях.
До тех пор, пока это не изменится, хорошей идеей, возможно, будет добавить
<option>nob_adapt</option> к x264encopts, если предполагаете, что затухания
- будут иметь сильный эффект на Ваш конкретный видеоклип.
+ будут давать существенный вклад в Вашем конкретном видеоклипе.
</para>
</listitem>
</itemizedlist>
@@ -3995,30 +3990,30 @@
<listitem>
<para>
<emphasis role="bold">Двухпроходное кодирование</emphasis>:
- Выше советовалось всегда использовать кдирование в два прохода, но все же
+ Выше советовалось всегда использовать кодирование в два прохода, но все же
существуют причины этого не делать. Например, если Вы захватываете TV
трансляцию и кодируете в реальном времени, придется использовать однопроходный
режим. К тому же один проход очевидно быстрее, чем два; если Вы используете
точно такой же набор опций в обоих случаях, двухпроходной режим медленнее
- вдвое.
+ почти вдвое.
</para>
<para>
Все же существует очень хорошие причины использовать кодирование в два
- прохода. Во-первых, управление битпотоком при однопроходного режима не
+ прохода. Во-первых, управление битпотоком однопроходного режима не
является телепатом и часто делает необоснованный выбор, потому что не может
видеть общую картину. Например, предположим, что Вы имеете двухминутное видео,
состоящее из двух независимых частей. Первая половина — очень динамичная
сцена, продолжающаяся 60 секунд и требующая сама по себе битпоток примерно
- 2500 кбит/сек, чтобы прилично выглядеть. Сразу за ней следует менее
+ 2500 кбит/сек, чтобы прилично выглядеть. Сразу за ней следует гораздо менее
требовательная 60-секундная сцена, которая хорошо выглядит при 300 кбит/сек.
- Предположим, Вы запросили битпоток 14000 кбит/сек; в теории этого достаточно
+ Предположим, Вы запросили битпоток 1400 кбит/сек; в теории этого достаточно
для удовлетворения потребностей обеих сцен.
В этом случае управление битпотоком в однопроходном режиме сделает пару "ошибок".
Во-первых, оно установит битпоток в 1400 кбит/сек для обеих частей. Первая
часть может оказаться чрезмерно квантованной, что приведет к
- недопустимому и неоправданно блочному изображению. Вторая часть будет
- недостаточно квантованной; она может выглядеть отлично, но цена битпотока для
- этого качества будет полностью неоправданной.
+ недопустимо выглядящему и неоправданно блочному изображению. Вторая часть будет
+ существенно недостаточно квантованной; она может выглядеть отлично, но цена
+ битпотока для этого качества будет полностью неоправданной.
Чего намного труднее избежать, так это проблемы перехода между двумя
сценами. В первых секундах малодинамичной части квантователь будет чрезвычайно
превышен, потому что управление битпотоком все еще ожидает встретить такие же
@@ -4057,7 +4052,7 @@
x264 предоставляет возможность делать желаемое количество последовательных
проходов. Если Вы указали <option>pass=1</option> при первом проходе,
используйте затем <option>pass=3</option> в последующем проходе, этот проход
- будет одновременно читать статистику предыдущего прохода и записывать ее
+ будет одновременно читать статистику предыдущего прохода и записывать свою
собственную. Дополнительный проход, следующий за этим, будет иметь очень
хорошую основу для осуществления очень точных предсказаний размеров кадров при
выбранном квантователе. На практике, общее улучшение качества от использования
@@ -4065,7 +4060,7 @@
немного худшему глобальному PSNR, чем у предыдущего прохода.
При обычном использовании три прохода помогают, если Вы при двух проходах
получаете либо плохое предсказание битпотока, либо плохо выглядящие переходы
- между сценами. Это в точности то, что наверняка будет происходить на очень
+ между сценами. Это отчасти то, что наверняка будет происходить на очень
коротких клипах. Существуют также особые случаи, когда три (или более)
проходом удобны для продвинутых пользователей, но, для краткости, это
руководство не включает в себя описание этих особых случаев.
@@ -4074,17 +4069,17 @@
<emphasis role="bold">qcomp</emphasis>:
<option>qcomp</option> управляет соотношением количества бит, отданных
"дорогим" высокодинамичным и "дешевым" малодинамичным кадрам. Один крайний
- случай, <option>qcomp=0</option>, предназначен для истинно постоянного
+ случай: <option>qcomp=0</option>, предназначен для истинно постоянного
битпотока. Обычно это сделает высокодинамичные сцены выглядящими просто
ужасно, в то время как малодинамичные сцены будут, возможно, выглядеть
- отлично, но при этом будут использовать во много раз больший битпоток, чем им
- необходимо, чтобы выглядеть просто великолепно.
- Другая крайность, <option>qcomp=1</option>, добивается примерно одинакового
- параметра квантования (QP). Постоянный QP не выглядит ужасно, но большинство
+ абсолютно великолепно, но при этом будут использовать во много раз больший
+ битпоток, чем им необходимо, чтобы выглядеть лишь превосходно.
+ Другая крайность: <option>qcomp=1</option>, добивается примерно одинакового
+ параметра квантования (QP). Постоянный QP не выглядит плохо, но большинство
людей думают, что более разумно частично снизить битпоток в сильно
дорогих сценах (где потеря качества не очень заметна) и перераспределить их в
сцены, которые легче закодировать с отличным качеством.
- <option>qcomp</option> по-умолчанию установлена в 0.6, что по мнению многих
+ <option>qcomp</option> по умолчанию установлена в 0.6, что по мнению многих
людей может быть несколько мало (также часто используется 0.7-0.8).
</para></listitem>
<listitem><para>
@@ -4109,7 +4104,7 @@
<para>
H.264 определяет простую процедуру удаления блочности в I-блоках, которая
использует предустановленные степени обработки и пороговые значения в
- зависимости от QP интересующего блока.
+ зависимости от QP рассматриваемого блока.
По-умолчанию, блоки с высоким QP обрабатываются сильнее, а в блоках с низким
QP удаление блочности вообще не производится.
Предустановленые степени обработки, определенные стандартом, тщательно подобраны
@@ -4123,11 +4118,12 @@
воздействия фильтра деблокинга (читай, -3).
Это, однако, почти никогда не является хорошей идеей, и, люди, это делающие, в большинстве
случаев не совсем хорошо понимают, как работает удаление
- блочности по-умолчанию.
+ блочности по умолчанию.
</para>
<para>
+ <!-- FIXME: Можно ли как-то перевести in-loop? -->
Первая и самая важная вещь, которую нужно знать о in-loop фильтре удаления
- блочности состоит в том, что пороговые значения по-умолчанию практически
+ блочности состоит в том, что пороговые значения по умолчанию практически
всегда PSNR-оптимальны.
В редких случаях, где они неоптимальны, идеальное смещение будет плюс минус 1.
Изменение параметров деблокинга на большие значения фактически гарантирует
@@ -4146,7 +4142,7 @@
легко обратить внимание на неверно изображенный шум.
Когда речь идет о субъективном качестве, шум и детали в некоторой степени
взаимозаменяемы.
- Уменьшая силу фильтра удаления блочности, Вы скорее всего увеличиваете ошибку,
+ Уменьшая силу фильтра удаления блочности, Вы, скорее всего, увеличиваете ошибку,
добавляя ореолы, но глаз этого не замечает, поскольку он путает артефакты с
деталями.
</para>
@@ -4201,19 +4197,19 @@
<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>
+ <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.89dB</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.48dB</entry>
+ <entry>-1.48дБ</entry>
</row>
</tbody>
</tgroup>
More information about the MPlayer-translations
mailing list