Кодирование кодеком x264 в MeGUI

1. Общие сведения
2. Настройки параметров кодирования. 1 часть | 2 часть
3. Подбор оптимального битрейта и параметров для рипа x264 (by shellgen)
4. Советы опытных пользователей

MeGUI - программа с открытым исходным кодом, представляет собой графическую оболочку для консольных программ сжатия аудио и видео.
MeGUI изначально разрабатывалась для того, чтобы быть посредником при кодировании DVD в один файл с помощью консольных программ. Сейчас MeGUI пригоден для многих задач по перекодированию, в том числе и для конвертирования аудио. На входе приложение поддерживает любой видео файл через AviSynth*, на выходе можно получить видео закодированное с помощью snow, x264 или XviD, аудио формата ac-3, aac, mp2, mp3 или vorbis и упаковать это все в контейнер avi, mkv или mp4. В приложении можно создавать очередь задач, приостанавливать и продолжать кодирование, параллельно выполнять задачи из очереди на многоядерных процессорах, автоматически определять черезстрочное видео и порядок полей, автоматически скачивать обновления аудио- видеокодеков и остальных необходимых инструментов. Как и большинство программ с открытым исходным кодом, MeGUI распространяется через сайт sourceforge. Альтернатива (скачать, установить, обновить все что спросит). Для работы приложения необходимо наличие .NET framework** не ниже второй версии.

~ AviSynth* - средство для обработки, в частности линейного и нелинейного монтажа видеоматериалов. Работает как фрэймсервер, имеющий систему сценариев, редактирование которых позволяет осуществлять нелинейное редактирование любого уровня сложности с высоким уровнем воспроизводимости результатов. AviSynth — свободно распространяемая программа с открытым кодом. Домашняя страница | Русская страница проекта
~ .NET framework** - программная платформа компании Microsoft, предназначенная для создания обычных программ и веб-приложений. Домашняя страница

Дополнительные рекомендуемые к установке компоненты:
K-Lite Codec Pack (пакет Full или Mega)
*для 64-битных ОС дополнительно устанавливается 64-битная версия кодеков

Для создания темы используется ревизия MeGUI 1911 (DEVELOPMENT UPDATE SERVER). В следствии частых обновлений программы возможны некоторые изменения в интерфейсе, добаление новых функций и возможностей.
Перед снятием скриншотов все настройки были сброшены в дефолт (по умолчанию). Некоторые дальнейшие рекомендации могут отличаться от установленных дефолтных значений.

При первом запуске конфигурации настроек кодирования в MeGUI видим окно с ползунком, с помощью которого можно менять ПРЕСЕТЫ (поле Presets) по настройке кодека х264.

Поле Modes
По умолчанию: targeting quality (постоянное качество квантизеров, задается в диапазоне 0-64. предпочтительнее значение 16-23)
targeting file size (задается желаемый размер файла)

Поле Presets (пресеты)
Система, добавленная с ревизии r1177, спроектирована на уменьшение работы, необходимой для формирования сценария, эффективной камандной строки commandlines, которые выполняют то, что Вы хотите.
По умолчанию: Medium

Варианты изменений опций позволяют добиться соответствующей эффективности сжатия и качества. Если Вы определите заданный пресет, то изменения, которые он делает, будут применены прежде, чем применены все другие параметры.
• Ultrafast (ультра-быстрый):
ref 1, scenecut 0, no-deblock, no-cabac, bframes 0, partitions none, no-8x8dct, me dia, subme 0, aq-mode 0, no-mixed-refs, trellis 0, b-adapt 0, no-mbtree
• Veryfast (очень быстрый):
partitions i8x8,i4x4, me dia, subme 1, ref 1, no-mixed-refs, trellis 0, no-mbtree
• Faster (более быстрый):
no-mixed-refs, ref 2, subme 4, no-mbtree
• Fast (быстрый):
ref 2, subme 6, rc-lookahead 30
• Medium (средний):
нет изменений по сравнению с теми, что выставлены первоначально.
• Slow (медленный):
me umh, subme 8, ref 5, b-adapt 2, direct auto, rc-lookahead 50
• Slower (медленнее):
me umh, subme 9, ref 8, b-adapt 2, direct auto, partitions all, trellis 2, rc-lookahead 60
• Veryslow (очень медленный):
me umh, subme 10, merange 24, ref 16, b-adapt 2, direct auto, partitions all, trellis 2, bframes 8, rc-lookahead 60
• Placebo (плацебо):
me tesa, subme 10, merange 24, ref 16, b-adapt 2, direct auto, partitions all, trellis 2, bframes 16, rc-lookahead 60
Рекомендации: неопределенны.

Поле Tunings (тонкие настройки или тюнинг)
По умолчанию: default

Опции тюнинга далее оптимизируют настройки вашего входного источника видео. Если Вы определите настройку, то изменения будут применены после того, что было задано пресетами, но перед всеми другими параметрами
• film:
оптимизация установок для кодирования фильмов : deblock -1:-1, psy-rd 1:0.15
• animation:
оптимизация установок для кодирования анимэ: ref (удвоение по умолчанию reference, если значение меньше, чем 1), deblock 1:1, psy-rd 0.4:0, aq-strength 0.6, bframes (добавляет 2 bframes к значению по умолчанию)
• grain:
Оптимизация для зернистого изображения с повышенной детализацией: deblock -2:-2, psy-rd 1:0.25, no-dct-decimate, ipratio 1.1, pbratio 1.1, aq-strength 0.5, deadzone-intra 6, deadzone-inter 6, qcomp 0.8
• psnr:
оптимизация для PSNR: aq-mode 0, no-psy
• ssim:
оптимизация для SSIM: aq-mode 2, no-psy
• fastdecode: оптимизация для быстрого декодирования содержания: no-deblock, no-cabac, no-weightb
Рекомендация: Согласно вашему исходнику. Не определяйте, если ваш источник не соответствует ни одной из опций.

Поле AVC Profiles (Профили)
По умолчанию: high
Доступные варианты опций профиля имеют:
• Baseline(базовая линия): Устанавливает no-8x8dct, no-cabac, нет cqm* среди разрешённых опций, нет bframes. Можно получить на выходе файл с ошибками, если включен ключ interlaced.
• main: Устанавливает no-8x8dct и нет cqm* среди разрешённых опций.
• high: нет ограничений.
Рекомендации: значение baseline - для устройств с ограниченными ресурсами (смартфоны, коммуникаторы, КПК и т.д.) и high - во всех остальных случаях.

Поле AVC level
По умолчанию: unrestricted/autoguess (автовыбор).
Допустимые уровни включают 1, 1b, 1.1, 1.2, 1.3, 2, 2.1, 2.2, 3, 3.1, 3.2, 4, 4.1, 4.2, 5, 5.1. При значении по умолчанию x264 попытается автоматически обнаружить уровень. Это обнаружение не совершенно, и может недооценить уровень, если Вы не используете средства контроля VBV, чтобы ограничить максимальный bitrate.
Это очень важный параметр для аппаратной совместимости. Уровень 4.1 - максимум, обычно поддерживается такими аппаратами, как Xbox 360, Playstation 3, Popcorn Hour A-100 Media Extender и некоторыми другими. GPU-базирующиеся декодеры DXVA на PC имеют максимальный уровень 4.1 также. Blu-Ray и цифровые видеодиски HD - Уровень 4.1.
Рекомендация: level 4.1

Для ручной настройки параметров ставим галочку Show Advanced Settings, становятся доступными дополнительные вкладки с настройками.

Вкладка Frame-Type

Поле H.264 Features
Deblocking - фильтр деблокинга (in loop)
MPEG-4 AVC представляет видео в виде перемещающихся блоков (макроблоков). Фильтр цикличного деблокинга (in loop filter) определяет края этих квадратов и определённым образом уравнивает их разницу (смазывает). Фильтр деблокинга - стандартная опция MPEG-4 AVC и он не должен быть отключен.
Использование фильтра подавления блоков с параметрами - Deblocking strength (сила подавления блоков): Deblocking threshold (точность определения блоков). При кодировании изображение разбивается на блоки размерами 8х8 пикселей и каждый такой блок кодируется отдельно. При недостаточном битрейте, эти блоки становятся заметными. Включение данной опции поможет решить проблему. Рекомендуется использовать даже при высоких битрейтах.
По умолчанию: 0:0
Deblocking strength - рекомендуется выбрать значение от -2 до 2. Большее значение увеличивает силу подавления блоков, но картинка становится немного размытой (используйте при низких битрейтах или при кодировании мультипликации). Меньшее значение уменьшает силу, зато картинка остается достаточно четкой (используйте при высоких битрейтах). Если не знаете, что выбрать, то оставьте 0 - подходит для большинства случаев.
Deblocking threshold - рекомендуется выбрать значение от -2 до 2. При больших значениях, кодек может распознать некоторые детали за блок и применить к ним фильтр подавления блоков. При меньших значениях, деталей сохранится больше, но некоторые блоки могут быть приняты за деталь (используйте большие значения при кодировании мультипликации - в ней четкие контуры, поэтому кодек не ошибется). Желательно чтобы этот параметр отличался не больше, чем на единицу от предыдущего. Если не знаете, что выбрать, то оставьте 0 - подходит для большинства случаев.
CABAC (Context-adaptive binary arithmetic coding (контекстно-адаптивное двоичное арифметическое кодирование) - алгоритм сжатия без потерь для синтаксических элементов видеопотока на основе вероятности их появления. Обеспечивает более эффективное сжатие, чем CAVLC, но требует значительно больше времени на расшифровку.
CAVLC (Context-adaptive variable-length coding (контекстно-зависимое адаптивное кодирование с переменной длиной кодового слова) — альтернатива CABAC меньшей сложности. Тем не менее, оно сложнее и эффективнее, чем алгоритмы, применяемые для тех же целей в более ранних технологиях сжатия видео (как правило это алгоритм Хаффмана).
CABAC использует больше процессорного времени для кодирования и декодирования. Когда он отключен, видео кодируется с CAVLC, который использует меньше процессорного времени и, соответственно, даёт хуже качество.
Примечание: много карманных устройств не имеют мощности для обработки и воспроизведения содержания CABAC, таким образом, Вы должны закодировать CAVLC для них. Материал, произведенный компьютерами Apple, также имеет тенденцию испытывать недостаток в способности декодировать CABAC должным образом. Выгода CABAC - сжатие приблизительно на 10-20 % по сравнению с CAVLC.
Рекомендация: Значение по умолчанию, всегда, если ваш аппарат не поддерживает это.

Поле GOP Size
Maximum GOP Size - максимальный интервал между ключевыми кадрами (Max IDR frame interval).
Устанавливает максимальный размер группы картинок - GOP'а. Кадры в GOP'е не могут быть связанными (референсными) с кадрами другого GOP'а с помощью начального ключевого кадра этой группы (IDR кадров), по которому выполняется поиск по фильму. Размер GOP'а динамически вычисляется во время кодирования для максимального сжатия, однако большой размер GOP'а приведёт к замедлению случайного поиска.
По умолчанию: 250
Minimum GOP Size - минимальное расстояние между ключевыми (I) кадрами.
Устанавливает минимальный размер группы картинок - GOP'а. Макроблоки в картинке одного GOP'а не могут быть связанными (референсами) с макроблоками картинки из другого GOP'а, с помощью начального кадра этой группы (IDR кадров) выполняется поиск по фильму. Размер GOP'а динамически вычисляется во время кодирования для максимального сжатия, хотя маленький GOP может обеспечить лучшую передачу динамичных сцен, но это приведёт к излишней трате битрейта.
По умолчанию: 25

Поле B-Frames
Weighted Prediction for B-frame (Взвешенное B-предсказание) - позволяет использовать B-кадры там, где присутствует плавный переход от одного оттенка цвета к другому (градиент или затухание). Потери в скорости кодирования минимальны, поскольку не требуется делать дополнительные вычисления. Так же не сильно влияет на требования декодера к CPU. Рекомендуется включить.
Number of B-frames (Максимальное количество последовательных B-кадров) - количество последовательных B-кадров между I и P кадрами. B-кадры – кадры, в которых закодированы изменения не только от предыдущих кадров, но и от последующих. Имеют еще большую степень сжатия, чем P-кадры.
Устанавливает максимальное число параллельных B-фреймов, которые x264 может использовать. B-фреймы подобны P-фреймам, кроме того, они могут использовать предсказание движения от будущих фреймов также. Это может привести к значительному улучшению эффективности степени сжатия. Кадры двунаправленного предсказания (B-кадры) сильно улучшают сжимаемость, т.к. они хранят данные об изменениях относительно прошлого кадра и разницы с будущим. B-кадры в основном имеют качество хуже, нежели I- или P- кадры, но они увеличивают общее качество и позволяют сжимать видео очень эффективно.
B-frame bias (Вероятность использования B-кадров) - положительные значения увеличивают вероятность того, что кодек решит закодировать некоторый кадр как двунаправленный. Отрицательные - уменьшают. Рекомендуемое значение 0.
Adaptive B-frames (Адаптировать распределение B-кадров) - при включении этой опции кодек будет более разумно распределять двунаправленные кадры, сокращая их последовательное количество в сценах, которые не сильно от этого выйграют. Имеет смысл только при первом проходе в многопроходном кодировании и только если в опции Number of B-frames вы выбрали значение больше единицы. "0-Off" - отключить. "1-Fast" - старый алгоритм, достаточно быстрый. "2-Optimal" - новый алгоритм, значительно медленнее, что становится очевидным при увеличении максимального количества последовательных B-кадров, однако если это значение равно 16, то используйте этот режим, т.к. кодек имеет дополнительную оптимизацию по скорости при таком сочетании опций. Рекомендуется значение 2-Optimal.
B-pyramid (Позволить использовать B-кадры в качестве опорных) - если эта опция включена, то B-кадры могут кодировать изменения от предыдущих и последующих B-кадров. Эта опция доступна только если максимальное количество последовательных B-кадров больше единицы. Если это так, то рекомендуется включить эту опцию. Рекомендуется значение - Normal.

Поле Other
Number of Reference Frames (Количество кадров на которые могут ссылаться P- и B-кадры) - чем больше - тем эффективней могут быть закодированы P/B-кадры, но для кодирования потребуется больше времени. Максимальное значение 16, однако уже после 5 прирост качества ощущается все меньше и меньше, а прирост времени кодирования все больше и больше. Рекомендуемое значение 4 - максимальное для видео 1080p, и 9 - максимальное для 720p, придерживаясь level 4.1 спецификации, который является уровнем, осуществленным в BD и цифровом видеодиске HD, и самом высоком уровне, поддержанном в большинстве бытовой электроники, которые поддерживают воспроизведение H.264, включая Xbox 360, Playstation 3
Number of Extra I-Frames (Чувствительность смены сцен) - порог обнаружения смены сцены в кадре - для вставки принудительного ключевого кадра.
Полезность определения смены сцен заключается в расстановке I-кадров (ключевых кадров) в местах резкой смены сцен. Это влияет на качество - слишком частая смена приведёт к напрасной трате битрейта. Рекомендация - значение по умолчанию.
P-frame Weighted Prediction. Рекомендация - значение по умолчанию.
Encode interlaced (Кодирование чересстрочного материала) - рекомендется включить, если кодируете чересстрочный материал. В этом случае каждый полукадр будет закодирован по отдельности и ваше видео останется чересстрочным. Если вы не включите эту опцию кодируя чересстрочное видео, то оно станет прогрессивным (два полукадра будут закодированы как один кадр) с характерным "эффектом расчески" на границах движущихся объектов. На кодирование этой расчески потребуется много информации, которая могла быть использована для кодирования более важных вещей. Рекомендация - не включать, галочку не ставить.
Adaptive I-frame Decision. Рекомендация - значение по умолчанию.
Pulldown. Рекомендация - none.

Вкладка Rate Control

Поле Quantizers
Min/Max/Delta (Мин/Макс/Шаг квантователя) - указывает наименьший возможный квантователь, наибольший и шаг изменения. Первый счетчик задает минимальный квантователь (рекомендуемое значение - 10). Чем меньше квантователь, тем лучше качество картинки (и хуже сжатие). Во многих кадрах картинка сжатая квантователями ниже 16 визуально воспринимается как сжатая без потерь. Учтите, что на ключевые кадры этот параметр тоже воздействует, а это значит, что сильно увеличив этот параметр, ключевой кадр будет выглядеть плохо, а на основе этого ключевого кадра могут быть построены еще около 250 P- и B-кадров. Второй счетчик задает максимальный квантователь (рекомендуемое значение - 51). Чем выше квантователь, тем лучше сжатие (и хуже качество). Третий счетчик задает шаг квантователя (рекомендуемое значение - 4). Этот параметр указывает на сколько могут различаться квантователи в соседних кадрах. Не рекомендуется устанавливать сильно большие шаги т.к. это может привести к заметным скачкам качества между соседними кадрами.
Quantizers Ratio (I:P/P:B) (Соотношение квантователей) - первый счетчик указывает соотношение квантователей между I-кадром и последующим за ним P-кадром. Рекомендуемое значение 1,4 - это означает, что если, например, ключевой кадр был закодирован квантователем десятого уровня, то следующий за ним P-кадр будет закодирован квантователем не менее, чем 10*1,4=14 уровня. Другими словами увеличение этой опции приводит к улучшению ключевых кадров, за счет ухудшения последующих P- и B- кадров, в результате вы получите прекрасный неподвижный фон (он будет взят из ключевого кадра) и ужасно выглядящие изменения (они кодируются в P- и B-кадрах). Если вы все же решите увеличить значение этой опции, то не забудьте увеличить и шаг квантователя, иначе ничего не изменится. Второй счетчик указывает соотношение квантователей между P-кадром и последующим за ним B-кадром. Рекомендуемое значение 1,3. Принцип работы тот же, что и описанный выше.
Deadzones (Inter/Intra). Рекомендация: по умолчанию
• Inter - установит inter (внешний) размер luma-квантизеру deadzone. Deadzones должны быть в диапазоне от 0 до 32.
• Intra - установит intra (внутренний) размер luma-квантизеру deadzone. Deadzones должны быть в диапазоне от 0 до 32.
Chroma QP offset - разница квантования цветности и яркости.
Устанавливает уровень снижения качества между яркостной и цветовой составляющими. Человеческий глаз более чувствителен к изменению яркости, чем цвета. Понизив цветовую детализацию можно повысить уровень сжимаемости. Обычно, x264 кодирует все три цветовых составляющих (luma-яркость, U -1-й цветоразностный сигнал, V -2-й цветоразностный сигнал) с тем же самым квантизатором. Это значение будет добавлено к квантизаторам для U и V составляющих. Это позволяет Вам смещать x264 в пользу яркости (luma), устанавливая положительные значения, сигналы цветности будут иметь более высокие квантизаторы, или в пользу цвета (сигнал цветности), устанавливая отрицательные значения. Помните, что x264 кодирует видео, как YV12, что означает, что сигнал цветности поднимает только половину цветового пространства, а luma делает так или иначе.
Отметьте: x264 только кодирует luma и составляющие сигнала цветности в том же самом квантизаторе до квантизатора 29. После этого сигнал цветности прогрессивно квантован более низким количеством, чем luma, пока Вы не заканчиваете luma со значением q51 и сигнал цветности с q39. Рекомендуемое значение 0.

Поле Rate control
VBV buffer size (Максимальный размер видео буфера) - используйте эту опцию только если у вас аппаратный декодер H264, который требует этого. Рекомендуемое значение 0 (автоматическое определение), также можно оставить поле пустым - это равносильно нулю.
VBV maximum bitrate (Максимальный битрейт в видео буфере) - при наличии аппаратного декодера H264, устанавливает максимально допустимый битрейт видео в буфере. Рекомендуемое значение 0 (автоматическое определение).
VBV initial buffer (Стартовый размер видео буфера) - видео не начнет проигрываться, пока видео буфер не будет заполнен на указанную часть. Строго рекомендуемое значение 0,9.
Bitrate variance (Колебание битрейта) - задается в процентах с точностью до одной десятой, имеет смысл только при однопроходном кодировании. Указывает на то, как сильно может отклоняться битрейт от указанного среднего значения в большую или меньшую сторону. При меньших значениях можно более точно предсказать размер конечного файла, но способность кодека к адаптации сложных сцен снижается. При больших значениях размер конечного файла менее предсказуем, зато на сложные сцены будет выделено больше бит, чем на простые. Установка в 0% дает постоянный битрейт, 100% - постоянное качество. Обратите внимание, что установка в 100% - хорошая альтернатива двупроходному кодированию в тех случаях когда оно не применимо или когда размер конечного файла не важен.
Quantizer compression (Выбор квантователя для сжатия) - задается числом от 0 до 1 с точностью до одной десятой. Указывает на то, как сильно может отклоняться квантователь от рекомендуемого значения. Считается, что в высокодинамичных сценах можно пожертвовать качеством не смотря на сложность картинки т.к. во время быстрого движения мелкие детали плохо различимы. Установка меньшего значения будет применять более высокие квантователи (с худшим качеством) к высокодинамичным сценам и более низкие (с хорошим качеством) - к малодинамичным. Установка большего значения - наоборот. Рекомендуемое значение 0,6.
Temp. blur of est. frame complexity (Уменьшение колебаний квантователя) - применяет гауссово размытие заданного радиуса к кривой квантователя. Это означает, что каждый квантователь назначенный определенному кадру будет размыт с квантователем назначенным соседнему кадру, что позволит избежать резких скачков качества между соседними кадрами. Рекомендуемое значение - 20.
Temp. blur of quant after CC (Уменьшение колебаний квантователя (после) - Повторно применяет гауссово размытие заданного радиуса к кривой квантователя для более плавного перехода между квантователями. Не очень важная настройка, оставьте значение по умолчанию - 0,5.
NB of Frrames for lookahead (число кадров для frametype предвидения) - устанавливает число кадров, применяемых для mb-tree ratecontrol. Увеличение величины кадров генерирует лучшие результаты, но это также замедляет кодирование. Максимальное значение - 250. Рекомедация: 40-50 (см. пресеты). По умолчанию: 40.
MB-Tree Rate Control (Use MB-Tree) - эта опция передаёт информацию от будущих блоков к прошлым блокам поперек векторов движения. Эту опцию можно было описать, как ограничение qcomp, чтобы воздействовать на индивидуальные блоки вместо целых сцен. Таким образом, вместо того, чтобы понижать качество в сценах высокой сложности (как x264 в настоящее время делает), эта опция понизит качество только на сложной части сцены, в то время, как например, статический фон останется высококачественным. Эта опция также имеет много других более тонких эффектов, некоторые дают потенциально отрицательный результат, но во многих случаях MB-Tree Rate Control даёт положительный результат. Применение его помогает при всех битрейтах, и может даже помочь при феноменально низких битрейтах, где видео иначе развалилось бы полностью на блоки. Рекомендация : при подключении MB–Tree стоит увеличить qcomp=0.7…75 с целью ограничить воздействие mb-tree и не допустить больших провалов по качеству.

Вкладка Analysis

Поле Motion Estimation
Chroma M.E. (Цветовая оценка движения) - рекомендуется включить для того, чтобы движение объектов искалось не только в канале luma, но и в каналах U-chroma и V-chroma. Отключение даст незначительную прибавку к скорости и незначительную потерю качества.
M.E. Range (Диапазон поиска движения) - указывает радиус поиска движения объекта в пикселях. Большие значения улучшают качество ценой потери скорости кодирования. Для алгоритмов "diamond" и "hexagon" допустимыми значениями являются числа от 4 до 16 (рекомендуется 16). Для остальных алгоритмов - от 4 до 64 (рекомендуется 32).
M.E. Algorithm (Алгоритм поиска движения).
• Diamond - простейший поиск, начиная с одного пикселя одного кадра, начинают просматриваться соседние пиксели на соседнем кадре, на один пиксель выше, правее, ниже и левее. Выбирается наиболее вероятно сдвинувшийся пиксель и процесс повторяется до тех пор, пока не будет найден лучший пиксель или пока не будет достигнут предел диапазона поиска движения.
• Hexagon - похож на предыдущий, но оцениваются 6 соседних пикселей. Немного медленней, но более эффективный, чем предыдущий алгоритм.
• Multi hex - лучше предыдущего, способен найти сложные векторы движения, ценой потери скорости кодирования. В отличие от предыдущих алгоритмов, в этом, и во всех последующих, опция "диапазон поиска движения" задает не количество итераций, а радиус в пределах которого будет искаться пиксель.
• Exhaustive - не намного лучше, но намного медленнее, работает методом перебора в диапазоне поиска движения: строит все возможные вектора движения и выбирает наилучший.
• SATD Eshaustive - похож на предыдущий, чуть-чуть лучше и чуть-чуть медленне. Два последних алгоритма не рекомендуются из-за огромной потери скорости кодирования при незначительном улучшении качества.
Рекомендация: Multi hex (umh).
Subpixel refinement (Точность векторов движения или улучшение полу-пиксельной точности) - устанавливает один из десяти уровней сложности оценки субпиксельной точности векторов движения. Чем выше уровень, тем в больших случаях могут быть построены векторы движения повышенной точности. Практика показывает, что увеличение значения может привести и к худшему результату. Если это произошло, попробуйте увеличить диапазон поиска движения (M.E. Range).

Поле Extra
MV Prediction mode - определяет метод нахождения векторов движения для B-кадров.
• Пространственный (Spatial) метод использует поиск в соседних блоках одного кадра, который может дать в результате повышение PSNR.
• Временный (Temporal) метод использует блоки соседнего кадра, который может быть даст качество лучше.
• Auto выбирает для каждого кадра отдельно. Лучше всего использовать в двухпроходном режиме (включён в обоих проходах).
Рекомендации: auto – в случае 2-проходного режима и spatial при кодировании CRF.
Trellis - выполняет треллис квантование для повышения эффективности сжатия. Вариант "На макроблоках" (Final MB) - хороший компромисс между падением скорости и повышением эффективности.
Варианты подключения: 0 – none Trellis (не подключено), 1 - Final MB (на макроблоках), 2 – Always (везде)
Рекомендации: 2 – Always (везде), но при условии совместной работы с psy-trellis, иначе происходит незначительное замыливание мелких деталей. Предупреждение: требует подключения CABAC.
PSY-RD strength (Сила RD-оптимизации) - устанавливает силу RD-оптимизации. Прежде, чем использовать эту опцию, убедитесь, что вы включили эту оптимизацию (Subpixel refinement должен быть больше либо равен шести).
PSY-trellis strength (Сила Trellis квантования) - чтобы использовать требуется чтобы Тrellis был больше или равен 1. Psy-Trellis - "экспериментальная" опция, и не рекомендуется для реального кодирования. Не повышайте величину Psy-Trellis более 0.5, хотя бы в начале.
Рекомендации: оставьте всё по умолчанию, хотя для многих исходных материалов вполне приемлемы значения 1.0:0.15 при условии установки aq-strength=0.7…1.2 и trellis=2.
No Mixed Reference frame (Смешанные P/B-кадры) - все блоки из одного P- или B-кадра могут ссылаться только на один кадр. Включение данной опции позволит каждому блоку ссылаться на разные кадры независимо друг от друга, что увеличит эффективность кодирования. По умолчанию включено (установка галочки отключает опцию).
No Dct Decimation (Не использовать прореживание блоков) - отключение опции предварительной DCT трансформации сигнала непосредственно перед кодированием. Кодер пишет видеопотоку все анализируемые блоки DCT. В результате на следующий этап компрессии подаётся оптимизированный сигнал. Если ключом эту трансформацию отключить, то можно выиграть в детализации при двухпроходном кодировании, поскольку у кодека за 2 прохода появляется возможность оценить весь видеоряд. Опыт показывает, что лучше не включать эту опцию при кодировании в режиме постоянного качества CRF, так как серьезно увеличивается размер файла при незначительном улучшении видео.
No fast P-skip (Запрет быстрого пропуска определения P-кадров) - быстрый пропуск определения P-кадров повышает скорость, но может вызвать небольшую блочность в местах, где непрерывная цветовая гамма или лёгкий градиент (тёмные сцены или небо). Включение (отметка галочкой) этой опции ОТКЛЮЧИТ быстрый пропуск. Рекомендации: включить при 2-хпроходном кодировании, при CRF – желательно отключить.
NoiseReduction (Удаления шума) - оценивает шумность фильма и, основываясь на этом значении, пытается удалить шум с минимальными потерями деталей перед квантованием. Это далеко не лучший способ удаления шума (внешние фильтры дают качество лучше), но это очень быстрый способ. Рекомендация: по умолчанию.

Поле Macroblocks
Используемые типы блоков.
При кодировании изображения кодек разбивает его на макроблоки размерами 16*16 пикселей. Каждый такой макроблок разбивается еще на 2, 4, 8 или 16 частей. Вы можете указать какие типы блоков должен использовать кодек для каждого типа кадров: i8*8, i4*4 - для ключевых кадров; p8*8 (включает также p16*8 и p8*16), p4*4 (включает также p8*4 и p4*8) - для однонаправленных кадров; b8*8 (включает также b16*8 и b8*16) - для двунаправленных кадров. Чем больше вариантов разбиения вы разрешите использовать кодеку, тем лучше будет закодирован материал, ценой потери скорости кодирования.

Вкладка Misc

Поле Input/Output
PSNR calculation (подсчет отношения сигнала к шуму по мощности) - на качество выходного видео никак не влияет - включение данной опции немного замедлит кодирование, зато по окончанию, на закладке Log вы можете посмотреть подсчитанный коэффициент PSNR. Теоретически данный коэффициент может изменяться от 0 до бесконечности, однако на практике его значения чаще лежат в интервале 30-50 децибел (чем выше значение, тем ближе качество сжатого видео к оригиналу). Рекомендуется выключить.
SSIM calculation (используется для сравнения качества видео (подобно psnr), но используя другую метрику качества видео) - на качество выходного видео никак не влияет - включение данной опции немного замедлит кодирование, зато по окончанию, на закладке Log вы можете посмотреть подсчитанный коэффициент SSIM. Качество исходного видео принимается за единицу, чем ближе коэффициент SSIM к единице - тем ближе качество сжатого видео к оригиналу. Рекомендуется выключить.
Force SAR (Соотношение сторон пикселя) - записывает размер неквадратного пикселя в видео потоке, который будет использоваться при дальнейшем проигрывании. Это позволяет производить анаморфное кодирование. Рекомендация: по умолчанию (отключено).

Поле Other
Threads (выбор количества вычислительных потоков) - актуально для многоядерных процессоров и многопроцессорных систем. Установите значение 0, для автоматического определения. Кодирование в несколько потоков значительно увеличивает скорость кодирования, при незначительном ухудшении качества (на столько незначительном, что невооруженным глазом разница станет заметной лишь при кодировании более чем в 30 потоков).
Non Deterministic - немного улучшит качество SMP, за счет воспроизведения. Не для общего использования. Рекомендация: по умолчанию.
Thread-Input - декодирует входное видео в отдельном потоке к процессу кодирования. Разрешено неявно, когда потоков > 1. Рекомендация: Разрешено, если есть больше, чем один логический доступный CPU.
Slow first pass - используется, чтобы отключить быстрый 1-проходный режим. Рекомендация: снять галочку.

Чтение лога кодека и оптимизация битрейта

В связи с тем, что многие при выборе битрейта ошибочно полагаются лишь на показатель b-p/f, который иногда помогает, а иногда оказывается совершенно бесполезной цифрой, привожу на мой взгляд более правильную методику подсчёта целевого битрейта. Каждый видеоряд обладает разной сжимаемостью, для некоторых 0.1 пресловутого b-p/f достаточно, чтобы прозрачно без артефактов закодироваться в компактный размер. Бывают же сложные видеопоследовательности, которые не помещаются и в .25 b-p/f . Намётанный глаз сразу распознает приблизительную сложность видоряда для кодека, но более-менее достоверно оценить сжимаемость можно нижеописанным способом (занимает не более 5-10 минут с учётом времени на енкод, если только не использован тормозной скрипт). Имеет смысл при подготовке основательного рипа с упором на размер-качество.
Задача: Сжать распределённую выборку из целевой видеопоследовательности с заданным коэффициентом качества и оценить полученный результат.

Шаг 1. Сделать распределённую выборку из сорса
Достаточно добавить в конец .avs скрипта три волшебные строки и на выходе получим ряд продолжительностью ~2550 фреймов, составленный из равномерно выдернутых из видеоряда кусков по 50 фреймов. Обычно этого достаточно, чтобы оценить сжимаемость более-менее равномерного видео длительностью до 1.5-2 часов.
Три строки:

selectTotal1=framecount()/100
selectTotal2=selectTotal1*2
selectrangeevery(selectTotal2,50)

Шаг 2. Сжать подготовленную последовательность с настройками, с которыми планируете сжимать последний проход, но указать не битрейт и не -pass ?, а например -crf 18 (важно, что указываем не -q, а именно -crf (Const. Quality)
Ждём завершения... и смотрим лог

Шаг 3. Читаем лог
Параметры компрессии
Средние кванты
Использование b-фреймов
Использование частиц
Распределение DCT трансформации 8x8
Распередление выбора режима анализа векторов движения
Использование ref фреймов***
Полученный битрейт


Cкрытый текст -

 

-[Information] Job commandline: "C: Program Files MeGUI tools x264 x264.exe" -crf 18 -deblock -3:-3 -bframes 5 -b-adapt 2 -ref 4 -no-mbtree -merange 32 -me umh -direct auto -subme 9 -partitions all -trellis 2 -no-fast-pskip -sar 1:1 -output "C: Users Ден Desktop test.mkv" "C: Users Ден Desktop test.avs"
-[Information] [17.01.2011 21:19:04] Encoding started
-[Information] Standard output stream
-[Information] Standard error stream
-[NoImage] avs [info]: 1920x816p 1:1 @ 2500000/104271 fps (cfr)
-[NoImage] x264 [info]: using SAR=1/1
-[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
-[NoImage] x264 [info]: profile High, level 4.0
-[NoImage]
-[NoImage] x264 [info]: frame I:56 Avg QP:15.52 size:219438
-[NoImage] x264 [info]: frame P:583 Avg QP:16.89 size: 86691
-[NoImage] x264 [info]: frame B:1875 Avg QP:18.85 size: 38109
-[NoImage] x264 [info]: consecutive B-frames: 6.6% 1.4% 5.0% 16.7% 16.3% 53.9%
-[NoImage] x264 [info]: mb I I16..4: 6.0% 84.2% 9.8%
-[NoImage] x264 [info]: mb P I16..4: 0.9% 17.2% 0.5% P16..4: 33.7% 22.5% 5.9% 0.3% 0.2% skip:18.7%
-[NoImage] x264 [info]: mb B I16..4: 0.1% 1.2% 0.1% B16..8: 58.0% 11.9% 3.1% direct: 5.5% skip:20.1% L0:44.3% L1:46.1% BI: 9.5%
-[NoImage] x264 [info]: 8x8 transform intra:89.0% inter:56.1%
-[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
-[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 94.3% 88.8% 63.4% inter: 41.1% 37.5% 1.6%
-[NoImage] x264 [info]: i16 v,h,dc,p: 72% 12% 8% 8%
-[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 7% 12% 10% 13% 12% 12% 11% 12%
-[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 8% 5% 9% 15% 14% 13% 12% 11%
-[NoImage] x264 [info]: i8c dc,h,v,p: 40% 24% 23% 12%
-[NoImage] x264 [info]: Weighted P-Frames: Y:5.5% UV:2.9%
-[NoImage] x264 [info]: ref P L0: 51.5% 11.8% 24.7% 10.9% 1.1% 0.0%
-[NoImage] x264 [info]: ref B L0: 88.1% 9.2% 2.8%
-[NoImage] x264 [info]: ref B L1: 93.8% 6.2%
-[NoImage] x264 [info]: kb/s:10245.33
-[NoImage] encoded 2514 frames, 2.23 fps, 10245.38 kb/s

Средние кванты
Имеем три цифры квантов: для I фреймов, для P фреймов и для B фреймов. Чем динамичнее видеоряд, тем больше будет между ними разница и тем выше будут кванты для B фреймов. Если все три цифры не превышают 18, то полученного битрейта будет много и его смело можно резать процентов на 25 минимум. Если все три цифры превышают 22-23, то битрейта не хватает и его надо поднимать, если только целью не является минимальный размер рипа с допустимыми артефактами компресии. Для очень динамичного видео средний квант ~25 для b-фреймов вполне допустим. Обычно стоит следить, чтобы он не поднимался выше.
В логе, полученном с -crf 18, кванты как правило будут находится в промежутке 16..23. Полученный в результате битрейт и будет предпочтительным для сохранения максимально прозрачного качества. Если его делать выше, то это будет как праивло раздутием размера, опускаться ниже можно, но желательно не более чем на ~35-40%. При этом надо помнить, что поднимая/опуская битрейт на каждые 12.5% мы поднимаем/опускаем CRF на 1 целый пункт и в то же время, поднимая/опуская CRF на 6 пунктов мы увеличиваем/уменьшаем битрейт вдвое.

Использование b-фреймов
Процент задействованных b-фреймов, по порядку от 0 до 16. Если начиная с какой-то позиции стоят лишь 0.0 или 0.1-0.2, то использование -bframes больше этой цифры по сути бессмысленно и в большинстве случаев только увеличит время, необходимое для енкода.

Использование частиц
Использование частиц анализа
I : i16x16,i8x8,i4x4 / PI: p16x16,p8x8,p4x4 / PP: p16x16,p8x8,p8x4,p4x8,p4x4 / BI: b16x16,b8x8,b4x4 / BB: b16x16,b16x8,b8x8
Если из лога видно, что какие-либо частицы не задействованы или задействованы по минимуму, то можно не включать их анализ в ключ -partitions p8x8,p4x4,b8x8,i8x8,i4x4. Как правило желательно оставлять анализ всех частиц для SD контента и выключать только p4x4 для HD сигнала.

Распределение DCT трансформации 8x8
Показывает насколько задействована 8x8 DCT трансформация, если проценты очень низкие, то ключ -8x8dct можно опустить в пользу скорости. Случай очень редкий, обычно стоит оставить параметр задействованным, если только не стоит задача сделать енкод максимально быстро. Без этого ключа автоматичнески отключится анализ частиц i8x8.

Распередление выбора режима анализа векторов движения
Показывает процент выбора кодеком между режимами локального и темпорального анализа векторов. Для мультипроходного режима стоит оставлять -direct auto, если только енкод не нужно сделать максимально быстро или кодируется чересстрочный сигнал. Смысл использования -direct auto в однопроходном режиме теряется, обычно для однопрохода можно смело оставлять -direct spatial.

Использование ref фреймов
От 1 до 16 показывает насколько задействованы ссылочные кадры. Если после определённой цифры начинаются 0.0-0.2%, то смысл использовать -ref выше данного числа теряется, только увеличит время енкода. Аналогично как и для -bframes.

*** параметр, на который особо следует обращать внимание, даже если позволяет подняться еще на одну планку. Не стОит забывать о совместимости с медиаплеерами: для рипа 1080p желательно не превышать 4 reframes, для рипа 720p 8 reframes.

Шаг 4. Визуальный контроль
Цифры цифрами, но не забываем открыть полученный огрызок в любимом проигрывателе и оценить результат глазами. Еще лучше сравнить полученный результат с исходным изображением, удобнее всего это делать при помощи программы AvsP. Поскольку i-фреймов на весь видеоряд как правило не более 1-2% и сжимаются они с наименьшими возможными квантами, имеет смысл сравнение только b и p фреймов.

Вывод информации о кадрах через ffdshow
Через кнопку Пуск заходим в конфигурацию ffdshow.
В случае отдельно установленного ffdshow

Входящий в состав пака K-Lite

В ffdshow задаем кодек вывода ffmpeg-mt или libavcodec, потом идем в настройку OSD и помечаем все, что хотим вывести (в нашем случае номер и тип кадра).

Открываем исходное и скодированное видео в AvsP. Идём в трей, кликаем правой кнопкой мыша по иконке ffdshow и выбираем OSD.

Выполняем кропинг исходного видео (правой кнопкой клац по картинке (всплывет контестное меню) -> Crop editor). Или грузим в AvsP скрипт, который мы создавали для рипа.
Ползунком (для точности попадания в кадр пользуемся стрелками клавиатуры) ищем одинаковые кадры, получается что-то вроде этого:

На разных видеопоследовательностях по разному отражается потеря деталей. Для видеоряда а-ля "групповые брачные игры карликовых муравьёв в тени пальмы на песочном пляже, вид сверху, с пальмы, с трёх метров" потеря деталей на уровне CRF 18 может оказаться губительной и это сразу будет видно глазами, части тел муравьёв утонут в песке и недостаточных квантах, что безусловно потревожит режиссёрскую задумку. Мультик снятый а-ля размытая-флеш-векторная графика может быть малоотличим от исходника при CRF 25-26. Но это крайности. Обычный видеоряд выглядит прозрачно в енкоде с битрейтом полученном на CRF 18-20.

Сравниваем исключительно однотипные кадры (B с B / P с P), так как разные типы кадров имеют разную степень сжатия. Сохранить кадр с "впечатанным" типом кадра можно так: клац по картинке правой кнопкой мыша, попадаем в контекстное меню, выбираем Save image as... (по умолчанию уже выставлен формат .png). Примечание. После работы в AvsP не забудьте отключать OSD, иначе ffdshow будет выводить инфу и в плеерах, которые задействуют ffdshow для декодирования видео, а еще хуже - при кодировании видео вшивается в видеоряд просчет номеров и типов кадров.

Пример сравнения.
...Source vs Rip

Выбор режима деблокинга
Деблокинг задаётся ключом -f сила:порог. С первым параметром, с силой, всё достаточно просто: чем выше сила, тем эффективнее сработает встроенный деблокер, страхуя от появления случайной блочности, но тем больше возрастает риск размытия деталей и нежелательного смягчения картинки. Очевидно, что занижать силу деблокинга для нерезкого сигнала не только бессмысленно, но и вредно. От того, что в меньшей степени замаскируются границы блоков, резкости в мыльном сигнале не прибавится. Значение по умолчанию '0' -> хорошее значение, если наверняка не знаете какого эффекта нужно достичь, то лучше его там и оставить и не крутить без надобности. Так или иначе в 90% случаев не стоит опускать силу ниже, чем -3, такая сила остаётся всё ещё довольно безопасной для большинства более менее ровных видео с точки зрения появления артефактов, если только не сильно баловаться с порогом.
Порог деблокинга менее предпочтительно крутить вообще, он отвечает за то, где будет распознаваться структура блока, а где артефакт. Чем выше порог, тем больше резких, насыщенных деталями блоков попадёт под деблок. Чем ниже порог, тем больше под деблок попадёт нерезких, незаполненных деталями блоков, но тем меньше будут деблочиться нерезкие блоки с незначительной детализацией (e.g шум, зерно в глубокой тени). Крутить надо исключительно аккуратно, т.к. когда его уводят в минуса, то фильтру не дают обезблочить тёмные области с шумом, а когда задирают, то размывается больше изначально неблочных структур. Чтобы избежать блочности опускать его ниже 0 есть смысл только если картинка действительно чистая, например вылизана по самые гланды какими-нибудь темпоральными шумодавами.
Если коротко, то чем выше сила деблокинга, тем сильнее он применяется, чем выше порог, тем больше блоков ему попадается.
Чем ниже кванты, тем ниже сила деблокинга, а чем они выше, тем естественно деблокинг сильнее. Кодек сам подстраивает деблок и если с низкими квантами вы опустили деблок до -3:-2 например, то не удивляйтесь, откуда в некоторых участках проскакивает блочность и ринжинг. Заминание деблока в минус никогда не сделает картинку резче чем она есть, а поднятие деблока в плюс едва ли поможет избавиться от блочности исходного сигнала.
В то же время на выскоих квантах чуть приподнимая деблок можно потихоньку гасить более явные блочные артефакты компресии, а если их нет или на глаз не видно, то и крутить не надо.

psyRD + psyTrellis (by Nicko123)
[b]Psy- RDO/Trellis[b] помогает поднять и передать в рипе мелкую фактуру с минимальными затратами битрейта.
1. Psy-RDO (первая цифра после Psy X.X : x.x) вылавливает из исходника шумовую компоненту (некоррелированный сигнал) и добавляет ее впоследствии в рип в тех местах где его вероятность появления выше, наподобие управляемого информацией из рипа функционального генератора шума.
2. Psy-Trellis (вторая цифра после Psy x.x : X.X) ищет реальные мелкие детали (коррелированный сигнал, в основном границы, мелкая фактура, ...) и пакует их по более простым правилам, но с гораздо более высокой компрессией, чем сам кодек, также использует вероятностный подход, но в меньшей степени чем RDO и в основном при силе большей 1 для сверхмалых битрейтов, 0.8-1.0 для средних и 0.1-0.8 для высоких. Эффективность передачи и количество мелких деталей в рипе зависит от установленной силы.
Соотношение и силу обоих компонент нужно подбирать исключительно на глаз, принимая во внимание реальный шумовой битрейт (-RDO) и количество мелкой фактуры (-Trellis) в исходнике.
SSIM и PSNR при этом по идее могут/должны падать, но на глаз картинка будет существенно ближе к оригиналу.

aq-mode (MasterNobody, @lolkin@)
AQ работает следующим образом (по крайней мере все варианты сейчас реализованные в иксе): определяется дисперсия макроблока (пикселей в макроблоке 16x16) и в зависимости от ее значения по функции (функции различны для разных режимов AQ) макроблоку назначается отклонение от базового кванта кадра (обычно чем меньше дисперсия тем меньше делается квант, а чем больше дисперсия тем соответственно больше квант). Это приводит к тому что качество "плоских" макроблоков (где дисперсия меньше) увеличивается за счет более "энергетичных" макроблоков (с большей дисперсией). А так как обычно снижение качества "энергетичных" макроблоков заметно меньше, чем повышение качества "плоских" макроблоков, то общее визуальное качество увеличивается. Но здесь нужно учитывать, что если основная задача сохранить зерно/шумы и используемый битрейт достаточно высок (что качество "плоских" макроблоков и так достаточно), то есть смысл понизить силу AQ, чтобы он не увеличивал кванты из-за зерна/шумов. Также иногда полезно снижение AQ на исходниках типа аниме, если его сила кажеться слишком большой (порча резких контуров или ringing). +Добавка по поводу работы с mbtree: текущий вариант --aq-mode 2 лучше не использовать вместе с mbtree, так как он плохо с ним работает.
aqmode2 c mb-tree наверно не стоит, он разрабатывался когда дерева не было, можно пробовать --aq-mode 2 --aq-strength 1.0:1.0 представляет собой модифицированный aqmode2, попытка "вытащить" части видео ,где обычный aqmode2 подсирал, введением qp-offset. показывал интересные результаты(иногда)
Про aqmode3 особо сказать нечего, вроде косячный.

weightp (MasterNobody, shellgen)
Cам по себе weightp 2 никак в негавтивном смысле себя нигде не проявляет, только плюсы.
weightp дает более эффективное сжатие переходов (fade in / fade out). Противопоказаний никаких особых нет. Артефактов не замечено с нормальными декодерами (но могут быть проблемы с декодерами несоответствующими стандарту H.264, такими как CoreAVC 1.x или некоторыми железными плейерами). Здесь речь именно о --weightp 2. --weightp 1 тоже полезен, но уже не так эффективен для сжатия переходов (fade in / fade out).
Насчет подбора me по логу, это мне кажется какой-то извините ахинеей. me выбирается не по логам, а исходя из того насколько дольше вы готовы ждать при соответствующем повышении качества (выше umh ИМХО не стоит).

trellis
Особенность работы треллиса в том, что он может размазывать по ровным областям мусор , метрикой psy-trellis устанавливается коэффициент этой самой мазни. Если сигнал чистый, фон ровный и не имеет ярко выраженной шумовой структуры, то отключив треллис, можно предотвратить "мазню" в фоне, но вместе с тем можно потерять на резкости других деталей, поэтому для их сохранения может понадобиться доп. битрейт, который можно было сэкономить за счёт треллиса. С другой стороны, поднимая дэдзоны есть шанс уложиться и в меньший битрейт за счёт отсечения низкоквантовых деталей, в этом случае доп. битрейт не потребуется. Всё очень сильно зависит от сигнала, к каждому нужен свой подход, но как правило включенный треллис позволяет передать больше деталей в аналогичный битрейт. trellis дает субъективный результат. А на мультиках его рекомендуется отключать.

deadzone-inter xx
deadzone-intra xx (MasterNobody)
Q: deadzone ставить по 6 как рекомендуют, чтобы сохранить зерно или оставить можно по умолчанию 11-21 ?
A: Это в зависимости от, того, какие задачи ставить. Если это анимация, да еще такая, в которой нет мелких деталей, то можно и дефолтные 11, 21, а если высокодетализированный источник и нужно сохранить даже мелкий шум, то уменьшаем вплоть 6,4. В любом случае по скриншотам придется смотреть и экспериментировать. Задает пороги для мелких деталей в пределах которых x264 будет их выкидывать не пытаясь сохранить. Наверно при deadzone-intra 6, deadzone-inter 6 стоит задуматься о хорошем запасе битрейта.
Чем ниже значение, тем более мелкие детали по яркости будет стремиться сохранить кодек, но тем больше естественно понадобится битрейта для их сохранения.
Лучше придерживаться золотого правила: "Не знаешь - не крути". А вообще если используется --trellis 2, то deadzones уже практически ни на что не влияют. С другими же режимами trellis их иногда можно уменьшить для сохранения зерна/шумов. Так раньше (а может и сейчас) можно было часто увидеть --deadzone-inter 6 --deadzone-intra 6 именно для целей сохранения зерна/шумов (опять же нужно учитывать, что это повышает битрейт, так что имеет смысл при достаточно высоких битрейтах).

mbtree (shellgen)
Грубо говоря, опускает кванты макроблокам, на которые часто ссылаются близлежащие в радиусе --rc-lookahead фреймы и vice versa. Чем ниже --qcomp, тем больше эффект от mbtree. В мультипроходе эффективнее срабатывает.
На SSIM и прочих попугаях всегда сказывается положительно, чего не скажешь о визуальном восприятии. На анимации наверное хорошо, на живом видео субъективно пока не очень. Более эффективно работает в мультипроходе, в crf тоже судя по результатам неплохо, но теоретически менее эффективно.
Опыт использования MBtree на средних и высоких битрейтах и высоко детальном видео
Для анимации и битрейтодефицитных пережаток возможно всё и хорошо, но в остальном ничего хорошего не замечено пока... Особенно на динамике и с зерном вообще IMHO плохо, для себя остановился пока на --no-mbtree.
mbtree хорош для чистой картинки с повторяющимися кадрами. Это не только новое аниме, но и прочая 2D мультипликация.
Q: Простым сценам в результате достается меньше, а сложным битрейта больше, чем раньше, когда мы не использовали mbtree ?
A: Нет. Больше битрейта достается не "сложным сценам", а "полезным" макроблокам.

psy-rd
Опция позволяет нам регулировать оптимизацию расходуемого на кодирование битрейта (rate-distortion optimization, RDO). Оптимизация предполагает максимально эфективное использование битрейта с точки зрения восприятия картинки человеком. Чем большие значения мы выставляем в этой опции, тем больше мы отдаем предпочтение детализации перед битрейтом. Но... Эти процедуры/методики ориентированы на получение не "такого же" (подобного) изображения, а визуально похожего ("психовизуальные показатели"). Они не делают картинку "более четкой" (более, чем что?), а сохраняют (пытаются сохранить) детализацию за счет битрейта крупных объектов (использование psy-rd понижает PSNR/SSIM). Это приводит к появлению артефактов (части крупных объектов распознаются кодеком как отдельные объекты), что особенно критично при некачественных исходниках.

colormatrix (MaLLIeHbKa)
Правильней указать цветовой диапазон исходника в настройках x264 следующим ключом: "--colormatrix xxx". Где xxx - BT.709, BT.601 и т.д.
--colormatrix "bt470bg" например если DGIndex показывает 470. Еще варианты: undef, bt709, fcc, bt470bg, smpte170m, smpte240m, GBR, YCgCo
Q: Что значат 625 и 525 в "ITU-R..."?
A: Число линий для PAL (625) и NTSC (525)
Q: Что это за опции в логе: Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177
A: Грубо говоря, информационные данные (на сам энкод никак не влияют), содержащие рекомендации декодеру по преобразованию цветового пространства, дабы он сам не строил предположений на этот счёт (предположения обычно строятся на основе разрешения, или не строятся вовсе). Далеко не все декодеры этими данными пользуются.

vbv-bufsize
bufsize — это размер промежуточного буфера перед декодером. maxrate — скорость, с которой этот буфер заполняется. "Пик" — максимальный объём информации, который декодер может получить в единицу времени. Если буфер заполнен, то за одну секунду декодер может получить не больше (maxrate+bufsize). За две секунды не более (2*maxrate+bufsize) и т.д. Аналогично работает -m limit в iptables, если это о чём-то говорит.
Buffer underflow будет, если параметры VBV неправильно подобраны. Очевидно, что сами по себе "пики" не являются ограничением.

subme
--subme 10 хорошо для 2 прохода.
С точки зрения соответствия оригиналу subme 9, предпочтительнее.
Есть такое дело. Когда битрейта более чем достаточно, есть смысл на него опускаться; если имеет место быть даже самую малость битодефицит, QPRD здорово вытягивает.
Q: Когда 9 лучше, чем 10?
A: Таких примеров не скажу, а если они и есть, то вполне может оказаться что и 8 лучше чем 9 (вообщем, это только случаи когда меньше RD лучше, но это скорее всего может быть только когда как-то криво выкрутили --psy-rd).

merange (максимальное количествово итераций при поиске векторов движения) (komisar666)
Определяет максимальное количество попыток (с измененными данными) нахождения оптимального варианта при поиске вектора движения макроблока. Чем больше, тем лучше качество. Но падение скорости не стоит выигрыша уже после 12.
Отметьте, что для umh, esa и tesa, увеличение merange значительно замедлит кодирование.
hex –> umh разница в размере большая, в скорости не очень существенная
umh –> esa –> tesa разница в размере минимальная (причём иногда в "странную" сторону, как ни удивительно), а время вырастает очень существенно, чуть ли не "в разы" (tesa), что уж очень печально
16 –> 24 разница есть, но не очень большая и в размере и в скорости
24 –> 32 тоже есть, но уже незначительная в размере
>32 – практически пустая трата времени
umh – по-моему самый оптимальный алгоритм, с точки зрения соотношения производительность/качество. Всё, что "ниже его" – несколько быстрее и ощутимо хуже. Всё что выше – ощутимо медленнее и незначительно лучше
На счёт merange при umh: разницы между всеми значениям "16 и выше" вижу немного. Меньше 16 ставить не стОит. Можно поднять до 24-32.
Алгоритмы esa и tesa – медленные, дающие небольшой прирост в качестве, логично их использовать, когда скорость энкода совсем не важна, а +капельку улучшения получить хочется. Логично что в таком случае поставить merange можно и побольше (раз времени то совсем не жалко). Но всё равно не думаю, что в значениях больше 32 есть хоть какой-то смысл.
Алгоритмы "меньше umh" – быстрые алгоритмы, позволяющие получить "максимум" fps энкода. Логично, что если стремимся именно к этому, то ставить большие значения merange нелогично, т.к. скорость "уйдёт", а качество "не придёт"... Иными словами больше 16 ставить смысла не вижу.
Такое лучше все же смотреть по SSIM. Улучшение точности M.E. в принципе ведь не всегда должно приводить именно к уменьшению размера. Но так конечно tesa+32 это плацебо которое на качество влияет очень слабо.
merange в некоторых кругах "рекомендуют" FrameWidth/16(именно на 16 делят -на размер макроблока) Увеличивать его полезно при кодировании динамичного исходника... т.е. чтобы алгоритму поиска движения дать возможность найти макроблок с выпущенной пулей, "улетевшей" во втором кадре на расстояние, большее, чем merange...
За МЕ Range в логе отвечает параметр direct, и как я понимаю, чем он ниже, тем менее востребованы высокие значения МЕ Range.

no-dct-decimate (shellgen)
У нас есть блок. У этого блока есть dct коэффициенты. Если коэффициент меньше порога X, то его можно обнулить. А можно оставить на второй проход, вдруг битрейта хватит и на его сохранение. Ключ --no-dct-decimate отвечает, грубо говоря, за опцию предварительной DCT трансформации сигнала перед непосредственно кодированием, как результат - сигнал на следующий этап компрессии подаётся уже немного оптимизированный. Если ключом эту трансформацию отключить, то есть вероятность немного выиграть в детальности в мультипроходе, т.к. за несколько проходов у кодека есть возможность оценить полную версию сигнала, НО категорически не стоит выключать DCT оптимизацию при однопроходном кодировании, только навредит по очевидным причинам.

rc-lookahead
Памяти много - выкручивайте побольше. На что на практике влияет rc-lookahead ?
На количество фреймов, используемых mb-tree (mb-tree ratecontrol) и vbv (vbv-lookahead).
- Если задействуете mb-tree, то значение rc-lookahead должно быть меньше или равно keyint.
- Если используете vbv, то значение rc-lookahead должно быть меньше или равно max( keyint, max( vbv-maxrate, bitrate ) / vbv-bufsize * fps ))

deblock (@lolkin@)
Чем выше квант тем больше сила деблокинга, и наоборот. соотв при низких квантах деблок практически не задействован.
Q: Подскажите, есть ли еще какие-либо методы борьбы с квадратами на участках с равномерными цветами (в мультфильмах), кроме деблока и значительного повышения битрейта?
A: Если исходник mpeg, то в строке загрузки указать cpu=4 (для борьбы с блочностью).

ssim
psnr
SSIM - это объективный измеритель соответствия входящего сигнала выходящему. Считется, что он ближе к человечьей субъективности.
Q: Какое значение SSIM считается достаточно хорошим?
A: Для живого видео цифра пригодна больше для сравнения эффективности различных синтетических настроек на одном и том же подопытном. Хоть SSIM в отличие от PSNR и заточено в некоторой степени на восприятие, но psy портит его почём зря, часто заметно прибавляя визуального комфорта, так что обращать избыточное внимание на этого попугая не стоит.
Q: Скажите пожалуйста, насколько важны параметры SSIM и PSNR? Кто-то включает их в выкладываемый лог, кто-то нет.
И значения того же SSIM: ~0.96 можно считать неудачным результатом и искать лучшие решения?
A: ssim/psnr считают, в данном случае, соответствие выходящего сигнала из кодека входящему сигналу B в кодек. Если мы пофильтруем то кодек на вход получит сигнал с лучшей сжимаемостью и увеличится ssim. Чтобы посчитать реальный ssim надо взять сигнал до кодека и без фильтров и сигнал после кодека. Только смысла такого сравнения мало. Тот же фильтр сложного деинтерлейса уронит тебе тот ssim до невозможности.

fullrange
У нас есть в видео три сигнала. Они могут быть от 0 до 255. Это fullrange он же PC. Они могут быть в диапазоне ТВ ( 16-235 яркость и 16-240 цветность). При работе с промышленными непержатыми енкодами с оптических носителей в 99.9% случаев специально указывать fullrange не нужно.

CRF(pass) (k0stix, @lolkin@, komisar666)
Constant Rate Factor есть модель, ориентированная в отличие от битрейта не на биты и байты, а на оптимизированные исходя из психовизуальных выкладок потери lossy кодирования, чем ниже, тем. меньше потери. Пропорциональная зависимость CRF от битрейта лишь следствие этого.
Есть общая тенденция, при подборе битрейта как правило близким к оптимальному будет битрейт при том значении CRF, при котором кванты I фреймов не упадут ниже 16-17 (более низкие значения обычно сигналят об откровенном перерасходе), а B-фреймов не подскочат выше 25-25.5 (более высокие значения как правило вызывают явно различимые артефакты). Всё что находится в промежутке между этими значениями - надо сравнивать глазами, чтобы оценить возможность/необходимость поднять кванты повыше/пониже. В большинстве случаев комбинация близкая к qi18-qp20-qb23 даст результат, максимально приближенный к оптимальному.
Если нужно выжать из объёма максимум, попав при этом в точный размер, не вылазя за пределы левелов аппаратной поддержки, не жалея времени, то целесообразно делать мультипроходный CRF
Первый проход: --crf ??.? --pass 1 --stats "stats.txt"
Второй проход: --bitrate <битрейт, полученный на первом проходе, скорректированный под целевой> --pass 3 --stats "stats.txt" --vbv-...
Если аппаратная совместимость не актуальна (для SD разрешения она в том числе неактуальна), то тратить время на мультипроход из соображений часы/"выигрыш в качестве" не вполне целесообразно.
Если судить по квантам, уже 2-проходный на основе crf выигрывает в сравнении с однопроходным, даже без mbtree. Точно так же и на глаз.
crf никак не привязан к какому-то определенному битрейту, он дает битрейта ровно столько, сколько надо на данный отрезок видео. Т.е. надо, чтоб битрейт подскачил на 420 кбпс и сохранялся таким в течение 5 минут, crf столько и выделит. С кодированием в битрейт все вертится вокруг заданного битрейта, грубо говоря, на графике это выглядело б как кривая, постоянно ходящая вокруг оси координат (заданного битрейта), постоянно пытаясь вернуться к заданному значению. Помимо того, это и разные алгоритмы сжатия. crf, опять-таки, как я понял, больше внимания уделяет не слишком динамичным сценам, т.е. там, где действительно можно глазом уловить разницу во время просмотра. На ядреной такой динамике может что и пропустить.
При одинаковом битрейте 2-ой проход на основе статистики с crf дает ощутимое преимущество в сравнении с просто crf-ом, как по попугайчикам, так и визуально
1. Для quality-based кодирования вполне достаточно 1-Pass CRF. Нужно вписаться в ограничения хардварных декодеров?, CRF+VBV сейчас прекрасно работает.
2. Есть острая необходимость вписаться в конкретный битрейт/размер файла - 2-pass CRF. Причем первый с --slow-firstpass, вторым тюним если промахнулись.
Q: Есть ли ещё какие-либо критические моменты или рекомендации к CRF энкоду, в плане настроек, кроме --no-dct-decimate --no-fast-pskip --direct spatial ?
A: В остальном от мультипрохода твикинг однопроходного CRF'а не отличается, за исключением того, что при кодировании HD сигнала лучше делать тот же CRF, но в два прохода, чтобы не вылезти за пределы допустимого с точки зрения хардварных чипов VBV, особенно 1080p касается. )
Q: Если выбран crf 20, 20 это средний квант для P ?
A: Это значение RateFactor в понятии кодека, при котором получается некое "постоянное качество", но никак не квант.

Adaptive B-frames (Адаптировать распределение B-кадров) - при включении этой опции кодек будет более разумно распределять двунаправленные кадры, сокращая их последовательное количество в сценах, которые не сильно от этого выйграют. Имеет смысл только при первом проходе в многопроходном кодировании и только если в предыдущей опции вы выбрали значение больше единицы.

Видимо, эта часть была взята отсюда - http://wiki.oszone.net/index.php/MeGUI.
Однако там предыдущим является описание поля "Number of B-frames", а не "B-frame bias" как здесь.
Да и по логике - адаптировать есть смысл только, если максимальное кол-во В-кадров будет более 1.

Надо бы заменить "в предыдущей опции" на "в опции Number of B-frames".

Devprojman сказал(a):

Надо бы заменить "в предыдущей опции" на "в опции Number of B-frames".

Спасибо, Devprojman, поправил

PS материал собирался с разных источников (порядка 5), если есть неточности (мог что-то упустить), буду рад если пользователи найдут и укажут на них

Здравствуйте. Хотел бы задать вопрос по-поводу кодирования в *mkv в MeGui. Есть отснятый камерой и отредактированный в SONY Vegas HD файл 1920X1080 *m2t. На выходе MeGui выдаёт файл отличного качества, только местами при проигрывании видео "заквадрачивается". Пробовал разные варианты пресетов. Ничего. В чём может быть причина. Спасибо всем кто ответит. (На выходе H264 1280X720 mkv)

vorogeдля начала не плохо бы увидеть инфо-файл полученного рипа с артефактами. Как сделать

Здравствуйте, спасибо за отзывчивость. Весь файл я уже стёр за ненадобностью из-за артефактов. К тому же файл очень большой по длительности около 3 часов 20 минут. Поэтому высылаю информацию короткого отрывка этого файла без звука, если это поможет... В любом случае спасибо.

Общее
Полное имя : C:UsersVitaVideosUntitledA.mkv
Формат : Matroska
Размер файла : 15,9 Мегабайт
Продолжительность : 27 с.
Общий поток : 4890 Кбит/сек
Программа-кодировщик : x264 r1867 22bfd31
Библиотека кодирования : Haali Matroska Writer b0

Видео
Идентификатор : 1
Формат : AVC
Формат/Информация : Advanced Video Codec
Профайл формата : [email protected]
Параметры CABAC формата : Да
Параметры ReFrames формата : 10 кадры
Режим смешивания : Container [email protected]
Идентификатор кодека : V_MPEG4/ISO/AVC
Продолжительность : 27 с.
Битрейт : 4792 Кбит/сек
Номинальный битрейт : 5000 Кбит/сек
Ширина : 1280 пикс.
Высота : 720 пикс.
Соотношение кадра : 16:9
Частота кадров : 25,000 кадр/сек
Разрешение : 24 бит
Колориметрия : 4:2:0
Тип развёртки : Прогрессивная
Бит/(Пиксели*Кадры) : 0.208
Размер потока : 15,6 Мегабайт (98%)
Библиотека кодирования : x264 core 112 r1867 22bfd31
Настройки программы : cabac=1 / ref=10 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=5000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

vorogeпосоветовать могу следующее:
1 - перепаковать исходный видеоряд из контейнера .m2ts в .mkv (с помощью tsMuxer в режиме Demux вытащить "голый" видеоряд и запаковать в mkv с помощью mkvmerge)
2 - перед созданием скрипта и енкодом проиндексировать файл с помощью File Indexer встроенного в MeGUI (Tools / File Indexer или Ctrl+F2)
3 - понизить AVC level 5.0 до 4.1
4 - понизить число ReFrames до 8
5 - отключить mb-tree
6 - предыдущие 5 пунктов проделать одновременно.

Уокер
Спсибо большое за совет. Буду пробовать, если не получится буду экспериментировать с другими прогами. По-любому Спасибо.

voroge сказал(a):

Здравствуйте. Хотел бы задать вопрос по-поводу кодирования в *mkv в MeGui. Есть отснятый камерой и отредактированный в SONY Vegas HD файл 1920X1080 *m2t. На выходе MeGui выдаёт файл отличного качества, только местами при проигрывании видео "заквадрачивается". Пробовал разные варианты пресетов. Ничего. В чём может быть причина. Спасибо всем кто ответит. (На выходе H264 1280X720 mkv)

похожая проблема, кодировал BD c черезстрочной разверткой, продолжительностью примерно 40 мин в 1080p. в авс скрипте выставил деинтерлейс. пытался ужать в 4 Гб. получилось примерно 11 Мбит/с, ref 5. мегуи стоял на выключение после окончания кодирования, лог не увидел, хотя я не очень его и умею читать. но очень часто картинка рассыпается на квадраты. в чем может быть проблема? в квантах или неправильном деинтерлейсе?

arslanov
Проблемма может быть в чём угодно, частота кадров, настройки, оптимальный битрейт, нужнен лог и инфа, "лог" можно найти в самой (установленной) мегуи, в папке logs

arslanov сказал(a):

похожая проблема, кодировал BD c черезстрочной разверткой, продолжительностью примерно 40 мин в 1080p. в авс скрипте выставил деинтерлейс. пытался ужать в 4 Гб. получилось примерно 11 Мбит/с, ref 5. мегуи стоял на выключение после окончания кодирования, лог не увидел, хотя я не очень его и умею читать. но очень часто картинка рассыпается на квадраты. в чем может быть проблема? в квантах или неправильном деинтерлейсе?

Деинтерлейс в скрипте был прописан до кропа и ресайза или после?
Рекомендовано применять этот фильтр, до кропа и ресайза.

DMITROO сказал(a):

arslanov Проблемма может быть в чём угодно, частота кадров, настройки, оптимальный битрейт, нужнен лог и инфа, "лог" можно найти в самой (установленной) мегуи, в папке logs

лог приведу ниже, кодировал вчера еше одно видео прогрессивное и есть места такие же самые с рассыпанием на квадраты, там где есть быстрое движение. вроде битрейт достаточный и настройки средние. я грешу на сам кодек 264, раньше я этого не замечал, или может какието збои в железе, но наверное всетаки первое, наверное сборка кодека какаято кривоватая

интерлейсный исходник1

[spoiler]General

ID : 0

Complete name : F:DownloadHDYOZAKURABDMVSTREAM

прогрессивный источник2

[spoiler]General

ID : 0

Complete name : F:DownloadHDIMAX_WILD_AUSTRALIABDMVSTREAM

Уокер сказал(a):

vorogeпосоветовать могу следующее: 1 - перепаковать исходный видеоряд из контейнера .m2ts в .mkv (с помощью tsMuxer в режиме Demux вытащить "голый" видеоряд и запаковать в mkv с помощью mkvmerge) 2 - перед созданием скрипта и енкодом проиндексировать файл с помощью File Indexer встроенного в MeGUI (Tools / File Indexer или Ctrl+F2) 3 - понизить AVC level 5.0 до 4.1 4 - понизить число ReFrames до 8 5 - отключить mb-tree 6 - предыдущие 5 пунктов проделать одновременно.

еше может быть контейнер .m2ts и это както влияет на рип? в предварительном тест проходе по 50 кадров такого рассыпания нет. сутки на 2 прохода это конечно не дает стимула для эксперимента. ЗЫ: почему перепакованый х264 в .mkv меньше весит чем .m2ts?

arslanov сказал(a):

еше может быть контейнер .m2ts и это както влияет на рип? в предварительном тест проходе по 50 кадров такого рассыпания нет. сутки на 2 прохода это конечно не дает стимула для эксперимента. ЗЫ: почему перепакованый х264 в .mkv меньше весит чем .m2ts?

Быть может все что угодно. Попробуйте выполнить все те рекомендации, что я писал ранее. Кодеки переустановите.
Весит меньше потому что контейнер другой, другие методы паковки.