Почему для развития видео 4K нужно внедрять стандарт HEVC H.265
Видео 4K занимает тонну пространства, что затрудняет загрузку и потоковое вещание в лучшем качестве. К счастью, одна технология меняет это, и она известна как High Efficiency Video Coding (HEVC) или H.265.
Потребуется много времени, чтобы эта новая технология стала вездесущей, но это происходит: 4K UHD Blu-ray использует HEVC, VLC 3.0 воспроизводить 4K с помощью надежного HEVC, а iPhone может даже сохранить записанное видео в HEVC для экономии памяти.
Но как это работает, и почему так важно для видео 4K?
Текущий стандарт: AVC/H.264
Когда вы смотрите диск Blu-ray, видео на YouTube или фильм из iTunes, все они имеют идентичный исходный файл, который был получен в студии редактирования. Чтобы разместить этот фильм на диске Blu-ray или сделать его достаточно маленьким, чтобы удобно загружать из интернета, видео должно быть сжато.
Расширенное кодирование видео, также известное как AVC или H.264, является лучшим стандартом для сжатия видео среди широко используемых. Существует несколько различных методов, которые он использует, чтобы попытаться уменьшить размер файла видео.
Например, в любом отдельном фрейме он ищет области, которые имеют однотоный цвета. Например на фото нжие большая часть неба имеет достаточно однообразный синий цвет, поэтому алгоритм сжатия может разбить изображение на куски, называемые «макроблоками», и вместо того, чтобы помнить цвет каждого пикселя, просто укажет, что все эти куски в верхней части имеют один и тот же синий цвет. Это намного эффективнее, чем сохранение цвета каждого отдельного пикселя, и снижает размер файла конечного кадра. В видео это называется внутрикадровым сжатием – сжатие данных отдельного кадра.
AVC также использует межкадровое сжатие, которое рассматривает несколько кадров и отмечает, какие части кадра меняются, а какие нет. Алгоритм сжатия также развивает фрейм на макроблоки и говорит: «Знаешь что? Эти куски не меняются 100 кадров подряд, поэтому давайте просто отображать их снова, вместо того, чтобы хранить все части изображения 100 раз». Это может значительно уменьшить размер файла.
Это всего лишь два упрощенных примера использования методов AVC/H.264. Но, они позволяют сделать видеофайл более эффективным, не ставя под угрозу качество.
Конечно, любое видео потеряет качество, если вы слишком сильно его сжимаете, но чем умнее эти методы, тем сильнее вы можете сжать видео без больших потерь.
HEVC/H.265 сжимает видео более эффективно
Высокоэффективное видеокодирование, также известное как HEVC или H.265, является следующим шагом в этой эволюции. В нем реализовано множество методов, используемых в AVC/H.264, чтобы сделать сжатие видео еще более эффективным.
Например, когда AVC просматривает несколько кадров на наличие изменений, макроблоки могут иметь несколько разных форм и размеров, максимум до 16×16 пикселей. С HEVC эти фрагменты могут быть размером до 64×64, что намного больше, чем 16×16, это означает, что алгоритм может запоминать меньшее количество фрагментов, тем самым уменьшая размер общего видео.
Опять же, в HEVC используются другие методы, но это одно из самых больших улучшений – оно позволяет HEVC сжимать видео вдвое сильнее, чем AVC, при том же уровне качества. Это особенно важно для видео 4K, которое занимает огромное пространство с AVC. HEVC делает 4K видео намного более удобным для потоковой передачи, загрузки или копирования на ваш жесткий диск.
HEVC медленнее без аппаратного декодирования
HEVC является утвержденным стандартом с 2013 года, так почему его не используют во всех видео?
Алгоритмы сжатия H.265 сложны – для вычисления этого процесса на лету требуется очень много «математики». Существует два основных способа, которыми компьютер может декодировать это видео: программное декодирование, при котором он использует процессор компьютера для выполнения этих расчетов, и аппаратное декодирование, при котором он переносит нагрузку на графическую карту (или интегрированный графический чип на процессоре). Графическая карта намного эффективнее, если у нее есть встроенная поддержка кодека видео, которое вы пытаетесь воспроизвести.
Таким образом, хотя многие ПК и программы могут пытаться воспроизвести видео HEVC, оно может «заикаться» или быть очень медленным без аппаратного декодирования. Таким образом, HEVC не принесёт много пользы, если у вас нет видеокарты и видеопроигрывателя, которые поддерживают аппаратное декодирование HEVC.
Это не проблема для автономных устройств воспроизведения. 4K проигрыватели Blu-ray, в том числе Xbox One, уже сконструированы с учетом HEVC. Но когда дело доходит до воспроизведения видео HEVC на компьютере, всё становится сложнее.
Вашему устройству потребуется одно из следующих аппаратных средств для быстрого декодирования видео HEVC:
Вам также понадобится использовать операционную систему и видеоплеер, который поддерживает не только видео HEVC, но и аппаратное декодирование HEVC, – этот момент немного «мутный». Многие приложения имеют поддержку аппаратного декодирования HEVC, но в некоторых случаях оно может работать только с некоторыми фишками из списка выше. Возможно, вам придётся включить аппаратное ускорение в вашем плеере, чтобы он работал правильно.
С течением времени большее количество компьютеров сможет обрабатывать видео такого типа, и больше плееров будут поддерживать H.265. Для этого может потребоваться некоторое время, чтобы стандарт стал повсеместным, и до этого Вам придётся хранить свои 4K видео в AVC/H.264 при больших размерах файлов (или сжимать их больше и терять качество изображения). Но чем шире будет поддерживаться больше HEVC/H.265, тем лучше будет видео.
H.265 vs H.264 сравнение форматов видео. Что такое HEVC и AVC
Опубликовано admin в 24 октября, 2019 24 октября, 2019
H.265 vs H.264 – сравнение современных форматов сжатия видео.
H.265 (HEVC), в отличии от H.264 (AVC), становится наиболее часто используемым форматом для сжатия видео и записи контента 4K / 8K UHD, не говоря уже о видео HD / SD. Увеличение количества видео 4K и 8K бросает вызов текущему стандарту сжатия H.264, поскольку ему больше не удается кодировать видео Ultra HD с удовлетворительной скоростью передачи данных, чем контент HD.
Вследствие этого, стандарт сжатия видео HEVC следующего поколения получает преимущество над AVC благодаря лучшей эффективности сжатия. Это позволяет на 50% снизить скорость передачи, но обеспечивает такое же качество видео.
Этот пост показывает различия между двумя стандартами, основанные на размере файла, использовании полосы пропускания, скорости передачи данных, качестве и совместимости.
Что такое H.265 (HEVC)?
H.265 также называется высокоэффективным кодированием видео (HEVC). Данный формат в два раза более эффективен, чем H.264 при кодировании. Он вдвое снижает скорость передачи при том же уровне качества по сравнению со своим предшественником. Предназначен для дисплеев HDTV следующего поколения и систем захвата контента, которые имеют прогрессивную частоту кадров и разрешение, а также улучшенное качество изображения с точки зрения уровня шума, цветовых пространств и динамического диапазона.
Что такое H.264 (AVC)?
H.264 или MPEG-4 AVC – это формат кодирования видео, который в настоящее время является одним из наиболее часто используемых для сжатия и доставки видеоконтента. AVC экономит битрейт на 50% и более по сравнению с его предшественником MPEG-2. Имеет более широкий спектр приложений, охватывающих все сжатое видео, начиная от потоковых приложений с низким битрейтом (YouTube, iTunes, Vimeo, Facebook, Instagram) для различных передач HDTV по наземному, кабельному и спутниковому телевидению. Он также широко используется для дисков Blu-ray, DVD, IP-сетей и приложений для цифрового кино с кодированием, практически без потерь.
Сравнение форматов сжатия видео
Эффективность сжатия
H.265 отличается от H.264 эффективностью сжатия. HEVC удваивает эффективность кодирования по сравнению со своим предшественником. Это означает, что кодек H.265 экономит около 50% битрейта при том же качестве кодирования. В частности, среднее уменьшение битов для H.265 составляет 64% при 4K UHD, 62% при 1080p, 56% при 720p и 52% при 480p. Таким образом, если загрузить фильм в H.265 и воспроизвести его на устройстве iPhone Android, то будет сохранено 50% памяти мобильного устройства. И качество фильма не пострадает!
Сравнение форматов видео и эффективность сжатия
Полоса пропускания
H.265 превосходит H.264 и в отношении использования полосы пропускания. Поскольку алгоритм HEVC использует эффективное кодирование, он обещает приблизительно 40-50% уменьшения полосы пропускания передачи, необходимой для сжатия видео (например, в формате 720p), с тем же качеством. Как правило, для потоковой передачи 4K H264 (AVC) требуется полоса пропускания 32 Мбит / с, а для передачи видео 4K HEVC – всего 15 Мбит / с. Таким образом, можно наслаждаться 4k видео без проблем даже при перегруженном сетевом соединении.
H.264 и H.265 – полоса пропускания
Качество видео
Большая разница между рассматриваемыми кодеками заключается в качестве видео при одинаковой скорости передачи данных. В AVC границы областей блока, вероятно, будут искажены, потому что каждый макроблок является фиксированным, а данные независимы друг от друга. В то время как H.265 предлагает более четкие детали на гранях и сглаживает градиентные области с меньшим количеством артефактов.
Таким образом, H.265 лучше, чем H.264, когда речь идет о сжатии видео с лучшим качеством изображения.
Размер файла
Высокая степень сжатия также тесно связана с требованием цифрового хранения видеопотоков и передачи. Уменьшенная пропускная способность приводит к уменьшению размера файла. Тесты показывает, что видео, закодированное с помощью H.264, в 1-3 раза больше, чем H.265. Это выгодно для хранения информации на жестком диске или устройствах с ограниченным пространством хранения, необходимого для размещения видеоданных. В этом отношении большое преимущество H.265 перед H.264.
H.265 vs H.264 сравнение форматов – размер файла
Совместимость форматов
Ничто не совершенно. Так же, как и HEVC. Все, сказанное выше, является преимуществом HEVC перед H264. Но есть и недостаток – плохая совместимость. В настоящее время новый формат далеко не так популярен, как H264. Современные устройства и платформы, поддерживающие кодек H264, составляют 99%. Поддержка кодека H265, может составлять около 30-40%.
Преимущества и недостатки
H.265 имеет много преимуществ перед H.264. Например, он поддерживает до 8K UHDTV (разрешением, максимум 8192 × 4320), скорость передачи данных составляет несколько ГБ / с, а размер файла вдвое меньше, и это с лучшим качеством! H.265 имеет большое влияние на увеличение спроса и продажи экранов 4К, предлагая более высокое качество видео даже в сети с ограниченной пропускной способностью.
Но есть и обратная сторона. HEVC требует больше времени для кодирования по сравнению с AVC. Во-вторых, поскольку перспективный кодек, который сейчас широко не используется, просмотр видео H.265 не так прост. Поэтому преобразование H.265 в H.264 по-прежнему очень востребовано в наши дни.
Пишите в комментариях ниже какую информацию добавить или убрать для форматов сжатия видео – H.264 (AVC) vs H.265 (HEVC). Открыт для предложений по оформлению и наполнению страницы.
Высокоэффективное кодирование видеоизображений (HEVC)
Что такое высокоэффективное кодирование видеоизображений (HEVC)?
До недавнего времени при необходимости оптимизировать качество видео и уменьшить размеры файлов предпочтение отдавалось кодеку H.264 (также известному как AVC). Переход на кодек H.265 (или HEVC) требует большей вычислительной мощности по сравнению с H.264, однако кодек HEVC работает намного эффективнее и обеспечивает повышение качества видео при более низких битрейтах.
Переломным моментом в использовании видеокодека HEVC / H.265 стала Всемирная конференция разработчиков Apple (WWDC) 2017 года, на которой компания Apple объявила кодек HEVC своим «видеокодеком следующего поколения». Последствия этого события стали глобальными. Благодаря такой заинтересованности в HEVC и уже появившейся на тот момент в большинстве микросхем для мобильных устройств аппаратной поддержке видеокодирования HEVC поставщики видеоконтента осознали, что кодек HEVC стал новым стандартом сжатия видео для потоковой передачи.
HEVC по сравнению с AVC. В чем преимущества кодека HEVC?
Из объявления Apple: «Одним словом, эффективность. И в первую очередь – эффективность кодирования. Кодек HEVC примерно на 40 % эффективнее AVC. Это означает, что воспроизведение с приличным качеством начнется для пользователя на 40 % быстрее, а когда плеер полностью адаптируется к видеопотоку, контент будет выглядеть на 40 % лучше. Мы решили сделать HEVC доступным для всех. В самые новые устройства Apple поддержка HEVC встроена на аппаратном уровне. Даже для более старых устройств, где такой аппаратной поддержки нет, мы планируем развертывание кодека HEVC на программном уровне. Так что теперь HEVC будет использоваться повсюду».
Ответ на вопрос любой компании относительно выбора между HEVC и AVC можно обобщенно выразить в виде двух основных преимуществ кодека HEVC.
При использовании кодека HEVC с той же пропускной способностью, что и AVC, можно достичь более высокого качества видео – либо обеспечить тот же уровень качеств, что и AVC, с использованием половины пропускной способности, необходимой для AVC.
HEVC по сравнению с H.264 и MPEG‑2. Сравнение трех кодеков
Если коротко, кодек HEVC предоставляет инструменты для передачи видео с заданным уровнем качества при наименьшем объеме передаваемой информации. Ниже приведено сравнение кодеков MPEG‑2, H.264 и HEVC по компонентам.
Как работает видеокодек. Часть 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 | Описание |
|---|---|
| 0 | Неизвестный тип |
| 1 | Кодированный фрагмент изображения без IDR |
| 2 | Кодированный раздел данных среза A |
| 3 | Кодированный раздел данных среза B |
| 4 | Кодированный раздел данных среза C |
| 5 | Кодированный IDR-фрагмент IDR-изображения |
| 6 | Дополнительная информация о расширении SEI |
| 7 | Набор параметров SPS-последовательности |
| 8 | Набор параметров PPS-изображения |
| 9 | Разделитель доступа |
| 10 | Конец последовательности |
| 11 | Конец потока |
| . | . |
Обычно первым 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.
| Название параметра | Категория | Описание |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Если продолжить проверку нашего созданного видео в двоичном виде (например: ), то можно перейти к последнему 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.
