Войти
| Расширенное кодирование видео для общих аудиовизуальных услуг | |
| Статус | Действующий |
|---|---|
| Год начала | 2003 |
| Последняя версия | июнь 2019 |
| Организация | ITU-T (SG16 ), ISO, IEC |
| Комитет | VCEG, MPEG |
| Базовые стандарты | H.261, H.262 (также известный как MPEG-2 Video ), H.263, MPEG-1 |
| Связанные стандарты | H. 265, H.266 |
| Домен | сжатие видео |
| Веб-сайт | https://www.itu.int/rec/T-REC-H.264 |
Расширенный Кодирование видео (AVC ), также упоминаемое как H.264 или MPEG-4 Часть 10, расширенное кодирование видео (MPEG-4 AVC ) - это стандарт сжатия видео, основанный на блочно-ориентированном кодировании с компенсацией движений целочисленным DCT. Это, безусловно, наиболее часто используемый формат для записи, сжатия и распространения видеоконтента, который по состоянию на сентябрь 2019 года использовался 91% разработчиков видеоиндустрии. Он поддерживает разрешения до 8K UHD.
Целью проекта H.264 / AVC было создание стандарта, способного обеспечить хорошее качество видео при существенно более низкой скорости передачи данных, чем предыдущие стандарты (т. е. половину или меньшую скорость передачи MPEG-2, H.263 или MPEG-4 Part 2 ), не увеличивая сложность конструкции настолько, что это было бы непрактично или чрезмерно дорого в реализации. Это было достигнуто с помощью таких функций, как целочисленное дискретное косинусное преобразование с уменьшенной сложностью (целочисленное DCT), сегментация переменного размера блока и межкадровое предсказание для нескольких изображений . Дополнительная цель заключалась в обеспечении достаточной гибкости, позволяющей применять стандарт к широкому спектру приложений в самых разных сетях и системах, включая низкие и высокие скорости передачи данных, видео низкого и высокого разрешения, широковещательную передачу, DVD хранилище, RTP /IP пакетные сети и ITU-T мультимедийные системы телефонии. Стандарт H.264 можно рассматривать как «семейство стандартов», состоящее из ряда различных профилей, хотя его «высокий профиль», безусловно, является наиболее часто используемым форматом. Конкретный декодер декодирует по крайней мере один, но не обязательно все профили. Стандарт описывает формат закодированных данных и то, как данные декодируются, но не определяет алгоритмы кодирования видео - это оставлено открытым, поскольку разработчики кодировщиков могут выбирать сами, и было разработано большое количество схем кодирования. развит. H.264 обычно используется для сжатия с потерями, хотя также возможно создавать действительно кодированные без потерь области в изображениях с потерями с кодированием или для поддержки редких случаев использования, для которых полное кодирование без потерь.
H.264 был стандартизирован ITU-T группой экспертов по кодированию видео (VCEG) Исследовательской группы 16 вместе с ISO / IEC JTC1 Группа экспертов по движущимся изображениям (MPEG). Проект партнерства известен как Joint Video Team (JVT). Стандарт ITU-T H.264 и стандарт ISO / IEC MPEG-4 AVC (формально ISO / IEC 14496-10 - MPEG-4 Part 10, Advanced Video Coding) поддерживаются совместно, так что они имеют идентичное техническое содержание. Окончательная редакционная работа над первой версией стандарта была завершена в мае 2003 г., и в последующие редакции были добавлены различные расширения его возможностей. Высокоэффективное кодирование видео (HEVC), также известное как H.265 и MPEG-H Part 2, является преемником H.264 / MPEG-4 AVC, разработанным теми же организациями, хотя более ранние стандарты все еще широко используются.
H.264, пожалуй, наиболее известен как наиболее часто используемый формат кодирования видео на дисках Blu-ray. Он также широко используется для потоковой передачи интернет-источников, таких как видео с Netflix, Hulu, Prime Video, Vimeo, YouTube и iTunes Store, веб-программное обеспечение, такое как Adobe Flash Player и Microsoft Silverlight, а также различные HDTV вещает по наземному (ATSC, ISDB-T, DVB-T или DVB-T2 ), кабельному (DVB- C ) и спутниковые (DVB-S и DVB-S2 ) системы.
H.264 защищен патентами, принадлежащими различным сторонам. Лицензия, охватывающая большинство (но не все) патентов, существенных для H.264, находится в ведении патентного пула, администрируемого MPEG LA.
. Коммерческое использование запатентованных технологий H.264 требует оплаты роялти MPEG LA и другим владельцам патентов. MPEG LA разрешил бесплатное использование технологий H.264 для потоковой передачи Интернет-видео, которое является бесплатным для конечных пользователей, и Cisco Systems выплачивает роялти MPEG LA от имени пользователей двоичных файлов за его открытый источник кодировщик H.264.
Имя H.264 соответствует соглашению об именах ITU-T, где стандарт является членом линии H.26x стандартов кодирования видео VCEG ; имя MPEG-4 AVC связано с соглашением об именах в ISO /IEC MPEG, где стандарт является частью 10 ISO / IEC 14496, который является набор стандартов, известный как MPEG-4. Стандарт был разработан совместно VCEG и MPEG после ранее проведенных работ по разработке в ITU-T в качестве проекта VCEG под названием H.26L. Таким образом, принято ссылаться на стандарт под такими именами, как H.264 / AVC, AVC / H.264, H.264 / MPEG-4 AVC или MPEG-4 / H.264 AVC, чтобы подчеркнуть общее наследие. Иногда его также называют «кодеком JVT» в связи с организацией Joint Video Team (JVT), которая его разработала. (Такое партнерство и множественное именование не редкость. Например, стандарт сжатия видео, известный как MPEG-2, также возник в результате партнерства между MPEG и ITU-T, где видео MPEG-2 известно Сообщество ITU-T как H.262.) Некоторые программы (такие как медиаплеер VLC ) внутренне идентифицируют этот стандарт как AVC1.
В начале 1998 года Группа экспертов по кодированию видео (VCEG - ITU-T SG16 Q.6) отправила запрос для предложений по проекту под названием H.26L с целью удвоить эффективность кодирования (что означает уменьшение вдвое скорости передачи данных, необходимой для данного уровня точности) по сравнению с любыми другими существующими стандартами кодирования видео для широкого спектра приложений. VCEG возглавлял Гэри Салливан (Microsoft, ранее PictureTel, США). Первый проект проекта этого нового стандарта был принят в августе 1999 года. В 2000 году Томас Виганд (Институт Генриха Герца, Германия) стал сопредседателем VCEG.
В декабре 2001 г. VCEG и Группа экспертов по движущемуся изображению (MPEG - ISO / IEC JTC 1 / SC 29 / WG 11) сформировали Объединенную группу по видео ( JVT) с уставом для доработки стандарта кодирования видео. Официальное утверждение спецификации было получено в марте 2003 года. Председателями JVT были Гэри Салливан, Томас Виганд и Аджай Лутра (Motorola, США: позже Аррис, США). В июле 2004 г. был завершен проект Fidelity Range Extensions (FRExt). С января 2005 г. по ноябрь 2007 г. JVT работала над расширением H.264 / AVC в сторону масштабируемости с помощью Приложения (G) под названием Scalable Video Coding (SVC). Команда менеджеров JVT была расширена Йенсом-Райнером Ом (RWTH Aachen University, Германия). С июля 2006 г. по ноябрь 2009 г. JVT работала над Multiview Video Coding (MVC), расширением H.264 / AVC в сторону 3D-телевидения и ограниченного диапазона бесплатно- Точка зрения телевидения. Эта работа включала разработку двух новых профилей стандарта: Multiview High Profile и Stereo High Profile.
В процессе разработки стандарта были разработаны дополнительные сообщения для содержания дополнительной информации о расширении (SEI). Сообщения SEI могут содержать различные типы данных, которые указывают синхронизацию видеоизображений или описывают различные свойства кодированного видео или способы его использования или улучшения. Также определены сообщения SEI, которые могут содержать произвольные пользовательские данные. Сообщения SEI не влияют на основной процесс декодирования, но могут указывать, как видео рекомендуется обрабатывать или отображать. Некоторые другие высокоуровневые свойства видеоконтента передаются в информации о пригодности видео (VUI), например, указание цветового пространства для интерпретации видеоконтента. По мере разработки новых цветовых пространств, например, для видео с расширенным динамическим диапазоном и с широкой цветовой гаммой, для их обозначения были добавлены дополнительные идентификаторы VUI.
Стандартизация первой версии H.264 / AVC была завершена в мае 2003 года. В первом проекте по расширению исходного стандарта затем была разработана JVT. то, что называлось Fidelity Range Extensions (FRExt). Эти расширения обеспечили более качественное кодирование видео, поддерживая увеличенную точность выборки битовой глубины и информацию о цвете с более высоким разрешением, включая структуры выборки, известные как Y′C BCR 4: 2: 2 (также известные как YUV 4: 2 : 2 ) и 4: 4: 4. В проект FRExt также были включены несколько других функций, таких как добавление целочисленного дискретного косинусного преобразования 8 × 8 (целочисленное DCT) с адаптивным переключением между преобразованиями 4 × 4 и 8 × 8, определяемое кодером перцепционное матрицы взвешивания на основе квантования, эффективное межкадровое кодирование без потерь и поддержка дополнительных цветовых пространств. Проектные работы по проекту FRExt были завершены в июле 2004 года, а черновые работы по ним были завершены в сентябре 2004 года.
Затем были разработаны пять других новых профилей (см. Версию 7 ниже), предназначенных в первую очередь для профессиональных приложений, добавление поддержки цветового пространства расширенной гаммы, определение дополнительных индикаторов соотношения сторон, определение двух дополнительных типов «дополнительной информации улучшения» (подсказка после фильтра и отображение тонов) и отказ от одного из предыдущих профилей FRExt (High 4: 4: 4 профиль), на что указывают отзывы отрасли, должен был быть разработан иначе.
Следующей важной функцией, добавленной к стандарту, было Масштабируемое кодирование видео (SVC). Определенный в Приложении G к H.264 / AVC, SVC позволяет создавать потоки битов, которые содержат уровни подпотоков битов, которые также соответствуют стандарту, включая один такой поток битов, известный как «базовый уровень», который может быть декодирован с помощью H. 264 / AVC кодек, не поддерживающий SVC. Для масштабируемости временного битового потока (то есть наличия подпотока с меньшей временной частотой дискретизации, чем основной битовый поток), полные блоки доступа удаляются из битового потока при получении подпотока. В этом случае синтаксис высокого уровня и опорные изображения с межкадровым предсказанием в потоке битов строятся соответственно. С другой стороны, для пространственной масштабируемости и масштабируемости качественного битового потока (то есть наличия подпотока с более низким пространственным разрешением / качеством, чем у основного битового потока), NAL (Уровень абстракции сети ) удаляется из битового потока. при выводе подпотока. В этом случае межуровневое предсказание (то есть предсказание сигнала с более высоким пространственным разрешением / качеством на основе данных сигнала с более низким пространственным разрешением / качеством) обычно используется для эффективного кодирования. Расширения масштабируемого кодирования видео были завершены в ноябре 2007 года.
Следующей важной функцией, добавленной к стандарту, было Кодирование видео с несколькими экранами (MVC). Определенный в Приложении H к H.264 / AVC, MVC позволяет создавать потоки битов, которые представляют более одного представления видео сцены. Важным примером этой функциональности является кодирование стереоскопического 3D видео. В работе MVC были разработаны два профиля: профиль Multiview High поддерживает произвольное количество просмотров, а профиль Stereo High разработан специально для стереоскопического видео с двумя ракурсами. Расширения Multiview Video Coding были завершены в ноябре 2009 года.
Позже были разработаны дополнительные расширения, которые включали кодирование 3D-видео с совместным кодированием карт глубины и текстуры (называемые 3D-AVC), стереоскопическое кодирование с поддержкой кадров (MFC) с несколькими разрешениями и кодирование 3D-MFC, различные дополнительные комбинации функций, а также более высокие размеры кадров и частоту кадров.
Версии стандарта H.264 / AVC включают следующие завершенные редакции, исправления и поправки (даты - даты окончательного утверждения в ITU-T, а окончательное утверждение «Международного стандарта» даты в ISO / IEC несколько отличаются и в большинстве случаев немного позже). Каждая версия представляет изменения относительно следующей более низкой версии, которая интегрирована в текст.
Следующие организации владеют одним или несколькими патентами в пуле патентов MPEG LA H.264 / AVC.
| Организация | Активные патенты | Патенты с истекшим сроком действия | Всего патентов |
|---|---|---|---|
| Panasonic Corporation | 1,137 | 60 | 1,197 |
| Godo Kaisha IP Bridge | 1,111 | 19 | 1,130 |
| LG Electronics | 949 | 41 | 990 |
| Dolby Laboratories | 759 | 16 | 775 |
| Toshiba | 358 | 33 | 391 |
| Microsoft | 208 | 7 | 215 |
| Nippon Telegraph and Telephone (включая NTT Docomo ) | 187 | 2 | 189 |
| Sony | 116 | 31 | 147 |
| Общество Фраунгофера | 125 | 16 | 141 |
| 136 | 3 | 139 | |
| GE Сжатие видео | 136 | 0 | 136 |
| Fujitsu | 102 | 4 | 106 |
| Mitsubishi Electric | 54 | 50 | 104 |
| ООО «Тагиван II» | 77 | 0 | 77 |
| Samsung Electronics | 23 | 40 | 63 |
| Maxell | 51 | 2 | 53 |
| Philips | 5 | 39 | 44 |
| Vidyo | 41 | 2 | 43 |
| Ericsson | 34 | 0 | 34 |
| Научно-исследовательский институт электроники и телекоммуникаций (ETRI) Кореи | 32 | 0 | 32 |
Видеоформат H.264 имеет очень широкий диапазон приложений, охватывающий все формы цифрового сжатого видео, от приложений потоковой передачи через Интернет с низкой скоростью передачи данных до приложений для телевещания HDTV и приложений цифрового кино с кодированием практически без потерь. Сообщается, что при использовании H.264 достигается снижение скорости передачи данных на 50% или более по сравнению с MPEG-2 Part 2. Например, сообщалось, что H.264 обеспечивает такое же качество цифрового спутникового ТВ, что и текущие реализации MPEG-2, с менее чем половиной битрейта, при этом текущие реализации MPEG-2 работают со скоростью около 3,5 Мбит / с, а H.264 - только с 1,5. Мбит / с. Sony утверждает, что режим записи AVC со скоростью 9 Мбит / с эквивалентен качеству изображения формата HDV, который использует приблизительно 18–25 Мбит / с.
Для обеспечения совместимости и отсутствия проблем После принятия H.264 / AVC многие органы по стандартизации внесли поправки или добавили в свои стандарты, связанные с видео, чтобы пользователи этих стандартов могли использовать H.264 / AVC. И формат Blu-ray Disc, и формат HD DVD, производство которого сейчас прекращено, включают H.264 / AVC High Profile как один из трех обязательных форматов сжатия видео. Проект цифрового видеовещания (DVB ) одобрил использование H.264 / AVC для телевещания в конце 2004 года.
Комитет по передовым телевизионным системам (ATSC) Орган по стандартизации в Соединенных Штатах одобрил использование H.264 / AVC для телевещания в июле 2008 года, хотя стандарт еще не используется для фиксированных передач ATSC в Соединенных Штатах. Он также был одобрен для использования с более поздним стандартом ATSC-M / H (мобильный / портативный), использующим части AVC и SVC H.264.
Рынки CCTV (замкнутое телевидение) и видеонаблюдение включили эту технологию во многие продукты.
Многие распространенные зеркалки используют видео H.264, заключенное в контейнеры QuickTime MOV, в качестве собственного формата записи.
AVCHD - это формат записи высокой четкости, разработанный Sony и Panasonic, в котором используется H.264 (соответствующий H.264 при добавлении дополнительных функций и ограничений для конкретных приложений).
AVC-Intra - это формат сжатия только внутри кадра, разработанный Panasonic.
XAVC - формат записи, разработанный Sony, который использует уровень 5.2 для H. 264 / MPEG-4 AVC, что является наивысшим уровнем, поддерживаемым этим видеостандартом. XAVC может поддерживать разрешение 4K (4096 × 2160 и 3840 × 2160) со скоростью до 60 кадров в секунду (кадров в секунду). Sony объявила, что камеры, поддерживающие XAVC, включают две камеры CineAlta - Sony PMW-F55 и Sony PMW-F5. Sony PMW-F55 может записывать XAVC с разрешением 4K при 30 кадрах в секунду при 300 Мбит / с и разрешением 2K при 30 кадрах в секунду при 100 Мбит / с. XAVC может записывать разрешение 4K со скоростью 60 кадров в секунду с выборкой цветности 4: 2: 2 со скоростью 600 Мбит / с.
Блок-схема H.264 H. 264 / AVC / MPEG-4 Part 10 содержит ряд новых функций, которые позволяют сжимать видео намного эффективнее, чем старые стандарты, и обеспечивают большую гибкость для применения в самых разных сетевых средах. В частности, некоторые из таких ключевых функций включают в себя:
Эти методы, наряду с некоторыми другими, помогают H.264 работать значительно лучше, чем любой предшествующий стандарт, в самых разных обстоятельствах и в самых разных средах приложений. H.264 часто может работать радикально лучше, чем видео MPEG-2, обычно обеспечивая такое же качество при половинной или меньшей скорости передачи данных, особенно при высокой скорости передачи и видеоконтенте с высоким разрешением.
Как и другие стандарты ISO / IEC. Стандарты видео MPEG, H.264 / AVC имеет эталонную программную реализацию, которую можно бесплатно загрузить. Его основная цель - дать примеры функций H.264 / AVC, а не быть полезным приложением как таковым. Некоторая работа по проектированию эталонного оборудования также проводилась в Экспертной группе по движущимся изображениям. Вышеупомянутые аспекты включают функции во всех профилях H.264. Профиль кодека - это набор функций этого кодека, определенных для соответствия определенному набору спецификаций предполагаемых приложений. Это означает, что многие из перечисленных функций не поддерживается в некоторых профилях. Различные профили H.264 / AVC обсуждаются в следующем разделе.
Стандарт определяет несколько наборов возможностей, которые называются профилями, ориентированными на определенные классы приложений. Они объявляются с использованием кода профиля (profile_idc), а иногда и набора дополнительных ограничений, применяемых в кодировщике. Код профиля и указанные ограничения позволяют декодеру распознавать требования для декодирования этого конкретного битового потока. (И во многих системных средах разрешено использовать только один или два профиля, поэтому декодерам в этих средах не нужно заботиться о распознавании менее часто используемых профилей.) Безусловно, наиболее часто используемым профилем является профиль High Profile.
Профили для немасштабируемых приложений 2D-видео включают следующее:
Для видеокамер, монтажных и профессиональных приложений стандарт содержит четыре дополнительных профиля только внутри кадра, которые определены как простые подмножества других соответствующих профилей. В основном они предназначены для профессиональных приложений (например, камеры и системы редактирования):
В результате масштабируемого кодирования видео (SVC) Расширение стандарт содержит пять дополнительных масштабируемых профилей, которые определены как комбинация профиля H.264 / AVC для базового уровня (идентифицируемого вторым словом в имени масштабируемого профиля) и инструментов, которые достигают масштабируемого расширения:
В результате Multiview Video Coding (MVC), стандарт содержит два профиля с несколькими экранами:
В расширение Multi-Resolution Frame-Compatible (MFC) добавлено два другие профили:
3D-AVC добавлено еще два профиля:
| Функция | CBP | BP | XP | MP | ProHiP | HiP | Hi10P | Hi422P | Hi444PP |
|---|---|---|---|---|---|---|---|---|---|
| I и P сегменты | Да | Да | Да | Да | Да | Да | Да | Да | Да |
| Битовая глубина (на выборку) | 8 | 8 | 8 | 8 | 8 | 8 | от 8 до 10 | от 8 до 10 | от 8 до 14 |
| форматов цветности | 4: 2: 0.. | 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 |
| Гибкое упорядочивание макроблоков (FMO) | No | Да | Да | No | No | No | No | No | Нет |
| Произвольное упорядочение срезов (ASO) | No | Да | Да | No | No | No | No | No | Нет |
| Избыточные срезы (RS) | No | Да | Да | No | No | No | No | No | Нет |
| Разделение данных | No | No | Да | No | No | No | No | No | Нет |
| Срезы SI и SP | No | No | Да | No | No | No | No | No | Нет |
| Чересстрочное кодирование (PicAFF, MBAFF) | No | No | Да | Да | No | Да | Да | Да | Да |
| B-срезы | No | No | Да | Да | Да | Да | Да | Да | Да |
| Несколько опорных кадров | Да | Да | Да | Да | Да | Да | Да | Да | Да |
| Внутрицикловый фильтр деблокирования | Да | Да | Да | Да | Да | Да | Да | Да | Да |
| Энтропийное кодирование CAVLC | Да | Да | Да | Да | Да | Да | Да | Да | Да |
| CABAC энтропийное кодирование | No | No | No | Да | Да | Да | Да | Да | Да |
| 4: 0: 0 ( Монохромный ) | No | No | No | No | Да | Да | Да | Да | Да |
| Адаптивность преобразования 8 × 8 против 4 × 4 | No | No | No | No | Да | Да | Да | Да | Да |
| Матрицы масштабирования квантования | No | No | No | No | Да | Да | Да | Да | Да |
| Отдельно C B и C R Контроль качества | No | No | No | No | Да | Да | Да | Да | Да |
| Раздельное кодирование цветовой плоскости | No | No | No | No | No | No | No | No | Да |
| Прогнозирующее кодирование без потерь | No | No | No | No | No | No | No | No | Да |
Поскольку этот термин используется в стандарте, "уровень" означает указанный набор ограничений, которые указывают степень требуемой производительности декодера для профиля. Например, уровень поддержки в профиле определяет максимальное разрешение изображения, частоту кадров и скорость передачи данных, которые может использовать декодер. Декодер, который соответствует данному уровню, должен быть способен декодировать все потоки битов, закодированные для этого уровня и всех более низких уровней.
| Уровень. | Максимальная. скорость декодирования. (макроблоков / с) | Максимальный. размер кадра. (макроблоки) | Максимальная скорость передачи видео. для видео. уровень кодирования (VCL). (ограниченная базовая линия,. базовая линия, расширенная. и основные профили). (кбит / с) | Примеры для высокого разрешения. при максимальной частоте кадров. (максимальное количество сохраненных кадров) Переключить дополнительные сведения. |
|---|---|---|---|---|
| 1 | 1,485 | 99 | 64 | 128 × [email#160;protected] (8) 176 × [email#160;protected] (4) |
| 1b | 1,485 | 99 | 128 | 128 × 96 @ 30.9 (8) 176 × [email#160;protected] (4) |
| 1.1 | 3000 | 396 | 192 | 176 ×[email#160;protected] ( 9). 320 × [email#160;protected] (3) 352 × [email#160;protected] (2) |
| 1.2 | 6000 | 396 | 384 | [email#160;protected] (7) [email#160;protected] (6) |
| 1.3 | 11,880 | 396 | 768 | 320 × [email#160;protected] (7) 352 × [email#160;protected] (6) |
| 2 | 11,880 | 396 | 2,000 | 320 ×[email#160;protected] (7) 352 × [email#160;protected] (6) |
| 2.1 | 19,800 | 792 | 4,000 | 352 · [email#160;protected] (7) 352 · [email#160;protected] (6) |
| 2,2 | 20,250 | 1,620 | 4,000 | [email#160;protected],7 (12). [email#160;protected],6 (10). [email#160;protected],0 (6) 720 × [email#160;protected],5 (5) |
| 3 | 40,500 | 1,620 | 10,000 | [email#160;protected],4 (12). [email#160;protected],1 (10). 720 × [email#160;protected] (6) 720 × [email#160;protected] (5) |
| 3,1 | 108000 | 3600 | 14000 | 720 × 480 @ 80,0 (13). 720 × [email#160;protected],7 (11) 1,280 × 720 @ 30,0 (5) |
| 3,2 | 216000 | 5120 | 20,000 | 1,280 × 720 @ 60,0 (5) 1,280 × 1024 @ 42,2 (4) |
| 4 | 245,760 | 8,192 | 20,000 | 1,280 × 720 @ 68,3 ( 9). 1920 × 1080 @ 30,1 (4) 2048 × 1024 @ 30,0 (4) |
| 4,1 | 245,760 | 8,192 | 50,000 | 1,280 × 720 @ 68,3 (9). 1,920 × 1080 @ 30,1 (4) 2048 × 1024 @ 30,0 (4) |
| 4,2 | 522,240 | 8,704 | 50,000 | 1,280 × 720 @ 145,1 (9). 1,920 × 1080 @ 64,0 (4) 2048 × 1080 @ 60,0 (4) |
| 5 | 589 824 | 22 080 | 135,000 | 1920 × 1080 @ 72,3 (13). 2048 × 1024 @ 72,0 (13). 2048 × 1080 @ 67,8 (12). 2560 × 1,920 @ 30,7 (5) 3,672 × 1536 @ 26,7 (5) |
| 5,1 | 983,040 | 36,864 | 240,000 | 1,920 × 1080 @ 120,5 (16). 2560 × 1,920 @ 51,2 (9). 3,840 × 2160 при 31,7 (5). 4 096 × 2048 при 30,0 (5). 4 096 × 2160 при 28,5 (5) 4 096 × 2304 при 26,7 (5) |
| 5,2 | 2,073,600 | 36,864 | 240,000 | 1,920 × 1080 @ 172,0 (16). 2560 × 1,920 @ 108,0 (9). 3,840 × 2160 @ 66,8 (5). 4096 × 2048 @ 63,3 (5). 4,096 × 2160 @ 60,0 (5) 4096 × 2304 @ 56,3 (5) |
| 6 | 4,177,920 | 139,264 | 240,000 | 3,840 × 2,160 при 128,9 (16). 7,680 × 4,320 при 32,2 (5) 8,192 × 4,320 при 30,2 (5) |
| 6,1 | 8,355,840 | 139,264 | 480,000 | 3,840 × 2160 при 257,9 (16). 7,680 × 4,320 при 64,5 (5) 8192 × 4320 при 60,4 (5) |
| 6,2 | 16,711,680 | 139,264 | 800,000 | 3,840 × 2160 при 300,0 (16). 7,680 × 4,320 при 128,9 (5) 8,192 × 4,320 @ 120.9 (5) |
Максимальная скорость передачи данных для высокого профиля в 1,25 раза больше, чем для ограниченного базового, базового, расширенного и основного профилей; 3 раза для Hi10P и 4 раза для Hi422P / Hi444PP.
Количество выборок яркости составляет 16 × 16 = 256 раз больше количества макроблоков (и количество выборок яркости в секунду в 256 раз больше количества макроблоков в секунду).
Ранее кодированные изображения используются кодерами H.264 / AVC для обеспечения предсказаний значений выборок в других изображениях. Это позволяет кодировщику принимать эффективные решения о наилучшем способе кодирования данного изображения. В декодере такие изображения сохраняются в виртуальном буфере декодированных изображений (DPB). Максимальная емкость DPB в единицах кадров (или парах полей), как показано в скобках в правом столбце приведенной выше таблицы, может быть вычислена следующим образом:
Где MaxDpbMbs - постоянное значение, представленное в таблице ниже, как функция номера уровня, а PicWidthInMbs и FrameHeightInMbs - ширина изображения и высота кадра для кодированных видеоданных, выраженная в единицах макроблоков. (округлено до целых значений с учетом кадрирования и сопряжения макроблоков, если применимо). Эта формула указана в разделах A.3.1.h и A.3.2.f издания стандарта 2017 г.
| Уровень | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MaxDpbMbs |
Например, для изображения HDTV шириной 1920 сэмплов (PicWidthInMbs = 120) и высотой 1080 сэмплов (FrameHeightInMbs = 68) декодер уровня 4 имеет максимальная емкость хранения DPB этажа (32768 / (120 * 68)) = 4 кадра (или 8 полей). Таким образом, значение 4 показано в скобках в таблице выше в правом столбце строки для Уровня 4 с размером кадра 1920 × 1080.
Важно отметить, что текущее декодируемое изображение не включается в вычисление полноты DPB (если кодировщик не указал, что оно будет сохранено для использования в качестве эталона для декодирования других изображений или для отложенного вывода. сроки). Таким образом, декодер должен иметь достаточно памяти для обработки (по крайней мере) одного кадра больше, чем максимальная емкость DPB, рассчитанная выше.
В 2009 году рабочая группа HTML5 была разделена между сторонниками Ogg Theora, бесплатного видеоформата, который, как считается, не перегружен по патентам, и H.264, который содержит запатентованную технологию. Еще в июле 2009 года было заявлено, что Google и Apple поддерживают H.264, тогда как Mozilla и Opera поддерживают Ogg Theora (теперь Google, Mozilla и Opera поддерживают Theora и WebM с VP8 ). Microsoft с выпуском Internet Explorer 9 добавила поддержку видео HTML 5, закодированного с использованием H.264. На симпозиуме Gartner / ITXpo в ноябре 2010 г. генеральный директор Microsoft Стив Баллмер ответил на вопрос «HTML 5 или Silverlight ?» говоря: «Если вы хотите сделать что-то универсальное, нет никаких сомнений в том, что мир переходит на HTML5». В январе 2011 года Google объявил, что они прекращают поддержку H.264 из своего браузера Chrome и поддерживают как Theora, так и WebM / VP8, чтобы использовать только открытые форматы.
18 марта 2012 г. Mozilla объявила о поддержке H.264 в Firefox на мобильных устройствах в связи с преобладанием видео в кодировке H.264 и повышенной энергоэффективностью использования выделенного аппаратного декодера H.264. распространены на таких устройствах. 20 февраля 2013 года Mozilla реализовала в Firefox поддержку декодирования H.264 в Windows 7 и выше. Эта функция основана на встроенных в Windows библиотеках декодирования. Firefox 35.0, выпущенный 13 января 2015 года, поддерживает H.264 в OS X 10.6 и выше.
30 октября 2013 года Rowan Trollope из Cisco Systems объявил что Cisco выпустит как двоичные файлы, так и исходный код видеокодека H.264 под названием OpenH264 по упрощенной лицензии BSD и выплатит все роялти за его использование MPEG LA для любых программных проектов которые используют предварительно скомпилированные двоичные файлы Cisco, тем самым делая двоичные файлы Cisco OpenH264 бесплатными. Однако любые программные проекты, использующие исходный код Cisco вместо двоичных файлов, будут нести юридическую ответственность за выплату всех лицензионных отчислений MPEG LA. Текущие целевые архитектуры ЦП - x86 и ARM, текущие целевые операционные системы - Linux, Windows XP и более поздние версии, Mac OS X и Android; Примечательно, что iOS отсутствует в этом списке, поскольку она не позволяет приложениям получать и устанавливать бинарные модули из Интернета. Также 30 октября 2013 года Брендан Эйч из Mozilla написал, что он будет использовать двоичные файлы Cisco в будущих версиях Firefox, чтобы добавить поддержку H.264 в Firefox, где кодеки платформы недоступны..
Cisco опубликовала исходный код для OpenH264 9 декабря 2013 г.
| Функция | QuickTime | Nero | OpenH264 | x264 | Main-. Concept | Elecard | TSE | Pro-. Coder | Avivo | Elemental | IPP |
|---|---|---|---|---|---|---|---|---|---|---|---|
| B-срезы | Да | Да | Да | Да | Да | Да | Да | Да | No | Да | Да |
| Несколько опорных кадров | Да | Да | Да | Да | Да | Да | Да | Да | No | Да | Да |
| Чересстрочное кодирование (PicAFF, MBAFF) | No | MBAFF | MBAFF | MBAFF | Да | Да | No | Да | MBAFF | Да | Нет |
| Энтропийное кодирование CABAC | Да | Да | Да | Да s | Да | Да | Да | Да | No | Да | Да |
| 8 × 8 против 4 × 4 адаптивность преобразования | No | Да | Да | Да | Да | Да | Да | Да | No | Да | Да |
| Матрицы масштабирования квантования | No | No | Да | Да | Да | No | No | No | No | No | Нет |
| Отдельно C B и C R QP control | No | No | Да | Да | Да | Да | No | No | No | No | Нет |
| Расширенные форматы цветности | No | No | No | 4 : 0: 0. 4: 2: 0. 4: 2: 2. 4: 4: 4 | 4: 2: 2 | 4: 2: 2 | 4:2:2 | No | No | 4:2:0. 4:2:2 | Нет |
| Наибольшая глубина выборки (бит) | 8 | 8 | 8 | 10 | 10 | 8 | 8 | 8 | 8 | 10 | 12 |
| Прогнозирующее кодирование без потерь | No | No | No | Да | No | No | No | No | No | No | Нет |
Поскольку для кодирования и декодирования H.264 требуется значительная вычислительная мощность в определенных типах арифметических операций, программные реализации, работающие на процессорах общего назначения, обычно менее энергоэффективный. Однако новейшие четырехъядерные процессоры x86 общего назначения обладают достаточной вычислительной мощностью для кодирования SD и HD в реальном времени. Эффективность сжатия зависит от алгоритмических реализаций видео, а не от того, используется ли аппаратная или программная реализация. Таким образом, разница между аппаратной и программной реализацией больше в энергоэффективности, гибкости и стоимости. Чтобы повысить энергоэффективность и уменьшить форм-фактор аппаратного обеспечения, можно использовать специализированное оборудование либо для полного процесса кодирования или декодирования, либо для ускорения в среде, управляемой ЦП.
Решения на базе ЦП известны как гораздо более гибкие, особенно когда кодирование должно выполняться одновременно в нескольких форматах, с разными скоростями передачи и разрешениями (многоэкранное видео ) и, возможно, с дополнительными функции поддержки формата контейнера, расширенные интегрированные рекламные функции и т. д. Программное решение на базе ЦП обычно значительно упрощает балансировку нагрузки нескольких одновременных сеансов кодирования в одном ЦП.
Процессоры 2-го поколения Intel "Sandy Bridge " Core i3 / i5 / i7, представленные на выставке CES в январе 2011 г. (Consumer Electronics Show ) предлагает встроенный аппаратный кодировщик Full HD H.264, известный как Intel Quick Sync Video.
Аппаратный кодировщик H.264 может быть ASIC или FPGA.
Кодеры ASIC с функциями кодировщика H.264 доступны от многих компаний, производящих полупроводники, но основной дизайн, используемый в ASIC, обычно лицензируется одной из нескольких компаний, таких как Chips Media, Allegro DVT, On2 (ранее Hantro, приобретена Google), Imagination Technologies, NGCodec. Некоторые компании предлагают продукты как FPGA, так и ASIC.
Texas Instruments производит линейку ядер ARM + DSP, которые выполняют кодирование DSP H.264 BP 1080p со скоростью 30 кадров в секунду. Это обеспечивает гибкость в отношении кодеков (которые реализованы как высоко оптимизированный код DSP), будучи более эффективным, чем программное обеспечение на обычном ЦП.
В странах, где поддерживаются патенты на программные алгоритмы, ожидается, что поставщики и коммерческие пользователи продуктов, использующих H.264 / AVC, будут платить лицензионные отчисления за патенты за запатентованная технология, которую используют их продукты. Это также относится к базовому профилю.
Частная организация, известная как MPEG LA, которая никоим образом не связана с организацией по стандартизации MPEG, управляет лицензиями на патенты, относящиеся к этому стандарт, а также другие пулы патентов , такие как MPEG-4 Part 2 Video, HEVC и MPEG-DASH. Патентообладатели включают Fujitsu, Panasonic, Sony, Mitsubishi, Apple, Колумбийский университет, KAIST, Dolby, Google, JVC Kenwood, LG Electronics, Microsoft, NTT Docomo, Philips, Samsung, Sharp, Toshiba и ZTE, хотя большинство патентов в пуле принадлежит Panasonic (1197 патентов), Godo Kaisha IP Bridge (1130 патентов) и LG Electronics (990
26 августа 2010 года MPEG LA объявила, что роялти не будут взиматься за закодированное в H.264 Интернет-видео, которое бесплатно для конечных пользователей. Остальные лицензионные платежи остаются в силе, например, роялти за продукты, декодирующие и кодирующие видео H.264, а также за операторов бесплатного телевидения и каналов подписки. Условия лицензии обновляются блоками по 5 лет.
Поскольку первая версия стандарта была завершена в мае 2003 г. (17 лет назад), а наиболее часто используемый профиль (высокий профиль) был завершен в июне 2004 г. (16 лет назад) срок действия значительного количества патентов, которые первоначально применялись к стандарту, истек, хотя один из патентов США в пуле MPEG LA H.264 действует как минимум до 2027 года.
В 2005 году, Qualcomm подала в суд на Broadcom в окружном суде США, утверждая, что Broadcom нарушила два своих патента, создав продукты, соответствующие стандарту сжатия видео H.264. В 2007 году окружной суд постановил, что патенты не имеют исковой силы, поскольку Qualcomm не раскрыла их JVT до выпуска стандарта H.264 в мае 2003 года. В декабре 2008 года Апелляционный суд США по федеральному округу подтвердил постановление окружного суда о том, что патенты не имеют исковой силы, но переданы в районный суд с указанием ограничить объем неисполнения требований для продуктов, совместимых с H.264.
