Преимущества и принцип работы кодека HikVision H.264+
Просматривая спецификации современных камер HikVision, пытливый читатель непременно обратит внимание на заявленную поддержку стандарта сжатия видео H.264+. Подробное описание лицензируемого кодека H.264, также обозначаемого в специальной литературе, как AVC (Advanced Video Coding), можно отыскать даже в Википедии, но что же скрывается за красующимся справа знаком «плюс»: принципиально новые возможности, или все это — не более, чем маркетинговый трюк? Попробуем разобраться.
Предпосылки к разработке кодека H.264+
Формат H.264+ был создан на основе алгоритмов H.264/AVC. Инженеры HikVision адаптировали популярный стандарт сжатия под специфику задач, решаемых современными системами видеонаблюдения, и существенно улучшили компрессию без ущерба для качества изображения. Благодаря этому эксплуатация аппаратуры с поддержкой H.264+ позволяет снизить нагрузку на сеть, а также сократить объем видеоархива, оптимизировав затраты на построение и обслуживание охранной инфраструктуры. Поддержка нового стандарта была внедрена в цифровых камерах HikVision серий EasyIP и EasyIP 2.0. Одним из ярких представителей последней можно назвать модель DS-2CD2042WD-I, доступную в четырех модификациях, отличающихся друг от друга фокусным расстоянием объектива (4, 6, 8 или 12 мм).
![DS-2CD2042WD-I (6 мм)](/800/600/https/www.ami-com.ru/upload/iblock/987/9a6845bce53c92fa2f9c43281dc38067.jpg)
DS-2CD2042WD-I (6 мм)
Уличная IP-камера с разрешением 4 Мп, объективом 6 мм, функцией WDR 120дБ и ИК-подсветкой до 30м
4-мегапиксельные камеры поддерживают запись видео с разрешением вплоть до 2688 х 1520 пикселей (максимальный фреймрейт при этом ограничивается 20 кадрами в секунду), или в формате Full HD в реальном времени. Интеллектуальный алгоритм сжатия, наряду с поддержкой функционирования в двухпоточном режиме передачи данных позволяют оптимизировать нагрузку на систему безопасности и существенно экономить дисковое пространство. Так, например, если при использовании обычных камер для видеонаблюдения в режиме 24/7 при разрешении 1920 x 1080 пикселей и фреймрейте 25 к/с месячный архив будет занимать порядка 1.2 ТБ, то кодек H.264+ помогает сократить его размеры на треть (до 462 ГБ) без заметной потери качества.
В отличие от традиционной съемки, видеонаблюдение имеет три важные отличительные черты:
- фон сцены статичен и остается неизменным в течение продолжительного промежутка времени;
- практический интерес представляют только движущиеся объекты, появление которых в кадре может быть неравномерным;
- наблюдение ведется в круглосуточном режиме, в условиях непостоянного освещения.
С учетом данных особенностей, разработчикам кодека H.264+ удалось дополнительно повысить степень сжатия видеоданных за счет использования ряда инновационных технологий, ключевыми из которых являются кодирование с предсказанием на базе цифровой модели фона и динамическое управление видеопотоком. Рассмотрим перечисленные приемы по отдельности.
Принцип работы кодирования с предсказанием в формате H.264+
Практически все актуальные алгоритмы обработки видео параллельно задействуют два метода сжатия: внутрикадровое и межкадровое. При внутрикадровом каждый кадр обрабатывается, как обособленное изображение, вследствие чего такой подход оказывается малоэффективным, так как в отличие от текстовой информации графика очень плохо поддается компрессии. Напротив, при межкадровом сжатии учитываются только динамические элементы в двух соседних кадрах. То есть, потенциально видеозапись статического изображения, в котором за время съемки не происходит никаких изменений, можно сжать до объема одного-единственного начального кадра.
При перекодировании видео в формат H.264 формируются следующие типы кадров:
- I-кадры (от английского «Intra-coded frames», их также принято называть опорными или ключевыми) — содержат информацию о статичных объектах, не меняющихся на протяжении длительного времени, и подвергаются внутрикадровой обработке;
- P-кадры («Predicted frames», предсказанные кадры, также именуемые разностными) — несут в себе данные об участках сцены, претерпевших изменения, а также ссылки на соответствующие I-кадры. P-кадры подвергаются межкадровому сжатию;
- B-кадры («Bi-predicted frames», или двунаправленные предсказанные кадры) — могут ссылаться на I-, P- и даже другие B-кадры (их число может достигать 32), причем как на предыдущие, так и на последующие.
Применительно к видеонаблюдению нетрудно догадаться, что в качестве опорных используются фоновые изображения, а в P-кадрах сохраняются данные о движущихся объектах. При этом ключевые кадры подвергаются максимально возможному сжатию, тогда как движущиеся объекты обрабатываются таким образом, чтобы их изображение оставалось качественным, а мелкие детали — хорошо различимыми.
Кстати, P-кадры называют «предсказанными» не случайно: дело в том, что для сокращения временной избыточности содержание последующего кадра вычисляется на основании данных, полученных из предыдущего. Разумеется, предсказание не может быть абсолютно точным, поэтому сцена корректируется исходя из разности между истинным изображением и предсказанным (эту погрешность принято называть «сигнал ошибки»). С первого взгляда такой подход кажется сложным, однако именно он позволяет добиться максимальной компрессии, тем более, что в ряде сценариев предсказание оказывается чрезвычайно точным (например, когда речь заходит о видеонаблюдении за проезжей частью, так как автомобили перемещаются линейно), позволяя дополнительно сэкономить вычислительные ресурсы.
В свою очередь, использование B-кадров расширяет возможности записи и воспроизведения. Поскольку они могут ссылаться не только на предыдущие, но и на последующие кадры, видеопоток, несущий информацию об однообразных, повторяющихся движениях (вращение колеса авто) можно дополнительно сжать. Кроме того, B-кадры позволяют в несколько раз сократить время доступа к видеоархиву, что особенно заметно при поиске конкретной сцены, так как для ее отображения понадобится распаковать лишь каждый второй или третий кадры, тогда как если бы кодек оперировал только I- и P-кадрами, то потребовалась бы декомпрессия всей последовательности изображений.
Интеллектуальное управление видеопотоком формата H.264+
Следующей особенностью кодека H.264+ является поддержка динамического изменения размера видеопотока в зависимости от времени суток, что особенно актуально для систем круглосуточного видеонаблюдения. Фирменные алгоритмы HikVision отслеживают динамику нагрузки на камеру в течение 24 часов, рассчитывая величину среднесуточных флуктуаций и корректируя степень сжатия видео с привязкой к прогнозируемой активности в кадре.
На приведенной схеме пиковая активность в кадре приходится на временной промежуток C (между 12 и 18 часами), тогда как утром и ночью снимаемая сцена статична (зоны A и B). Поток обрабатываемых данных при этом оказывается ниже практически на 95%, что помогает существенно сэкономить дисковое пространство. Конечная экономия зависит от количества движущихся объектов, интенсивности их перемещения и размера статичных участков, используемых при формировании I-кадров.
Чтобы лучше сориентироваться, можно воспользоваться следующей таблицей, позволяющей оценить перспективы использования кодека H.264+ в различных ситуациях.
Зона интереса | Размер статичного фона | Уровень активности в кадре | Потенциальная экономия |
---|---|---|---|
Небольшой частный магазин | малый | средний | 50% |
Оживленная улица в дневное время | средний | высокий | 65% |
Промзона в ночное время суток | большой | минимальный | 95% |
Благодаря всему вышеперечисленному, формат H.264+ оказывается идеальным решением для создания системы видеонаблюдения с применением камер высокой четкости (с разрешением Full HD и выше) на объектах, где необходимо вести непрерывную видеофиксацию, а возможности детекции движения допустимо задействовать лишь в сценариях видеоаналитики. Современный стандарт компрессии изображения позволяет существенно сократить издержки, связанные с архивацией и хранением данных, не жертвуя при этом качеством записи. Результаты можно оценить по следующему ролику, специально подготовленному специалистами HikVision.
Как видно, интеллектуальные алгоритмы делают H.264+ значительно эффективнее по сравнению с обычным H.264/AVC. И что немаловажно, при его использовании сохраняется обратная совместимость с аппаратным и программным обеспечением, поддерживающим стандарт H.264: таким образом вы нисколько не будете стеснены при подборе оборудования и прикладного ПО.
H.264 — это… Что такое H.264?
H.264, MPEG-4 Part 10 или AVC (Advanced Video Coding) — лицензируемый стандарт сжатия видео, предназначенный для достижения высокой степени сжатия видеопотока при сохранении высокого качества.
О стандарте
Он был создан ITU-T Video Coding Experts Group (VCEG) совместно с ISO / IEC Moving Picture Experts Group (MPEG) в рамках совместной программы Joint Video Team (JVT).
Стандарты ITU-T H.264 и ISO/IEC MPEG-4 Part 10 (формальное название — ISO/IEC 14496-10) технически полностью идентичны. Финальный черновой вариант первой версии стандарта был закончен в мае 2003 года.
Используется в цифровом телевидении высокого разрешения (HDTV) и во многих других областях цифрового видео.
Возможности
Стандарт H.264 / AVC / MPEG-4 Part 10 содержит ряд новых возможностей, позволяющих значительно повысить эффективность сжатия видео по сравнению с предыдущими (такими, как ASP) стандартами, обеспечивая также большую гибкость применения в разнообразных сетевых средах. Основные из них:
- Многокадровое предсказание:
- Использование сжатых ранее кадров в качестве опорных (то есть с заимствованием части материала из них) куда более гибко, чем в предыдущих стандартах. Позволяется использование до 32 ссылок на другие кадры, тогда как в ASP и более ранних число ссылок ограничено одним или, в случае B-кадров, двумя кадрами. Это поднимает эффективность кодирования, так как позволяет кодеру выбирать для компенсации движения между большим количеством изображений. В большинстве сцен данная функция обеспечивает не очень большое улучшение в качестве и не даёт заметного понижения битрейта. Однако, для некоторых сцен, например, с частыми повторяющимися участками, возвратно-поступательным движением и т. п. данный подход при сохранении качества позволяет очень сильно снизить затраты битрейта.
- Независимость порядка воспроизведения изображений и порядка опорных изображений. В предшествующих стандартах устанавливалась жёсткая зависимость между порядком следования изображений для использования при компенсации движения и порядком следования изображений при воспроизведении. В новом стандарте эти ограничения в значительной мере устранены, что позволяет кодеру выбирать порядок изображений для компенсации движения и для воспроизведения с высокой степенью гибкости, которая ограничена только объёмом памяти, который гарантирует возможность декодирования. Устранение ограничения также позволяет в ряде случаев устранить дополнительную задержку, ранее связанную с двунаправленным предсказанием.
- Независимость методов обработки изображений и возможности их использования для предсказания движения. В предшествующих стандартах изображения, закодированные с использованием некоторых методов (например, двунаправленного предсказания), не могли использоваться в качестве опорных для предсказания движения других изображений видеопоследовательности. Устраняя это ограничение, новый стандарт обеспечивает кодеру большую гибкость и, во многих случаях, возможность использовать для предсказания движения изображение, более близкое по содержанию к кодируемому.
- Компенсация движения с переменным размером блока (от 16×16 до 4×4 пикселя) позволяет крайне точно выделять области движения.
- Векторы движения, выводящие за границы изображения. В MPEG-2 и предшествовавших ему стандартах векторы движения могли указывать только на пикселы, находящиеся в границах декодированного опорного изображения. Методика экстраполяции за границы изображения, появившаяся как опция в H.263, включена в новый стандарт.
- Шеститочечная фильтрация компонента яркости для полупиксельного предсказания с целью уменьшения зубчатости краев и, в конечном счёте, обеспечения большей чёткости изображения.
- Точность до четверти пиксела (Qpel) при компенсации движения обеспечивает очень высокую точность описания движущихся областей (что особенно актуально для медленного движения). Цветность, как правило, хранится с разрешением, уменьшенным вдвое по вертикали и горизонтали (прореживание цвета), поэтому компенсация движения для компонента цветности использует точность в одну восьмую пиксела цветности.
- Взвешенное предсказание, позволяющее использовать масштабирование и сдвиг после компенсации движения на величины, указанные кодером. Такая методика может чрезвычайно сильно поднять эффективность кодирования для сцен с изменением освещённости, например при эффектах затемнения, постепенного появления изображения.
- Пространственное предсказание от краёв соседних блоков для I-кадров (в отличие от предсказания только коэффициента трансформации в H.263+ и MPEG-4 Part 2, и дискретно-косинусного коэффициента в MPEG-2 Part 2). Новая методика экстраполяции краёв ранее декодированных частей текущего изображения повышает качество сигнала, используемого для предсказания.
- Сжатие макроблоков без потерь:
- Метод представления макроблоков без потерь в PCM, при котором видеоданные представлены непосредственно, позволяющий точно описывать определённые области и допускающий строгое ограничение на количество закодированных данных для каждого макроблока.
- Улучшенный метод представления макроблоков без потерь, позволяющий точно описывать определённые области, при этом обычно затрачивая существенно меньше битов, чем PCM (поддерживается не во всех профилях).
- Гибкие функции чересстрочного сжатия (поддерживается не во всех профилях):
- Адаптивное к изображению кодирование полей (PAFF), позволяющее кодировать каждый кадр как кадр или как пару полей (полукадров) — в зависимости от отсутствия\наличия движения.
- Адаптивное к макроблокам кодирование полей (MBAFF), позволяющее независимо кодировать каждую вертикальную пару макроблоков (блок 16×32) как прогрессивные или чересстрочные. Позволяет использовать макроблоки 16×16 в режиме разбиения на поля (сравните с 16×8 полумакроблоками в MPEG-2). Почти всегда эффективнее PAFF.
- Новые функции преобразования:
- Точное целочисленное преобразование пространственных блоков 4×4 (концептуально подобное широко известному DCT, но упрощенное и способное обеспечить точное декодирование[1]), позволяющее точное размещение разностных сигналов с минимумом шума, часто возникающего в предыдущих кодеках.
- Точное целочисленное преобразование пространственных блоков 8×8 (концептуально подобное широко известному DCT, но упрощенное и способное обеспечить точное декодирование; поддерживается не во всех профилях), обеспечивающее большую эффективность сжатия схожих областей, чем 4×4.
- Адаптивный выбор кодеком между размерами блока 4×4 и 8×8 (поддерживается не во всех профилях).
- Дополнительное преобразование Адамара, применяемое к дискретно-косинусным коэффициентам основного пространственного преобразования (к коэффициентов яркости, и, в особом случае, цветности) для достижения большей степени сжатия в однородных областях.
- Квантование:
- Логарифмическое управление длиной шага для упрощения распределения битрейта кодером и упрощенного вычисления обратной длины квантования.
- Частотно-оптимизированные матрицы масштабирования квантования, выбираемые кодером для оптимизации квантования на основе человеческих особенностей восприятия (поддерживается не во всех профилях).
- Внутренний фильтр деблокинга в цикле кодирования, устраняющий артефакты блочности, часто возникающие при использовании основанных на DCT техниках сжатия изображений.
- Энтропийное кодирование квантованных коэффициентов трансформации:
- Context-adaptive binary arithmetic coding (CABAC, контекстнозависимое адаптивное бинарное арифметическое кодирование) — алгоритм сжатия без потерь для синтаксических элементов видеопотока на основе вероятности их появления. Поддерживается только в Main Profile и выше. Обеспечивает более эффективное сжатие, чем CAVLC, но требует значительно больше времени на декодирование.
- Context-adaptive variable-length coding (CAVLC, контекстнозависимое адаптивное кодирование с переменной длиной кодового слова) — альтернатива CABAC меньшей сложности. Тем не менее, оно сложнее и эффективнее, чем алгоритмы, применяемые для тех же целей в более ранних технологиях сжатия видео (как правило это алгоритм Хаффмана).
- Часто используемое, простое и высоко структурированное кодирование словами переменной длины многих элементов синтаксиса, не закодированных CABAC или CAVLC, известное как коды Голомба (экспоненциальное кодирование Голомба).
- Функции устойчивости к ошибкам:
- Определение уровня сетевой абстракции (NAL), позволяющее использовать один и тот же синтаксис видео в различных сетевых окружениях, включая наборы параметров последовательности (sequence parameter sets, SPSs) и наборы параметров изображения (picture parameter sets, PPSs), которые обеспечивают большую надёжность и гибкость, чем предыдущие технологии.
- Гибкое упорядочивание макроблоков (FMO), также известное как группы частей (поддерживается не во всех профилях) и произвольное упорядочивание частей (ASO) — методы реструктурирования порядка представления фундаментальных областей (макроблоков) в изображениях. При эффективном использовании гибкое упорядочивание макроблоков может существенно повысить устойчивость к потере данных.
Благодаря ASO, так как каждая часть изображения может быть декодирована независимо от других (при определённых ограничениях кодирования), новый стандарт позволяет посылать и получать их в произвольном порядке друг относительно друга. Это может снизить задержку в приложениях реального времени, особенно при использовании на сетях, имеющих режим работы доставка вне очереди. Эти функции могут также использоваться для множества других целей помимо восстановления ошибок.
- Разбиение данных — функция, обеспечивающая разделение данных разной важности (например, векторы движения и другая информация предсказания имеет большую значимость для представления видеоконтента) по разным пакетам данных с разными уровнями защиты от ошибок (поддерживается не во всех профилях).
- Избыточные части. Возможность посылки кодером избыточного представления областей изображений, позволяя воспроизвести области изображений (обычно с некоторой потерей качества), данные о которых были потеряны в процессе передачи (поддерживается не во всех профилях).
- Нумерация кадров, позволяющая создание «подпоследовательностей» (включая временно́е масштабирование включением дополнительных кадров между другими) а также обнаружение (и скрытие) потерь целых кадров при сбоях канала или пропаже пакетов.
Профили
Стандарт определяет комплекты возможностей, которые называются профили, ориентированные на конкретные классы приложений.
- Baseline Profile (Базовый профиль)
- Применяется в недорогих продуктах, требующих дополнительной устойчивости к потерям. Используется для видеоконференций и в мобильных продуктах. Включает все возможности Constrained Baseline Profile и, дополнительно, возможности для большей устойчивости к потерям при передаче. С появлением Constrained Baseline Profile отошел на второй план, т.к. все потоки Constrained Baseline Profile соответствуют Baseline Profile, и оба этих профиля имеют общий код идентификатора.
- Constrained Baseline Profile (Ограниченный базовый профиль)
- Рассчитан на применение в недорогих продуктах. Включает набор возможностей, общих для профилей Baseline, Main, и High профилей.
- Main Profile (Основной профиль)
- Применяется для цифрового телевидения стандартной четкости в трансляциях, использующих сжатие MPEG-4 в соответствии со стандартом DVB.
- Extended Profile (Расширенный профиль)
- Предназначен для потокового видео, имеет относительно высокую степень сжатия и дополнительные возможности для повышения устойчивости к потере данных.
- High Profile (Высокий профиль)
- Является основным для цифрового вещания и видео на оптических носителях, особенно для телевидения высокой четкости. Используется для Blu-Ray видеодисков и DVB HDTV вещания.
- High 10 Profile (Высокий профиль 10)
- Дополнительно поддерживает 10-битовую глубину кодирования изображения.
- High 4:2:2 Profile (Hi422P)
- В основном нацелен на профессиональное использование при работе с чересстрочным видеопотоком. Поддерживает дополнительный вариант кодирования цветности.
- High 4:4:4 Predictive Profile (Hi444PP)
- Базируясь на Hi422P, включает еще один вариант кодирования цветности и работу с 14-битной глубиной кодирования.
Для профессионального применения стандарт содержит четыре дополнительных all-Intra («всё внутри») профиля, которые характеризуются отсутствием межкадрового сжатия. То есть, при кодировании одного кадра информация о соседних не используется:
- High 10 Intra Profile
- High 4:2:2 Intra Profile
- High 4:4:4 Intra Profile
- CAVLC 4:4:4 Intra Profile
С принятием расширения Scalable Video Coding (SVC) к стандарту были добавлены три профиля, соответствующие базовым, с добавлением возможности включать потоки более низкого разрешения.
- Scalable Baseline Profile
- Scalable High Profile
- Scalable High Intra Profile
Добавление расширения Multiview Video Coding (MVC) принесло еще два дополнительных профиля:
- Stereo High Profile
- Этот профиль рассчитан на стереоскопическое 3D видео (два изображения).
- Multiview High Profile
- Этот профиль поддерживает два или несколько изображений (каналов) в потоке с использованием как межкадрового, так и межканального сжатия, но не поддерживает некоторые возможности MVC.
Функции | CBP | BP | XP | MP | HiP | Hi10P | Hi422P | Hi444PP |
---|---|---|---|---|---|---|---|---|
I and P slices | Да | Да | Да | Да | Да | Да | Да | Да |
Chroma formats | 4:2:0 | 4:2:0 | 4:2:0 | 4:2:0 | 4:2:0 | 4:2:0 | 4:2:0/4:2:2 | 4:2:0/4:2:2/4:4:4 |
Sample depths (bits) | 8 | 8 | 8 | 8 | 8 | 8 to 10 | 8 to 10 | 8 to 14 |
Flexible macroblock ordering (FMO) | Нет | Да | Да | Нет | Нет | Нет | Нет | Нет |
Arbitrary slice ordering (ASO) | Нет | Да | Да | Нет | Нет | Нет | Нет | Нет |
Redundant slices (RS) | Нет | Да | Да | Нет | Нет | Нет | Нет | Нет |
Data partitioning | Нет | Нет | Да | Нет | Нет | Нет | Нет | Нет |
SI and SP slices | Нет | Нет | Да | Нет | Нет | Нет | Нет | Нет |
B slices | Нет | Нет | Да | Да | Да | Да | Да | Да |
Interlaced coding (PicAFF, MBAFF) | Нет | Нет | Да | Да | Да | Да | Да | Да |
Multiple reference frames | Да | Да | Да | Да | Да | Да | Да | Да |
In-loop deblocking filter | Да | Да | Да | Да | Да | Да | Да | Да |
CAVLC entropy coding | Да | Да | Да | Да | Да | Да | Да | Да |
CABAC entropy coding | Нет | Нет | Нет | Да | Да | Да | Да | Да |
8×8 vs. 4×4 transform adaptivity | Нет | Нет | Нет | Нет | Да | Да | Да | Да |
Quantization scaling matrices | Нет | Нет | Нет | Нет | Да | Да | Да | Да |
Separate Cb and Cr QP control | Нет | Нет | Нет | Нет | Да | Да | Да | Да |
Monochrome (4:0:0) | Нет | Нет | Нет | Нет | Да | Да | Да | Да |
Separate color plane coding | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да |
Predictive lossless coding | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да |
Уровни
Согласно определению стандарта, «уровень» является определенным набором ограничений, указывающих степень требуемой производительности декодера для профиля. Например, поддержка уровня в профиле будет указывать максимальное разрешение изображения, частоту кадров и битрейт так, что декодер можно будет использовать. Декодер, который соответствует данному уровню, обязан декодировать все потоки битов, которые кодируются для этого уровня и для всех более низких уровней.
Уровень | Макс. кол-во макроблоков | Макс. скорость видеопотока (VCL) кбит/с | Примеры максимального разрешения@частоты кадров (макс. кол-во сохраненных кадров) | ||||
---|---|---|---|---|---|---|---|
в секунду | в кадре | BP, XP, MP | HiP | Hi10P | Hi422P, Hi444PP | ||
1 | 1,485 | 99 | 64 | 80 | 192 | 256 | 128×96@30.9 (8) 176×144@15.0 (4) |
1b | 1,485 | 99 | 128 | 160 | 384 | 512 | 128×96@30.9 (8) 176×144@15.0 (4) |
1.1 | 3,000 | 396 | 192 | 240 | 576 | 768 | 176×144@30.3 (9) 320×240@10.0 (3) 352×288@7.5 (2) |
1.2 | 6,000 | 396 | 384 | 480 | 1,152 | 1,536 | 320×240@20.0 (7) 352×288@15.2 (6) |
1.3 | 11,880 | 396 | 768 | 960 | 2,304 | 3,072 | 320×240@36.0 (7) 352×288@30.0 (6) |
2 | 11,880 | 396 | 2,000 | 2,500 | 6,000 | 8,000 | 320×240@36.0 (7) 352×288@30.0 (6) |
2.1 | 19,800 | 792 | 4,000 | 5,000 | 12,000 | 16,000 | 352×480@30.0 (7) 352×576@25.0 (6) |
2.2 | 20,250 | 1,620 | 4,000 | 5,000 | 12,000 | 16,000 | 352×480@30.7(10) 352×576@25.6 (7) 720×480@15.0 (6) 720×576@12.5 (5) |
3 | 40,500 | 1,620 | 10,000 | 12,500 | 30,000 | 40,000 | 352×480@61.4 (12) 352×576@51.1 (10) 720×480@30.0 (6) 720×576@25.0 (5) |
3.1 | 108,000 | 3,600 | 14,000 | 17,500 | 42,000 | 56,000 | 720×480@80.0 (13) 720×576@66.7 (11) 1280×720@30.0 (5) |
3.2 | 216,000 | 5,120 | 20,000 | 25,000 | 60,000 | 80,000 | 1,280×720@60.0 (5) 1,280×1,024@42.2 (4) |
4 | 245,760 | 8,192 | 20,000 | 25,000 | 60,000 | 80,000 | 1,280×720@68.3 (9) 1,920×1,080@30.1 (4) 2,048×1,024@30.0 (4) |
4.1 | 245,760 | 8,192 | 50,000 | 62,500 | 150,000 | 200,000 | 1,280×720@68.3 (9) 1,920×1,080@30.1 (4) 2,048×1,024@30.0 (4) |
4.2 | 522,240 | 8,704 | 50,000 | 62,500 | 150,000 | 200,000 | 1,920×1,080@64.0 (4) 2,048×1,080@60.0 (4) |
5 | 589,824 | 22,080 | 135,000 | 168,750 | 405,000 | 540,000 | 1,920×1,080@72.3 (13) 2,048×1,024@72.0 (13) 2,048×1,080@67.8 (12) 2,560×1,920@30.7 (5) 3,680×1,536@26.7 (5) |
5.1 | 983,040 | 36,864 | 240,000 | 300,000 | 720,000 | 960,000 | 1,920×1,080@120.5 (16) 4,096×2,048@30.0 (5) 4,096×2,304@26.7 (5) |
Патенты
В странах, где действуют патенты на программное обеспечение, разработчики программного обеспечения, использующего алгоритмы H.264/AVC, обязаны платить лицензионные отчисления держателям патентов. Держателями таковых, в частности, являются Microsoft, Fujitsu, Philips, Apple, Samsung, Cisco, Toshiba, Panasonic [2][3]. Также существует организация MPEG LA, которая является администратором консолидированного пула патентов [4][5]. Всего существует более сотни патентов, так или иначе затрагивающих или описывающих алгоритмы H.264. Сроки действия части из них уже истекли, однако некоторые будут продолжать действовать в США вплоть до 2028 года [6][2].
В марте 2011 г. Министерство юстиции США начало расследование против MPEG LA по подозрению в использовании патентного права с целью устранения конкурента — WebM от Google. Поводом к началу расследования стали обвинения в нарушении патентов третьих разработчиков.[7]
Недостатки
Кодеки для MPEG-4 AVC более требовательны к ресурсам, нежели кодеки на основе MPEG-4 ASP (такие, как DivX и XviD)[8], однако это компенсируется другими достоинствами[9].
Формат запатентован, и создатели кодеков обязаны платить за их распространение путём покупки лицензий. С 2011 года MPEG LA могла бы начать взимать плату и с тех, кто участвует в кодировании и/или бесплатном предоставлении пользователям видеопотока в AVC.[10][11] Однако позже этот срок был изменён на 2015 год, а 26 августа 2010 года компания MPEG LA объявила, что за бесплатное предоставление пользователям видеопотока в H.264 плата взиматься не будет.[12]
Примечания
См. также
Ссылки
![]() | |
---|---|
MPEG-1 • 2 • 3 • 4 • 7 • 21 • A • B • C • D • E • V • M • U | |
Разделы MPEG-1 | Part 3: Аудио (Layer I • Layer II • Layer III) |
Разделы MPEG-2 | Part 1: Системы (Транспортный поток • Программный поток) • Part 2: Видео (H.262) • Part 3: Аудио (Layer I • Layer II • Layer III • Многоканальный MPEG) • Part 6: DSM CC • Part 7: AAC |
Разделы MPEG-4 | Part 2: Видео • Part 3: HE-AAC • Part 6: DMIF • Part 10: H.264 • Part 11: Описание сцены • Part 12: Формат медиафайлов ИСО • Part 14: Формат файла MP4 • Part 17: Потоковый текстовый формат • Part 20: Облегченное приложение воспроизведения сцен (LASeR) |
Разделы MPEG-7 | Part 2: Язык описания определений (DDL) |
Разделы MPEG-21 | Parts 2, 3 и 9: Цифровой объект • Part 5: Язык описания прав (REL) |
Разделы MPEG-D | Part 1: Пространственный звук MPEG |
![]() | |
---|---|
Перечни: Перечень стандартов ИСО • Перечень романизаций ISO • Перечень стандартов IEC Категории: Категория:Стандарты ISO • Категория:Протоколы OSI | |
1 по 9999 | 1 • 2 • 3 • 4 • 5 • 6 • 7 • 9 • 16 • 31 (-0, -1, -2, -3, -4, -5, -6, -7, -8, -9, -10, -11, -12, -13) • 128 • 216 • 217 • 226 • 228 • 233 • 259 • 269 • 296 • 302 • 306 • 428 • 639 (-1, -2, -3, -5, -6) • 646 • 690 • 732 • 764 • 843 • 898 • 1000 • 1004 • 1007 • 1073-1 • 1413 • 1538 • 1745 • 2014 • 2015 • 2022 • 2108 • 2145 • 2146 • 2281 • 2709 • 2711 • 2788 • 3029 • 3103 • 3166 (-1, -2, -3) • 3297 • 3307 • 3602 • 3864 • 3901 • 3977 • 4031 • 4157 • 4217 • 5218 • 5775 • 5776 • 5964 • 6166 • 6344 • 6346 • 6425 • 6429 • 6438 • 6523 • 6709 • 7001 • 7002 • 7098 • 7185 • 7388 • 7498 • 7736 • 7810 • 7811 • 7812 • 7813 • 7816 • 8000 • 8217 • 8571 • 8583 • 8601 • 8632 • 8652 • 8691 • 8807 • 8820-5 • 8859 (-1, -2, -3, -4, -5, -6, -7, -8, -9, -10, -11, -12, -13, -14, -15, -16) • 8879 • 9000 • 9075 • 9126 • 9241 • 9362 • 9407 • 9506 • 9529 • 9564 • 9594 • 9660 • 9897 • 9945 • 9984 • 9985 • 9995 |
10000 по 19999 | 10006 • 10118-3 • 10160 • 10161 • 10165 • 10179 • 10206 • 10303 • 10303-11 • 10303-21 • 10303-22 • 10303-238 • 10303-28 • 10383 • 10487 • 10585 • 10589 • 10646 • 10664 • 10746 • 10861 • 10957 • 10962 • 10967 • 11073 • 11170 • 11179 • 11404 • 11544 • 11783 • 11784 • 11785 • 11801 • 11898 • 11940 • 11941 • 11941 (TR) • 11992 • 12006 • 12164 • 12182:1998 • 12207:1995 • 12207:2008 • 12234-2 • 13211 (-1, -2) • 13216 • 13250 • 13399 • 13406-2 • 13407 • 13450 • 13485 • 13490 • 13567 • 13568 • 13584 • 13616 • 14000 • 14031 • 14396 • 14443 • 14496-10 • 14496-14 • 14644 (-1, -2, -3, -4, -5, -6, -7, -8, -9) • 14649 • 14651 • 14698 • 14698-2 • 14750 • 14882 • 14971 • 15022 • 15189 • 15288 • 15291 • 15292 • 15408 • 15444 • 15445 • 15438 • 15504 • 15511 • 15686 • 15693 • 15706 • 15706-2 • 15707 • 15897 • 15919 • 15924 • 15926 • 15926 WIP • 15930 • 16023 • 16262 • 16750 • 17024 • 17025 • 17369 • 17799 • 18000 • 18004 • 18014 • 18245 • 18629 • 18916 • 19005 • 19011 • 19092-1 • 19092-2 • 19114 • 19115 • 19439 • 19501:2005 • 19752 • 19757 • 19770 • 19775-1 • 19794-5 |
20000+ | 20000 • 20022 • 21000 • 21047 • 21827:2002 • 22000 • 23008-2 • 23270 • 23360 • 24613 • 24707 • 25178 • 26000 • 26300 • 26324 • 27000 series • 27000 • 27001 • 27002 • 27003 • 27004 • 27005 • 27006 • 27007 • 27729 • 27799 • 29199-2 • 29500 • 31000 • 32000 • 38500 • 42010 • 50001 • 80000 |
См. также: Все статьи, начинающиеся с «ISO» |
H.264 — Википедия. Что такое H.264
H.264, MPEG-4 Part 10 или AVC (Advanced Video Coding) — лицензируемый стандарт сжатия видео, предназначенный для достижения высокой степени сжатия видеопотока при сохранении высокого качества.
О стандарте
Создан ITU-T Video Coding Experts Group (VCEG) совместно с ISO / IEC Moving Picture Experts Group (MPEG) в рамках совместной программы Joint Video Team (JVT).
Стандарты ITU-T H.264 и ISO/IEC MPEG-4 Part 10 (формальное название — ISO/IEC 14496-10) технически полностью идентичны. Финальный вариант первой версии стандарта был закончен в мае 2003 года.
Используется в цифровом телевидении высокой четкости HDTV и во многих других областях цифрового видео.
Возможности
Стандарт H.264 / AVC / MPEG-4 Part 10 содержит ряд возможностей, позволяющих значительно повысить эффективность сжатия видео по сравнению с предыдущими (такими, как ASP) стандартами, обеспечивая также большую гибкость применения в разнообразных сетевых средах. Основные из них:
- Многокадровое предсказание:
- Использование сжатых ранее кадров в качестве опорных (то есть с заимствованием части материала из них) куда более гибко, чем в предыдущих стандартах. Позволяется использование до 32 ссылок на другие кадры, тогда как в ASP и более ранних число ссылок ограничено одним или, в случае B-кадров, двумя кадрами. Это поднимает эффективность кодирования, так как позволяет кодеру выбирать для компенсации движения между большим количеством изображений. В большинстве сцен данная функция обеспечивает не очень большое улучшение в качестве и не даёт заметного понижения битрейта. Однако, для некоторых сцен, например, с частыми повторяющимися участками, возвратно-поступательным движением и т. п. данный подход при сохранении качества позволяет очень сильно снизить затраты битрейта.
- Независимость порядка воспроизведения изображений и порядка опорных изображений. В предшествующих стандартах устанавливалась жёсткая зависимость между порядком следования изображений для использования при компенсации движения и порядком следования изображений при воспроизведении. В новом стандарте эти ограничения в значительной мере устранены, что позволяет кодеру выбирать порядок изображений для компенсации движения и для воспроизведения с высокой степенью гибкости, которая ограничена только объёмом памяти, который гарантирует возможность декодирования. Устранение ограничения также позволяет в ряде случаев устранить дополнительную задержку, ранее связанную с двунаправленным предсказанием.
- Независимость методов обработки изображений и возможности их использования для предсказания движения. В предшествующих стандартах изображения, закодированные с использованием некоторых методов (например, двунаправленного предсказания), не могли использоваться в качестве опорных для предсказания движения других изображений видеопоследовательности. Устраняя это ограничение, новый стандарт обеспечивает кодеру большую гибкость и, во многих случаях, возможность использовать для предсказания движения изображение, более близкое по содержанию к кодируемому.
- Компенсация движения с переменным размером блока (от 16×16 до 4×4 пикселя) позволяет крайне точно выделять области движения.
- Векторы движения, выводящие за границы изображения. В MPEG-2 и предшествовавших ему стандартах векторы движения могли указывать только на пикселы, находящиеся в границах декодированного опорного изображения. Методика экстраполяции за границы изображения, появившаяся как опция в H.263, включена в новый стандарт.
- Шеститочечная фильтрация компонента яркости для полупиксельного предсказания с целью уменьшения зубчатости краев и, в конечном счёте, обеспечения большей чёткости изображения.
- Точность до четверти пиксела (Qpel) при компенсации движения обеспечивает очень высокую точность описания движущихся областей (что особенно актуально для медленного движения). Цветность, как правило, хранится с разрешением, уменьшенным вдвое по вертикали и горизонтали (прореживание цвета), поэтому компенсация движения для компонента цветности использует точность в одну восьмую пиксела цветности.
- Взвешенное предсказание, позволяющее использовать масштабирование и сдвиг после компенсации движения на величины, указанные кодером. Такая методика может чрезвычайно сильно поднять эффективность кодирования для сцен с изменением освещённости, например при эффектах затемнения, постепенного появления изображения.
- Пространственное предсказание от краёв соседних блоков для I-кадров (в отличие от предсказания только коэффициента трансформации в H.263+ и MPEG-4 Part 2, и дискретно-косинусного коэффициента в MPEG-2 Part 2). Новая методика экстраполяции краёв ранее декодированных частей текущего изображения повышает качество сигнала, используемого для предсказания.
- Сжатие макроблоков без потерь:
- Метод представления макроблоков без потерь в PCM, при котором видеоданные представлены непосредственно, позволяющий точно описывать определённые области и допускающий строгое ограничение на количество закодированных данных для каждого макроблока.
- Улучшенный метод представления макроблоков без потерь, позволяющий точно описывать определённые области, при этом обычно затрачивая существенно меньше битов, чем PCM (поддерживается не во всех профилях).
- Гибкие функции чересстрочного сжатия (поддерживается не во всех профилях):
- Адаптивное к изображению кодирование полей (PAFF), позволяющее кодировать каждый кадр как кадр или как пару полей (полукадров) — в зависимости от отсутствия\наличия движения.
- Адаптивное к макроблокам кодирование полей (MBAFF), позволяющее независимо кодировать каждую вертикальную пару макроблоков (блок 16×32) как прогрессивные или чересстрочные. Позволяет использовать макроблоки 16×16 в режиме разбиения на поля (сравните с 16×8 полумакроблоками в MPEG-2). Почти всегда эффективнее PAFF.
- Новые функции преобразования:
- Точное целочисленное преобразование пространственных блоков 4×4 (концептуально подобное широко известному DCT, но упрощенное и способное обеспечить точное декодирование[1]), позволяющее точное размещение разностных сигналов с минимумом шума, часто возникающего в предыдущих кодеках.
- Точное целочисленное преобразование пространственных блоков 8×8 (концептуально подобное широко известному DCT, но упрощенное и способное обеспечить точное декодирование; поддерживается не во всех профилях), обеспечивающее большую эффективность сжатия схожих областей, чем 4×4.
- Адаптивный выбор кодеком между размерами блока 4×4 и 8×8 (поддерживается не во всех профилях).
- Дополнительное преобразование Адамара, применяемое к дискретно-косинусным коэффициентам основного пространственного преобразования (к коэффициентов яркости, и, в особом случае, цветности) для достижения большей степени сжатия в однородных областях.
- Квантование:
- Логарифмическое управление длиной шага для упрощения распределения битрейта кодером и упрощенного вычисления обратной длины квантования.
- Частотно-оптимизированные матрицы масштабирования квантования, выбираемые кодером для оптимизации квантования на основе человеческих особенностей восприятия (поддерживается не во всех профилях).
- Внутренний фильтр деблокинга в цикле кодирования, устраняющий артефакты блочности, часто возникающие при использовании основанных на DCT техниках сжатия изображений.
- Энтропийное кодирование квантованных коэффициентов трансформации:
- Context-adaptive binary arithmetic coding (CABAC, контекстнозависимое адаптивное бинарное арифметическое кодирование) — алгоритм сжатия без потерь для синтаксических элементов видеопотока на основе вероятности их появления. Поддерживается только в Main Profile и выше. Обеспечивает более эффективное сжатие, чем CAVLC, но требует значительно больше времени на декодирование.
- Context-adaptive variable-length coding (CAVLC, контекстнозависимое адаптивное кодирование с переменной длиной кодового слова) — альтернатива CABAC меньшей сложности. Тем не менее, оно сложнее и эффективнее, чем алгоритмы, применяемые для тех же целей в более ранних технологиях сжатия видео (как правило это алгоритм Хаффмана).
- Часто используемое, простое и высоко структурированное кодирование словами переменной длины многих элементов синтаксиса, не закодированных CABAC или CAVLC, известное как коды Голомба (экспоненциальное кодирование Голомба).
- Функции устойчивости к ошибкам:
- Определение уровня сетевой абстракции (NAL), позволяющее использовать один и тот же синтаксис видео в различных сетевых окружениях, включая наборы параметров последовательности (sequence parameter sets, SPSs) и наборы параметров изображения (picture parameter sets, PPSs), которые обеспечивают большую надёжность и гибкость, чем предыдущие технологии.
- Гибкое упорядочивание макроблоков (FMO), также известное как группы частей (поддерживается не во всех профилях) и произвольное упорядочивание частей (ASO) — методы реструктурирования порядка представления фундаментальных областей (макроблоков) в изображениях. При эффективном использовании гибкое упорядочивание макроблоков может существенно повысить устойчивость к потере данных.
Благодаря ASO, так как каждая часть изображения может быть декодирована независимо от других (при определённых ограничениях кодирования), новый стандарт позволяет посылать и получать их в произвольном порядке друг относительно друга. Это может снизить задержку в приложениях реального времени, особенно при использовании на сетях, имеющих режим работы доставка вне очереди. Эти функции могут также использоваться для множества других целей помимо восстановления ошибок.
- Разбиение данных — функция, обеспечивающая разделение данных разной важности (например, векторы движения и другая информация предсказания имеет большую значимость для представления видеоконтента) по разным пакетам данных с разными уровнями защиты от ошибок (поддерживается не во всех профилях).
- Избыточные части. Возможность посылки кодером избыточного представления областей изображений, позволяя воспроизвести области изображений (обычно с некоторой потерей качества), данные о которых были потеряны в процессе передачи (поддерживается не во всех профилях).
- Нумерация кадров, позволяющая создание «подпоследовательностей» (включая временно́е масштабирование включением дополнительных кадров между другими) а также обнаружение (и скрытие) потерь целых кадров при сбоях канала или пропаже пакетов.
Профили
Стандарт определяет комплекты возможностей, которые называются профили, ориентированные на конкретные классы приложений.
- Baseline Profile (Базовый профиль)
- Применяется в недорогих продуктах, требующих дополнительной устойчивости к потерям. Используется для видеоконференций и в мобильных продуктах. Включает все возможности Constrained Baseline Profile и, дополнительно, возможности для большей устойчивости к потерям при передаче. С появлением Constrained Baseline Profile отошёл на второй план, так как все потоки Constrained Baseline Profile соответствуют Baseline Profile, и оба этих профиля имеют общий код идентификатора.
- Constrained Baseline Profile (Ограниченный базовый профиль)
- Рассчитан на применение в недорогих продуктах. Включает набор возможностей, общих для профилей Baseline, Main, и High профилей.
- Main Profile (Основной профиль)
- Применяется для цифрового телевидения стандартной четкости в трансляциях, использующих сжатие MPEG-4 в соответствии со стандартом DVB.
- Extended Profile (Расширенный профиль)
- Предназначен для потокового видео, имеет относительно высокую степень сжатия и дополнительные возможности для повышения устойчивости к потере данных.
- High Profile (Высокий профиль)
- Является основным для цифрового вещания и видео на оптических носителях, особенно для телевидения высокой четкости. Используется для Blu-Ray видеодисков и DVB HDTV вещания.
- High 10 Profile (Высокий профиль 10)
- Дополнительно поддерживает 10-битовую глубину кодирования изображения.
- High 4:2:2 Profile (Hi422P)
- В основном нацелен на профессиональное использование при работе с чересстрочным видеопотоком. Поддерживает дополнительный вариант кодирования цветности.
- High 4:4:4 Predictive Profile (Hi444PP)
- Базируясь на Hi422P, включает ещё один вариант кодирования цветности и работу с 14-битной глубиной кодирования.
Для профессионального применения стандарт содержит четыре дополнительных all-Intra профиля, которые характеризуются отсутствием межкадрового сжатия. То есть, при кодировании одного кадра информация о соседних не используется:
- High 10 Intra Profile
- High 4:2:2 Intra Profile
- High 4:4:4 Intra Profile
- CAVLC 4:4:4 Intra Profile
С принятием расширения Scalable Video Coding (SVC) к стандарту были добавлены три профиля, соответствующие базовым, с добавлением возможности включать потоки более низкого разрешения.
- Scalable Baseline Profile
- Scalable High Profile
- Scalable High Intra Profile
Добавление расширения Multiview Video Coding (MVC) принесло ещё два дополнительных профиля:
- Stereo High Profile
- Этот профиль рассчитан на стереоскопическое 3D видео (два изображения).
- Multiview High Profile
- Этот профиль поддерживает два или несколько изображений (каналов) в потоке с использованием как межкадрового, так и межканального сжатия, но не поддерживает некоторые возможности MVC.
Функции | CBP | BP | XP | MP | HiP | Hi10P | Hi422P | Hi444PP |
---|---|---|---|---|---|---|---|---|
I and P slices | Да | Да | Да | Да | Да | Да | Да | Да |
Chroma formats | 4:2:0 | 4:2:0 | 4:2:0 | 4:2:0 | 4:2:0 | 4:2:0 | 4:2:0/4:2:2 | 4:2:0/4:2:2/4:4:4 |
Sample depths (bits) | 8 | 8 | 8 | 8 | 8 | 8 to 10 | 8 to 10 | 8 to 14 |
Flexible macroblock ordering (FMO) | Нет | Да | Да | Нет | Нет | Нет | Нет | Нет |
Arbitrary slice ordering (ASO) | Нет | Да | Да | Нет | Нет | Нет | Нет | Нет |
Redundant slices (RS) | Нет | Да | Да | Нет | Нет | Нет | Нет | Нет |
Data partitioning | Нет | Нет | Да | Нет | Нет | Нет | Нет | Нет |
SI and SP slices | Нет | Нет | Да | Нет | Нет | Нет | Нет | Нет |
B slices | Нет | Нет | Да | Да | Да | Да | Да | Да |
Interlaced coding (PicAFF, MBAFF) | Нет | Нет | Да | Да | Да | Да | Да | Да |
Multiple reference frames | Да | Да | Да | Да | Да | Да | Да | Да |
In-loop deblocking filter | Да | Да | Да | Да | Да | Да | Да | Да |
CAVLC entropy coding | Да | Да | Да | Да | Да | Да | Да | Да |
CABAC entropy coding | Нет | Нет | Нет | Да | Да | Да | Да | Да |
8×8 vs. 4×4 transform adaptivity | Нет | Нет | Нет | Нет | Да | Да | Да | Да |
Quantization scaling matrices | Нет | Нет | Нет | Нет | Да | Да | Да | Да |
Separate Cb and Cr QP control | Нет | Нет | Нет | Нет | Да | Да | Да | Да |
Monochrome (4:0:0) | Нет | Нет | Нет | Нет | Да | Да | Да | Да |
Separate color plane coding | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да |
Predictive lossless coding | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да |
Уровни
Согласно определению стандарта, «уровень» является определенным набором ограничений, указывающих степень требуемой производительности декодера для профиля. Например, поддержка уровня в профиле будет указывать максимальное разрешение изображения, частоту кадров и битрейт так, что декодер можно будет использовать. Декодер, который соответствует данному уровню, обязан декодировать все потоки битов, которые кодируются для этого уровня и для всех более низких уровней.
Уровень | Макс. кол-во макроблоков | Макс. скорость видеопотока (VCL) кбит/с | Примеры максимального разрешения@частоты кадров (макс. кол-во сохранённых кадров) | ||||
---|---|---|---|---|---|---|---|
в секунду | в кадре | BP, XP, MP | HiP | Hi10P | Hi422P, Hi444PP | ||
1 | 1,485 | 99 | 64 | 80 | 192 | 256 | 128×96@30,9 (8) 176×144@15,0 (4) |
1b | 1,485 | 99 | 128 | 160 | 384 | 512 | 128×96@30,9 (8) 176×144@15,0 (4) |
1.1 | 3,000 | 396 | 192 | 240 | 576 | 768 | 176×144@30,3 (9) 320×240@10,0 (3) 352×288@7,5 (2) |
1.2 | 6,000 | 396 | 384 | 480 | 1,152 | 1,536 | 320×240@20,0 (7) 352×288@15,2 (6) |
1.3 | 11,880 | 396 | 768 | 960 | 2,304 | 3,072 | 320×240@36,0 (7) 352×288@30,0 (6) |
2 | 11,880 | 396 | 2,000 | 2,500 | 6,000 | 8,000 | 320×240@36,0 (7) 352×288@30,0 (6) |
2.1 | 19,800 | 792 | 4,000 | 5,000 | 12,000 | 16,000 | 352×480@30,0 (7) 352×576@25,0 (6) |
2.2 | 20,250 | 1,620 | 4,000 | 5,000 | 12,000 | 16,000 | 352×480@30,7 (10) 352×576@25,6 (7) 720×480@15,0 (6) 720×576@12,5 (5) |
3 | 40,500 | 1,620 | 10,000 | 12,500 | 30,000 | 40,000 | 352×480@61,4 (12) 352×576@51,1 (10) 720×480@30,0 (6) 720×576@25,0 (5) |
3.1 | 108,000 | 3,600 | 14,000 | 17,500 | 42,000 | 56,000 | 720×480@80,0 (13) 720×576@66,7 (11) 1280×720@30,0 (5) |
3.2 | 216,000 | 5,120 | 20,000 | 25,000 | 60,000 | 80,000 | 1280×720@60,0 (5) 1280×1024@42,2 (4) |
4 | 245,760 | 8,192 | 20,000 | 25,000 | 60,000 | 80,000 | 1280×720@68,3 (9) 1920×1080@30,1 (4) 2048×1024@30,0 (4) |
4.1 | 245,760 | 8,192 | 50,000 | 62,500 | 150,000 | 200,000 | 1280×720@68,3 (9) 1920×1080@30,1 (4) 2048×1024@30,0 (4) |
4.2 | 522,240 | 8,704 | 50,000 | 62,500 | 150,000 | 200,000 | 1920×1080@64,0 (4) 2048×1080@60,0 (4) |
5 | 589,824 | 22,080 | 135,000 | 168,750 | 405,000 | 540,000 | 1920×1080@72,3 (13) 2048×1024@72,0 (13) 2048×1080@67,8 (12) 2560×1920@30,7 (5) 3680×1536@26,7 (5) |
5.1 | 983,040 | 36,864 | 240,000 | 300,000 | 720,000 | 960,000 | 1920×1080@120,5 (16) 4096×2048@30,0 (5) 4096×2304@26,7 (5) |
5.2 | 2,073,600 | 36,864 | 240,000 | ? | ? | ? | 1,920×1,080@172 (?) 2,048×1,536@160 (?) 4,096×2,160@60 (?) |
6 | 4,177,920 | 139,264 | 240,000 | ? | ? | ? | 2,048×1,536@300 (?) 4,096×2,160@120 (?) 8,192×4,320@30 (?) |
6.1 | 8,355,840 | 139,264 | 480,000 | ? | ? | ? | 2,048×1,536@300 (?) 4,096×2,160@240 (?) 8,192×4,320@60 (?) |
6.2 | 16,711,680 | 139,264 | 800,000 | ? | ? | ? | 4,096*2,304@300 (?) 8,192×4,320@120 (?) |
Патенты
В странах, где действуют патенты на программное обеспечение, разработчики программного обеспечения, использующего алгоритмы H.264/AVC, обязаны платить лицензионные отчисления держателям патентов. Держателями таковых, в частности, являются Microsoft, Fujitsu, Philips, Apple, Samsung, Cisco, Toshiba, Panasonic[2][3]. Также существует организация MPEG LA, которая является администратором консолидированного пула патентов[4][5]. Всего существует более сотни патентов, так или иначе затрагивающих или описывающих алгоритмы H.264. Сроки действия части из них уже истекли, однако некоторые будут продолжать действовать в США вплоть до 2028 года[6][2].
В марте 2011 г. Министерство юстиции США начало расследование против MPEG LA по подозрению в использовании патентного права с целью устранения конкурента — WebM от Google. Поводом к началу расследования стали обвинения в нарушении патентов третьих разработчиков[7].
Недостатки
Кодеки для MPEG-4 AVC более требовательны к ресурсам, нежели кодеки на основе MPEG-4 ASP (такие, как DivX и XviD)[8], однако это компенсируется другими достоинствами[9].
Формат запатентован, и создатели кодеков обязаны платить за их распространение путём покупки лицензий. С 2011 года MPEG LA могла бы начать взимать плату и с тех, кто участвует в кодировании и/или бесплатном предоставлении пользователям видеопотока в AVC[10][11]. Однако позже этот срок был изменён на 2015 год, а 26 августа 2010 года компания MPEG LA объявила, что за бесплатное предоставление пользователям видеопотока в H.264 плата взиматься не будет[12].
Примечания
См. также
Ссылки
Формат сжатия H.264,что это за формат?
H.264, MPEG-4 Part 10 или AVC (Advanced Video Coding) — лицензируемый стандарт сжатия видео, предназначенный для достижения высокой степени сжатия видеопотока при сохранении высокого качества. Применяется для более рационального использования устройств хранения и передачи данных. Кодер H.264 без ущерба для качества изображения может снижать размер файла цифрового видео более чем на 80% по сравнению с форматом Motion JPEG и на 50% — по сравнению со стандартом MPEG-4 Part 2. Что означает гораздо меньшие требования к полосе пропускания для передачи и объему памяти для хранения видеофайла. Или же, с другой стороны, возможность получения гораздо лучшего качества видеоизображения при той же скорости передачи данных. На сегодняшний день формат H.264 является одним из самых прогрессивных и отвечающих современным требованиям алгоритмов компрессии.
Стандарт H.264 предназначен для технических решений в следующих областях:
- Трансляции по сети, через спутник, через DSL соединения и т.д.
- Интерактивный или постоянные хранения данных на оптических и магнитных носителях (DVD, HDD)
- Потоковое мультимедиа по сети и т.д.
Благодаря своим преимуществам перед MPEG-4 и M-JPEG, H.264 может стать форматом номер один в системах видеонаблюдения. Сжатие видеоизображения заключается в удалении избыточных видеоданных или сокращении их объема, благодаря чему файлы с оцифрованным видео удается эффективно передавать по сети и хранить. При сжатии к исходному видеоизображению применяется определенный алгоритм. Применение обратного алгоритма позволяет практически без потерь восстановить оригинальное видеоизображение. В стандарте H.264 технология сжатия видеоизображения вышла на новый уровень: появилась более совершенная схема внутреннего предсказания, используемая для кодирования I-кадров. Благодаря этой схеме количество битов, необходимых для хранения I-кадра, значительно снижается, а качество изображения остается неизменным. Получить такой результат удается за счет использования моноблоков меньшего размера. Поиск совпадающих пикселов теперь осуществляется среди ранее закодированных пикселов, расположенных по краям нового макроблока. Значения этих пикселов используются повторно. В результате объем, который занимает изображение, значительно уменьшается.
В H.264, кроме того, усовершенствован механизм поблочной компенсации движения, который используется для кодирования P- и B-кадров. Кодировщик H.264 может по своему выбору осуществлять поиск совпадающих блоков (с точностью до субпиксела) в произвольном количестве областей одного или нескольких опорных кадров. Размер и форма блока также могут меняться, если при этом совпадение получается более точным. Для построения областей кадра, в которых нет совпадающих блоков, используются моноблоки с внутренним кодированием. Столь гибкий подход к компенсации движения оправдывает себя, например, при наблюдении за людными местами, когда требуется обеспечить также и качество изображения. Для компенсации движения выделяется большая часть ресурсов, отведенных видеокодеру. Поэтому от того, каким образом и насколько полно реализован этот алгоритм, зависит эффективность сжатия видеоизображения кодировщиком H.264.
При использовании H.264 удается также уменьшить количество артефактов блочности, характерных для Motion JPEG и других стандартов MPEG. Для этой цели в цикле кодирования используется внутренний фильтр деблокинга. В результате применения адаптивных алгоритмов удается сгладить края блоков и получить на выходе видеоизображение почти идеального качества.
В системах видеонаблюдения H.264, скорее всего, будет использоваться, в первую очередь, для решения задач, требующих больших скоростей передачи данных и высокого разрешения, например, в системах наблюдения за автомагистралями, в аэропортах и казино, где 30 к/с является нормой. В таких системах применение новой технологии позволит снизить требования к ширине каналов и объемам дискового пространства и приведет к значительной экономии.
Сравнение шести H.264 видеокодеков c DivX 5
ВведениеОсновная задача настоящего тестирования — сравнить результаты работы нового поколения MPEG4-кодеков (называемых MPEG-4 AVC или H.264) при записи домашнего видео простыми пользователями. Такие пользователи, как правило, используют простые известные программы для того, чтобы считывать DVD или оцифровывать сигнал с тюнера и редко изменяют настройки кодеков. Мы прекрасно понимаем, что писать кодеки так, чтобы они хорошо работали в разных ситуациях без специальной настройки (автоматически подстраиваясь под тип видео) сложнее, но тем больше чести авторам, если их кодеки хорошо справляются с такой задачей. DivX Pro 5 использовался для сравнения, как один из лучших кодеков предыдущего поколения, стандарта MPEG-4 ASP. Подробнее о разновидностях MPEG-4 можно прочитать здесь.
Использованные кодеки
КОДЕК | ПРОИЗВОДИТЕЛЬ | ВЕРСИЯ | ОБОЗНАЧЕНЫ НА ГРАФИКАХ |
dicas | 0.10 | AVC | |
MoonLight | 0.1.2546 | MoonLight | |
Main Concept | 1.04.02.00 | MainConcept | |
Fraunhofer IIS | от 25.11.2004 | Fraunhofer | |
Ateme | 1.0.3.2 | Ateme | |
Videosoft H.264 codec main | Videosoft | 2.1.0.2 | VSS_main |
DivXNetworks | 5.1.1 | DivX 5.1.1 |
Учитывая специфику H.264 (очень большое время работы при включении «по максимуму» всех опций и возможностей), мы в дальнейшем введем два набора настроек, получаемых от производителей кодеков (и только от них). Первый набор — «tuned» — настройки, дающие максимальное качество, но долгую работу и «fast» — настройки, обеспечивающие быструю работу, но с меньшим качеством. Причем и время, и качество будут измеряться в обоих случаях. Это позволит кодекам продемонстрировать, на что они способны по качеству и даст возможность более корректно сравнивать скорость, чем в варианте сравнения настроек по умолчанию. Часть 1: Методика тестирования
Метрика PSNR
Описание метрики
В рамках данного тестирования критерием качества сжатия служит метрика PSNR (peak signal to noise ratio/пиковое отношение сигнала к шуму, измеряется в дБ). Использование именно этой метрики обусловлено ее популярностью. Ее используют в большинстве научных статей и сравнений в качестве меры потерь качества. Как и все существующие метрики, она не идеальна и имеет свои достоинства и недостатки. Для понимания приведенных ниже цифр, необходимо знать лишь то, что значение метрики тем больше, чем больше разница между сравниваемыми изображениями.
Примечание: PSNR – это наиболее общепринятая метрика для оценки различий между двумя последовательностями. Несомненно, у неё есть множество недостатков. Можно придумать огромное количество последовательностей, на которых эта метрика не совсем адекватно себя ведёт. Например, два кадра, яркость одного из которых подняли на одну единицу (из, скажем, 255). Или два кадра, отличающихся одним пикселем – на первом пиксель белый, а на втором – чёрный. В обоих примерах вы с трудом сможете уловить различия в кадрах на глаз, но с точки зрения PSNR кадры будут значительно отличаться! Однако, несмотря на все недостатки, именно метрикой PSNR до сих пор пользуется большинство разработчиков кодеков для анализа своих результатов. Эта метрика понимается и признаётся всеми профессионалами в области кодирования видео. Именно по этой причине мы выбрали PSNR в качестве основной метрики.
Смысл графиков PSNR/Frame size
На графике изображена зависимость показателя метрики от среднего размера кадра. Каждая ветвь соответствует определенному кодеку. Ветви построены на опорных точках, каждая из которых соответствует конкретному битрейту. Хорошо видно, что на каждой ветви находится по десять точек (каждая последовательность сжимается на 10 настройках битрейта). Бывает, что кодек не удерживает битрейт и с разными настройками битрейта сжимает одинаково. В таких случаях, очевидно, на ветви кодека расположено менее десяти опорных точек. Для сравнения кодеков на этих графиках следует обращать внимание на то, как высоко расположены ветви кодеков. Чем выше находится ветвь – тем выше в среднем качество последовательности, сжатой данным кодеком. На вышеприведенном в качестве примера рисунке видно, что на высоком битрейте Videosoft сжал последовательность с меньшими потерями качества по сравнению с другими кодеками.
Методика тестирования
Последовательность действий
В тестировании участвует девять фильмов (см. ниже). Каждый фильм сжимается десять раз с разными битрейтами (кбит/с): 100, 225, 340, 460, 700, 938, 1140, 1340, 1840, 2340. Таким образом, для каждого кодека генерируется 50 фильмов. Затем для каждого фильма вычисляется метрика PSNR. Причем указанная метрика вычисляется для каждого кадра. Далее для построения графика используются соответствующие числа, в зависимости от типа графика.
Задачи и правила тестирования
- Подсчет PSNR производился с помощью программы luv_avi.
- Размер кадра считался как частное размера фильма и количества кадров.
- Значение ординаты на графиках Delta вычисляется как разница PSNR для этих кодеков и кодека DivX.
- При тестировании кодеков, которые накладывают свой логотип на сжатый фильм, логотип заменялся на черный прямоугольник и на исходный несжатый фильм накладывался такой же прямоугольник. Далее производилось сравнение
- Для кодеков, являющихся VfW (Video for Windows), сжатие проводилось при помощи программы VirtualDub 1.5.4.
- Для кодеков, работающих по интерфейсу DirectShow, сжатие проводилось при помощи программы GraphEdit (build 011008).
- Для кодеков, которые устанавливались как отдельные приложения для сжатия, сжатие проводилось при помощи этого приложения.
- Для кодеков, которые сжимали фильм не в формат avi, а в свой внутренний формат, для получения avi использовалась программа GraphEdit (build 011008) и декодер, поставляемый с кодеком.
- Кодек MainConcept вставлял лишние кадры в декодированную последовательность. Для покадрового сравнения приходилось удалять эти кадры вручную при помощи программы VirtualDub. При этом файл считался пригодным для сравнения, если в исправленном фильме последний кадр визуально совпадал с последним кадром в исходным фильме.
Основной задачей ставилась сравнительная оценка качества кодеков при их непрофессиональном использовании для сжатия фильмов. Соответственно оценка проводилась на последовательностях, обработанных простым распространенным фильтром деинтерлейсинга, а параметры кодека брались по умолчанию. Правила тестирования:
Самый распространённый вопрос по поводу этого тестирования – «А с какими настройками тестировались кодеки?». В полном тексте документа, в разных местах мы ответили на него 8 раз – с настройками по умолчанию! Это означает следующее. Мы брали чистую операционную систему и инсталлировали на неё кодек. Настройки, которые он выставил при этом, мы считали настройками по умолчанию. В процессе тестирования мы меняли только один параметр – битрейт. Таким образом, чтобы посмотреть все параметры, вам надо всего лишь заново проинсталлировать интересующий вас кодек.
Последовательности
Число кадров | Разрешение и цветовое пространство | |
bankomatdi | 376 | 704 x 352 (RGB) |
battle | 1599 | 704 x 288 (RGB) |
bbc3di | 374 | 704 x 576 (RGB) |
foreman | 300 | 352 x 288 (RGB) |
susidi | 374 | 704 x 576 (RGB) |
На разных последовательностях кодеки показывают разные результаты. Например, эффективно сжать последовательность из одинаковых кадров намного легче, чем последовательность, состоящую из существенно различающихся картинок. Есть и другие характеристики последовательностей – размер кадров, зашумлённость, длина последовательности, тип движения камеры и т.д. Для нашего тестирования мы выбрали стандартные последовательности. Многими из них пользуются производители кодеков для тестирования своих продуктов. Конечно, эти последовательности не покрывают всего множества фильмов – тут нет ни мультфильмов, ни видео с тюнера. В дальнейшем мы планируем расширить число последовательностей.Часть 2: Графики по PSNR для всех кодеков
Графики Y-PSNR — Frame Size
На этих графиках хорошо видна динамика зависимости качества сжатого фильма от его размера. Координатами опорных точек диаграммы являются средние по фильму значения метрики и размера кадра. Таким образом, каждая ветвь имеет по десять точек, соответствующих разным битрейтам.
Delta Y-PSNR – это графики относительного PSNR. В качестве референсного кодека выбран DivX 5.1.1. Для каждого замера на графике конкретного кодека бралась разница этого замера и значения PSNR для референсного кодека с тем же битрейтом. При отсутствии значения, PSNR референсного кодека получался линейной интерполяцией.
Y-PSNR Sequence battle
Delta Y-PSNR Sequence battle
Выводы
- На низких битрейтах DivX сильно уступает кодекам VSS_main, Fraunhofer, Ateme.
- На средних и высоких битрейтах кодек от Ateme опережает все остальные кодеки.
В полной версии сравнения представлены другие типы графиков для различных последовательностей и видеокодеков: V-PSNR, U-PSNR , Y-difference и bitrate-handling.
Часть 3: Покадровое сравнение видеокодеков
На этих графиках хорошо видно, как изменяется качество сжатия отдельных кадров кодеками. По оси X отложены номера соответствующих кадров, а по оси Y – PSNR кодеков при сравнении с оригиналом.
Sequence bankomatdi. Bitrate 100 kb/sec
Sequence bankomatdi. Bitrate 2340 kb/sec
Часть 4: Визуальное сравнение видеокодековВ сжатых последовательностях разные кадры имеют различное качество, зависящее от многих параметров, как самой последовательности, так и настроек кодека. Например, на качество кадра влияет такой параметр, как тип этого кадра – сжатый независимо, с учётом одного предыдущего или нескольких кадров (I, P и B кадры). Для разных кодеков один и тот же кадр последовательности может иметь различное качество. Например, если мы найдём кадр, который первый кодек закодировал независимо, а второй – с использованием предыдущего, то, скорее всего, кадр первого кодека будет смотреться лучше. Таким образом, для любых двух кодеков в последовательности можно найти кадры, на которых один из кодеков смотрится лучше другого. Для визуального сравнения мы выбирали кадры, на которых разница между кодеками максимальна. Сравнение проводилось между кодеками от компании Ateme и компании DivXNetworks, Inc.
- Битрейт 700 Кбит/с.
- Последовательности для сравнения: bbc3di и foreman.
Последовательность bbc3di, кадр 280
Последовательность foreman, кадр 282
Выводы
- При одинаковом значении метрики PSNR кодеки стандарта H.264 показывают заметно лучшее визуальное качество.
- Большинство кодеков явно оптимизированы для достижения максимальной скорости кодирования на сегодняшних конфигурациях и не используют всех возможностей, предоставляемых форматом H.264.
При сравнении кодеков всегда хочется узнать, кто же в итоге лучший. Часто при ответе на подобные вопросы возникают заключения вроде «H.264 лучше DivX на 45%!». Однако кодеки можно сравнивать по многим параметрам – качеству сжатых последовательностей, способности держать заданный битрейт, быстродействию, удобству использованию, размеру инсталлятора, красоте логотипа и т.д. Причём для разных задач отдельные параметры могут быть неодинаково важны. Например, если вы хотите сжимать телевизионный сигнал, для вас важна скорость работы кодека, если записывать сжатые фильмы на CD – то немаловажна точность соблюдения битрейта, а если решили сделать архив оцифрованного видео – то, скорее всего, определяющим фактором является качество сжатых последовательностей.
Как было сказано выше, данный текст является сильно сокращенным и откомментированным вариантом сравнения видеокодеков, предназначенного в первую очередь для профессиональных пользователей и производителей кодеков. Полный вариант этого тестирования имеет объем 70 pdf-страниц, содержит сравнения всех указанных в начале статьи видеокодеков, множество графиков и рисунков, не приведенных в данной статье.
Мы выражаем благодарность компаниям Moonlight Cordless LTD, Fraunhofer Institute for Integrated Circuits IIS и Ateme за любезно предоставленные для данного тестирования кодеки, недоступные публично.
[Все статьи в разделе «Цифровое Видео»]
Использование кодека H.264 в вещании
Тип компрессии Н.264, больше известный под названием MPEG-4 Part 10 Advanced Video Codec, достаточно быстро стал превалирующим стандартом видеокомпрессии для телевизионной индустрии.
Четвертое поколение кодеков, H.264 становится популярным даже среди контента для ведущих мобильных устройств. Производители устанавливают поддержку кодека практически во все устройства. Такая универсальность предполагает использование кодека повсеместно. Но это же качество делает кодек гораздо сложнее в настройках для оптимального использования, чем его предшественники. Он требует более высоких технологических мощностей для кодирования и декодирования процессов, что ограничивает его использование в устройствах низшей ценовой категории.
Это одна из тем, по которой ведутся многочисленные дискуссии о введении H.264 во все фазы телевизионного производства и о том, как быстро нужно адаптировать потоковую медиаиндустрию что бы полностью изменить ее цифровую сущность.
Что такое H.264?
H.264/MPEG-4 part10 AVC – передовая, на сегодняшний день, технология компрессии –результат коллективной работы команды известной как Joint Video Team (JVT). Группа была основана членами ITU (International Telecommunication Union) и (MPEG) Motion Picture Expert Group и опубликовала свой первый технический документ – спецификацию ITU-T H.264 и ISO/IES MPEG-4 Part 10 в 2003 году. Тогда же команда специалистов заверила, что кодек будет адоптирован и принят в производство телекоммуникационной и телевизионной индустрией уже вскоре.
Спецификация MPEG-4 определяет 27 отдельных и часто совместимых стандартов, названных Частями (Part), которые могут применяться в телевидении. Но некоторые из них не совместимы и не имеют никакого отношения к стандарту Part 10. Только Н.264 эквивалентен спецификации MPEG4 Part10. Что бы избежать конфузов следует придерживаться только этих понятий в подборе оборудования для производства.
H.264, в свою очередь, имеет также много подразделов, именуемых профилями, каждый из которых имеет свои специфические качества и пределы применений. Некоторые из них вытесняются более современными профилями. Спецификации меняются так часто, как происходит замена профилей.
Вещателям наиболее интересен Constrained Baseline Profile, который используется для интернет вещания и вещания для мобильных устройств с 2009 года. Для телевизионного наземного вещания используется Main Profile. Scalable High и Scalable High-Intra профиль, который был выделен из профиля High в 2007 году используется в видео продакшен и в некоторых широкополосных сетях. Также H.264 был стандартизирован для 3D видео начиная с 11-ой версии, учитывая возможное его применение в будущем в 3D телевидении.
H.264 унаследовал от своих предыдущих трех поколений кодеков основные направления в методиках кодирования, но с более развитым математическим аппаратом и с соответственными преимуществами.
— Кадры цифрового видео анализируются, сравниваются с предыдущими и последующими кадрами, детектируются тождественности и отличия. Как результат прогнозируется изображение воспроизводимого кадра и в последнем этапе, если данные теряются, то они восстанавливаются из предыдущих данных.
— Выбор различных алгоритмов кодирования для оптимального просчета процессов и контроль над их многообразием – особенность кодека. Это важно в оптимизации кодирования для узких полос пропускания и устройств с ограниченным разрешением.
Преимущества H.264
Кодек имеет несколько преимуществ, а именно:
— Низкий bit rate при высоком уровне качества. Это особенно важно для кабельных, спутниковых, а в Украине особенно важно для эфирных, операторов. Вместо одного канала с кодированием MPEG2, можно вместить два — с кодированием H.264. Это существенно удешевляет вещание и дает возможность вещать в приемлемом качестве там, где технологии передачи данных ограничены в полосе пропускания.
— Приемлемое качество изображение при низком bit rate. Это качество можно использовать в ограниченных полосах пропускания, например для мобильных устройств. Во многих случаях MPEG-4 является единственным возможным стандартом вещания при низком bit rate.
— Меньше технологий на рынке — больше аудитория. Если вы хотели бы добавить новую форму вещания, то шансы есть только у технологий кодирования базирующихся на H.264. Решения с использованием головных станций и инфраструктуры, поддерживающих MPEG-4, будет значительно дешевле, чем использование каких-то необычных устройств.
-Лучшая совместимость на долгое время. Выбор устройств поддерживающих H.264 постоянно расширяется, а в скором будущем каждое медиаустройство будет иметь встроенный кодек H.264. и так будет продолжаться до тех пор, пока это метод компрессии не сменит другой. Но он должен быть настолько революционным, что на его создание уйдут многие годы.
— Низкая стоимость внедрения. Невысокая конкуренция со стороны остальных стандартов приведет к быстрому росту рынка и понижению цены на продукты, также мы сможем наблюдать постепенное снижение спроса на дорогие мультистандартные устройства. Производство устройств совмещающих в себе кодер и плеер будет расти.
Оптимизация H.264 для телевидения
С гибкостью приходят и сложности. И H.264 не исключение. Установки кодера H.264 для вашего решения могут быть простыми, если выбрать их нажатием одной кнопки «по умолчанию». На самом деле оптимальная настройка кодера очень сложна. Только одна популярная библиотека настроек кодека H.264 имеет более 200 конфигураций .
К счастью наиболее распространенные set’ы имеются в шаблонах, тем не менее, лучшие возможности проигрывания видео могут быть выбраны только путем тщательной индивидуальной настройки в пользовательском интерфейсе.
Есть несколько критичных пунктов, которые особенно важны для H.264.
— Постоянный (CBR) и переменный (VBR) bit rate. При постоянном bit rate, а приблизительно половина трафика имеет CBR, нет никаких вопросов относительно сложности или других факторов, которые бы расширяли полосу пропускания. Это очень хорошее качество для потоков для мобильных устройств, потому что они имеют узкую полосу пропускания и не очень мощный процессор, которому легче обрабатывать постоянный поток данных без пиковых нагрузок. CBR также удобно использовать в интернет вещании, используя адаптивный стриминг. Потому что плеер автоматически переключается вперед и назад между различными потоками. А CBR помогает плееру синхронизироваться и воспроизводить видео бесшовно и стабильно.
Но CBR не оптимален со стороны качества, потому что поток не изменяется в зависимости от динамики и сложности видео. В то время как специфика VBR позволяет в необходимых сложных местах повышать bit rate и снижать степень сжатия для получения более качественного изображения. Это необходимо в сценах с быстрым движением мелких предметов. С другой стороны, больше битов — шире полоса пропускания. Это может создать большие проблемы. Поэтому если вы нуждаетесь в качественном H.264, скачайте фильм заранее.
— Размеры макроблока. Подобно другим кодекам H.264 создает в захваченном кадре индивидуальные распределения, называемые макроблоками. Компрессия видео и компенсационная технология, которая создает магическое сжатие каждого макроблока, в конечном счете, прогнозирует кадр, рассчитываемый из разницы между конечным и начальным макроблоками. Старые кодеки имели фиксированную величину макроблока 16х16 пикселей, но H.264 позволяет выбирать изменять этот размер. Несмотря на то, что минимальный размер блока составляет 4х4 пикселя, в особых случаях блоки могут уменьшаться до 1 пикселя, то есть не компрессироваться.
Малые, средние и большие блоки, чередуясь в кадрах, адаптивно регулируют процесс кодирования, способствуя получению оптимального изображения и в значительной мере определяя нагрузку процессора во время real-time кодирования. Для кодирования в вещательных решениях предпочтительно использовать минимальные макроблоки, но настолько что бы не вызвать пропуска кадров или других задержек связанных с отставанием компрессора. Увеличение размера макроблоков можно добиться, при необходимости, путем предварительной фильтрации изображения (например, блюринг). Главное определиться с компромиссом этих параметров.
Большинство профессиональных кодеров имеет возможность автоматически изменять размер макроблока при смене размера выходного кадра.
-GOP структура. Group of Picture (GOP) обычно изменяется так часто, как требуется вставить полный кадр, для воспроизведения прогнозируемых кадров без существенных потерь. Ваш выбор настроек может существенно повлиять на процесс кодирования. Большинство кодеров имеют автоматическую возможность вовремя вставлять в сцену полный кадр. Однако некоторый контент, например, как новости, имеет частые смены сцен, и частая автоматическая вставка полных кадров может привести к большим задержкам. Я помню одно такое устройство, которое не стартовало, если в новом футаже не было первого полного кадра. Ну, это из ряда вон, но увеличение структуры GOP за счет полных кадров может создать дополнительную задержку потока на 1-2 секунды. Если кэш устройства переполнится, то зрителей начнут раздражать стоп-кадры и рассыпание видео.
Таким образом, используя некоторые настройки кодека можно адаптировать изображение для конкретных задач.
P.S. Я бы не стал питать больших иллюзий по поводу качества вещания DVB-T2 в Украине. Используемый профиль с 8-битным преобразованием не позволит, даже при самых оптимальных решениях, поднять четкость ТВЛ выше 400. То есть четкость останется на том же уровне, что и сейчас. А размеры экранов в домохозяйствах за последние годы выросли в два раза. Да, конечно, уйдут эфирные помехи и шумы в зонах слабого и неуверенного приема. Но добавятся природные искажения, вносимые кодированием со скоростью потока всего лишь 2,5 мБс. Выход один – очень нежно фильтровать высокие частоты, увеличивая размер макроблоков, но без фанатизма. Как это сделать в отдельно взятой телекомпании с, как правило, непредсказуемым контентом – отдельная головная боль главных инженеров.
H.264 — Вікіпедія
H.264/MPEG-4 AVC — міжнародний стандарт відеокомпресії. Був розроблений групою фахівців організації ITU (Study Group 16, фахівці з відео-кодування) під назвою H.26L. У 2001 році група ITU об’єдналась з MPEG-Visual та розробку стандарту було продовжено в команді Joint Video Team (JVT). Метою проекту була розробка методів стиснення відео-даних, що гарантували б, у порівнянні з існуючими, щонайменше вдвічі менший бітрейт зі збереженням рівня якості як для мобільних приладів, так і для телебачення. У 2003 році обидві організації затвердили стандарт. Назва стандарту ITU: H.264. Стандарт ISO/IEC має назву MPEG-4/AVC (Advanced Video Coding) і є десятою частиною стандарту MPEG-4 (MPEG-4/Part 10, ISO/IEC 14496-10).
З прийняттям розширення Scalable Video Coding (SVC) до стандарту були додані три профілі, що відповідають базовим, з додаванням можливості включати потоки більш низької роздільної здатності.
- Scalable Baseline Profile
- Scalable High Profile
- Scalable High Intra Profile
Додавання розширення Multiview Video Coding (MVC) принесло ще два додаткових профілі:
- Stereo High Profile — розрахований на стереоскопічне 3D-відео (два зображення).
- Multiview High Profile — підтримує два або кілька зображень (каналів) в потоці з використанням як міжкадрового, так і міжканального стиснення, але не підтримує деякі можливості MVC.
На початку 1998 р «Експертна група з кодування відео» (Video Coding Experts Group) (VCEG – ITU-T SG16 Q.6) оголосила конкурс пропозицій щодо проекту під назвою H.26L, метою якого було збільшити вдвічі ефективність кодування (що означає зменшення необхідного бітрейту вдвічі для даного рівня якості) в порівнянні з будь-яким іншим стандартом відео кодування. VCEG очолив Гаррі Салліван (Microsoft, попередньо PictureTel, США). Перший проект дизайну для цього нового стандарту був прийнятий в серпні 1999 р. У 2000 р. співголовою VCEG став Thomas Wiegand (Heinrich Hertz Institute, Німеччина).
В грудні 2001 р. VCEG і Moving Picture Experts Group (MPEG – ISO/IEC JTC 1/SC 29/WG 11) з метою доопрацювати стандарт кодування відео створили Joint Video Team (JVT).[1] Офіційне затвердження специфікації відбулося в березні 2003 року. JVT очолював (і очолює) Gary Sullivan, Thomas Wiegand, і Ajay Luthra (Motorola, США: згодом Arris, США). У червні 2004 року проект розширення точності відтворення (FRExt) був завершений. З січня 2005 по листопад 2007 року JVT працював над розширенням стандарту H.264/AVC в напрямку масштабованості, за допомогою підтримки Annex (G), і це розширення має назву Scalable Video Coding (SVC). До адміністративної команди JVT долучився Jens-Rainer Ohm (Університет Аахена, Німеччина). З липня 2006 року по листопад 2009 року JVT працювала над Multiview Video Coding (MVC), додатком до H.264/AVC для об’ємного телебачення і тривимірного телебачення. Ця робота включала в себе створення двох нових розділів стандарту: «Multiview High Profile» і «Stereo High Profile».
Енкодер H.264 виконує процеси прогнозування, перетворення і кодування для створення стисненого потоку біт в форматі H.264. Декодер H.264 виконує відповідний процес декодування, зворотнього перетворення і реконструкції для відтворення відеопослідовності.
Процес кодування[ред. | ред. код]
Прогнозування[ред. | ред. код]
Енкодер обраховує кадр по частинам, які називаються макроблоками (16×16 пікселів зображення). Він отримує дані для прогнозування макроблоків на основі попередньо-закодованих даних, або на основі поточного кадру (інтрапрогнозування) або на основі інших кадрів, які вже було закодовано і передано (інтерпрогнозування). Енкодер виділяє прогнозовану інформацію із поточного макроблоку і утворює залишок (корисну різницю). Пошук підхожого інтерпрогнозування зазвичай описують як оцінку руху[en], а виділення інтерпрогнозування із поточного макроблоку як компенсацію руху.
Методи прогнозування, які використовуються в стандарті H.264, є більш гнучкими, ніж ті, що використовувались в попередніх стандартах, що дозволяє робити точне передбачення, а як наслідок — більш ефективне стиснення. Інтрапрогнозування використовує розміри блоків 16×16 і 4×4 для того, щоб передбачати макроблок із оточуючих, попередно закодованих пікселів в рамках одного і того ж кадру.
Інтерпрогнозування використовує набір з різних розміром блоків (від 16×16 до 4×4) для прогнозування пікселів в поточному кадрі із схожих регіонів попередньо закодованих кадрів.
Перетворення і квантування[ред. | ред. код]
Блок виділених зразків перетворюється за допомогою цілочисленого перетворення розмірністю 4×4 або 8×8, що є приблизно подібною формою дискретного косинусного перетворення (ДКП). Перетворення дає в результаті набір коефіцієнтів, кожен з яких є зваженим значенням для стандартного базисного зразку. При поєднанні зважений базисний зразок відтворює блок виділених зразків.
Результат перетворення, блок коефіцієнтів перетворення, квантується, тобто кожен коефіцієнт ділиться на ціле значення. Квантування знижує точність коефіцієнтів перетворення відповідно до значення параметру квантування (QP). Зазвичай, результатом є блок, в якому більшість коефіцієнтів дорівнюють нулю, із декількома не нульовими коефіцієнтами. Великі значення QP означатимуть, що більше коефіцієнтів будуть мати значення нуль, що призведе до сильного стиснення, що коштуватиме поганою якістю зображення. Мале значення параметру QP означатиме, що більше не нульових коефіцієнтів залишиться після квантування, що дасть кращу якість декодованого зображення, але малу ефективність стискання.
Кодування бітового потоку[ред. | ред. код]
Процес відеокодування утворює в результаті набір значень, які повинні кодуватися для того, щоб утворити стиснений бітовий потік. Цими даними є:
- Квантовані коефіцієнти перетворення
- інформація, необхідна декодеру для відтворення прогнозування
- інформація про структуру стиснених даних і засоби стиснення, що використовувалися під час кодування
- інформація про повну відеопослідовність.
Ці значення і параметри (синтаксичні елементи) перетворюються в бінарні коди із використанням кодування змінної довжини і/або арифметичного кодування. Кожен з цих методів кодування дозволяє отримати ефективне, компактне бінарне представлення інформації. Закодований бітовий потік можна зберігати і/або передавати.
Процес декодування[ред. | ред. код]
Декодування бітового потоку[ред. | ред. код]
Відеодекодер отримує стиснений бітовий потік H.264, розбирає всі синтаксичні елементи і декодує інформацію, описану вище (квантовані коефіцієнти трансформації, інформацію прогнозування, і ін.). Ця інформація використовується для зворотнього процесу кодування і відтворення послідовності відеозображень.
Масштабування і зворотне перетворення[ред. | ред. код]
Коефіцієнти перетворення маштабовано. Кожен коефіцієнт помножено на ціле число, для збереження його початкової розмірності. При зворотньому перетворенні поєднуються стандартні базисні зразки, зваженими за допомогою перемасштабованих коефіцієнтів, щоб відновити кожен блок із залишкових даних. Ці блоки поєднуються разом, щоб сформувати макроблок із залишку.
Реконструкція[ред. | ред. код]
Для кожного макроблоку декодер формує прогнозування, ідентичне тому, що було створено енкодером. Декодер додає дані прогнозування до декодованого залишку для відтворення декодованого макроблоку, який далі можна відобразити як частину відеокадру.