Как выбрать оптимальный битрейт и ключевые параметры для рипа в х265 (HEVC) при кодировании анимации (и не только).

Страницы :  1, 2, 3, 4, 5, 6  След.
Ответить
 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 21-Авг-21 05:22 (3 года 4 месяца назад, ред. 17-Фев-24 17:31)

В данной небольшой инструкции я постараюсь объяснить некоторые нюансы кодирования анимации (читай аниме), а также дать немного общей информации про работу кодека HEVC (x265). Ver 1.0 материал будет дополняться / изменяться / оформляться. За редактуру спасибо Horo.____Предполагается, что человек, читающий этот топик понимает, что обычно, при создании рипа аниме, оно подвергается обработке фильтрами для удаления алиасинга, бандинга и прочих артефактов, встречающихся на BLU RAY дисках. Он понимает, как кодировать кодеком х264 (если нет, советую почитать и изучить эту тему перед дальнейшим чтением) и возможно уже делал это раньше. Он также понимает, зачем нужен 10 битный профиль кодирования и не станет использовать его "просто так" при кодировании 8 битных исходников, так как в таком случае он получит только лишний битрейт на сохранение 2х лишних битов информации (8+2=10), не содержащих ничего, кроме "нулевых" битов информации, которые добавит кодек. Также предполагается, что разрешение кодируемого видео это 2160, 1080 или 720, как наиболее часто используемые на данный момент. Каждый рипер использует удобные лично ему инструменты, но обычно это фрейм-серверы AviSynth или VapourSynth для "фильтрации" видео и консольный кодировщик х265, который можно взять в официальном репозитории и скомпилировать самому, можно скачать готовые "сбилденные" экзешники с различных сайтов по кодированию или взять mod версии этого кодировщика с нашего (beatrice-raws) гитхаб - репозитория, которые добавляют отображение инфы о fps, длинны видео (в кадрах), примерного времени кодирования и прочего для удобства пользователя. Нижеперечисленная информация верна для кодировщика x265 x64 v3.4-3.5 версии. Это 2 последних версии кодировщика и настоятельно рекомендуется использовать только их.
____Также стоит понимать, что разница между х264 и х265 в плане сжатия не так велика, как многим кажется. х264 уже 18 лет, а х265 - 8. х264 был основан на дискретном косинусном преобразовании (которое работает с действительными числами) и преобразовании Адамара, которое очень легкое и предназначено для того, чтобы разобраться с тем, что DCT неспособно сжать достаточно хорошо. Если по простому - при dct изображение раскладывается на частотный спектр (вы могли видеть его примеры в раздачах лослесс аудио и с видео тоже можно провернуть такое, да, анализируется и сжимается (грубо говоря части кадра описываются формулами) для последующего восстановления исходного спектра, а как следствие - оригинального изображения при декодировании. И вот тут х265 выигрывает за счет того, что у него на несколько десятков способов анализа движения в кадре больше, чем у его предка. х265 способен более точно просчитать (анализировать) движение пикселя (макроблока) как во времени (несколько кадров вперед и назад), так и в рамках одного кадра (например перемещение объекта относительно фона). И вот этот более точный анализ позволяет отбросить намного больше частот из исходного спектра изображения, а при декодировании достаточно точно их восстановить, за чет чего экономится битрейт. Помимо этого х265 имеет несколько функций для удаления (корректирования) ошибок квантования сигнала (сжатия) при сверхнизких битрейтах. Он "размазывает" картинку в тех местах, где из-за недостатка битрейта лезет блочность (довольно большие группы микроблоков или пикселей, которые визуально выглядят как цветные квадраты), что позволяет ему класть на лопатки х264 при битрейтах ниже 1 мегабита. Но все это работает не в 100% случаев и не на 100% лучше.
____Реальная экономия при кодировании аниме в х265 относительно х264 без видимых потерь в качестве картинки это примерно 2-8 мегабит, бывает больше, бывает меньше. Все очень сильно зависит от "энергии изображения" исходного материала, с которым вы работаете. Есть ли там зерно, или просто шум, много ли движения, много ли темных сцен с множеством деталей и тд. Когда вы кодируете фильм или многосерийное аниме, это дает существенную экономию. Например минус даже 300 мегабайт с одной серии дадут профит в примерно 7 гигабайт на 24 серии. И это очень хороший результат для кодека, который по сути является х264 на стероидах. Но он не творит чудеса. Именно поэтому в аниме разделе рутеркера запрещены рерипы WEB и HDTV видео в х265 без изменения разрешения на более низкое. Беря максимально некачественно сжатое х264 веб видео (4 мегабита в среднем) и кодируя его в х265 вы не выиграете ничего. Вы не сделаете его лучше, в лучшем случае оно останется визуально таким же (если смотреть с 10 метров на монитор), а то и хуже, чем оригинальное. Намного лучше с точки зрения качества видео, при перекодировании изменить разрешение видео. Поэтому "легкие рипы" всегда были синонимом "720 версия". Точно также, как и со звуком, если вы перекодировали (например после выполнения процесса синхронизации и подгонки к видео) lossy в lossy, то вам стоит снизить битрейт.
Наглядный пример. Три рипа одного аниме, BD копия которого содержит огромное кол-во зерна. х264 21 мегабит - scy, порядка 4 гигабайт/серия, х265 14 мегабит - мой, порядка 2 гигабайт/серия и "мини кодирование" с ня от Tenrai-Sensei с 2 мегабитами битрейта на серию и 300-500 мегабайт на серию. Делайте выводы.


Часть 1. Параметры кодирования
Параметры кодирования
Для начала пройдемся по необходимым нам настройкам, все остальные настройки при желании вы можете прочесть в официальной документации х265.
Дисклеймер: здесь и далее перевод документации выполнен машинным способом.
--ref <1..16> _ [readthedocs.io]
Перевод документации
Максимальное разрешенное количество ссылок L0. Это число имеет эффект линейного множителя на объем работы, выполняемой при поиске движения, но обычно оказывает положительное влияние на сжатие и искажение.
Обратите внимание, что x265 допускает до 16 ссылок L0, но спецификация HEVC допускает не более 8 общих кадров ссылок. Итак, если у вас включены B-кадры, действительны только 7 ссылок L0, а если вы --b-pyramid также включили (что по умолчанию включено во всех предустановках), то только 6 ссылок L0 являются максимально разрешенными спецификацией HEVC. Если x265 обнаруживает, что общее количество ссылок больше 8, он выдает предупреждение о том, что результирующий поток не соответствует требованиям, и сигнализирует потоку как профиль NONE и level NONE и прерывает кодирование, если --allow-non-conformanceоно не указано. Совместимые декодеры HEVC могут отказываться декодировать такие потоки.
Значение по умолчанию: 3

Для видео в 1080 следует всегда устанавливать значение 4, для видео 720 - 6. Эти значения оптимальны и обычно не требуют изменения.
--allow-non-conformance, --no-allow-non-conformance _ [readthedocs.io]
Перевод документации
Разрешить х265 генерировать битовый поток с профилем и уровнем NONE. По умолчанию он прерывает любое кодирование, которое не соответствует строгому соответствию уровня. Две наиболее вероятные причины несоответствия: --ctu слишком маленький, --ref слишком высокий или битрейт или разрешение, выходящие за рамки спецификации.
Значение по умолчанию: отключено

Использование этого ключа не рекомендуется, так как х265 перестает контролировать возможность аппаратного декодирования кодируемого потока на конечном устройстве воспроизведения и позволяет пользователю выйти за пределы "спеков" такой поддержки. Вы должны полностью понимать, для чего вам это нужно.
--rd <1..6> _ [readthedocs.io]
Перевод документации
Уровень РДО в режиме решения. Чем выше значение, тем более исчерпывающим является анализ и тем больше используется оптимизация скоростных искажений. Чем ниже значение, тем быстрее кодируется, чем выше значение, тем меньше битовый поток (в общем).
Обратите внимание, что эта таблица нацелена на точность, но не обязательно является нашим окончательным целевым поведением для каждого режима.
Диапазон значений:
  1. 0 Режим sa8d и разделенные решения, внутренние с исходными пикселями, в настоящее время не поддерживаются
  2. 1 сгенерировано повторно (лучше внутреннее), выбор слияния / пропуска RDO
  3. 2 RDO разделяет и объединяет / пропускает выбор
  4. 3 Режим RDO и решения разделения, остаточная цветность, используемая для sa8d
  5. 4 В настоящее время то же, что и 3
  6. 5 Добавляет решения прогнозирования RDO
  7. 6 В настоящее время то же, что и 5
Значение по умолчанию: 3

Рекомендуется устанавливать значения в диапазоне 3-6, но не ниже, если вы конечно хотите сохранить качество на высоком уровне.
--ctu, -s <64|32|16> _ [readthedocs.io]
Перевод документации
Максимальный размер CU (ширина и высота). Чем больше максимальный размер CU, тем эффективнее x265 может кодировать плоские области изображения, что значительно снижает битрейт. Однако это приводит к потере параллелизма с меньшим количеством строк CU, которые могут быть закодированы параллельно, а также с меньшим параллелизмом кадров. Из-за этого в более быстрых пресетах используется размер CU 32.
Значение по умолчанию: 64

Тут все несколько сложнее, подавляющее большинство типов исходного материала в аниме "обожают" значение по умолчанию (64), но некоторые из них могут вызывать неприятные артефакты в виде видимых блоков 64х64 на ровных градиентах в местах с низким битрейтом. Если вы видите такие артефакты, вам следует использовать значение 32. Значения ниже обычно приводят к полному искажению видео.
--min-cu-size <32|16|8> _ [readthedocs.io]
Перевод документации
Минимальный размер CU (ширина и высота). При использовании 16 или 32 кодер не будет анализировать стоимость CU ниже этого минимального порога, экономя значительные объемы вычислений с предсказуемым увеличением битрейта. Этот параметр сильно влияет на производительность более быстрых предустановок.
Значение по умолчанию: 8 (минимум 8x8 CU для HEVC, наилучшая эффективность сжатия)

Оптимально оставлять значение по умолчанию (8), иначе вы рискуете сильно потереть в эффективности сжатия и / или внести артефакты в кодируемое видео.
--rect, --no-rect _ [readthedocs.io]
Перевод документации
Включить анализ прямоугольных перегородок Nx2N и 2NxN (разделение 50/50, два направления).
Значение по умолчанию: отключено

Я не заметил существенного прироста в качестве при включении этого параметра, а вот просадка в скорости кодирования весьма существенна.
--rskip <0|1|2> _ [readthedocs.io]
Перевод документации
Этот параметр определяет ранний выход из рекурсии глубины CU в режимах 1 и 2. При обнаружении CU пропуска используются дополнительные эвристики (в зависимости от уровня RD и режима rskip) для принятия решения о прекращении рекурсии.
  1. 0–4: режим 1 Соседние затраты и однородность CU.
  2. 5–6: режим 1 Сравнение с inter2Nx2N.
  3. 0–6: режим 2 Плотность краев CU.
Обеспечивает минимальное ухудшение качества при хорошем приросте производительности для ненулевых режимов. значит отключен.
Значение по умолчанию: 1, отключено при использовании. Это целое число, представляющее процент плотности границ в CU. Внутренне нормализовано до числа от 0,0 до 1,0 в x265. Рекомендуемые низкие пороги для медленного кодирования и высокие для быстрого кодирования.--rskip mode 0--tune grain

С этим параметром также все не так просто, как кажется. По моему опыту кодирования анимации, все значения, кроме 0 и 1, а также, как следствие этого, режимы 0 и 1 вносят искажения в видео и не рекомендуются к использованию. Возможно они дадут полезный результат при кодировании на сверхнизких битрейтах, но я не проверял. Общее правило - если вы хотите предельно высокой детализации кодируемого видео и его точному соответствию исходному материалу (например вы кодируете старое аниме 70-90 годов, которое представляет из себя сканирование кинопленки с кучей шума) то вам следует отключать его (значение 0), в остальных случаях можете включать.
--tskip, --no-tskip _ [readthedocs.io]
Перевод документации
Включите оценку кодирования с пропуском преобразования (обход DCT, но по-прежнему использующий квантование) для кодированных блоков 4x4 TU.
Эффективен только на уровнях RD 3 и выше, которые выполняют решения режима RDO. По умолчанию отключено.

Значение по умолчанию: отключено. Заставляет х265 прогонять блоки 4х4 через квантазер до dct преобразования. Это может спасти "темные линии в темных сценах".
--tu-intra-depth <1..4> _ [readthedocs.io]
Перевод документации
Квадратное дерево единиц преобразования (остаточное) начинается с той же глубины, что и квадродерево единиц кодирования, но кодер может решить дополнительно разделить дерево единиц преобразования, если это повышает эффективность сжатия. Этот параметр ограничивает количество попыток увеличения глубины рекурсии для блоков с внутренним кодированием.
Обратите внимание, что когда внутреннее предсказание CU равно NxN (возможно только с 8x8 CU), подразумевается разделение TU, и, таким образом, остаточное дерево квадратов начинается с 4x4 и не может разделить какой-либо дополнительный.
Значение по умолчанию: 1, что означает, что остаточное дерево квадратов всегда находится на той же глубине, что и закодированное единичное дерево квадратов.

Исходя из моего опыта кодирования анимации, в 99% отлично справляются значения 2-3, значение 4 позволяет х265 "угадывать" движение в кадре и может как спасти ситуацию при низком битрейте и "дорисовать" информацию в сцене на основе анализа с предыдущих кадров, так и вызвать артефакты в виде плавающих в рандомных местах кадра частей из соседних кадров (например линия волос оказалась не на голове, а в углу комнаты), тут все следует определять визуально в процессе подбора настроек и сравнения скриншотов. На самом деле, х265 при значении 4 у данного параметра критично ошибается достаточно редко.
--tu-inter-depth <1..4> _ [readthedocs.io]
Перевод документации
Квадратное дерево единиц преобразования (остаточное) начинается с той же глубины, что и квадродерево единиц кодирования, но кодер может решить дополнительно разделить дерево единиц преобразования, если это повышает эффективность сжатия. Этот параметр ограничивает количество попыток увеличения глубины рекурсии для блоков с межкадровым кодированием.
Значение по умолчанию: 1. это означает, что остаточное дерево квадратов всегда находится на той же глубине, что и закодированное единичное дерево квадратов, если CU не был закодирован с помощью прямоугольных разделов или разделов AMP, и в этом случае подразумевается разделение TU и, следовательно, остаточное дерево квадратов. начинается на один уровень ниже четырехугольного дерева CU.

Все, как и у предыдущего параметра.
--max-tu-size <32|16|8|4> _ [readthedocs.io]
Перевод документации
Максимальный размер ТУ (ширина и высота). Остаток может быть более эффективно сжат с помощью преобразования DCT, когда максимальный размер TU больше, но за счет дополнительных вычислений. Квадратное дерево единицы преобразования начинается на той же глубине, что и единица кодированного дерева, но если максимальный размер TU меньше, чем размер CU, тогда QT преобразования начинается на глубине max-tu-size.
Значение по умолчанию: 32

Этот параметр работает в связке с --ctu и вам или надо оставить его по умолчанию (32) при значении ctu 64 или изменить на 16 при значении ctu 32 исходя из той же логики (если наблюдаются артефакты в виде видимых блоков 64х64).
--dynamic-rd <0..4> _ [readthedocs.io]
Перевод документации
Повышает уровень RD в точках, где качество падает из-за принудительного контроля скорости VBV. Количество CU, для которых реконфигурируется RD, определяется на основе мощности. Уровень 1 дает лучший FPS, уровень 4 дает лучший SSIM. Сила 0 отключает эту функцию.
Значение по умолчанию: 0.

Этот параметр я бы посоветовал всем всегда включать, так как динамический подбор рд просто лучше статичного, поверьте, кодек лучше вас знает, что ему нужно.
--me <integer|string> _ [readthedocs.io]
Перевод документации
Метод поиска движения. Как правило, чем выше число, тем сложнее метод ME будет пытаться найти оптимальное соответствие. Алмазный поиск - самый простой. Поиск по шестиугольнику немного лучше. Uneven Multi-Hexegon - это адаптация метода поиска, используемого x264 для более медленных предустановок. Звездочка - это трехэтапный поиск, адаптированный из кодировщика HM: поиск по звездочному образцу, за которым следует дополнительное сканирование по основанию системы счисления, за которым следует дополнительное уточнение поиска по звездочке. Полный - это исчерпывающий поиск; на порядок медленнее, чем все другие поисковые запросы, но не намного лучше, чем э-э или звездочка. SEA аналогична реализации ESA x264 и обеспечивает оптимизацию скорости полного поиска.
Это трехэтапный поиск движения, в котором за вычислением DC следует вычисление ADS, за которым следует SAD переданных кандидатов вектора движения.
Значения:
  1. 0 dia
  2. 1 hex (по умолчанию)
  3. 2 umh
  4. 3 star
  5. 4 sea
  6. 5 full

Лично я всегда использую значение 3 star. Оно оптимально по соотношению скорость / качество анализа. Рекомендуемые значения: не ниже 2, верхнее значение ограничено только мощностью вашего пк и здравым смыслом.
--subme, -m <0..7> _ [readthedocs.io]
Перевод документации
Количество выполняемых дополнительных уточнений. Чем выше число, тем больше выполняется итераций и шагов subpel.
Значение по умолчанию: 2
При значениях –subme, превышающих 2, остаточная стоимость цветности включается во все шаги уточнения subpel, а остаточная цветность включается во все решения по оценке движения (выбор лучшего опорного изображения в каждом списке и выбор между слиянием, однонаправленным движением и двунаправленным движением). направленное движение). «Медленная» предустановка - это первая предустановка, позволяющая использовать остаточную цветность.
Диапазон значений: 1-7

Лично я всегда использую максимальное значение (5) Оно оптимально по соотношению скорость / качество анализа. Рекомендуемые значения: не ниже 3, верхнее значение ограничено только мощностью вашего пк и здравым смыслом.
--merange <integer> _ [readthedocs.io]
Перевод документации
Диапазон поиска движения.
Значение по умолчанию: 57
Значение по умолчанию получается из размера CTU по умолчанию (64) минус полудлина интерполяции яркости (4) минус максимальное расстояние subpel (2) минус один дополнительный пиксель на случай, если используется метод шестнадцатеричного поиска. Если бы диапазон поиска был больше этого, для опорных кадров потребовалась бы другая строка задержки CTU.
Диапазон значений: целое число от 0 до 32768

По опыту, лучше оставлять значение по умолчанию, слизком низкие значения понизят качество, слишком высокие (более 60) вызовут бесcмысленное увеличение времени кодирования с минимальным приростом качества.
--strong-intra-smoothing, --no-strong-intra-smoothing _ [readthedocs.io]
Перевод документации
Включите сильное внутреннее сглаживание для внутренних блоков 32x32. Этот флаг выполняет билинейную интерполяцию опорных угловых отсчетов для сильного эффекта сглаживания. Цель состоит в том, чтобы предотвратить артефакты блокирования или полосатости в регионах с небольшим / нулевым коэффициентом переменного тока.
Значение по умолчанию: включен

Тут все несколько сложнее, подавляющее большинство типов исходного материала в аниме "обожают" значение --no-strong-intra-smoothing (отключено), но некоторые из них могут иметь неприятные очень мелкие артефакты в виде блочности или полосатости в некоторых частях кадра, тогда этот параметр стоит включить, но помните, в 99% он сам вызывает небольшое, но неприятное понижение качества.
--psy-rd <float> _ [readthedocs.io]
Перевод документации
Влияние скорости искажения на решение оптимизированного режима для сохранения энергии исходного изображения в кодированном изображении за счет эффективности сжатия. Это влияет только на предустановки, которые используют решения режима на основе RDO ( --rd3 и выше). 1.0 - типичное значение.
Значение по умолчанию: 2.0
Диапазон значений: 0 .. 5.0

Тут все просто. Современ х264 особо ничего не поменялось. Значение по умолчанию (2) оптимально в большинстве случаев.
--psy-rdoq <float> _ [readthedocs.io]
Перевод документации
Влияние искажений на оптимизированное квантование за счет увеличения энергии реконструированного изображения. Обычно это улучшает воспринимаемое визуальное качество за счет более низких показателей качества. Он действует только при --rdoq-level 1 или 2. Высокие значения могут быть полезны для сохранения высокочастотных деталей.
По умолчанию: 0,0 (1,0 для предустановок медленный, медленный, очень медленный)
Диапазон значений: 0 .. 50.0

Этот параметр заменяет собой psy-trellis у х264 и работает по несколько иному алгоритму. Как вы наверно понимаете, psy-rd пытается описать энергию, тобишь все то огромное кол-во мелких деталей в кадре за счет алгоритмов, по которым декодер их обратно восстановит при воспроизведении и вот этот самый rdoq может значительно повысить визуальную детализацию изображения как за счет лучшего сохранения высокочастотных деталей (представьте себе частотный спектр после преобразования dct - зачастую все мелкие детали изображения являются высокочастотными), так и за счет своего ошибочного решения / анализа спектра (даже ошибочные "детальки" визуально добавляют детализации видео, так уж устроен наш мозг). Поэтому всегда рекомендую устанавливать значения не ниже 2, а лучше 4, но все конечно зависит от исходного материала для кодирования.
--keyint, -I <integer> _ [readthedocs.io]
Перевод документации
Максимальный внутренний период в кадрах. Особый случай бесконечной скорости (одиночный ключевой кадр в начале потока) может быть запущен с аргументом -1. Используйте 1 для принудительного использования all-intra. Когда включено внутреннее обновление, он указывает интервал, между которым происходят развертки обновления.
Значение по умолчанию: 250

Тут все просто, если вы кодируете видео с 24 или 23.976 fps, то устанавливайте 240, если не знаете, что поставить - 250, если вы кодируете видео с 30 fps - ставьте 300, иные значения фактически отключают аппаратную поддержку декодирования х265 и могут вызвать артефакты. Многие кодеры любят за счет высоких значений keyint (720 и выше) повышать уровень сжатия, так как ключевые кадры "весят" достаточно много и их меньшее кол-во вызывает снижение битрейта, но это ОЧЕНЬ мешает кодеку определять правильные значения для ряда сцен и зачастую полностью ломают перемотку в плеерах при воспроизведении, так как она выполняется по ключевым кадрам.

--crf <0..51.0> _ [readthedocs.io]
Перевод документации
Переменный битрейт с контролем качества. CRF - это метод контроля скорости по умолчанию; он не пытается достичь какой-либо конкретной целевой скорости, вместо этого он пытается достичь заданного однородного качества, а размер потока битов определяется сложностью исходного видео. Чем выше коэффициент скорости, тем выше квантование и ниже качество.
Значение по умолчанию: 28.0.

Тут можно написать очень много текста, но все всегда сводится к одному - идеальным рипом считается тот, "что выглядит как исходник, а весит меньше". Поэтому не стоит думать, что большие значения crf позволят вам безболезненно снизить битрейт видео. Не забывайте про энергию изображения, различные исходники имеют свой уникальный минимальный битрейт, при котором они продолжают выглядеть отлично, ваша задача всегда сводится к поиску этого самого значения битрейта. От себя могу сказать, что для кодирования современной анимации с небольшим уровнем шума и тд оптимальны значения в диапазоне 14 - 16. Для кодирования сканирования кинопленки или иных исходников с большим кол-вом шума оптимальны значения 15 - 18. И я всегда советую использовать именно режим crf при кодировании анимации. Со временем вы научитесь хорошо контролировать битрейт другими способами, нежели бездумным кручением этого параметра.
--aq-mode <0|1|2|3|4> _ [readthedocs.io]
Перевод документации
Режим работы адаптивного квантования. Увеличьте или уменьшите квантование для каждого блока на основе анализа сложности исходного изображения. Чем сложнее блок, тем больше используется квантование. Это компенсирует тенденцию кодировщика тратить слишком много битов на сложные области и недостаточно на плоские.
Возможные значения:
  1. 0 отключен
  2. 1 AQ включен
  3. 2 AQ включен с автоматическим отклонением (по умолчанию)
  4. 3 AQ включен с автоматическим отклонением и смещением к темным сценам. Это рекомендуется для 8-битного кодирования или 10-битного кодирования с низким битрейтом, чтобы предотвратить цветовые полосы / блокировку.
  5. 4 Включен AQ с автоматическим отклонением и информацией о краях.

Также весьма важный параметр для достижения хорошего качества. Рекомендуемые значения при кодировании анимации: 3-4 Если вы хотите настроить х265 аля х264 и лишь частично использовать его "фишки", то ваш выбор - значение 3, оно наиболее близко к значению 3 в 264. Значение 4 чуть более адаптивно и может помочь в некоторых случаях. Все зависит от ситуации.
--aq-strength <float> _ [readthedocs.io]
Перевод документации
Отрегулируйте силу адаптивных смещений квантования. Установка --aq-strengthна 0 отключает AQ. В aq-режимах 2 и 3 высокие значения aq-Strength приведут к большим смещениям QP, что приведет к большой разнице в достигнутых битрейтах.
Значение по умолчанию: 1.0.
Диапазон значений: от 0,0 до 3,0

Тут все очень индивидуально, но диапазон разумных значений обычно лежит в пределах от 0.40 до 3. Помните, что даже малейшее изменение этого параметра очень влияет на получаемую картинку и подбирать его надо в ходе тестовых кодирований. Например, по моему опыту, значения 1.01 / 1.02 / 1.03 могут достаточно сильно отличаться визуально.
--hevc-aq _ [readthedocs.io]
Перевод документации
Включить адаптивное квантование. Он масштабирует размер шага квантования в соответствии с пространственной активностью одной единицы кодирования относительно средней пространственной активности кадра. Этот метод AQ использует минимальную дисперсию субблока в каждой единице кодирования для представления пространственной сложности единицы кодирования.

Этот режим воистину, отличная новая "фишка" х265 для кодирования анимации, некое сочетание режима 3 у aq-mode и aq-motion. В нем весь подбор идеальных значений ложится на сам кодек. Отлично работает примерно в 60% случаев.
Он очень сильно зависим от параметра --qp-adaptation-range.

--qp-adaptation-range _ [readthedocs.io]
Перевод документации
Диапазон Delta-QP по адаптации QP на основе психовизуальной модели.
Значение по умолчанию: 1.0.
Диапазон значений: от 1,0 до 6,0

При включенном hevc-aq отличные результаты выходят при значениях в диапазоне от 2 до 4.
--aq-motion, --no-aq-motion _ [readthedocs.io]
Перевод документации
Отрегулируйте смещения AQ на основе относительного движения каждого блока по отношению к движению кадра. Чем больше относительное движение блока, тем больше используется квантование.
Значение по умолчанию: отключено. Экспериментальная функция

Включение этой функции может помочь вам дополнительно сэкономить битрейт при использовании режимов aq-mode 3 и 4, но используйте с осторожностью, иногда может вызывать артефакты в пограничных областях с быстрым / малым движением (бабочка летящяя по статичному фону в виде неба, к примеру, будет обрамлена артефактами сжатия, где aq-motion не смогло правильно определить границы работы.
--cutree, --no-cutree _ [readthedocs.io]
Перевод документации
Включите использование полей векторов движения в нижнем разрешении просмотра вперед, чтобы определить количество повторного использования каждого блока для настройки коэффициентов адаптивного квантования. Блокам CU, которые часто повторно используются в качестве эталона движения для более поздних кадров, дается более низкий QP (больше битов), в то время как блокам CU, которые быстро изменяются и на которые нет ссылок, дается меньше битов. Это имеет тенденцию улучшать детализацию фона видео с меньшим количеством деталей в областях с интенсивным движением.
Значение по умолчанию: включен

Этот параметр родственник mbtree ("дерево" на сленге) из 264, но работает намного более аккуратно и правильнее. Если вы кодируете современную анимацию с малым кол-вом шума, он вам совершенно не нужен, так как вы прекрасно уложитесь в необходимый битрейт при учете правильного использования других параметров, а активация cutree в таком случае только навредит. Но если вы кодируете аниме, что представляет собой сканирование кинопленки или другое, но также с огромным кол-вом зерна в кадре, то cutree - ваш выход. При большом кол-ве зерна в кадре основная проблема состоит в том, что это самое зерно "забивает" собой практически каждый бит информации и эти биты принимают полностью уникальные значения, что заставляет кодек бездумно расходовать битрейт на их сохранение. Кодек всегда будет думать, что битрейта недостаточно для достижения заданного уровня качества и всегда повышать его и зачастую вы получите битрейт больший, чем в исходном материале. Включение cutree заставит х265 сместить чашу весов. Что это значит. cutree фактически ставит во главу угла детализацию фона (который зачастую статичен), а не динамически изменяемых элементов (движение). Но так как при сильной зернистости 99% кадра - это динамика с точки зрения кодека, то он будет отбирать битрейт у этого самого зерна, и перекидывать его на общую детализацию кадра, на те элементы, что он считает базовыми и / или статичными. Поэтому использование cutree на таких типах исходного материала позволяет существенно и безболезненно снизить средний битрейт до вменяемых значений. Пример: https://slow.pics/c/TAWI0etw - х264 15.5 Mb/s х265 12.0 Mb/s при этом, для достижения 15 мегабит битрейта на 264 мне понадобилось применить довольно сильное шумоподавление и потерять текстуру зерна, а в случае х265 и включенного cutree, шумодав был установлен на минимум и при этом зерно сохранено практически полностью, а битрейт оказался даже ниже, чем у х264.
--qcomp <float> _ [readthedocs.io]
Перевод документации
qComp устанавливает коэффициент сжатия кривой квантователя. Он взвешивает квантователь кадров на основе сложности остатка (измеряется опережением). Его значение должно быть от 0.5 до 1.0. Значение по умолчанию: 0.6. Увеличение его до 1.0 будет эффективно генерировать CQP.

Обычно лучше оставить значение по умолчанию, но если вы видите, что cutree слишком сильно сбивает средний битрейт и начинают лезть артефакты, то значение можно повысить, обычно до 0.72
--deblock=<int>:<int>, --no-deblock _ [readthedocs.io]
Перевод документации
Переключить фильтр цикла деблокирования, при желании указать смещения силы деблокирования.
<int>: <int> - разбирается как смещение tC и бета-смещение <int>, <int> - разбирается как смещение tC и бета-смещение <int> - смещениям tC и Beta присвоено одно и то же значение
Если не указано иное, смещения по умолчанию равны 0. Смещения должны находиться в диапазоне от -6 (наименьшая прочность) до 6 (наибольшая прочность).
Чтобы полностью отключить фильтр деблокирования, используйте –no-deblock или –deblock = false.
По умолчанию включен, оба смещения по умолчанию равны 0.
Если деблокирование отключено или смещения не равны нулю, эти изменения от конфигурации по умолчанию сигнализируются в PPS.

Каждый волен выбирать то значение, которое его устраивает. Меня например, всегда устраивает значение 1/-1
--sao, --no-sao _ [readthedocs.io]
Перевод документации
Переключить образец адаптивного фильтра контура смещения.
Значение по умолчанию: включен

Очень веселый фильтр х265, который призван работать в паре с deblock для удаления возникающих артефактов от недостатка битрейта при кодировании на сверхнизких и / или с недостатком битрейта. В 99% его следует отключать, только если ваш средний битрейт ниже 2 мегабит, то можете включить, но sao любит снижать детализацию путем размытия мелких деталей.
--limit-sao, --no-limit-sao _ [readthedocs.io]
Перевод документации
Ограничьте вычисление фильтра SAO путем раннего завершения процесса SAO на основе режима внешнего предсказания, корреляций в пространственной области CTU и отношений между яркостью и цветностью.
Значение по умолчанию: отключено.

Если вы таки включили sao, и оно начало смывать полезные детали, вы можете спасти ситуацию включением этого параметра.
--limit-refs <0|1|2|3> _ [readthedocs.io]
Перевод документации
Если установлено значение X265_REF_LIMIT_DEPTH (1), x265 будет ограничивать эталоны, проанализированные на текущей глубине, на основе эталонов, используемых для кодирования 4 подблоков на следующей глубине. Например, CU 16x16 будет использовать только ссылки, используемые для кодирования его четырех CU 8x8.
Если установлено значение X265_REF_LIMIT_CU (2), прямоугольные и асимметричные разделы будут использовать только ссылки, выбранные при поиске движения 2Nx2N (в том числе на самой низкой глубине, на которую в противном случае не влияет ограничение глубины).
Если установлено значение 3 (X265_REF_LIMIT_DEPTH && X265_REF_LIMIT_CU), поиск движения 2Nx2N на каждой глубине будет использовать только ссылки из разделенных CU, а поиск движения прямоугольного/усиленного движения на этой глубине будет использовать только ссылки, выбранные 2Nx2N.
Для всех ненулевых значений данного параметра, текущая глубина будет оценивать внутренний режим (внутри срезов), только если внутренний режим был выбран как лучший режим хотя бы для одного из 4 подблоков.
Вы часто можете увеличить количество используемых ссылок (в пределах вашего уровня декодера), если вы включите один или оба этих флага.
Значение по умолчанию: 3.

Установка значения 2 дает лучшие результаты при установке остальных настроек, как в моих пресетах ниже и установка значений 0, 1, 3 дает лучшие результаты при использовании ключей --rect и --amp.
--refine-intra <0..4> _ [readthedocs.io]
Перевод документации
Включает уточнение внутренних блоков в текущем кодировании.
Значения:
  1. 0 Уровень 0 — форсирует и режим, и глубину из кода сохранения.
  2. 1 Уровень 1 — оценивает все внутренние режимы на текущей глубине (n) и на глубине (n+1), когда текущий размер блока на единицу больше, чем min-cu-size. Форсирует режимы для больших блоков.
  3. 2 Уровень 2 - В дополнение к функциональности уровня 1, на всех глубинах принудительно (a) только глубина, когда угловой режим выбран кодом сохранения. (b) глубина и режим, когда другие внутренние режимы выбираются кодом сохранения.
  4. 3 Уровень 3. Выполнение анализа внутренних режимов на глубину повторного использования из первого кодирования.
  5. 4 Уровень 4 — не использует повторно никакую информацию об анализе — повторите анализ для внутреннего блока..
    Значение по умолчанию: 1.0.

Установка значения по умолчанию дает лучшие результаты при установке остальных настроек, как в моих пресетах ниже и установка значений 0, 2, 3 дает лучшие результаты при использовании ключей --rect и --amp. Если вы установили ключ --dynamic-refine, то значение 4 для данного параметра будет оптимальным.
--refine-inter <0..3> _ [readthedocs.io]
Перевод документации
ключает уточнение промежуточных блоков в текущем кодировании.
Значения:
  1. 0 Уровень 0 — форсирует и режим, и глубину из кода сохранения.
  2. 1 Уровень 1 — оценивает все внутренние режимы на текущей глубине (n) и на глубине (n+1), когда текущий размер блока на единицу больше, чем min-cu-size. Форсирует режимы для больших блоков.
  3. 2 Уровень 2 - В дополнение к функциональным возможностям уровня 1, ограничивает режимы, которые оцениваются, когда определенные режимы определяются как наилучшие при кодировании сохранения.
  4. 3 Уровень 3. Выполните анализ межмодовых режимов при повторном использовании глубины из сохраненного кода.
    Значение по умолчанию: 0.

Установка значения по умолчанию дает лучшие результаты при установке остальных настроек, как в моих пресетах ниже и установка значений 1, 2, 3 дает лучшие результаты при использовании ключей --rect и --amp.
--cbqpoffs <integer> _ [readthedocs.io]
Перевод документации
Смещение QP цветности Cb от QP яркости, выбранной с помощью управления скоростью. Это общий способ потратить больше или меньше битов на канал цветности. По умолчанию 0
Диапазон значений: от -12 до 12.

При кодировании материала с цветовой субдискретизацией 420 нам понадобится немного снизить уровень сжатия цветности относительно яркости и для этого лучше всего подходит значение -2 (оно подобрано имперически еще со времен 264). При кодировании 422 или 444 лучше еще сильнее снизить это значение ( - 6 или даже - 12), так как в этих режимах кодек по умолчанию повышает этот параметр для компенсации размера файла, исходя из особенностей человеческого зрения (человеческий глаз более восприимчив к изменению яркости, чем цвета). Но сильное увеличение квантазера для цветности может вызвать появление видимых артефактов сжатия.
--crqpoffs <integer> _ [readthedocs.io]
Перевод документации
Смещение QP цветности Cr от QP яркости, выбранной с помощью управления скоростью. Это общий способ потратить больше или меньше битов на канал цветности. По умолчанию 0.
Диапазон значений: от -12 до 12.

Все, как у параметра cbqpoffs, только уже для Cr.
____Теперь немного пройдемся по теории: наша цель состоит в создании кодирования максимально прозрачного (в идеале неотличимого на глаз от исходника) материала, который должен воспроизводиться не только на пк, но также на устройствах с аппаратным декодированием ("железные" плееры). Для этого необходимо хорошо понимать, что бездумное выкручивание и изменение некоторых ключевых параметров кодировщика просто повысит трудность декодирования конечного рипа и зарубит на корню его декодирование на железных плеерах, зачастую при этом не дав никакой прибавки в качестве. Поэтому важно следовать всем известным еще с х264 границам значений для параметров --ref (не более 4 для 1080 и не более 6 для 720), --keyint (240 для 24 или 23.976 fps, универсальные 250 или 300 для видео с 30 fps), а также не стоит изменять значения профилей кодировщика, в 265 они задаются автоматически исходя из указанных параметров кодирования и разрешения видео и напрямую влияют на конечное декодирование на различных устройствах.
Никогда (в случае 264 тоже) у 265 не стоит использовать пресеты (как встроенные в сам кодировщик, так и простое бездумное копирование моих). Для каждого конкретного кодирования (разные фильмы к примеру), настройки подбираются индивидуально и настраиваются также под каждый конкретный исходник. Вы можете использовать пресеты как опору для начала настроек, но они не предназначены для получения хороших результатов сами по себе. Иными словами - вы выбираете пресет, который по вашему мнению, лучше всего подойдёт для вашего исходника и далее начинаете его "крутить" добивались идеального результата. Желательно найти несколько сложных сцен из вашего материала для кодирования, общей продолжительностью 2000 - 4000 кадров и которые максимально отражают то, что представляет из себя ваш исходный материал (много темных сцен - вырезайте и тестируйте на них, много динамики - тестируйте на ней) и сделать несколько тестовых кодирований, а потом в результате их визуального сравнения выбрать лучшее.

Часть 2. Несколько пресетов по кодированию анимации лично от меня + встроенные пресеты
Пресеты кодирования
Все ключи, что не указаны в примерах ниже, остаются со значениями по умолчанию. Такие параметры, как --crf, --bframes, --aq-strength, --deblock и --psy-rdoq, естественно могут быть вами изменены для достижения наилучшего результат кодирования конкретно на вашем исходном материале.
Номер 1: _
Пресет для аниме со стандартным типом исходника - мелкий шумок
--limit-refs 2 --ctu 32 --max-tu-size 16 --hist-scenecut --no-cutree --no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 15 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --qcomp 0.72 --refine-mv 3 --analyze-src-pics --max-merge 5
Номер 2: _
Второй вариант пресета 1, если он дает плохие результаты или размер файла слишком большой
--hist-scenecut --no-cutree --no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 15 --b-pyramid --weightp --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --refine-mv 3 --analyze-src-pics --max-merge 5
Номер 3: _
Пресет для аниме с сильным зерном (как цифровым, так и для исходников, представляющих из себя сканирование кинопленки)
--no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --no-early-skip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --qcomp 0.72 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 16 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 4 --refine-mv 3 --analyze-src-pics --max-merge 5
Тут включено дерево (аналог mbtree из 264 - cutree в 265). Оно очень хорошо детектит именно динамическое крупное зерно и применяет к нему более сильный квантазер, что дает хорошее качество + вменяемый битрейт (10 - 15 мегабит, а не 25 - 30, в варианте без cutree). --qcomp 0.72 призван чуток завысить битрейт, чтобы окончательно нивелировать артефакты от возможного недостатка битрейта в следствии применения cutree + это сглаживает скачки битрейта.
Номер 4: _
Пресет для аниме с цифровым зерном среднего размера, что вызывает повышение среднего битрейта до 16 - 18 мегабит при использовании пресета номер 1 и сильную потерю деталей при занижении crf в нем же
--ctu 32 --rc-lookahead 80 --max-tu-size 16 --no-cutree --open-gop --no-strong-intra-smoothing --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 9 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 4 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 1 --refine-intra 4 --dynamic-refine --tu-inter-depth 1 --me 3 --wpp --subme 7 --crf 14.8 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --refine-mv 3 --analyze-src-pics --qcomp 0.76 --max-merge 5

Встроенные пресеты от разработчиков x265: _
x265 имеет десять --preset параметров, которые позволяют найти компромисс между скоростью кодирования (количество закодированных кадров в секунду) и эффективностью сжатия (качество на бит в битовом потоке). Предустановка по умолчанию — medium. Он позволяет достичь наилучшего возможного качества, не тратя слишком много мощности ЦП на поиск абсолютно самого эффективного способа достижения этого качества. Когда вы используете более быстрые предустановки, кодировщик повышает производительность, жертвуя качеством и эффективностью сжатия. Когда вы используете более медленные предустановки, x265 использует больше вычислений для достижения наилучшего качества при выбранном битрейте (или, в случае использования –crf, самом низком битрейте при выбранном уровне качестве).
  1. 0 ultrafast
  2. 1 superfast
  3. 2 veryfast
  4. 3 faster
  5. 4 fast
  6. 5 medium (default)
  7. 6 slow
  8. 7 slower
  9. 8 veryslow
  10. 9 placebo
    preset
    ctu
    min-cu-size
    bframes
    b-adapt
    rc-lookahead
    lookahead-slices
    scenecut
    ref
    limit-refs
    me
    merange
    subme
    rect
    amp
    limit-modes
    max-merge
    early-skip
    recursion-skip
    fast-intra
    b-intra
    sao
    signhide
    weightp
    weightb
    aq-mode
    cuTree
    rdLevel
    rdoq-level
    tu-intra
    tu-inter
    limit-tu
    0
    32
    16
    3
    0
    5
    8
    0
    1
    0
    dia
    57
    0
    0
    0
    0
    2
    1
    1
    1
    0
    0
    0
    0
    0
    0
    1
    2
    0
    1
    1
    0
    1
    32
    8
    3
    0
    10
    8
    40
    1
    0
    hex
    57
    1
    0
    0
    0
    2
    1
    1
    1
    0
    0
    1
    0
    0
    0
    1
    2
    0
    1
    1
    0
    2
    64
    8
    4
    0
    15
    8
    40
    2
    3
    hex
    57
    1
    0
    0
    0
    2
    1
    1
    1
    0
    1
    1
    1
    0
    2
    1
    2
    0
    1
    1
    0
    3
    64
    8
    4
    0
    15
    8
    40
    2
    3
    hex
    57
    2
    0
    0
    0
    2
    1
    1
    1
    0
    1
    1
    1
    0
    2
    1
    2
    0
    1
    1
    0
    4
    64
    8
    4
    0
    15
    8
    40
    3
    3
    hex
    57
    2
    0
    0
    0
    2
    0
    1
    1
    0
    1
    1
    1
    0
    2
    1
    2
    0
    1
    1
    0
    5
    64
    8
    4
    2
    20
    8
    40
    3
    3
    hex
    57
    2
    0
    0
    0
    2
    1
    1
    0
    0
    1
    1
    1
    0
    2
    1
    3
    0
    1
    1
    0
    6
    64
    8
    4
    2
    25
    4
    40
    4
    3
    star
    57
    3
    1
    0
    1
    3
    0
    1
    0
    0
    1
    1
    1
    0
    2
    1
    4
    2
    1
    1
    0
    7
    64
    8
    8
    2
    40
    1
    40
    5
    1
    star
    57
    4
    1
    1
    1
    4
    0
    1
    0
    1
    1
    1
    1
    1
    2
    1
    6
    2
    3
    3
    4
    8
    64
    8
    8
    2
    40
    1
    40
    5
    0
    star
    57
    4
    1
    1
    0
    5
    0
    1
    0
    1
    1
    1
    1
    1
    2
    1
    6
    2
    3
    3
    0
    9
    64
    8
    8
    2
    60
    1
    40
    5
    0
    star
    92
    5
    1
    1
    0
    5
    0
    0
    0
    1
    1
    1
    1
    1
    2
    1
    6
    2
    4
    4
    0

Часть 3. HDR видео и с чем его едят.
Типы HDR и основные принципы его работы
  1. WCG: Wide Color Gamut — больше цветов.
  2. HDR: обычно под этим подразумевают комбинацию WCG + более широкий диапазон яркости.
  3. HDR10: единый список информации о цвете и яркости для установки верхней и нижней границ.
  4. HDR10+: список метаданных для каждой сцены или кадра, позволяющий достичь динамического изменения этих границ (динамические метаданные).
  5. Dolby Vision: проприетарный формат динамических метаданных.
  6. HLG: обычное цветовое пространство (BT.709) + HDR.
Если по простому, то, что на самом деле позволяет HDR, — это просто отобразить более яркие светлые цвета и более "темные" тени. Отобразить то, что невозможно закодировать существующими форматами видео. Человеческий глаз очень чувствителен к небольшим изменениям в темноте, и традиционный диапазон яркости в 8-битном видео представляет собой лестницу, где каждый уровень света находится на одинаковом расстоянии от предыдущего и последующего.

Для достижения большей плавности нам нужны две вещи: больше бит для хранения информации о цвете (так называемое 10-битное видео) и какая-то математическая модель, которая сможет изменить или подменить стандартную гамма кривую на данные, которые позволят отобразить HDR. Стандартным генератором кривых для UHD-фильмов является SMPTE ST 2084, но есть также HLG, про него будет рассказано чуть позже.
Мы должны получить вот такой результат гамма - кривой:



Что ж, теперь, когда у нас есть 10-битное видео, у нас также есть место для большего количества цветов, верно? Альянс UHD тоже так думал, поэтому они установили стандартные требования к UHD-видео:
  1. Разрешение 3840×2160
  2. Минимум 10 бит
  3. SMPTE ST 2084
  4. Цветовая гамма BT.2020

Поэтому теперь они используют 10-битную или 12-битную глубину цвета и более широкое цветовое пространство (BT.2020) вместо традиционного 8-битного (BT.709), чтобы охватить гораздо больший массив цвета и яркости.
Этот новый стандарт не имеет прямой обратной совместимости, поэтому иногда вы можете встретить устройства, которые воспроизводят то, что должно быть красивой красочной сценой, болезненно приглушенно и практически обесцвеченно. Например, вот 10-битное HDR видео BT.2020 с правильным декодированием (слева) и прямое преобразование в 8-битное (справа):



Теперь более подробно разберем основные типы HDR:
HDR10:
Этот тип HDR позволяет указать небольшой набор информации о цвете и яркости, используемой в видео, чтобы в дальнейшем передать это устройству воспроизведения. При создании HDR видео используется так называемый мастер - дисплей, на котором калибруются и создаются необходимые значения. Параметры этого мастер - дисплея (такие как точка белого и проч. обычно содержаться в метаданных HDR видео для того, что бы конечное устройство воспроизведения могло корректировать эти значения от эталонного (мастер - дисплей) учитывая собственные возможности и калибровку.
Также есть еще два важных параметра:
  1. MaxFALL (Максимальный средний уровень яркости кадра) указывает максимальное значение среднего уровня яркости кадра (в кд/м2 или нитах) для всего видео. MaxFALL вычисляется путем усреднения декодированных значений яркости всех пикселей в кадре. MaxFALL обычно намного ниже, чем MaxCLL.
  2. MaxCLL (Максимальный уровень яркости всего видео) указывает максимальный уровень яркости любого отдельного пикселя (в кд/м2 или нитах) для всего видео. MaxCLL обычно измеряется по конечному контенту после мастеринга. Обычно MaxCLL будет равен пиковой яркости, которую смог достичь мастер - монитор в самом ярком кадре видео.
Если вы извлечете эти элементы метаданных, хранящиеся в сообщениях SEI видео , это будет выглядеть примерно так:
"side_data_list": [
{
"side_data_type": "Mastering display metadata",
"red_x": "35400/50000",
"red_y": "14600/50000",
"green_x": "8500/50000",
"green_y": "39850/50000",
"blue_x": "6550/50000",
"blue_y": "2300/50000",
"white_point_x": "15635/50000",
"white_point_y": "16450/50000",
"min_luminance": "50/10000",
"max_luminance": "40000000/10000"
},
{
"side_data_type": "Content light level metadata",
"max_content": 0,
"max_average": 0
}
]
Такие кодировщики, как x265 (для HEVC/H.265) и rav1e (AV1), могут поддерживать отображение этих параметров мастеринга и будут принимать аргументы в упрощенном формате. Например, они примут MaxFALL как «G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min)».
G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(40000000,50)
HDR10+:
Расширение HDR10, HDR10+, также называемое HDR10 plus, поддерживает эту информацию для каждого кадра или сцены. Видео с поддержкой HDR10+, как правило, также включают статические метаданные HDR10. HDR10+ специально предназначен для 10-битного видео и разрешения до 8K.
Если вы извлечете эти элементы метаданных, хранящиеся в сообщениях SEI видео , это будет выглядеть примерно так:
{
"BezierCurveData": {
"Anchors": [124, 255, 380, 501, 617, 728, 845, 904, 935],
"KneePointX": 194,
"KneePointY": 242
},
"LuminanceParameters": {
"AverageRGB": 354,
"LuminanceDistributions": {
"DistributionIndex": [1, 5, 10, 25, 50, 75, 90, 95, 99],
"DistributionValues": [16, 5312, 98, 123, 315, 551, 707, 805, 4986]
},
"MaxScl": [7056, 5801, 4168]
},
"NumberOfWindows": 1,
"TargetedSystemDisplayMaximumLuminance": 400
}
Кодер HEVC x265 способен принимать такой файл метаданных JSON и применять HDR10+ к видео. Прямо сейчас я не знаю ни одного кодировщика AV1 или H.266/VVC, который мог бы это сделать.
Dolby Vision:
Dolby использует динамический HDR в своем собственном «Dolby Vision», который, в отличие от всех других вариантов, требует лицензионных отчислений. Тем не менее, он поддерживает 12-битное видео для большего диапазона цветов и яркости, чем HDR10+ способен отобразить в настоящее время.
В настоящее время большинство 4K Blu-ray и телевизоров поддерживают либо Dolby Vision, либо HDR10+, однако можно поддерживать и то, и другое в одном видео.
Кроме того, в отличие от всех предыдущих вариантов, невозможно перекодировать видео с Dolby Vision без исходного файла метаданных (RPU). Что это такое и как его получить и тд будет подробно рассказано далее.
Если вы извлечете эти элементы метаданных, хранящиеся в сообщениях SEI видео , это будет выглядеть примерно так:
Parsing RPU file...
{
"dovi_profile": 8,
"header": {
"rpu_nal_prefix": 25,
"rpu_type": 2,
"rpu_format": 18,
"vdr_rpu_profile": 1,
"vdr_rpu_level": 0,
"vdr_seq_info_present_flag": true,
"chroma_resampling_explicit_filter_flag": false,
"coefficient_data_type": 0,
"coefficient_log2_denom": 23,
"vdr_rpu_normalized_idc": 1,
"bl_video_full_range_flag": false,
"bl_bit_depth_minus8": 2,
"el_bit_depth_minus8": 2,
"vdr_bit_depth_minus_8": 4,
"spatial_resampling_filter_flag": false,
"reserved_zero_3bits": 0,
"el_spatial_resampling_filter_flag": false,
"disable_residual_flag": true,
"vdr_dm_metadata_present_flag": true,
"use_prev_vdr_rpu_flag": false,
"prev_vdr_rpu_id": 0,
"vdr_rpu_id": 0,
"mapping_color_space": 0,
"mapping_chroma_format_idc": 0,
"num_pivots_minus_2": [
0,
0,
0
],
"pred_pivot_value": [
[
0,
1023
],
[
0,
1023
],
[
0,
1023
]
],
"nlq_method_idc": null,
"nlq_num_pivots_minus2": null,
"num_x_partitions_minus1": 0,
"num_y_partitions_minus1": 0
},
"vdr_rpu_data": {
"mapping_idc": [
[
0
],
[
0
],
[
0
]
],
"mapping_param_pred_flag": [
[
false
],
[
false
],
[
false
]
],
"num_mapping_param_predictors": [
[
0
],
[
0
],
[
0
]
],
"diff_pred_part_idx_mapping_minus1": [
[
0
],
[
0
],
[
0
]
],
"poly_order_minus1": [
[
0
],
[
0
],
[
0
]
],
"linear_interp_flag": [
[
false
],
[
false
],
[
false
]
],
"pred_linear_interp_value_int": [
[
0
],
[
0
],
[
0
]
],
"pred_linear_interp_value": [
[
0
],
[
0
],
[
0
]
],
"poly_coef_int": [
[
[
0,
1
]
],
[
[
0,
1
]
],
[
[
0,
1
]
]
],
"poly_coef": [
[
[
0,
0
]
],
[
[
0,
0
]
],
[
[
0,
0
]
]
],
"mmr_order_minus1": [
[
0
],
[
0
],
[
0
]
],
"mmr_constant_int": [
[
0
],
[
0
],
[
0
]
],
"mmr_constant": [
[
0
],
[
0
],
[
0
]
],
"mmr_coef_int": [
[
[]
],
[
[]
],
[
[]
]
],
"mmr_coef": [
[
[]
],
[
[]
],
[
[]
]
]
},
"nlq_data": null,
"vdr_dm_data": {
"affected_dm_metadata_id": 0,
"current_dm_metadata_id": 0,
"scene_refresh_flag": 0,
"ycc_to_rgb_coef0": 9574,
"ycc_to_rgb_coef1": 0,
"ycc_to_rgb_coef2": 13802,
"ycc_to_rgb_coef3": 9574,
"ycc_to_rgb_coef4": -1540,
"ycc_to_rgb_coef5": -5348,
"ycc_to_rgb_coef6": 9574,
"ycc_to_rgb_coef7": 17610,
"ycc_to_rgb_coef8": 0,
"ycc_to_rgb_offset0": 16777216,
"ycc_to_rgb_offset1": 134217728,
"ycc_to_rgb_offset2": 134217728,
"rgb_to_lms_coef0": 7222,
"rgb_to_lms_coef1": 8771,
"rgb_to_lms_coef2": 390,
"rgb_to_lms_coef3": 2654,
"rgb_to_lms_coef4": 12430,
"rgb_to_lms_coef5": 1300,
"rgb_to_lms_coef6": 0,
"rgb_to_lms_coef7": 422,
"rgb_to_lms_coef8": 15962,
"signal_eotf": 65535,
"signal_eotf_param0": 0,
"signal_eotf_param1": 0,
"signal_eotf_param2": 0,
"signal_bit_depth": 12,
"signal_color_space": 0,
"signal_chroma_format": 0,
"signal_full_range_flag": 1,
"source_min_pq": 7,
"source_max_pq": 3079,
"source_diagonal": 42,
"num_ext_blocks": 5,
"ext_metadata_blocks": [
{
"Level1": {
"block_info": {
"ext_block_length": 5,
"ext_block_level": 1,
"remaining": [
0,
0,
0,
0
]
},
"min_pq": 0,
"max_pq": 2081,
"avg_pq": 1090
}
},
{
"Level2": {
"block_info": {
"ext_block_length": 11,
"ext_block_level": 2,
"remaining": [
0,
0,
0
]
},
"target_max_pq": 2081,
"trim_slope": 2353,
"trim_offset": 2048,
"trim_power": 2048,
"trim_chroma_weight": 2048,
"trim_saturation_gain": 2048,
"ms_weight": 0
}
},
{
"Level4": {
"block_info": {
"ext_block_length": 3,
"ext_block_level": 4,
"remaining": []
},
"anchor_pq": 1277,
"anchor_power": 393
}
},
{
"Level5": {
"block_info": {
"ext_block_length": 7,
"ext_block_level": 5,
"remaining": [
0,
0,
0,
0
]
},
"active_area_left_offset": 0,
"active_area_right_offset": 0,
"active_area_top_offset": 0,
"active_area_bottom_offset": 0
}
},
{
"Level6": {
"block_info": {
"ext_block_length": 8,
"ext_block_level": 6,
"remaining": []
},
"max_display_mastering_luminance": 1000,
"min_display_mastering_luminance": 1,
"max_content_light_level": 308,
"max_frame_average_light_level": 123
}
}
]
},
"remaining": [
0
],
"rpu_data_crc32": 1135672536
}
HLG:
В постоянно меняющимся мире телевизионного вещания был нужен способ поддержки как 30-летних телевизоров и ресиверов, так и совершенно нового HDR. Поэтому применили немного черной магии (математики) и выяснили, как отправлять сигналы, используя как гамма, так и логарифмические кривые, отсюда и название «Гибридная логарифмическая гамма» (HLG). Старые телевизоры SDR считывают гамма-кривую и воспроизводят правильное (обычное SDR) изображение, в то время как приставки и телевизоры, поддерживающие HLG, будут показывать HDR-видео.
Дополнительная информация по HDR для самостоятельного изучения:
  1. Страница видео с расширенным динамическим диапазоном в Википедии
  2. HDR10+
  3. HLG
  4. BT.2020 и BT.709
  5. Технический документ Dolby Vision
  6. Информационный документ о системе HDR10+
  7. Пиксельные форматы 101
  8. 10-битные и 16-битные видеоформаты YUV (Microsoft Docs)
Продолжение следует...
[Профиль]  [ЛС] 

neko_kun

Стаж: 17 лет 2 месяца

Сообщений: 399

neko_kun · 21-Авг-21 13:08 (спустя 7 часов)

Пресеты! Пресеты гони!!!1111
[Профиль]  [ЛС] 

Koo1

Стаж: 15 лет 8 месяцев

Сообщений: 1143


Koo1 · 21-Авг-21 13:39 (спустя 30 мин., ред. 21-Авг-21 13:39)

Обзор стандартных пресетов, чем плохи, как подредактировать
У х264 пресеты-то в чистом виде использовать нельзя, а тут и подавно бред какой-то
Сравнение с VP9 и AV1
[Профиль]  [ЛС] 

volta_john

Стаж: 14 лет 6 месяцев

Сообщений: 780

volta_john · 21-Авг-21 14:57 (спустя 1 час 18 мин.)

jensen123321
Удачи и успехов в составлении сего мануала.
Почаще напоминай о том, что реальные результаты скорее всего не будут соответствовать ожиданиям, мечтам, обещаниям про "на 50% лучше" и прочим горячим фантазиям на тему чудо кодировщиков и чудо фильтров на всё видео без масок и сценинга.
Печаль только, что, как обычно, читать его будут редко, а следовать ему - ещё реже, ибо либо МНОГАБУКАВ!!!, либо ЯЛУЧШЕЗНАЮ.
Цитата:
81866887Ver 0.1 материал будет дополняться / изменяться / оформляться.
Очень важное примечание. Машинный перевод убийственный просто, да и вычитку с редактурой остального не один раз делать придётся.
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 19-Фев-22 23:54 (спустя 5 месяцев, ред. 19-Фев-22 23:54)

Обновил инструкцию, добавил описание нескольких ключей + пресеты.
[Профиль]  [ЛС] 

Thanatos_DNDZ

Стаж: 14 лет 10 месяцев

Сообщений: 178


Thanatos_DNDZ · 21-Фев-22 11:49 (спустя 1 день 11 часов)

Хотелось бы увидеть разбор параметров в пресетах medium slow veryslow и обозначить те, которые идут по-умолчанию для каждого пресета, что бы понимать как это задумано разработчиками и где увеличивается сложность, на каких параметрах, что-бы уже отталкивать от этого икрутить на свое усмотрение.
Ну и в целом гайд по остальным праметрам обозначить.
[Профиль]  [ЛС] 

DukeNukem2005

Top Loader 04* 1TB

Стаж: 12 лет 11 месяцев

Сообщений: 1552

DukeNukem2005 · 25-Фев-22 19:09 (спустя 4 дня)

У меня вопрос: Есть видео с Битрейт : 217 Кбит/сек, Максимальный битрейт : 1 118 Кбит/сек. Как изменить Битрейт, чтобы было от 320 до 360?
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 11-Май-22 00:08 (спустя 2 месяца 13 дней)

Обновил инструкцию, начал рассказывать о принципах работы и кодировании HDR видео
[Профиль]  [ЛС] 

dio669

Старожил

Стаж: 14 лет 11 месяцев

Сообщений: 1206

dio669 · 30-Июн-22 00:05 (спустя 1 месяц 18 дней)

Небольшое наблюдение --tskip хоть и не указан в Preset Options, но режим Placebo его включает.
[Профиль]  [ЛС] 

Koo1

Стаж: 15 лет 8 месяцев

Сообщений: 1143


Koo1 · 16-Авг-22 03:03 (спустя 1 месяц 16 дней, ред. 16-Авг-22 03:03)

jensen123321 писал(а):
81866887Он также понимает, зачем нужен 10 битный профиль кодирования и не станет использовать его "просто так" при кодировании 8 битных исходников, так как в таком случае он получит только лишний битрейт
Наоборот размер будет меньше, обсуждали в этом разделе уже, меньше на 1-5%, при том не на аниме, а на каком-нибудь бразильском сериале из 80-х. Или это у 265 размер будет больше, а у 264 меньше? Вряд ли.
Где найти ответ, что с пресетами, почему х264 можно легко использовать, а тут так плохо?
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 17-Авг-22 17:51 (спустя 1 день 14 часов, ред. 17-Авг-22 17:51)

Koo1 писал(а):
83505523Наоборот размер будет меньше
Нет, больше битовая глубина - больше битрейт. Это аксиома.
Koo1 писал(а):
83505523Где найти ответ, что с пресетами, почему х264 можно легко использовать, а тут так плохо?
Да не плохо, просто все пресеты ориентированы на сохранение хорошей картинки при низком битрейте. Например, практически везде включено sao и cutree, а также применены довольно высокие значения для других параметров, что зачастую просто бесполезная трата ресурсов и можно сделать совсем по другому и с лучшим качеством. У 264 такая же беда с его пресетами, но там параметров в разы меньше и поэтому контроля за ними так же меньше. Однако это имеет свой минус - у вас довольно мало инструментов для тонкой настройки, а зачастую это требуется.
[Профиль]  [ЛС] 

Koo1

Стаж: 15 лет 8 месяцев

Сообщений: 1143


Koo1 · 18-Авг-22 03:25 (спустя 9 часов)

jensen123321
то есть если пытаться через пресет, с минимумом настроек попроще и универсальнее, то будет хуже х264?
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 18-Авг-22 13:33 (спустя 10 часов)

Koo1
Будет +/- одинаково, а местами чуть хуже по качеству, но меньше по размеру. Sao например, нужно только на сверхнизких, cutree на зерне и лучше всего в связке с rect и tskip + aq3, а во всех пресетах этого нет и rect с tskip отключены по умолчанию. Потому как все заточено на меньший размер относительно 264 любой ценой. Тот же sao - это фильтр, который хорошо убирает артефакты при сверхнизких битрейтах, но он включён практически во всех пресетах и просто будет вызвать потерю мелких деталей изображения там, где это не нужно.
[Профиль]  [ЛС] 

Koo1

Стаж: 15 лет 8 месяцев

Сообщений: 1143


Koo1 · 18-Авг-22 13:41 (спустя 8 мин.)

jensen123321
пресеты, пресетами, но у x264 есть подходящие -tune, непонятно, почему x265 не подвезли
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 18-Авг-22 14:19 (спустя 37 мин.)

Koo1
У него тоже есть.
[Профиль]  [ЛС] 

Koo1

Стаж: 15 лет 8 месяцев

Сообщений: 1143


Koo1 · 18-Авг-22 15:12 (спустя 53 мин.)

jensen123321
ну, самый основной - film, как-то не завезли
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 18-Авг-22 15:53 (спустя 40 мин., ред. 18-Авг-22 15:53)

Koo1
Да эти tune что в 264, что тут больше во вред. Grain например, работает хуже, чем простая связка cutree и rect.
[Профиль]  [ЛС] 

Koo1

Стаж: 15 лет 8 месяцев

Сообщений: 1143


Koo1 · 31-Авг-22 17:02 (спустя 13 дней)

jensen123321
а для видео из реала (в разном виде: старые сериалы на двд или даже vhs, фильмы...) можно пресетов накидать?
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 01-Сен-22 00:00 (спустя 6 часов, ред. 01-Сен-22 00:00)

Koo1 писал(а):
83566764старые сериалы на двд или даже vhs, фильмы
264
Серьезно, 265 не для sd разрешений. Там он будет максимально близок к 264
[Профиль]  [ЛС] 

useroil

Стаж: 14 лет 10 месяцев

Сообщений: 41


useroil · 25-Окт-22 18:51 (спустя 1 месяц 24 дня, ред. 25-Окт-22 18:51)

Пресеты на ffmpeg нужны?
По сравнению с x264 коэффициент сжатия = 0.7 т.е. фильм 1Gb = 700Mb x265
Одна проблема, с этими фильмами (x265) меня в архив шлют, больше не пытаюся здесь кого то осчастливить..
Если что маякните в ЛС
[Профиль]  [ЛС] 

Horо

Moderator senior

Стаж: 15 лет 8 месяцев

Сообщений: 5270

Horо · 25-Окт-22 19:11 (спустя 19 мин.)

useroil писал(а):
83812313Одна проблема, с этими фильмами (x265) меня в архив шлют, больше не пытаюся здесь кого то осчастливить..
правильно делают.
[Профиль]  [ЛС] 

dio669

Старожил

Стаж: 14 лет 11 месяцев

Сообщений: 1206

dio669 · 25-Окт-22 20:15 (спустя 1 час 3 мин.)

Horо писал(а):
83812437правильно делают
А почему, разве x265 хорош только для аниме?
[Профиль]  [ЛС] 

Horо

Moderator senior

Стаж: 15 лет 8 месяцев

Сообщений: 5270

Horо · 25-Окт-22 21:26 (спустя 1 час 11 мин.)

dio669 писал(а):
83812729А почему, разве x265 хорош только для аниме?
Жать полуторачасовой фильм в 1080р в 700 метров — затея изначально говно. Вне зависимости от того, кино это или аниме.
А человек кроме этого еще и бьютифай фильтр накидывает:
Поиск писал(а):
Доп. информация: Видео было очищено и отшлифовано
[Профиль]  [ЛС] 

dio669

Старожил

Стаж: 14 лет 11 месяцев

Сообщений: 1206

dio669 · 25-Окт-22 23:01 (спустя 1 час 34 мин., ред. 25-Окт-22 23:01)

Порекомендуйте оптимальные настройки x265 для кино/клипов 720p/1080p, очищенных от шумов. Апскейлю топазом некоторые старые двд. Так как нравится абсолютно гладкая картинка, пример, возможно подойдут пресеты для аниме? Я накрутил как мне показалось максимум что можно выжать, но по времени кодировалось неделю.)) Материала не так много, не горит, но хотелось бы побыстрее и качество не терять.
Вот такой ужас я ставил:
скрытый текст
--crf 15 --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1 --ctu 64 --min-cu-size 8 --bframes 16 --b-adapt 2 --rc-lookahead 250 --lookahead-slices 1 --scenecut 40 --allow-non-conformance --ref 16 --limit-refs 0 --me star --merange 92 --subme 7 --rect --amp --no-limit-modes --max-merge 5 --no-early-skip --rskip 0 --no-fast-intra --b-intra --sao --signhide --weightp --weightb --aq-mode 4 --cutree --rd 6 --rdoq-level 2 --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 0 --tskip --psy-rd 0.4 --aq-strength 0.4 --deblock 1:1
[Профиль]  [ЛС] 

useroil

Стаж: 14 лет 10 месяцев

Сообщений: 41


useroil · 25-Окт-22 23:07 (спустя 6 мин., ред. 25-Окт-22 23:07)

Фраза из моего релиза "Очищено и отшлифовано"
Хоть качество фильма было на высоте но, малый размер предполагает скрытую манипуляцию с качеством изображения у большинства пользователей трекера.
Но я не унываю и жду VVC, сейчас пока опыты с VVC, там 1000Gb(x264)>=700Mb(x265)>=350Mb(x266), VVC доступен только на Линуксе...
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 26-Окт-22 14:16 (спустя 15 часов, ред. 26-Окт-22 14:16)

useroil
Нет такого понятия, как коэффициент сжатия применительно к сравнению разных кодеков.
Вы можете устанавливать его любой на любом кодеке. Вопрос только в качестве конечной картинки. И не удивляйтесь, что при использовании деструктивных фильтров и настроек кодирования, ваши раздачи закрывают.
[Профиль]  [ЛС] 

useroil

Стаж: 14 лет 10 месяцев

Сообщений: 41


useroil · 27-Окт-22 10:54 (спустя 20 часов)

У меня -preset p7 максимальный для ffmpeg, на качество ставил.
[Профиль]  [ЛС] 

shrajk1

Стаж: 13 лет 5 месяцев

Сообщений: 8


shrajk1 · 04-Дек-22 11:46 (спустя 1 месяц 8 дней)

здравствуйте. Есть видео с глубиной цвета 10bit. Как в x265 оставить эти 10 bit? По умолчанию переводит видео в 8bit
[Профиль]  [ЛС] 

jеnsen

Помощник модератора

Стаж: 14 лет 8 месяцев

Сообщений: 2973

jеnsen · 04-Дек-22 16:45 (спустя 4 часа)

shrajk1
Скачать 10 бит билд и кодировать им.
[Профиль]  [ЛС] 

shrajk1

Стаж: 13 лет 5 месяцев

Сообщений: 8


shrajk1 · 04-Дек-22 16:59 (спустя 14 мин.)

уточню вопрос. Какие команды должны быть.
[Профиль]  [ЛС] 
 
Ответить
Loading...
Error