Кодировщик х264 что это

Как использовать кодеки Nvidia NVENC: HEVC или H264

Выбираем кодек для записи игровых видео с графической картой NVIDIA:

H.264 против HEVC: какой кодек лучше?

Хотя H.264 долго оставался стандартом качества для западных стримеров, сейчас лучшим выбором будет HEVC. Хотя максимальный стандарт качества у них одинаковый, HEVC лучше справляется с предоставленным ему дисковым пространством. Если записать два видео, одинаковых по продолжительности, содержанию и месту на жёстком диске, видео, кодированное в HEVC, будет лучшего качества. При одинаковом качестве записи файлы HEVC всегда меньше, чем видео, записанные в H.264.

Почему же многие пользователи до сих пор предпочитают H.264? Проблема нового формата — в высоких требованиях и совместимости:

Для стримеров, которые не обновляют железо каждый год, но всё же обладают достаточно мощными видеокартами, чтобы играть в ресурсоёмкие игры, H.264 на сегодняшний день будет лучшим выбором.

Сравнение скорости, качества и размера видео H.264 и HEVC

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

Для сравнения использовалось видео продолжительностью в одну минуту, записанное в разрешении 1920×1080 при частоте кадров (FPS) 30 кадров в секунду. Качество записи в обоих случаях было установлено на 80 из 100.

Чтобы использовать кодировщик Nvidia NVENC, выполните следующие шаги:

Как настроить кодек:

Если вы не видите нужные опции кодеков H264 или HEVC в панели выбора кодеков Bandicam, попробуйте следующие решения:

Кодировщики NVENC работают на операционных системах Win 7, 8 и 10. В Windows XP и более старых ОС опции NVENC будут недоступны.

Обратите внимание: не все модели, поддерживающие H264, будут поддерживать новый стандарт HEVC.

Если вы устанавливали или обновляли Bandicam в последние несколько лет, проблем возникнуть не должно: кодировщик NVENC H264 поддерживается с Bandicam 2.0, а обновлённый стандарт NVENC HEVC — с 2.4.0.

Сообщение об ошибке: не удалось инициализировать кодек. Хотите попробовать снова с кодеком H.264 (CPU)?

Если компьютеру не хватает ресурсов или NVENC используется другой программой, вы получите сообщение об ошибке. Чтобы начать запись, закройте все ненужные приложения, чтобы освободить память, и попробуйте ещё раз. Если проблема сохраняется, используйте другой кодек, например, H.264 (CPU). Если вам нужно использовать Bandicam одновременно с другими программами, которые задействуют технологию NVENC (STEAM VR, Shadow Play и т.д.), загрузите программное решение с GitHub.

Источник

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 Мб.

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

Источник

Магия H.264

H.264 — стандарт сжатия видео. И он вездесущ, его используют для сжатия видео в интернете, на Blu-ray, телефонах, камерах наблюдения, дронах, везде. Все сейчас используют H.264.

Нельзя не отметить технологичность H.264. Он появился в результате 30-ти с лишним лет работы с одной единственной целью: уменьшение необходимой пропускной способности канала для передачи качественного видео.

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

Видео в несжатом виде это последовательность двумерных массивов, содержащих информацию о пикселях каждого кадра. Таким образом это трёхмерный (2 пространственных измерения и 1 временной) массив байтов. Каждый пиксель кодируется тремя байтами — один для каждого из трёх основных цветов (красный, зелёный и синий).

1080p @ 60 Hz = 1920x1080x60x3 =>

Этим практически невозможно было бы пользоваться. Blu-ray диск на 50Гб мог бы вмещать всего около 2 мин. видео. С копированием так же будет не легко. Даже у SSD возникнут проблемы с записью из памяти на диск.

Поэтому да, сжатие необходимо.

Обязательно отвечу на этот вопрос. Но сперва я покажу кое-что. Взгляните на главную страницу Apple:

Я сохранил изображение и приведу в пример 2 файла:

Эмм… что? Размеры файлов кажется перепутали.

Нет, с размерами всё в порядке. Видео H.264 с 300 кадрами весит 175 Кб. Один единственный кадр из видео в PNG — 1015 Кб.

Кажется, мы храним в 300 раз больше данных в видео, но получаем файл весом в 5 раз меньше. Получается H.264 эффективнее PNG в 1500 раз.

Как такое возможно, в чём заключается приём?

А приёмов очень много! H.264 использует все приёмы о которых вы догадываетесь (и уйму о которых нет). Давайте пройдёмся по основным.

Избавляемся от лишнего веса.

Представьте, что вы готовите машину к гонкам и вам нужно её ускорить. Что вы сделаете в первую очередь? Вы избавитесь от лишнего веса. Допустим, машина весит одну тонну. Вы начинаете выбрасывать ненужные детали… Заднее кресло? Пфф… выбрасываем. Сабвуфер? Обойдёмся и без музыки. Кондиционер? Не нужен. Коробка передач? В мусо… стойте, она еще пригодится.

Таким образом вы избавитесь от всего, кроме необходимого.

Этот метод отбрасывания ненужных участков называется сжатием данных с потерями. H.264 кодирует с потерями, отбрасывая менее значимые части и сохраняя при этом важные.

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

Важные части? Как алгоритм может определять их важность в кадре?

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

Что же на самом деле делает H.264?

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

Видите как на сжатом изображении исчезли отверстия в решётке динамика у MacBook Pro? Если не приближать, то можно и не заметить. Изображение справа весит всего 7% от исходного и это при том, что сжатия в традиционном смысле не было. Представьте машину весом всего лишь 70 кг!

7%, ого! Как возможно так избавиться от детализации?

Для начала немного математики.

Информационная энтропия

Мы подходим к самому интересному! Если вы посещали теорию информатики, то возможно вспомните про понятие информационной энтропии. Информационная энтропия это количество единиц для представления некоторых данных. Заметьте, что это вовсе не размер самих данных. Это минимальное количество единиц, которое нужно использовать, чтобы представить все элементы данных.

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

Предположим, что монета весьма странная — её подбросили 10 раз и каждый раз выпадал орёл. Как бы вы кому нибудь рассказали об этом? Вряд ли как-то вроде ОООООООООО, вы бы сказали «10 бросков, все орлы» — бум! Вы только что сжали информацию! Легко. Я вас спас от многочасовой утомительной лекции. Это, конечно же, огромное упрощение, но вы преобразовали данные в некое короткое представление с той же информативностью. То есть уменьшили избыточность. Информационная энтропия данных не пострадала — вы только преобразовали представление. Такой способ называется энтропийным кодированием, который подходит для кодирования любого вида данных.

Частотное пространство

Теперь, когда мы разобрались с информационной энтропией, перейдем к преобразованию самих данных. Можно представить данные в фундаментальных системах. Например, если использовать двоичный код, будут 0 и 1. Если же использовать шестнадцатеричную систему, то алфавит будет состоять из 16 символов. Между вышеупомянутыми системами существует взаимно однозначная связь, поэтому можно легко преобразовывать одно в другое. Пока всё понятно? Идём дальше.

А представьте, что можно представить данные, которые изменяются в пространстве или времени, в совершенно иной системе координат. Например, яркость изображения, а вместо системы координат с x и y, возьмём частотную систему. Таким образом, на осях будут частоты freqX и freqY, такое представление называется частотным пространством[Frequency domain representation]. И существует теорема, что любые данные можно без потерь представить в такой системе при достаточно высоких freqX и freqY.

Хорошо, но что такое freqX и freqY?

freqX и freqY всего лишь другой базис в системе координат. Так же как можно перейти из двоичной системы в шестнадцатеричную, можно перейти из X-Y в freqX и freqY. Ниже изображён переход из одной системы в другую.

Мелкая решётка MacBook Pro содержит высокочастотную информацию и находится в области с высокими частотами. Таким образом мелкие детали имеют высокую частоту, а плавные изменения, такие как цвет и яркость низкую. Всё, что между, остаётся между.

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

Пока всё понятно, но зачем это нужно?

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

Ниже знакомый нам ноутбук, но теперь уже с, применёнными к ней, круговыми масками.

В процентах указана информационная энтропия относительно исходного изображения. Если не приближать, то разница не заметна и при 2%! — машина теперь весит 20 кг!

Именно таким образом нужно избавляться от веса. Такой процесс сжатия с потерями называется Квантованием.

Это впечатляет, какие еще приёмы существуют?

Цветовая обработка

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

В телевизорах, цвета RGB преобразуются в YCbCr, где Y это компонента яркости (по сути яркость черно-белого изображения), а Cb и Cr компоненты цвета. RGB и YCbCr эквиваленты в плане информационной энтропии.

Зачем же тогда усложнять? RGB разве не достаточно?

Во времена чёрно-белых телевизоров, была только компонента Y. А с началом появления цветных телевизоров у инженеров встала задача о передаче цветного RGB изображения вместе с чёрно-белым. Поэтому вместо двух каналов для передачи, было решено кодировать цвет в компоненты Cb и Cr и передавать их вместе с Y, а цветные телевизоры уже сами будут преобразовывать компоненты цвета и яркости в привычный им RGB.

Но вот в чём хитрость: компонента яркости кодируется в полном разрешении, а компоненты цвета лишь в четверть. И этим можно пренебречь, т.к. глаз/мозг плохо различает оттенки. Таким образом можно уменьшить размер изображения в половину и с минимальными отличиями. В 2 раза! Машина будет весить 10 кг!

Данная технология кодирования изображения со снижением цветового разрешения называется цветовой субдискретизацией. Она используется повсеместно уже давно и относится не только к H.264.

Это самые значительные технологии в уменьшении размера при сжатии с потерями. Нам удалось избавиться от большинства детализации и сократить информацию о цвете в 2 раза.

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

Компенсация движения

H.264 стандарт, который позволяет компенсировать движения.

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

Но зачем? Большая часть изображения одинакова. Поле, сетка, зрители не меняются, единственное что движется это мячик. Что если определить единственное изображение фона и одно изображение мячика, движущегося по нему. Не сэкономило бы это значительно места? Вы видите к чему я клоню, не так ли? Компенсация движения?

И это именно то, что H.264 делает. H.264 разбивает изображение на макроблоки, обычно 16х16, которые используются для расчёта движения. Один кадр остаётся статичным, обычно его называют I-кадр [Intra frame], и содержит всё. Последующие кадры могут быть либо P-кадры [predicted], либо B-кадры [bi-directionally predicted]. В P-кадрах вектор движения кодируется для каждого макроблока на основе предыдущих кадров, таким образом декодер должен использовать предыдущие кадры, взяв последний из I-кадров видео и постепенно добавляя изменения последующих кадров пока не дойдёт до текущего.

Ещё интереснее обстоят дела с B-кадрами, в которых расчёт производится в обоих направлениях, на основании кадров идущих до и после них. Теперь вы понимаете почему видео в начале статьи весит так мало, это всего лишь 3 I-кадра, в которых мечутся макроблоки.

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

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

Выглядит впечатляюще. Теперь что?

Теперь мы подведём черту, используя традиционное энтропийное кодирование без потерь. Почему нет?

Энтропийное кодирование

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

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

Вот теперь всё! В основе H.264 лежат вышеупомянутые технологии. В этом и заключаются приёмы стандарта.

Отлично! Но меня разбирает любопытство узнать, сколько же весит теперь наша машина.

Исходное видео было снято в нестандартном разрешении 1232×1154. Если посчитать, то получится:

5 сек. @ 60 fps = 1232x1154x60x3x5 => 1.2 Гб
Сжатое видео => 175 Кб

Если соотнести результат с оговорённой массой машины в одну тонну, то получится вес равный 0.14 кг. 140 граммов!

Конечно же я в очень упрощённом виде изложил результат десятилетних исследований в этой сфере. Если захотите узнать больше, то страница в википедии вполне познавательна.

Источник

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 кадров.

Источник