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

Автор оригинала: leandromoreira
  • Перевод

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




Kodek's History

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

Для чего? Невзирая на определённые ограничения как по пропускной способности так
и по количеству места для хранения данных, рынок требует всё более качественного видео. Припоминаете, как в прошлом посте мы подсчитали необходимый минимум для 30 кадров в секунду, 24 бита на пиксель, с разрешение 480x240? Получили 82,944 Мбит/с без сжатия. Сжатие — это пока единственный способ вообще передавать HD/FullHD/4K на телевизионные экраны и в Интернет. Как это достигается? Сейчас кратко рассмотрим основные методы.
EDISON Software - web-development
Перевод сделан при поддержке компании 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).

image

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


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

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


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

image

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

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

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

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

image

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


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

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


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

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

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

2 февраля 2017 года Синттра Р.Дж. (Cintra, R.J.) и Байер Ф.М. (Bayer F.M.) опубликовали статью про DCT-подобное преобразование для сжатия изображений, требующее только 14 дополнений.

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

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

image

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

image

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

image

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

image

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

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

image

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

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

image

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

image

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

image

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

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



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

image

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

image


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


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

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

image

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

image

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

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


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

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


Предположим, у нас есть поток символов: a, e, r и t. Вероятность (в пределах от 0 до 1) того, как часто встречается каждый символ в потоке, представлена в этой таблице.
a e r t
Вероятность 0,3 0,3 0,2 0,2
Мы можем присвоить уникальные двоичные коды (предпочтительно малые) наиболее вероятным, а более крупные коды — менее вероятным.
a e r t
Вероятность 0,3 0,3 0,2 0,2
Бинарный код 0 10 110 1110
Сжимаем поток, предполагая, что в итоге потратим 8 бит на каждый символ. Без сжатия на символ понадобилось бы 24 бита. Если каждый символ заменять на его код, то получается экономия!

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

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

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

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


Предположим, у нас есть поток символов: a, e, r, s и t, и их вероятность представлена этой таблицей.
a e r s t
Вероятность 0,3 0,3 0,15 0,05 0,2
С этой таблицей построим диапазоны, содержащие все возможные символы, отсортированные по наибольшему количеству.

image

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

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

image

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

image

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

image

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

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

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

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

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

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


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

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

./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264

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

image

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


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

image

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

image

Как говорилось, декодер должен знать не только данные изображения, но также и детали видео, кадра, цвета, используемые параметры и многое другое. Первый байт каждого 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-сегмента).

image

Если ознакомиться со спецификацией битового потока 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)
Если выполнить некоторые математические операции со значениями этих полей, то получим разрешение. Можно представить 1920 x 1080, используя pic_width_in_mbs_minus_1 со значением 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Опять же, экономя место, вместо кодирования 1920 сделали это со 119.

Если продолжить проверку нашего созданного видео в двоичном виде (например: xxd -b -c 11 v/minimal_yuv420.h264), то можно перейти к последнему NAL, который является самим кадром.

image

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

image

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

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

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

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

image

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

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


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

image

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

image

Обзор


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

image

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

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


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

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

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

image



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

Edison
276,01
Изобретаем успех: софт и стартапы
Поделиться публикацией

Комментарии 15

    +3
    а стандарты MPEG1, MPEG2, MPEG4 совсем забыли?
    эти стандарты от ISO
    все что H.xxx это от ITU
    разные организации и разные правила лицензирования…
    в случае H.264 была создана Joint Video Team и паралельный стандарт от ISO называеться MPEG4 Part 10 AVC
      +3
      В общем и целом MPEG-и особого интереса не представляют, только в качестве исторической справки. За исключением древнего (или узкоспециализированного) легаси-железа сейчас нет причин их использовать.
        +2
        ну как же, все стандарты сегодня принимаються в том числе под игидой MPEG
        каждый раз упоминаю H.264 добавляют AVC — advanced video codec, что являеться абривиатурой MPEG.
        а следущее поколение чаще называют HEVC чем H.265, что тоже от MPEG
        сеогдня нет ниодного железа не поддерживающего вариацию страндарта от MPEG
        и если уж вдаваться в подробности
        вендору железа «надежней» поддерживать именно MPEGи
        так как когда закрываеться спецификация у них, то она уже практически не меняеться
        а ITU это формально рекомендация и более гибкая для корректировок
        обратите вимание на количество Annex-ов в стандартах ITU которые иногда переворачивают все с ног наголову
          +2
          Тут смысл в том, что MPEG в принципе сейчас активно используется в производстве, но в основном в i-frame варианте, при монтаже. Об этом даже многие монтажеры не знают.
          Но как кодек для потребителя — умер уже давно. Я mpeg-ов (к великому счастью) не видел уже давно на просторах Интернета. Как и контейнер AVI, который теперь используются как «тупой, но надежный», для всяких архивных видео в том же FFV1.
          Эти применения не совсем актуальны для этой статьи, КМК.
            +2
            извините но сейчас вы сказали мягко говоря чушь!
            во первых MPEG это под группа в организации ISO
            во вторых какой из стандартов вы имеете ввиду? MPEG1? MPEG2? MPEG4?
            в 3тих, MPEG4 part 10 есть ни что иное как H.264/AVC
            и в 4тых еще раз HEVC это от MPEG

            упоминув нигде не используемый VP3
            и забыть упоминуть что
            H.261 <=> MPEG1
            H.262 <=> MPEG2
            H.263 <=> MPEG4 — до сих пор повсеместно используеться в кабельном ТВ
            мягко говоря странно

            en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Standardization
              +3
              во вторых какой из стандартов вы имеете ввиду? MPEG1? MPEG2? MPEG4?
              Все до MPEG-H Part 2 и MPEG-4 Part 10, если вам так угодно.
              H.263 <=> MPEG4 — до сих пор повсеместно используеться в кабельном ТВ мягко говоря странно
              По телевидению нужно писать отдельную статью, и там mpeg4\h.263 (где используются при вещании) — не от хорошей жизни. Да, я конечно прямо сейчас кодирую видео в 720x576, чтобы старая вещательная железка с h.263 смогла, но, как я уже сказал — не от хорошей жизни. Кабельное телевидение нас тоже потихоньку покидает в пользу цифрового.
              Да, можно написать про старые mpeg-и (MPEG1, MPEG2 из поста, на который я отвечал) — в виде исторической справки. Надо ли? Автор решил, что не надо. Если вы напишете — никто не будет против, уверен, лично я поставлю плюс.
              Да, можно написать про неактуальные \ неинтересные для потребителя h.263 и прочие divx — в виде углубления в тему железа для телевещания и принципов работы монтажных программ. Надо ли? Опять же — автор решил, что не надо. Возможно, информацией не владеет, или желания нет. Про свою статью уже повторять не буду.
              Лично я считаю, что статья не нуждается в этой информации. У вас мнение другое — ну и прекрасно.
              упоминув нигде не используемый VP3
              Я не упоминал VP3. Да, ему в статье тоже не место, как мне кажется. Статья о принципах работы современных энкодеров и кодеках, не энциклопедия всех ранее использовавшихся.
                +2
                на первой же картинке в статье присутствует VP3 и на прочь остутствует упоминание о МПЕГАх

                при монтаже используеться I-frame only не от устравшего кодека, а от специфики применения для редактирования, любой совремемныый будет тоже использоваться в таком режиме
                H.263 как таковой нигде толком не использовался, везде был MPEG4, так как это одно и тоже (если брать baseline обеих, и далее еще 2 профайла), а когда использовали Main то только MPEG4

                вообщем сегодня говоря H.xxx имееться ввиду MPEG а упоминая MPEG вспоминают о H.xxx, так как для конечного пользователя они одинаковые
                и это пользователь должен знать а то продадут ему одни и тоже дважды
                  +3
                  на первой же картинке в статье присутствует VP3
                  Понял, не заметил.
                  при монтаже используеться I-frame only не от устравшего кодека
                  Конечно же, мне об этом известно. И применяется не потому, что mpeg, а потому, что i-frame only.
                  так как для конечного пользователя они одинаковые
                  Ну и я говорю: структура организаций, принимающих кодеки, интересует очень малое количество людей. А H.264 — как его не назови: H.264, MPEG-4 Part 10 или MPEG-4 AVC — им и останется.
                +2
                Не только MPEG4, даже MPEG2 активно используется в спутниковом и кабельном телевидении. При этом некоторые старые модели спутниковых ресиверов не понимают картинку MPEG4.
                  +2
                  и есть пару фирм в европе которые для таких провайдеров прикручивают интеркативное ТВ и новые фишки: о)
        +2
        исходя из того, что тратим 0,031 бит на пиксель

        Ого, мало. Давно видел в каких-то видео 0.22 бит/пиксель (скорее всего — xVid), FullHD фильм могли сжимать в 0.11 бит/пиксель (нужно глянуть кодек будет).

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

        Core Duo T2050 сложно было тянуть FullHD HEVC.
          +2
          Но ведь декодирование на CPU как раз где-то во времена Core Duo стало моветоном.
            +3
            Оно стало моветоном к времени выхода видеокарт GF 8500/8600 (вроде как в первых 8800 GTX/GTS не было такой технологии). А в том ноуте была GeForce Go 7300.
            +2
            Core Duo T2050 сложно было тянуть FullHD HEVC.
            У меня до сих пор в раздачах на трекере, которые я оформил в 2019 году, жалуются, что «вот этот файл плохо воспроизводится, что такое?!»
            Такое там — HEVC. Так что не перевелись еще любители софтового декодирования.
            +3
            Отличные статьи!
            Один момент — мне кажется, что в статье не описана важность квантизации. А именно, что на этом шаге мы понижаем энтропию сигнала, подготавливая его таким образом к энтропийному кодированию.
            Соответственно: аггрессивная квантизация == потеря качества == лучшее сжатие на стадии энтропийного сжатия == меньший битрейт. И соответственно наоборот.
            Таким образом от кватизации зависит баланс — сжатие/качество.

            А также пару слов об RLE кодировании тоже не помешало б.

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

            Самое читаемое