Кодировщик x264 что это

x264 или как кодировать видео

Проблема с кодированием видео и его сжатием его из гигабайтов в мегабайты, по-моему, всегда была актуальной. Если более менее профессиональные операторы, монтажники и т.д. уже не одну кошку съели на этой теме, то например любители и те, кто записывают видео с экрана своего монитора, порой долго чешут затылок, прежде чем добиться каких либо серьезных результатов. В итоге куча потерянного времени, никому не нужные гигабайты исходящего трафика для загрузки домашнего видео на ютуб. Конечно, можно использовать в какой-то степени готовые решения в лице одной программы, и сжать видео буквально тремя кликами, но это не наш подход, когда абсолютно все шаги можно контролировать и влиять на них. Покопавшись в поиске, Хабр так и не выдал ничего похожего. Хотя возможно, что просто плохо поискал.

Сразу оговорюсь, что изначально статья не моя. Я наткнулся на неё, лет пять назад, когда встала задача что-то делать с записанными моментами из тогда любимой многими игры Battlefield 2, на популярном отечественном ресурсе мувимейкеров. Постепенно статья допиливалась и публиковалась, то там, то там. Не исключаю, что первоначально статья пришла из-за «бугра» и всего на всего была переведена на наш могучий язык.

Итак, кодек х264 пришел на смену таким монстрам своего времени как DivX и XviD и удачно положил обоих на лопатки. Для того, что бы добиться действительно впечатляющего результата, нам понадобится следующие вещи:
1. MeGUI — этим мы сжимаем само видео. Вернее, сжимает сам кодек, а это только GUI объединивший в себе десятки разных специализированных утилит.
2. Avisynth — фреймсервер. Если вдруг кто не знает, что это такое, то он является посредником между нашим не сжатым видео и кодеком.
3. VLC media player — Тут совсем все просто. Всеядный плеер, умеющий работать с потоковым видео. Достаточно популярный.
4. K-Lite Codec Pack — пакет все возможных кодеков, на все случаи жизни. Нам нужна сборка Mega.

Настоятельно рекомендую обновлять K-Lite Codec Pack, как минимум всегда перед сжатием видео. Это конечно не обязательно, но опыт подсказывает, что если вы столкнетесь с непонятными ошибками/косяками/глюками/etc то в 50%, а то и больше, обновление кодеков избавит вас от лишнего геморроя.
Кстати, MeGUI достаточно быстро и часто обновляется и дополняется. Скриншоты приведенные ниже, могут уже не соответствовать текущей версии, но это не страшно. Как правило, меняется расположение элементов, что то пододвинули вправо, что-то перенесли в другую закладку. Пропажа находится очень быстро, поэтому не пугайтесь.

Поехали. Устанавливаем Avisynth, а затем MeGUI. После того, как MeGUI обновится, идем в папку, где лежит наш опытный образец, и для удобства создаем там файл с расширением *.avs. Открываем блокнотом и пишем заветные строки:

Первая строка, подскажет MeGUI с каким файлом требуется работать. Вторая строка, указывает на используемую систему цветов.

Существует несколько различных способов представление цвета. Например: цветовое пространство YUV и RGB. В YUV цветовом пространстве есть один компонент, который представляет яркость (сигнал яркости) и два других компонента, которые представляют цвет (сигнал цветности). В то время как яркость передается со всеми деталями, некоторые детали в компонентах сигнала цветности могут быть удалены путем понижения разрешения отсчетов (фильтрация или усреднение), что может быть сделано несколькими способами (т.е. есть много форматов для сохранения изображения в цветовом пространстве YUV). YV12 — один из таких форматов (тут сигнал цветности общий для каждого блока пиксел 2×2), который поддерживается AviSynth.

У нас получился скрипт. Идем дальше. Открываем MeGUI и указываем месторасположение скрипта. Если скрипт AviSynth находится в той же папке где и ваше видео, то вторая строка заполнится автоматически.

Открываем настройки кодека, нажатием на кнопку Config, справа от Encoder settings. Ставим галочку, подтверждая, что нам действительно нужны расширенные настройки. Дальше нам остается поставить галочки в соответствии со скриншотами.

Нажимаем на кнопку queue и идем спать, пить кофе и т.д. в зависимости от предпочтений и мощностей ПК.

Хочу оговориться, что данный конфиг подходит для исходного видео 720p. Для 1080p нужно немного под редактировать конфиг:

Так же можно указать, сколько кодеру можно использовать ядер:

Что мы получаем в итоге. Я имел в наличии следующий видео-ролик:

Format: RGB
Codec ID: 0x00000000
Codec ID/Info: Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Duration: 3mn 42s
Bit rate: 663 Mbps
Width: 1 280 pixels
Height: 720 pixels
Display aspect ratio: 16:9
Frame rate: 29.970 fps
Bit depth: 8 bits
Bits/(Pixel*Frame): 24.000
Stream size: 17.2 GiB (100%)

После ожидания около 15-16 минут, я получил на выходе 184 Мб.

Если Хабру интересны подобные статьи на тематику сжатия видео, то я продолжу и поделюсь своим опытом. Если хотите меня поправить и указать на ошибку, то с радостью отвечу на всю критику и замечания.

Источник

OBS Studio. Настройка X264, ключи кодирования

Внимание — это предварительный обзор, для проверки всех функций требуется время, если вы нашли ошибку или недочёт в тексте не спешите писать гневные комментарии, а сообщите автору сайта о найденной ошибке через комментарии либо выделите слово и нажмите Ctrl + Enter

Ключи кодирования для OBS Studio пишутся в «Настройки» вкладка «Вывод», кодировщик «x264» поле «Настройки x264 (разделённые пробелом)», либо «H.264/AVC Nvidia NVENC» поле «FFmpeg».

Presets

profile

(Force the limits of an H.264 profile)

Учитывайте особенности имеющегося оборудования, отметить степень совместимости. Со значениями High и ниже способны работать мощные модели процессоров.

preset

(Use a preset to select encoding settings)

(Tune the settings for a particular type of source or situation)

Настройка параметров, оптимизирующих работу с конкретным видео образцом.

slow-firstpass

(Enable slow first pass)

Параметр включает «медленный» первый проход.

Frame-type options

I, keyint

(Maximum GOP size)

i, min-keyint

(Minimum GOP size)

Минимальный интервал между ключевыми/IDR кадрами.

no-scenecut

(Disable adaptive I-frame decision)

Полное отключение адаптивных I-кадров.

scenecut

(How aggressively to insert extra I-frames)

Данный параметр позволяет определять частоту использования дополнительных I кадров. Х264 создает для всех кадров метрику для определения того, как кадр отличается от впереди стоящего. Когда выведенное значение ниже установленного для scenecut, то I кадр располагается энкодером в данном месте. Если значение превышает установленное для scenecut, в этом месте располагается ключевой кадр. Данная функция отражается на качестве, увеличивая его в лучшую сторону, но при злоупотреблении сменой неминуема трата битрейта.

intra-refresh

(Use Periodic Intra Refresh instead of IDR frames)

Не допускается применение IDR кадров. Проверено

b, bframes

(Number of B-frames between I and P)

Опция определяет количество B кадров, расположенных между кадрами I и P. Эти кадры включают в себя закодированные изменения впереди и следом идущих за ними кадров. Обладают большой степенью сжатия, но при этом теряют в качестве. B-кадры идентичны Р-кадрам, однако они могут использовать предсказание движения от последующих кадров, что способствует существенному улучшению степени сжатия.

b-adapt

(Adaptive B-frame decision method)

Данная опция направлена на работу с B кадрами, регулируя их месторасположение и количество (автоматически убирает лишние).

b-bias

(Influences how often B-frames are used)

Данная опция позволяет контролировать количество B кадров, призванных заместить Р кадры.

b-pyramid

(Keep some B-frames as references)

Повышение эффективности применения нескольких B-кадров, из- за их возможности ссылаться на другие кадры, тем самым увеличивая эффективность использования 2-х и более кадров.

open-gop

(Use recovery points to close GOPs)

no-cabac

(Disable CABAC)

r, ref

(Number of reference frames)

Опция определяет количество референсных кадров. Указывает количество предыдущих кадров, готовых к связи с B и P кадрами.

no-deblock

(Disable loop filter)

Отключение фильтра подавления блочности.

f, deblock

(Loop filter parameters)

Сила деблокинга рассчитывается для каждого макроблока, учитывая его квантизер и близко расположенных макроблоков. Задачей Альфы является определение приграничного квадрата, что похоже на порог. Бета позволяет убедится в однородности изображения, что позволяет разграничить детали от блочности. В случае, когда блок является однородным, бета незначительно изменяет силу.

slices

(Number of slices per frame)

Определяем на сколько частей разбивается кадр.

slice-max-size

(Limit the size of each slice in bytes)

Задаем максимальное размер slice в байтах.

slice-max-mbs

(Limit the size of each slice in macroblocks)

Задаем максимальный размер slice в макроблоках.

(Enable interlaced mode (top field first)

(Enable interlaced mode (bottom field first)

constrained-intra

(Enable constrained intra prediction)

Ограниченное временное предсказание. Для base layer необходимо активизировать ограниченное временное предсказание.

pulldown

(Use soft pulldown to change frame rate)

Допустимо применение следующих готовых пресетов: none, 22, 32, 64, double, triple, euro.

fake-interlaced

(Flag stream as interlaced but encode progressive)

frame-packing

(For stereoscopic videos define frame arrangement)

Если у транслируется 3D видео. Информирование о типе видеоряда 3D, которое бывает следующим:

Lookahead

Lookahead повышает точность управления скоростью видеокодера, позволяя кодеру буферизовать указанное количество кадров, оценивать их сложность и распределять биты между этими кадрами соответствующим образом пропорционально их сложности. Обычно это приводит к лучшему качеству, потому что кодер может распределять биты, пропорциональные сложности, по большему количеству кадров. Количество опережающих кадров должно быть не меньше количества B-кадров + 1, чтобы избежать остановки процессора. Для достижения оптимального качества рекомендуется просмотр вперед на 10–20 кадров.

Источник

OBS Studio. Полный гайд по настройкам программы

На данный момент есть две версии OBS:

Для начала работы с OBS скачайте OBS Studio с официального сайта. Скачивание начнется после нажатия на кнопку с Вашей операционной системой. На выбор предоставляется Windows 7, 8, 8.1, 10, mac OS x 10.11+ и Linux. Проверьте название скачиваемого файла и убедитесь, что скачиваете полную версию программы. Установщик должен содержать словосочетание Full-Installer после версии программы. Например, OBS-Studio-22.0.2-Full-Installer.

Главное окно

Открывая OBS, мы видим главное окно, которое состоит из:

Чтобы изменить размер источника, кликните на его название и в превью трансляции появится выделенная красным граница источника. Потяните мышкой за одну из сторон, и вы измените размер.

Кнопки управления источниками и сценами (слева направо):

Основные настройки

Эту инструкцию написал и тщательно проверил для Вас ресурс prostrimer.ru. Перед запуском онлайн трансляции необходимо настроить программу, выбрать сервер, выставить качество, назначить горячие клавиши и т.д. Для этого нажимаем на «Настройки».

Вкладка «Общие»

Вкладка «Общие» отвечает за язык OBS, тему программы (Acri, Dark, Default, Rachni), общие настройки онлайн трансляции и источников. Пропустим детальный разбор каждой опции, заметим только «Автоматически включать запись во время трансляции». Если вы хотите иметь записи трансляций на физическом носителе, то эта опция будет вам полезна (учтите только то, что это добавит дополнительную нагрузку на ЦП).

Вкладка «Вещание»

В этой вкладке вы можете прикрепить свою трансляцию к платформе, на которой будет она проходить.

Настройка «Тип вещания» предлагает два выбора:

Вкладка «Вывод»

Данная вкладка отвечает за настройку кодирования трансляции и локальную запись. Окно настроек поделено на 2 «Режима вывода»:

Расширенный режим вывода предоставляет больше настроек для трансляции и рекомендуется к использованию. С более детальной настройкой качество изображение на вашей трансляции будет выглядеть лучше.

Разберем более детально два режима вывода, начнем с простого.

Простой режим

Теперь рассмотрим расширенный режим.

«Потоковое вещание» содержит основные настройки кодировщика.

Настройки кодировщика NVENC H.264

Настройки кодировщика NEW NVENC H.264

Настройки кодировщика x264

Настройки для кодировщика QuickSync H.264

Следующий по важности параметр трансляции это битрейт. Для меня с настройкой CBR (постоянный битрейт) оптимальным является 5500. Этот параметр зависит от вашего интернет-провайдера, провайдера трансляций и самой игры. Меняйте, наблюдайте за результатом, выставляйте оптимальный для вашей конфигурации. Кодировщики NVENC и QuickSync требуют больший битрейт, чем программный x264, но выставляя слишком высокий битрейт вы можете ухудшить качество трансляции. В интернете есть обширные статьи по настройке битрейта, но так как я использую только Twitch, Youtube, для оптимального битрейта мне хватает указанного выше показателя.

Настройки для кодировщика H264/AVC Encoder (AMD Advanced Media Framework)

«Аудио»

Содержит настройки для отдельных звуковых дорожек если вы используете разные дорожки в микшере.

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

Вкладка «Аудио»

Вкладка для настройки аудио устройства для трансляции. Дополнительно можно настроить функцию включать/выключать микрофон по нажатии и функцию push-to-talk (микрофон работает только пока нажата заданная клавиша). Настройки задержки включения и выключения микрофона определяют задержку перед использованием функции в миллисекундах (ms).

Вкладка «Видео»

Вкладка для настройки разрешения вашей трансляции. По умолчанию соотношение сторон выбрано равное соотношениям сторон для мониторов 16:9 это 1280х720, 1680х1050, 1920х1080 и т.д. Лучше отталкиваться от принятых к стандарту разрешений, если у вас монитор 16:10 или более широкий, ориентируйтесь на стандартные разрешения и старайтесь транслировать в 16:9 иначе зрители будут наблюдать чёрные полосы на трансляции снизу, либо вам придётся пожертвовать и обрезать изображение с боков.

Чтобы не нагружать процессор ещё сильнее, лучше не использовать масштабирование и выставлять одинаковое значение в опциях «Базовое разрешение» и «Выходное разрешение».

Вкладка «Горячие клавиши»

Вкладка настройки горячих клавиш для управления трансляцией, настройка функций включить/отключить звук, включить/выключить звук по нажатии. Можно задать горячие клавиши для запуска, остановки трансляции, начала и остановки записи и т.д.

Вкладка «Расширенные»

Вкладка для дополнительных настроек программы. Если вы плохо разбираетесь в программе, то вас заинтересует параметр «Приоритет процесса», формат имени файла записи и задержка потока. Остальные параметры лучше оставить без изменений, и менять только в том случае, если вы знаете, что они означают и это изменение улучшит качество вашей трансляции.

«Параметры запуска»

Возможные проблемы и решения

Уникальный опыт доступен благодаря ВК группе «OBS Studio | Open Broadcaster».

Источник

Влияние пресетов кодирования x.264 и x.265 на качество видео

Видео-версия этой статьи

Зачем нам кодеки и почему есть разное качество кодирования

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

Для реализации этой идеи внедряются специальные алгоритмы (программы), называемые кодеками, которыми и совершается компрессия данных. Но, к сожалению, компрессия происходит с потерей информации, то есть после декомпрессии видео оно становится менее качественным, появляются разнообразные проблемы среди которых:

Однако распространённые сейчас кодеки способны в очень малый объём данных скомпрессировать видео практически без потерь, но достигается это значительным увеличением требований к производимым расчётам. Иными словами — сжатие происходит очень долго.

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

Однако такой сценарий доступен не всегда. Если требуется передавать поток в режиме реального времени, то скорость кодирования должна быть равна или выше, чем скорость воспроизведения видео. В таком случае гипотетически можно увеличить битрейт и тем самым использовать упрощённые методы сжатия, теряя меньше деталей при компрессии. И это было бы так, если бы современные стриминговые площадки не ограничивали доступный битрейт для видеопотока.

Иными словами — для того чтобы терять меньше качества при стриминге видео неизбежно надо применять более реусурсозатратные алгоритмы сжатия данных.

Какие есть пресеты настроек

И для кодека x.264 и для более современного кодека x.265 есть масса параметров которые влияют на качество кодирования. Десятки опций имеющих возможность переключения множества параметров, которые образуют десятки тысяч комбинаций настроек. И чтобы пользователю не приходилось тратить своё время на подбор оптимальных конфигураций были введены готовые пресеты настроек. И для кодека x.264 и для кодека x.265 этих пресетов 10.

Названия пресетов передают их суть. А если точнее характеризуют скорость кодирования видео. То есть пресет «Ultra Fast» позволяет кодировать видео ультрабыстро, «Slow» — кодировать медленно, а самый «прожорливый» — «Placebo» и вовсе придуман был просто «чтобы было» и чтобы показать, что такое качество тоже возможно, но возможность его реального применения — это скорее самовнушение, чем действительность.

С пресетами разобрались. Теперь надо разбираться с методикой тестирования и критериями и оценками качества.

Методика тестирования

И это сейчас самое важное. В целом — тестов пресетов кодеков и так много, но есть проблемы с методикой, а вернее с тем, что обычные методики не предполагают контроля того насколько сложная сцена. А именно сложность сцены влияет на качество кодирования.

Суть сжатия заключается в выборе опорного кадра и анализе изменений в последующих или соседних кадрах, и если этих изменений мало, то и описание изменений будет занимать мало места, а значит эти описания изменений могут поместится и в малый битрейт без значительного ухудшения качества. А если изменений в соседних кадрах будет много и они будут сложные как по цветам, так и по геометрии, то описать такие изменения будет либо сложно с точки зрения алгоритмов, либо сложно с точки зрения требований по объёму этих записей. Напомню, что мы рассматриваем случай когда в объёме мы ограничены.

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

Задача не тривиальная и, забегая вперёд, оценки будут субъективными, так как оценки я буду ставить… умозрительно, на основе визуальных дефектов. Тем не менее — даже чтобы глазами посмотреть на разницу эту разницу надо как-то сгенерировать и выбрать точные метрики для отслеживания качества.

Оценивать предлагаю по вот этому тестовому кадру:

Нажмите для увеличения

В нём есть довольно много интересных мест, которые будут меняться при сжатии.

Для наглядности вот GIF анимация нескольких этапов ухудшения качества. Естественно и сама GIF анимация использует сжатие, так что она не всецело отражает разницу, но все исходники будут размещены в самом низу статьи, и с ними может ознакомится любой желающий.

Нажмите на изображение чтобы открыть анимацию (2,6 МБ)

Основные отличия можно рассмотреть в чёткости сеток, в чёткости сложной спиральной формы скруглённой сетки, в равномерности и плавности градиентов цветов и цветовых переходов, в качестве градиентов серого цвета, в пиксилезации и замылинности текстур высокой контрастности и текстур низкой контрастности, в чёткости отображения текста.

Показанные выше изображения — это стоп кадры видео. Вы уже можете увидеть, что кроме тестовой сцены присутствую ещё разнообразные геометрические фигуры. Для видео они изменяются каждый кадр, именно они и создают разницу между кадрами, которую, меняя число фигур, можно регулировать. То есть чем больше фигур, тем выше сложность кодирования и тем хуже удаётся кодеку воспроизвести оригинал при ограниченном битрейте.

Видео состоит из 11 градаций изменений сложности кодирования от 0-ой, самой простой сложности, до 10-ой, самой сложной. При переходе на каждую следующую градацию в картинку добавляется 100 дополнительных фигур, таким образом на 0-ой сложности число фигур — 0, а на 10 сложности число фигур — 1000.

Однако говорить о строгой линейности прироста сложности я бы не стал. Фигуры пересекаются друг с другом и трудно судить — становится сложнее кодировать из-за этого или проще при увеличении числа фигур. Тем не менее — приращение энтропии близко к линейному.

Остаётся только учесть последний фактор — а именно то, что нельзя оставлять тестовую часть картинки статичной. При кодировании статические объекты лучше сохраняются неизменными, а мы хотим получить данные не по сохранению статических объектов при кодировании, мы хотим получить проявление дефектов в общем случае.

Поэтому в видео не просто мелькают фигуры, меняясь каждый кадр, но и тестовая сцена для каждого из 11 уровней сложности один раз проезжает в стороны, и в «зачёт» мы берём последний кадр движения.

Итого у нас выходит 20 пресетов кодирования, по 10 на x.264 и x.265, и в каждом из 20 пресетов по 11 результатов тестирования по одному для каждого уровня сложности. То есть в сумме — 220 изображений. Ссылки на оригиналы находится в конце статьи.

Чтобы сжать видео первоначально было получено несжатое видео (55 секунд объёмом примерно в 20 ГБ) в Vegas Pro 15. Само видео я передать не могу в силу его размера, но проект видео в Vegas Pro можно скачать «тут«.

Далее это несжатое видео было сжато в программе MeGUI (скачать можно тут). Программа выполняет скрипт программы AviSynth, которую можно скачать тут. Самый простой скрипт будет если поместить видео и сам скрипт формата *.avs и программу MeGUI в одну папку и скрипт можно создать текстовым редактором (например блокнотом), вписав:

С соответствующими настройками кодирования с постоянным ограниченным битрейтом в 10 Мбит/с.

Результаты

Далее нам надо оценить результаты. И я хочу остановится на сложностях 6 и 10. Сложность 6 отражает довольно высокую нагрузку, реально достижимую в видео. Сложность 10 просто самая большая.

Нам необходимо заполнить таблицу:

Учитывая методику тестирования появляется одна проблема, связанная с объёмом видеофайла более 20 ГБ. С быстрыми кодированиями производительность ограничивалась скоростью чтения с SSD накопителя, а не Intel Core i9 9900k в стоке, на котором проводилось кодирование, поэтому говоря про скорость кодирования, она на «быстрых» пресетах идентичная и время заполнено в таблице ниже:

В виде графика эти данные выглядят так:

Видно, что время требующееся на сжатие — стремительно увеличивается с изменением пресета качества, по вертикали измерения в секундах.

Далее я дал субъективные оценки качества изображения для сложности 6 и сложности 10.

Приоритеты при оценке были следующими:

Если для вас лично приоритеты иные, то сравнительные оценки для вас лично будут другие. Рекомендую самостоятельно провести оценку используя исходные стоп кадры или сэмплы видео с разными пресетами сжатия.

Я дал оценки от 1 (наихудший результат) до 10 (неотличимый от оригинала) с градациями в 0,5 балла. Баллы выше 1 я ставил за удовлетворительный результат, оценку 1 я ставил за неудовлетворительный результат. То есть 1 балл — это не оценка качества, а отсутствие оценки (в сортах …. пиксельной каши не разбираюсь).

Оценки проводились для сложности 6 и 10.

Сложность сцены 6

Для сложности 6 результаты занесены в таблицу:

Эти же данные в виде графиков представлены ниже:

Графики зависимости качество кодирования от пресета настроек кодирования

Стоит отметить, что пресеты для x.264 очень нелинейно прирощают качество. Между качествами Slower и Very Slow кодека x.264 находятся все результаты для x.265 кроме Ultra Fast. При этом до пресета Fast в x.264 я результаты счёл неудовлетворительными. В то время как пресеты Very Slow и Placebo на x.264 оказались лучшими по качеству, чем Very Slow и Placebo на x.265.

Также предлагаю провести расчёт удельного качества в зависимости от потраченного времени. Но предупреждаю, что я хоть и пытался оценивать качество линейно, но в реальности субъективной оценкой линейности не добиться, так что графики представленные ниже имеют примерный характер. Результаты для кодирования выполненного с ограничением в SSD не учитываются.

Чем величина по вертикали больше, тем выше показатель удельного качества. То есть оценивается оправданность временных затрат.

Удельное качество зависимое от времени

С точки зрения математики, при анализе субъективных оценок качества, наиболее выгодным является пресет настроек Medium кодека x.265. То есть пресет позволяет получить приемлемое качество с приемлемыми затратами производительности.

Также видно для x.265, что дальнейший рост времени кодирования плохо компенсирует возрастающее качество.

Для x.264 ситуация иная. Качество приростает примерно с той же «скоростью», что и затрачиваемое на кодирование время (за исключением Placebo).

Сложность сцены 10

Далее оценим аналогичные параметры для максимальной сложности видео.

На максимальной сложности нелинейность качества на x.264 становится ещё выше, и расслоение качества на x.265 так же становится больше. При этом стоит отметить, что для placebo x.265 я поставил оценку 7,5, что ниже, чем Very Slow для x.264.

Удельное качество зависимое от времени кодирования

Полученные изменения привели к тому, что при увеличении сложности самого видео ситуация с x.264 становится лучше, и пресет Slower позволяет добиться хорошего соотношения качества/производительности, но этот пресет всё равно не обходит по этому показателю Medium x.265.

Выводы

В тесте не затронут вопрос производительности в реальном времени, а именно этот параметр важен для стрима, где и применяется софтверное кодирование. В настоящее время для старших процессоров intel на сокете 1151 v.2 с одновременной игрой в саму игру — достижим пресет medium для кодека x.264. Для старших процессоров AMD на сокете AM4 достижим пресет Slow для кодека x.264. В реальных задачах (уровень сложности 6) разница между пресетами есть, и достаточно ли она велика для того чтобы на основе неё делать выбор для стримменогового компьютера — решать только вам. Также стоит сказать, что существенно более высокое качество видео способен обеспечить пресет Slower, но для работы с ним в 1080p 60 FPS в реальном времени процессоров пока нет.

Ещё стоит отметить существенно большую чёткость изображения на средних пресетах x.265 в сравнении с x.264. Изображение полученное с пресетом x.265 Ultra Fast сопоставимо с изображением с пресетом slow x.264.

x.265 Ultra Fast требует существенно меньших затрат ресурсов, но поддержки кодека x.265 популярными стриминговыми сервисами нет.

Гипотетически достижимый сейчас пресет medium x.265 для кодирования в реальном времени и стриминга обеспечивал бы существенно более качественную картинку, чем технически недостижимый сейчас x.264 Slower.

Всё вышеописанное справедливо только для софтверного кодирования которое имеет лучшие характеристики качества/битрейт. При использовании аппаратного ускорения и кодировании в h.264 и h.265, при возможности выбора динамического битрейта и более высоких значений среднего битрейта кодирование видеокартой будет существенно лучше по соотношению качества/производительности, но хуже по соотношению качество/битрейт.

Тем не менее для монтажа видео и его вывода не в масштабах реального времени целесообразно применять аппаратное кодирование.

Для сравнения в архиве с оригиналами сжатых видео находится видео полученное RTX 2070 с динамическим битрейтом и средним битрейтом в 20 Мб/с, с объёмом в 133 МБ, против 93 для Placebo h.264.

Кодирование видео заняло около 24 секунд и для 6-ой сложности получено качество

8 баллов (примерно как x.265 medium и существенно лучше x.264 Slower).

Соотношение качество/производительность. Зелёный треугольник — результат RTX 2070 в сравнении с i9 9900k

Для 10-ой сложности качество при аппаратном кодировании RTX 2070 примерно соответствует x.265 Very Slow.

Соотношение качества/производительность. Зелёный треугольник — результат RTX 2070.

При этом производительность в кодировании/декодировании видео у видеокарт RTX 20** и GTX 16** (за исключением GTX 1650 не Super) — идентичная.

Вышеуказанная разница, естественно, получена с различным битрейтом, исходя из различных задач. Для расчётов процессором исходя из требований битрейта для стримов видеопотока, а для расчётов аппаратным кодированием видеокартой исходя из достаточности качества, то есть для получения качества сравнимого с обычными не стрим видео на Youtube. Пример тестового видео сжатого в VP9 после загрузки видео на Youtube имеется в архиве с видео.

Ссылки для скачивания исходных файлов:

Проект для Vegas Pro для создания не сжатого видео: тут (12 МБ)

Стоп кадры из тестовых видео: тут (502 МБ) (упаковано в архив 7-zip)

Видео зарендеренные с разными пресетами кодеков: тут (1,76 ГБ) (упаковано в архив 7-zip)

Видео на YouTube канале «Этот компьютер»

Источник