аппаратное или программное кодирование

Оптимальные настройки для лучшего качества стрима

Для начала, прежде чем мы перейдём непосредственно к тестированию, поговорим о тестовой платформе.

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

Фото с Techspot.com

На новых видеокартах много внимания было уделено повышению производительности и улучшению совместимости с HEVC, что не особо важно для стриминга. Новый движок архитектуры Turing предполагает 15% улучшение качества видео стандарта H.264, в сравнении с прошлым поколением видеокарт на Pascal (серия GTX 10xx). Мы определённо обратим на это внимание, а заодно посмотрим, как Turing работает с программным кодированием x264. Итак, в тестах мы будем использовать видеокарту RTX 2080, чтобы посмотреть на работу с кодированием Turing, Titan X Pascal для тестов видеокарты на Pascal, и Vega 64, чтобы увидеть, как пойдут дела у AMD.

Фото с Techspot.com

Все тесты проводились на разогнанном до 4.9 GHz Core i7-8700k и 16 ГБ оперативной памяти DDR4-3000. Именно такую платформу мы рекомендуем для игр на максимуме. В будущем мы также планируем разобраться, насколько хорош 9900K в сравнении с процессорами Ryzen от AMD.

Для захвата мы используем последнюю версию OBS, настроенную на запись в 1080p при 60 кадрах в секунду с постоянным битрейтом 6000 кбит/с. Это максимальные настройки качества, рекомендованные Twitch. Если вы собираетесь сделать запись игрового процесса для иных целей, то мы рекомендуем вам поднять битрейт, но для ведения трансляции на Twitch, вам нужно иметь 6 Мб/с или ниже, если ваш канал не подключен к партнёрской программе.

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

На видеокартах от Nvidia мы использовали NVENC в OBS и выбрали “Высокое Качество” при битрейте 6 Мбит/c. Разумеется есть и другие надстройки, но “Высокое Качество” выдаёт, как вы могли догадаться, самое высокое качество. На видеокартах Vega 64 от AMD мы опробовали множество разных настроек (как качества в целом, так и битрейта), но без особых успехов, как вы сами вскоре увидите.

Фото с Techspot.com

Фото с Techspot.com

Фото с Techspot.com

С тем, что энкодер от AMD “отвалился” еще в самом начале, давайте рассмотрим противостояние NVENC от Nvidia с процессорным программным кодингом x264. В более медленном тесте производительности Assassin’s Creed Odyssey, NVENC даже на “Высоком Качестве” заметно хуже, чем x264 с надстройками “Veryfast”, особенно при сравнении мелких деталей, хотя в обоих случаях используется битрейт 6 Мб/с. Veryfast x264 не идеален, но на фоне NVENC видеокарт Turing с огромным количеством макроблокинга и нечёткими деталями, он выглядит явным лидером.

Фото с Techspot.com

В более быстром тесте производительности Forza Horizon 4, NVENC видеокарт Turing местами уделывает надстройку veryfast x264. Вариант от Nvidia всё ещё страдает от макроблокинга, но у veryfast огромные проблемы с качеством деталей в движении. В игре с таким количеством движения, NVENC по качеству надстройки примерно равен “faster” x264. Тем не менее, надстройка “fast” x264 работает с движущимися объектами намного лучше, чем NVENC и даже полностью уделывает её, в случаях, когда движение на экране минимально, либо отсутствует вовсе.

Фото с Techspot.com

Фото с Techspot.com

Эти две надстройки лучше оставить для тех случаев, когда качество не особо важно, поскольку при битрейте 6 Мбит/с изображение получается весьма посредственным.

Фото с Techspot.com

Фото с Techspot.com

Для быстрого движения в Forza Horizon 4, опять же, стоит сразу забыть о veryfast, поскольку в случае с подобными играми он даже хуже NVENC. К сожалению, из-за битрейта в 6 Мбит/с, любая надстройка будет далека от оригинального материала, но medium визуально будет к нему ближе всего, да и смотрится намного лучше, чем с fast.

Производительность

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

Включив NVENC на картах Pascal или Turing, вы потеряете примерно 10-20% кадров в секунду, в зависимости от игры. Другими словами, между трансляцией с NVENC и выключенным стримом, разница в производительности будет 10-20%. Однако, чем больше игра зависит от видеокарты, тем сильнее NVENC ударит по производительности. Вот почему Forza Horizon 4 теряет больше кадров, чем зависимая от процессора Assassin’s Creed Odyssey.

Но есть и хорошие новости! Пусть вы и будете играть на чуть более низких кадрах в секунду при использовании NVENC, на трансляции будет идеальная картинка без падения кадров, даже если игра грузит видеокарту на 100%. Кодирующий движок карт AMD не так сильно влияет на производительность игры, но в случае высокой загрузки видеокарты происходит падение числа кадров в секунду примерно на 90%, что, как мы упоминали ранее, делает его бесполезным.

Производительность в режиме программного кодирования зависит от конкретной игры. В случае с требовательной как к процессору, так и к видеокарте Assassin’s Creed Odyssey, использование программного кодирования процессора для ведения трансляции может негативно сказаться на частоте кадров, да и надстройки, обеспечивающие высокое качество, могут не справляться.

Во второй части исследования будет интересно разобраться в том, как покажут себя другие процессоры. Но в этой части 8700K, популярный игровой процессор высокого уровня, показал примерную ситуацию с трансляцией игры, которая крайне требовательна к процессору и видеокарте. Тем не менее, процессоры похуже, особенно малоядерные от Intel, в основном будут нормально работать на надстройке veryfast.

Надстройка veryfast x264 снизила производительность всего на 6% (если верить минимальным кадрам в секунду), но разница между veryfast и fast равнялась всего 5%, несмотря на то, что для кодирования видео на надстройке fast требовалось значительно больше мощностей процессора.

На самой трансляции мы не увидели падения числа кадров на надстройках veryfast и faster, но уже на fast можно было заметить снижение числа кадров трансляции примерно на 12%. Из-за этого она периодически шла рывками. Учитывая, что игра работала на 120 кадрах в секунду, можно запросто поставить ограничение в 60 кадров, тем самым снизив нагрузку на процессор. С подобным ограничением, надстройка fast в итоге работает уже без падения числа кадров трансляции. Кроме того, это ограничение дает нам возможность опробовать medium, но даже с нашим процессором 8700K, наблюдалось падение числа кадров примерно на 2%, что не годится. Если мы бы планировали и дальше работать с надстройкой medium, то пришлось бы немного покопаться в настройках графики, чтобы ещё сильнее снизить нагрузку на процессор.

Предварительные итоги

По итогам тестирования, можно сделать несколько интересных выводов. Мы узнали, что кодирующий движок видеокарт Turing в H.264 стал не особо лучше (хотя было заявлено обратное), в сравнении с Pascal, а кодирование при помощи видеокарты всё ещё не стоит рассматривать, как вариант для стримов.

Фото с Techspot.com

Стримерам стоит использовать, как минимум, надстройку fast, так как это первая с конца надстройка, выдающая достаточно неплохое качество при битрейте 6 Мбит/с. Пусть она и не идеальна для быстрых сцен, эта надстройка работает в разы лучше, чем faster и veryfast, при этом оставаясь более-менее доступной для средних систем. Если у вас очень мощное железо, то можно попробовать и medium, а вот более медленные надстройки лучше даже не трогать.

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

Источник

Статьи

«Железо» или «софт»: что выбрать для живых трансляций?

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

В чём разница?

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

Программы для трансляции

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

Особенности

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

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

Чем выше качество и уровень обработки картинки в реальном времени, тем больше потребуется вычислительных мощностей. Это означает, что для нормальной трансляции обработанного видеопотока с высоким разрешением вам понадобится компьютер с мощным процессором и первоклассной графической картой. То есть, ваша программа трансляции может быть теоретически способна выдавать 4K видео на 60 кадрах в секунду и потоком 50 Мбит/с, но ваш компьютер, возможно, не сможет это обеспечить. Использования компьютера с недостаточной производительностью: а) заметно замедлить его работу и даже может привести к его сбою, и б) вызовет такие проблемы, как потеря кадров, «дёрганье», или буферизация на стороне зрителя.

Интерфейс пользователя Open Broadcast Software (OBS) на компьютере Mac

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

Требования и совместимость

Существует ещё кое-что, что следует учитывать при выборе программ для потокового вещания. Во-первых, в этом случае вы в значительной степени полагаетесь на свой компьютер, который может зависнуть, выдать «синий экран», внезапно начать устанавливать обновления и т. д. Особенно это касается компьютеров на ОС Windows.

Более того, не все потоковое программное обеспечение совместимо со всеми операционными системами. Например, такие программы как vMix, VIDBlaster и XSplit, несовместимо с Mac OS. Так что прежде чем инвестировать в программное обеспечение, обязательно проверьте его совместимость с ОС вашего компьютера.

И ещё одна вещь, о которой следует помнить – вам придётся использовать внешние источники видео и аудио. А обычные компьютеры не имеют возможности захватывать любые видеосигналы (например HDMI и SDI со звуковым каналом). И в этом случае вам потребуется приобрести ещё и внешние или внутренние карты захвата (они же фрейм-граберы), которые ещё больше увеличат стоимость всего комплекта. Для этих целей рекомендуем вам линейку карт захвата компании Epiphan Video.

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

Специализированное оборудование для живой трансляции.

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

Особенности

Поскольку устройства для потоковой трансляции – это, в принципе, тоже программное обеспечение, но уже установленное в специально разработанное «железо», то аппаратные энкодеры могут делать практически все то же самое, что и их программные «собратья» (см. Список функций программного обеспечения выше). Например, веб-интерфейс устройств семейства Epiphan Pearl позволяет создавать различные макеты, переключаться между ними, добавлять заголовки и многое другое. Но при этом появляются дополнительные факторы надежности, универсальности и простоты использования.

Потоковые аппаратные устройства, такие как «все-в-одном» типа Epiphan Pearl Nano или Pearl Mini, оснащены SDI, HDMI и USB-портами для захвата видео. Это означает, что им не нужны никакие дополнительные карты захвата для работы, что делает их более удобными в этом смысле.

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

Требования и совместимость

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

Всем этим устройствам требуется лишь электропитание и подключение к Интернету (через Ethernet или Wi-Fi-соединение). Вопрос о совместимости не стоит вообще, поскольку они работают независимо от компьютеров и их операционных систем.

Аппаратное или программное решения: что выбрать?

Цена (если у вас уже есть мощный компьютер)Для хорошего результата нужен мощный компьютер

Неидеальная надёжность (возможность сбоя компьютера)

Много дополнительных затрат (компьютер, компоненты, карты захвата)

Множество настроек, которые нужно осваивать, придётся серьёзно изучать программу.Аппаратный
вариантБóльшая надежность

Меньше проблем с установками и подключениямиДостаточно большое, пусть и одноразовое, вложение денег

Ограниченные возможности по оформлению

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

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

Если же вы ищете что-то, что способно само организовать вам живую трансляцию без лишней головной боли, «прямо из коробки», то выбирайте аппаратный вариант, отвечающий вашим задачам:

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

Источник

Как работает видеокодек. Часть 2. Что, для чего, как

Первая часть: Основы работы с видео и изображениями

Что? Видеокодек — это часть программного/аппаратного обеспечения, сжимающая и/или распаковывающая цифровое видео.

Для чего? Невзирая на определённые ограничения как по пропускной способности так
и по количеству места для хранения данных, рынок требует всё более качественного видео. Припоминаете, как в прошлом посте мы подсчитали необходимый минимум для 30 кадров в секунду, 24 бита на пиксель, с разрешение 480×240? Получили 82,944 Мбит/с без сжатия. Сжатие — это пока единственный способ вообще передавать HD/FullHD/4K на телевизионные экраны и в Интернет. Как это достигается? Сейчас кратко рассмотрим основные методы.

Перевод сделан при поддержке компании EDISON Software.

Кодек vs Контейнер

Распространенная ошибка новичков — путать кодек цифрового видео и контейнер цифрового видео. Контейнер это некий формат. Обёртка, содержащая метаданные видео (и, возможно, аудио). Сжатое видео можно рассматривать как полезную нагрузку контейнера.

Обычно расширение видеофайла указывает на разновидность контейнера. Например, файл video.mp4, вероятно всего, является контейнером MPEG-4 Part 14, а файл с именем video.mkv — это, скорее всего, матрёшка. Чтобы быть полностью уверенным в кодеке и формате контейнера, можно воспользоваться FFmpeg или MediaInfo.

Немного истории

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

Видеокодек H.261 появился в 1990 году (технически — в 1988) и был создан для работы со скоростью передачи данных 64 Кбит/с. В нём уже использовались такие идеи, как цветовая субдискретизация, макроблоки и т.п. В 1995 году был опубликован стандарт видеокодека H.263, который развивался до 2001 года.

В 2003 году была завершена первая версия H.264/AVC. В том же году компания «TrueMotion» выпустила свой бесплатный видеокодек, сжимающий видео с потерями под названием VP3. В 2008 году Google купил эту компанию, выпустив VP8 в том же году. В декабре 2012 года Google выпустил VP9, ​​и он поддерживается примерно на ¾ рынка браузеров (включая мобильные устройства).

AV1 — это новый бесплатный видеокодек с открытым исходным кодом, разработанный Альянсом за открытые медиа (AOMedia), в состав которого входят известнейшие компании, как-то: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel и Cisco. Первая версия кодека 0.1.0 была опубликована 7 апреля 2016 года.

Рождение AV1

В начале 2015 года Google работал над VP10, Xiph (который принадлежит Mozilla) работал над Daala, а Cisco сделала свой бесплатный видеокодек под названием Thor.

Затем MPEG LA сначала объявила годовые лимиты для HEVC (H.265) и плату, в 8 раз выше, чем за H.264, но вскоре они снова изменили правила:

без годового лимита,
плата за контент (0,5% от выручки) и
плата за единицу продукции примерно в 10 раз выше, чем за H.264.

Альянс за открытые медиа был создан компаниями из разных сфер: производителями оборудования (Intel, AMD, ARM, Nvidia, Cisco), поставщиками контента (Google, Netflix, Amazon), создателями браузеров (Google, Mozilla) и другими.

У компаний была общая цель — видеокодек без лицензионных отчислений. Затем появляется AV1 с гораздо более простой патентной лицензией. Тимоти Б. Терриберри сделал сногсшибательную презентацию, ставшей источником текущей концепции AV1 и её модели лицензии.

Вы будете удивлены, узнав, что можно анализировать кодек AV1 через браузер (заинтересовавшиеся могут перейти по адресу aomanalyzer.org).

Универсальный кодек

Разберём основные механизмы, лежащие в основе универсального видеокодека. Большинство из этих концепций полезны и используются в современных кодеках, таких как VP9, AV1 и HEVC. Предупреждаю, что многие объясняемые вещи будут упрощены. Иногда будут использоваться реальные примеры (как в случае с H.264) для демонстрации технологий.

1-й шаг — разбиение изображения

Первым шагом является разделение кадра на несколько разделов, подразделов и далее.

Для чего? Есть множество причин. Когда дробим картинку, можно точнее прогнозировать вектор движения, используя небольшие разделы для маленьких движущихся частей. В то время как для статического фона можно ограничиться и более крупными разделами.

Обычно кодеки организуют эти разделы в секции (или фрагменты), макроблоки (или блоки дерева кодирования) и множество подразделов. Максимальный размер этих разделов варьируется, HEVC устанавливает 64×64, в то время как AVC использует 16×16, а подразделы могут дробиться до размеров 4×4.

Припоминаете разновидности кадров из прошлой статьи?! Это же можно применить и к блокам, так что, у нас могут быть I-фрагмент, B-блок, P-макроблок и т.п.

Для желающих попрактиковаться — посмотрите как изображение разобъётся на разделы и подразделы. Для этого можно воспользоваться уже упоминаемой в прошлой статье Intel Video Pro Analyzer (тот, что платный, но с бесплатный пробной версией, имеющей ограничение на первые 10 кадров). Здесь проанализированы разделы VP9:

2-й шаг — прогнозирование

Как только у нас появились разделы, мы можем составлять астрологические прогнозы по ним. Для INTER-прогнозирования необходимо передать векторы движения и остаток, а для INTRA-прогнозирования передаётся направление прогноза и остаток.

3-й шаг — преобразование

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

Хотя есть и другие методы, рассмотрим более подробно дискретное косинусное преобразование (DCT — от discrete cosine transform). Основные функции DCT:

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

Давайте возьмем такой блок пикселей 8×8:

Этот блок рендерится в следующее изображение 8 на 8 пискелей:

Применим DCT к этому блоку пикселей и получаем блок коэффициентов размером 8×8:

И если отрендерим этот блок коэффициентов, получим такое изображение:

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

У этого блока коэффициентов есть интересное свойство: он отделяет высокочастотные компоненты от низкочастотных.

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

Частота означает, насколько быстро меняется сигнал.

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

Сначала конвертируем его в частотную область.

Далее отбрасываем часть (67%) коэффициентов, в основном нижнюю правую часть.

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

Видим, что оно напоминает исходное изображение, но есть много отличий от оригинала. Мы выбросили 67,1875% и все же получили что-то, напоминающее первоисточник. Можно было более продуманно отбросить коэффициенты, чтобы получить изображение ещё лучшего качества, но это уже следующая тема.

Каждый коэффициент формируется с использованием всех пикселей

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

Вы также можете попытаться визуализировать DCT, взглянув на простое формирование изображения на его основе. Например, вот символ A, формируемый с использованием каждого веса коэффициента:

4-й шаг — квантование

После того как на предыдущем шаге выбрасываем некоторые коэффициенты, на последнем шаге (преобразование), производим особую форму квантования. На этом этапе допустимо терять информацию. Или, проще говоря, будем квантовать коэффициенты для достижения сжатия.

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

Можем ли обратить этот блок коэффициентов? Да, можем, умножив на то же значение, на которые делили.

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

5 шаг — энтропийное кодирование

После того, как мы квантовали данные (блоки изображений, фрагменты, кадры), все еще можем сжимать их без потерь. Существует много алгоритмических способов сжатия данных. Мы собираемся кратко познакомиться с некоторыми из них, для более глубокого понимания вы можете прочитать книгу «Разбираемся со сжатием: сжатие данных для современных разработчиков» («Understanding Compression: Data Compression for Modern Developers»).

Кодирование видео с помощью VLC

Сжимаем поток, предполагая, что в итоге потратим 8 бит на каждый символ. Без сжатия на символ понадобилось бы 24 бита. Если каждый символ заменять на его код, то получается экономия!

Первый шаг заключается в кодировании символа e, который равен 10, а второй символ — это a, который добавляется (не математическим способом): [10] [0], и, наконец, третий символ t, который делает наш финальный сжатый битовый поток равным [10] [0] [1110] или же 1001110, для чего требуется всего 7 бит (в 3,4 раза меньше места, чем в оригинале).

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

И кодер, и декодер должны иметь доступ к таблице символов со своими бинарными кодами. Поэтому также необходимо отправить во входных данных и таблицу.

Арифметическое кодирование

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

Теперь давайте закодируем поток из трёх символов: eat.

Сначала выбираем первый символ e, который находится в поддиапазоне от 0,3 до 0,6 (не включая). Берём этот поддиапазон и снова делим его в тех же пропорциях, что и ранее, но уже для этого нового диапазона.

Давайте продолжим кодировать наш поток eat. Теперь берём второй символ a, который находится в новом поддиапазоне от 0,3 до 0,39, а затем берём наш последний символ t и, повторяя тот же процесс снова, получаем последний поддиапазон от 0,354 до 0,372.

Нам просто нужно выбрать число в последнем поддиапазоне от 0,354 до 0,372. Давайте выберем 0,36 (но можно выбрать и любое другое число в этом поддиапазоне). Только с этим числом сможем восстановить наш оригинальный поток. Это как если бы мы рисовали линию в пределах диапазонов для кодирования нашего потока.

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

С первым диапазоном замечаем, что наше число соответствует срезу, следовательно, это наш первый символ. Теперь снова разделяем этот поддиапазон, выполняя тот же процесс, что и раньше. Тут можно заметить, что 0,36 соответствует символу a, и после повторения процесса мы пришли к последнему символу t (формируя наш исходный кодированный поток eat).

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

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

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

6 шаг — формат битового потока

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

Мы поверхностно ознакомимся с битовым потоком H.264. Нашим первым шагом является создание минимального битового потока H.264 (FFmpeg по умолчанию добавляет все параметры кодирования, такие как SEI NAL — чуть дальше узнаем, что это такое). Можем сделать это, используя наш собственный репозиторий и FFmpeg.

Данная команда сгенерирует необработанный битовый поток H.264 с одним кадром, разрешением 64×64, с цветовым пространством YUV420. При этом используется в качестве кадра следующее изображение.

Битовый поток H.264

Стандарт AVC (H.264) определяет, что информация будет отправляться в макрокадрах (в понимании сети), называемых NAL (это такой уровень абстракции сети). Основной целью NAL является предоставление «дружественного к сети» представления видео. Этот стандарт должен работать на телевизорах (на основе потоков), в Интернете (на основе пакетов).

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

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

Обычно первым NAL битового потока является SPS. Этот тип NAL отвечает за информирование об общих переменных кодирования, таких как профиль, уровень, разрешение и прочее.

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

Например, первый байт после маркера синхронизации равен 01100111, где первый бит (0) находится в поле forbidden_zero_bit. Следующие 2 бита (11) сообщает нам поле nal_ref_idc, которое указывает, является ли этот NAL ссылочным полем или нет. И остальные 5 бит (00111) сообщает нам поле nal_unit_type, в данном случае это блок SPS (7) NAL.

Второй байт (binary=01100100, hex=0x64, dec=100) в SPS NAL — это поле profile_idc, которое показывает профиль, который использовал кодер. В данном случае использовался ограниченный высокий профиль (т.е. высокий профиль без поддержки двунаправленного B-сегмента).

Если ознакомиться со спецификацией битового потока H.264 для SPS NAL, то обнаружим много значений для имени параметра, категории и описания. Например, давайте посмотрим на поля pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.

Если продолжить проверку нашего созданного видео в двоичном виде (например: ), то можно перейти к последнему NAL, который является самим кадром.

Здесь видим его первые 6 байтовых значений: 01100101 10001000 10000100 00000000 00100001 11111111. Поскольку известно, что первый байт указывает на тип NAL, в данном случае (00101) это IDR фрагмент (5), и тогда получится дополнительно исследовать его:

Используя информацию спецификации, получится декодировать тип фрагмента (slice_type) и номер кадра (frame_num) среди других важных полей.

Чтобы получить значения некоторых полей (ue(v), me(v), se(v) или te(v)), нам нужно декодировать фрагмент, используя специальный декодер, основанный на экспоненциальном коде Голомба. Этот метод очень эффективен для кодирования значений переменных, особенно, когда если есть много значений по умолчанию.

Значения slice_type и frame_num этого видео равны 7 (I-фрагмент) и 0 (первый кадр).

Битовый поток можно рассматривать как протокол. Если желаете узнать больше о битовом потоке, стоит обратиться к спецификации ITU H.264. Вот макросхема, показывающая, где находятся данные изображения (YUV в сжатом виде).

Можно исследовать и другие битовые потоки, такие как VP9, H.265 (HEVC) или даже наш новый лучший битовый поток AV1. Все ли они похожи? Нет, но разобравшись хотя бы с одним — гораздо проще понять остальные.

Хотите попрактиковаться? Исследуйте поток битов H.264

Можно сгенерировать однокадровое видео и использовать MediaInfo для исследования потока битов H.264. Фактически, ничто не мешает даже поглядеть исходный код, который анализирует поток битов H.264 (AVC).

Для практики можно использовать Intel Video Pro Analyzer (я уже вроде говорил, что программа платная, но есть бесплатная пробная версия, с ограничением на 10 кадров?).

Обзор

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

Ранее рассчитали, что потребуется 139 Гб дискового пространства для хранения видеофайла длительностью один час при качестве 720p и 30 fps. Если использовать методы, которые разобрали в этой статье (межкадровые и внутренние прогнозы, преобразование, квантование, энтропийное кодирование и т.п.), то можно достичь (исходя из того, что тратим 0,031 бит на пиксель), видео вполне удовлетворительного качества, занимающее всего 367,82 Мб, а не 139 Гб памяти.

Как H.265 достигает лучшей степени сжатия, чем H.264?

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

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

HEVC имеет больше вариантов разделов (и подразделов), чем AVC, больше направлений внутреннего прогнозирования, улучшенное энтропийное кодирование и многое другое. Все эти улучшения сделали H.265 способным сжимать на 50% больше, чем H.264.

Источник