Расширенное кодирование видео

Из Википедии, бесплатной энциклопедии
«AVC1» перенаправляется сюда. Не путать с AV1 или VC-1 .

Расширенное кодирование видео / H.264 / MPEG-4, часть 10
Расширенное кодирование видео для общих аудиовизуальных услуг
Положение дел Действующий
Год начался 2003
Впервые опубликовано 17 августа 2004 г. ( 17 августа 2004 г. )
Последняя версия 14.0
22 августа 2021 г. ( 22 августа 2021 г. )
Организация МСЭ-Т , ИСО , МЭК
комитет SG16 ( ВКЭГ ), MPEG
Базовые стандарты H.261 , H.262 (он же MPEG-2 Video ), H.263 , ISO/IEC 14496-2 (он же MPEG-4, часть 2)
Сопутствующие стандарты H.265 (он же HEVC), H.266 (он же VVC)
Домен Сжатие видео
Лицензия MPEG Лос-Анджелес [1]
Веб-сайт www .Что .int /запись /T-REC-H .264
Блок-схема уровня кодирования видео кодера H.264 с показателем качества восприятия

Расширенное кодирование видео ( AVC ), также называемое H.264 или MPEG-4 Part 10 , представляет собой стандарт сжатия видео , основанный на блочно-ориентированном с компенсацией движения . кодировании [2] На сегодняшний день это наиболее часто используемый формат для записи, сжатия и распространения видеоконтента, который по состоянию на сентябрь 2019 года используют 91% разработчиков видеоиндустрии. . [3] [4] Он поддерживает максимальное разрешение 8K UHD . [5] [6]

Целью проекта H.264/AVC было создание стандарта, способного обеспечить хорошее качество видео при значительно более низких скоростях передачи данных , чем предыдущие стандарты (т. е. половина или меньше скорости передачи данных MPEG-2 , H.263 или MPEG-) . 4 Часть 2 ), не увеличивая при этом сложность конструкции настолько, что ее реализация стала бы непрактичной или чрезмерно дорогой. пониженной сложности Это было достигнуто с помощью таких функций, как целочисленное дискретное косинусное преобразование (целочисленное DCT), [7] сегментация переменного размера блока и межкадровое предсказание нескольких изображений . Дополнительная цель состояла в том, чтобы обеспечить достаточную гибкость, позволяющую применять стандарт к широкому спектру приложений в самых разных сетях и системах, включая низкие и высокие скорости передачи данных, видео с низким и высоким разрешением, вещание , хранение DVD , RTP / IP- пакетные сети и системы ITU-T мультимедийные телефонные . Стандарт H.264 можно рассматривать как «семейство стандартов», состоящее из ряда различных профилей, хотя его «высокий профиль» на сегодняшний день является наиболее часто используемым форматом. Конкретный декодер декодирует хотя бы один, но не обязательно все профили. Стандарт описывает формат кодированных данных и способ декодирования данных, но не определяет алгоритмы кодирования видео – это остается открытым, поскольку разработчики кодировщиков могут выбирать для себя, и существует большое количество схем кодирования. развитый. H.264 обычно используется для сжатия с потерями , хотя также возможно создать действительно области с кодированием без потерь в изображениях с кодированием с потерями или для поддержки редких случаев использования, для которых все кодирование выполняется без потерь.

H.264 был стандартизирован ITU-T Группой экспертов по кодированию видео (VCEG) 16-й Исследовательской комиссии совместно с ISO/IEC JTC 1 Группой экспертов по движущимся изображениям (MPEG). Партнерский проект известен как Объединенная видеокоманда (JVT). Стандарт ITU-T H.264 и стандарт ISO/IEC MPEG-4 AVC (формально ISO/IEC 14496-10 – MPEG-4 Часть 10, Расширенное кодирование видео) поддерживаются совместно, поэтому они имеют идентичное техническое содержание. Окончательная работа над первой версией стандарта была завершена в мае 2003 года, а в последующих редакциях были добавлены различные расширения его возможностей. Высокоэффективное кодирование видео (HEVC), также известное как H.265 и MPEG-H Part 2, является преемником H.264/MPEG-4 AVC, разработанного теми же организациями, хотя более ранние стандарты все еще широко используются.

H.264, пожалуй, наиболее известен как наиболее часто используемый формат кодирования видео на дисках Blu-ray . Он также широко используется потоковыми интернет-источниками, такими как видео с Netflix , Hulu , Amazon 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 . Via Licensing Corp приобрела MPEG LA в апреле 2023 года и сформировала новую компанию по управлению патентным пулом под названием Via Licensing Alliance . [8] Коммерческое использование запатентованных технологий H.264 требует выплаты гонораров Via и другим владельцам патентов. MPEG LA разрешил бесплатное использование технологий H.264 для потоковой передачи интернет-видео, которое бесплатно для конечных пользователей, а Cisco выплачивала MPEG LA гонорары от имени пользователей двоичных файлов за свой с открытым исходным кодом кодировщик H.264 openH264 .

Именование [ править ]

Имя H.264 соответствует ITU-T соглашению об именах , где Рекомендациям присваивается буква, соответствующая их серии, и номер рекомендации внутри серии. H.264 является частью «Рекомендаций серии H: аудиовизуальные и мультимедийные системы». H.264 далее подразделяется на «H.200-H.499: Инфраструктура аудиовизуальных услуг» и «H.260-H.279: Кодирование движущегося видео». [9] Название 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. [10] ) Некоторые программы (например, медиаплеер 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) с уставом для завершения разработки стандарта кодирования видео. [11] Официальное одобрение спецификации произошло в марте 2003 года. JVT возглавляли Гэри Салливан , Томас Виганд и Аджай Лутра ( Motorola , США: позже Аррис , США). В июле 2004 года был завершен проект расширения диапазона точности (FRExt). С января 2005 г. по ноябрь 2007 г. JVT работал над расширением H.264/AVC в сторону масштабируемости с помощью Приложения (G), называемого Масштабируемое кодирование видео (SVC). Руководящий состав JVT пополнился Йенсом-Райнером Омом ( RWTH Aachen University , Германия). С июля 2006 года по ноябрь 2009 года JVT работал над кодированием многовидового видео (MVC), расширением H.264/AVC для 3D-телевидения и телевидения с ограниченным диапазоном свободного обзора . Эта работа включала разработку двух новых профилей стандарта: Multiview High Profile и Stereo High Profile.

В ходе разработки стандарта были разработаны дополнительные сообщения для содержания дополнительной информации расширения (SEI). Сообщения SEI могут содержать различные типы данных, которые указывают синхронизацию видеоизображений или описывают различные свойства кодированного видео или то, как его можно использовать или улучшать. Также определены сообщения SEI, которые могут содержать произвольные данные, определяемые пользователем. Сообщения SEI не влияют на основной процесс декодирования, но могут указывать, как видео рекомендуется подвергать постобработке или отображать. Некоторые другие свойства видеоконтента высокого уровня передаются в информации об удобстве использования видео (VUI), например указание цветового пространства для интерпретации видеоконтента. По мере разработки новых цветовых пространств, например, для видео с расширенным динамическим диапазоном и широкой цветовой гаммой , для их обозначения были добавлены дополнительные идентификаторы VUI.

диапазона Fidelity и профили Расширения профессиональные

Стандартизация первой версии H.264/AVC была завершена в мае 2003 года. В рамках первого проекта по расширению исходного стандарта JVT затем разработала так называемое расширение диапазона точности (FRExt). Эти расширения обеспечили более качественное кодирование видео за счет поддержки повышенной точности битовой глубины выборки и информации о цвете более высокого разрешения, включая структуры выборки, известные как Y’C B C R 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. 264/AVC Кодек , не поддерживающий SVC. Для временной масштабируемости потока битов (т.е. наличия подпотока битов с меньшей временной частотой дискретизации, чем у основного потока битов), полные единицы доступа удаляются из потока битов при получении подпотока битов. В этом случае синтаксис высокого уровня и опорные изображения взаимного предсказания в битовом потоке конструируются соответствующим образом. С другой стороны, для пространственной и качественной масштабируемости битового потока (т.е. наличия подбитового потока с более низким пространственным разрешением/качеством, чем у основного битового потока), NAL ( уровень сетевой абстракции ) удаляется из битового потока при получении подбитового потока. . В этом случае межуровневое предсказание (т.е. предсказание сигнала с более высоким пространственным разрешением/качеством из данных сигнала с более низким пространственным разрешением/качеством) обычно используется для эффективного кодирования. Расширения масштабируемого видеокодирования были завершены в ноябре 2007 года.

Многоракурсное видеокодирование [ править ]

Следующей важной функцией, добавленной в стандарт, было кодирование многовидового видео (MVC). Согласно Приложению H стандарта H.264/AVC, MVC позволяет создавать потоки битов, которые представляют более одного просмотра видеосцены. Важным примером этой функциональности является стереоскопического 3D- кодирование видео. В работе MVC были разработаны два профиля: профиль Multiview High поддерживает произвольное количество просмотров, а профиль Stereo High разработан специально для стереоскопического видео с двумя представлениями. Расширения Multiview Video Coding были завершены в ноябре 2009 года.

3D-AVC и кодирование Стереоскопическое MFC

Позже были разработаны дополнительные расширения, которые включали кодирование 3D-видео с совместным кодированием карт глубины и текстуры (называемое 3D-AVC), стереоскопическое кодирование с поддержкой кадров с несколькими разрешениями (MFC) и 3D-MFC, различные дополнительные комбинации функций и более высокий кадр. размеры и частота кадров.

Версии [ править ]

Версии стандарта H.264/AVC включают следующие завершенные редакции, исправления и поправки (даты являются датами окончательного утверждения в ITU-T, тогда как окончательные даты утверждения «международного стандарта» в ISO/IEC несколько отличаются и в большинстве случаев немного позже). случаи). Каждая версия представляет собой изменения относительно следующей более низкой версии, интегрированной в текст.

  • Версия 1 (Издание 1): (30 мая 2003 г.) Первая утвержденная версия H.264/AVC, содержащая базовый, основной и расширенный профили. [12]
  • Версия 2 (Редакция 1.1): (7 мая 2004 г.) Исправление, содержащее различные незначительные исправления. [13]
  • Версия 3 (Издание 2): (1 марта 2005 г.) Основное дополнение, содержащее первую поправку, устанавливающую расширения диапазона точности (FRExt). В этой версии добавлены профили High, High 10, High 4:2:2 и High 4:4:4. [14] Через несколько лет профиль High стал наиболее часто используемым профилем стандарта.
  • Версия 4 (Редакция 2.1): (13 сентября 2005 г.) Исправление, содержащее различные незначительные исправления и добавление трех индикаторов соотношения сторон. [15]
  • Версия 5 (Редакция 2.2): (13 июня 2006 г.) Поправка, заключающаяся в удалении предыдущего профиля High 4:4:4 (обработано как исправление в ISO/IEC). [16]
  • Версия 6 (Редакция 2.2): (13 июня 2006 г.) Поправка, состоящая из незначительных расширений, таких как поддержка расширенного цветового пространства (в комплекте с вышеупомянутыми индикаторами соотношения сторон в ISO/IEC). [16]
  • Версия 7 (редакция 2.3): (6 апреля 2007 г.) Поправка, содержащая добавление прогнозного профиля High 4:4:4 и четырех профилей только для внутреннего использования (High 10 Intra, High 4:2:2 Intra, High 4:4). :4 Внутри и CAVLC 4:4:4 Внутри). [17]
  • Версия 8 (Издание 3): (22 ноября 2007 г.) Основное дополнение к H.264/AVC, содержащее поправку к масштабируемому кодированию видео (SVC), содержащую профили Scalable Baseline, Scalable High и Scalable High Intra. [18]
  • Версия 9 (Редакция 3.1): (13 января 2009 г.) Исправление, содержащее незначительные исправления. [19]
  • Версия 10 (Редакция 4): (16 марта 2009 г.) Поправка, содержащая определение нового профиля (профиль Constrained Baseline), в котором в различных ранее указанных профилях поддерживается только общий подмножество возможностей. [20]
  • Версия 11 (Издание 4): (16 марта 2009 г.) Основное дополнение к H.264/AVC, содержащее поправку для расширения многовидового видеокодирования (MVC), включая профиль Multiview High. [20]
  • Версия 12 (Редакция 5): (9 марта 2010 г.) Поправка, содержащая определение нового профиля MVC (профиль Stereo High) для кодирования двухвидового видео с поддержкой инструментов чересстрочного кодирования и определяющая дополнительное сообщение с дополнительной информацией об улучшении (SEI). называется SEI-сообщением устройства упаковки кадров. [21]
  • Версия 13 (Издание 5): (9 марта 2010 г.) Исправление, содержащее незначительные исправления. [21]
  • Версия 14 (Редакция 6): (29 июня 2011 г.) Поправка, определяющая новый уровень (Уровень 5.2), поддерживающий более высокие скорости обработки с точки зрения максимального количества макроблоков в секунду, и новый профиль (профиль Progressive High), поддерживающий только инструменты кодирования кадров. ранее указанного высокого профиля. [22]
  • Версия 15 (Выпуск 6): (29 июня 2011 г.) Исправление, содержащее незначительные исправления. [22]
  • Версия 16 (Редакция 7): (13 января 2012 г.) Поправка, содержащая определение трех новых профилей, предназначенных в первую очередь для приложений связи в реальном времени: профили Constrained High, Scalable Constrained Baseline и Scalable Constrained High. [23]
  • Версия 17 (Редакция 8): (13 апреля 2013 г.) Поправка с дополнительными индикаторами сообщений SEI. [24]
  • Версия 18 (Редакция 8): (13 апреля 2013 г.) Поправка, определяющая кодирование данных карты глубины для стереоскопического 3D-видео, включая профиль Multiview Depth High. [24]
  • Версия 19 (Редакция 8): (13 апреля 2013 г.) Исправление для исправления ошибки в процессе извлечения подбитового потока для многовидового видео. [24]
  • Версия 20 (Редакция 8): (13 апреля 2013 г.) Поправка, определяющая дополнительные идентификаторы цветового пространства (включая поддержку Рекомендации ITU-R BT.2020 для UHDTV ) и дополнительный тип модели в сообщении SEI с информацией о преобразовании тонов. [24]
  • Версия 21 (Издание 9): (13 февраля 2014 г.) Поправка, определяющая профиль Enhanced Multiview Depth High. [25]
  • Версия 22 (издание 9): (13 февраля 2014 г.) Поправка, определяющая улучшение совместимости кадров с несколькими разрешениями (MFC) для стереоскопического 3D-видео, профиль MFC High и незначительные исправления. [25]
  • Версия 23 (издание 10): (13 февраля 2016 г.) Поправка, определяющая стереоскопическое видео MFC с картами глубины, профиль MFC Depth High, сообщение SEI о громкости основного дисплея и дополнительные идентификаторы кодовых точек VUI, связанные с цветом. [26]
  • Версия 24 (Редакция 11): (14 октября 2016 г.) Поправка, определяющая дополнительные уровни возможностей декодера, поддерживающие изображения большего размера (уровни 6, 6.1 и 6.2), зеленое сообщение SEI с метаданными, альтернативное сообщение SEI с информацией о глубине и дополнительные идентификаторы кодовых точек VUI, связанные с цветом. [27]
  • Версия 25 (Редакция 12): (13 апреля 2017 г.) Поправка, определяющая профиль Progressive High 10, гибридную логарифмическую гамму (HLG), а также дополнительные кодовые точки VUI, связанные с цветом, и сообщения SEI. [28]
  • Версия 26 (Редакция 13): (13 июня 2019 г.) Поправка для указания дополнительных сообщений SEI для окружающей среды просмотра, информации об уровне освещенности контента, цветового объема контента, равноугольной проекции, проекции кубической карты, вращения сферы, упаковки по регионам, всенаправленного окна просмотра, Манифест SEI и префикс SEI. [29]
  • Версия 27 (Редакция 14): (22 августа 2021 г.) Поправка, указывающая дополнительные сообщения SEI для аннотированных областей и информации о интервале затвора, а также различные незначительные исправления и разъяснения. [30]

Патентовладельцы [ править ]

Дополнительная информация: MPEG LA.
Часть этого раздела исключена из MPEG LA . ( редактировать | история )

Следующие организации владеют одним или несколькими патентами в H.264/AVC патентном пуле MPEG LA.

Владельцы патентов H.264/AVC (по состоянию на декабрь 2022 г.) ) [31]
Организация [32] Действующие патенты Патенты с истекшим сроком действия Всего патентов [31]
Корпорация Панасоник 1,054 416 1,470
IP-мост Годо Кайша 1,033 267 1,300
LG Электроникс 871 130 1001
Долби Лаборатории 1014 414 1428
Тошиба 59 336 395
Майкрософт 95 145 240
Nippon Telegraph and Telephone (включая NTT Docomo ) 234 4 238
Сони 77 77 154
Общество Фраунгофера 208 16 224
Google 5 134 139
GE Сжатие видео 136 0 136
Фуджицу 92 14 106
Митсубиси Электрик 44 56 100
ООО «Тагиван II» 82 0 82
Самсунг Электроникс 17 46 63
Макселл 54 2 56
Филипс 6 41 47
видео 41 2 43
Эрикссон 1 33 34
Научно-исследовательский институт электроники и телекоммуникаций (ETRI) Кореи 10 25 35

Приложения [ править ]

Дополнительная информация: Список видеосервисов, использующих H.264/MPEG-4 AVC.

Видеоформат H.264 имеет очень широкий спектр применения, который охватывает все формы цифрового сжатого видео: от приложений потокового Интернет-вещания с низкой скоростью передачи данных до приложений HDTV и цифрового кино с кодированием практически без потерь. при использовании H.264 экономия скорости передачи данных составляет 50% и более по сравнению с MPEG-2 Part 2 Сообщается, что . Например, сообщается, что H.264 обеспечивает такое же качество цифрового спутникового телевидения, как и нынешние реализации MPEG-2, но с битрейтом менее половины, при этом текущие реализации MPEG-2 работают со скоростью около 3,5 Мбит/с, а H.264 - только со скоростью 1,5. Мбит/с. [33] Sony утверждает, что режим записи AVC со скоростью 9 Мбит/с эквивалентен качеству изображения формата HDV , который использует примерно 18–25 Мбит/с. [34]

Чтобы обеспечить совместимость и беспроблемное внедрение 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 на территории Соединенных Штатов. [35] [36] Он также был одобрен для использования с более новым стандартом ATSC-M/H (Mobile/Handheld), использующим части AVC и SVC H.264. [37]

( Рынки систем видеонаблюдения закрытого телевидения) и видеонаблюдения включили эту технологию во многие продукты.

Многие распространенные зеркальные фотокамеры используют видео H.264, завернутое в контейнеры QuickTime MOV, в качестве собственного формата записи.

Производные форматы [ править ]

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

AVC-Intra — это формат внутрикадрового сжатия, разработанный Panasonic .

XAVC — это формат записи, разработанный Sony и использующий уровень 5.2 H.264/MPEG-4 AVC, который является самым высоким уровнем, поддерживаемым этим видеостандартом. [38] [39] XAVC может поддерживать разрешение 4K (4096 × 2160 и 3840 × 2160) со скоростью до 60 кадров в секунду (fps). [38] [39] Sony объявила, что в число камер, поддерживающих XAVC, входят две камеры CineAlta — Sony PMW-F55 и Sony PMW-F5. [40] Sony PMW-F55 может записывать XAVC с разрешением 4K со скоростью 30 кадров в секунду и скоростью 300 Мбит/с и разрешением 2K со скоростью 30 кадров в секунду и скоростью 100 Мбит/с. [41] XAVC может записывать видео в разрешении 4K со скоростью 60 кадров в секунду и сэмплированием цветности 4:2:2 со скоростью 600 Мбит/с. [42] [43]

Дизайн [ править ]

Особенности [ править ]

Блок-схема H.264

H.264/AVC/MPEG-4 Part 10 содержит ряд новых функций, которые позволяют сжимать видео гораздо эффективнее, чем предыдущие стандарты, и обеспечивают большую гибкость для применения в самых разных сетевых средах. В частности, некоторые из таких ключевых особенностей включают в себя:

  • нескольких изображений Межкадровое предсказание , включая следующие функции:
    • Использование ранее закодированных изображений в качестве ссылок гораздо более гибко, чем в предыдущих стандартах, позволяя в некоторых случаях использовать до 16 опорных кадров (или 32 опорных полей в случае чересстрочного кодирования). В профилях, которые поддерживают кадры, отличные от IDR , большинство уровней указывают, что должна быть доступна достаточная буферизация, позволяющая использовать как минимум 4 или 5 опорных кадров с максимальным разрешением. Это контрастирует с предыдущими стандартами, где ограничение обычно было одним; или, в случае обычных « B-изображений » (B-кадров), два.
    • с переменным размером блока Компенсация движения (VBSMC) с размерами блоков от 16 × 16 до 4 × 4, что позволяет точно сегментировать движущиеся области. Поддерживаемые размеры блоков прогнозирования яркости включают 16×16, 16×8, 8×16, 8×8, 8×4, 4×8 и 4×4, многие из которых могут использоваться вместе в одном макроблоке. Размеры блоков предсказания цветности соответственно меньше, когда субдискретизация цветности . используется
    • Возможность использовать несколько векторов движения для каждого макроблока (один или два на раздел), максимум 32 в случае макроблока B, состоящего из 16 разделов 4×4. Векторы движения для каждой области раздела 8×8 или больше могут указывать на разные опорные изображения.
    • Возможность использования любого типа макроблоков в B-кадрах , включая I-макроблоки, что приводит к гораздо более эффективному кодированию при использовании B-кадров. Эта функция была особенно исключена из MPEG-4 ASP .
    • Шестиступенчатая фильтрация для получения прогнозов выборки полупиксельной яркости для более четкой субпиксельной компенсации движения. Четвертьпиксельное движение получается путем линейной интерполяции значений полупикселей для экономии вычислительной мощности.
    • Четвертьпиксельная точность для компенсации движения, позволяющая точно описать смещения движущихся областей. Для цветности разрешение обычно уменьшается вдвое как по вертикали, так и по горизонтали (см. 4:2:0 ), поэтому для компенсации движения цветности используется одна восьмая единиц сетки пикселей цветности.
    • Взвешенное прогнозирование, позволяющее кодировщику указать использование масштабирования и смещения при выполнении компенсации движения и обеспечивающее значительный выигрыш в производительности в особых случаях, таких как переход к затемнению, постепенное появление и перекрестное затухание. Сюда входит неявное взвешенное предсказание для B-кадров и явное взвешенное предсказание для P-кадров.
  • Пространственное предсказание по краям соседних блоков для «внутреннего» кодирования, а не предсказание только «DC», найденное в MPEG-2, часть 2, и предсказание коэффициента преобразования, найденное в H.263v2 и MPEG-4, часть 2. Сюда входит яркость можно использовать только один тип размеры блоков прогнозирования 16×16, 8×8 и 4×4 (из которых в каждом макроблоке ).
  • Целочисленное дискретное косинусное преобразование (целочисленное ДКП), [6] [44] [45] тип дискретного косинусного преобразования (DCT) [44] где преобразование представляет собой целочисленную аппроксимацию стандартного ДКП. [46] Имеет выбираемые размеры блоков. [7] и целочисленные вычисления с точным совпадением для уменьшения сложности, в том числе:
    • Пространственное блочное преобразование 4×4 с точным совпадением, обеспечивающее точное размещение остаточных сигналов с небольшим количеством « звона », часто встречавшегося в предыдущих конструкциях кодеков. Он похож на стандартный DCT, использовавшийся в предыдущих стандартах, но использует меньший размер блока и простую целочисленную обработку. В отличие от косинусных формул и допусков, выраженных в более ранних стандартах (таких как H.261 и MPEG-2), целочисленная обработка обеспечивает точно заданный декодированный результат.
    • Целочисленное пространственное блочное преобразование 8×8 с точным совпадением, позволяющее более эффективно сжимать сильно коррелированные области, чем при преобразовании 4×4. Эта конструкция основана на стандартном DCT, но упрощена и предназначена для обеспечения точно заданного декодирования.
    • Адаптивный выбор кодировщика между размерами блоков преобразования 4×4 и 8×8 для операции целочисленного преобразования.
    • Вторичное преобразование Адамара , выполняемое с коэффициентами «DC» первичного пространственного преобразования, применяется к коэффициентам DC цветности (а также к яркости в одном особом случае) для получения еще большего сжатия в гладких областях.
  • без потерь Функции кодирования макроблоков , включая:
    • Режим представления «макроблока PCM» без потерь, в котором образцы видеоданных представляются напрямую. [47] обеспечивая идеальное представление определенных регионов и позволяя налагать строгие ограничения на количество закодированных данных для каждого макроблока.
    • Усовершенствованный режим представления макроблоков без потерь, обеспечивающий идеальное представление определенных областей, обычно используя значительно меньше битов, чем режим PCM.
  • Гибкие : функции кодирования видео с чересстрочной разверткой, в том числе
    • Макроблок-адаптивное кодирование поля кадра (MBAFF), использующее структуру пар макроблоков для изображений, закодированных как кадры, что позволяет использовать макроблоки 16×16 в режиме поля (по сравнению с MPEG-2, где обработка в режиме поля в изображении, которое закодировано как кадр) приводит к обработке полумакроблоков 16×8).
    • Адаптивное к изображению кодирование полей кадра (PAFF или PicAFF), позволяющее свободно выбирать смесь изображений, кодируемых либо как полные кадры, где оба поля объединены для кодирования, либо как отдельные отдельные поля.
  • Схема квантования, включающая:
    • Логарифмическое управление размером шага для упрощения управления скоростью передачи данных с помощью кодеров и упрощенного масштабирования обратного квантования.
    • Матрицы масштабирования квантования с настройкой частоты, выбранные кодировщиком для оптимизации квантования на основе восприятия
  • Внутриконтурный фильтр деблокировки , который помогает предотвратить артефакты блокировки, характерные для других методов сжатия изображений на основе DCT, что приводит к улучшению внешнего вида и эффективности сжатия.
  • Схема энтропийного кодирования , включающая:
  • Характеристики устойчивости к потерям, включая:
    • Определение уровня сетевой абстракции (NAL), позволяющее использовать один и тот же синтаксис видео во многих сетевых средах. Одна из фундаментальных концепций разработки H.264 заключается в создании автономных пакетов для устранения дублирования заголовков, как в коде расширения заголовка (HEC) MPEG-4. [48] Это было достигнуто за счет отделения информации, относящейся к более чем одному фрагменту, от медиапотока. Комбинация параметров более высокого уровня называется набором параметров. [48] Спецификация H.264 включает два типа наборов параметров: набор параметров последовательности (SPS) и набор параметров изображения (PPS). Набор параметров активной последовательности остается неизменным на протяжении всей кодированной видеопоследовательности, а набор параметров активного изображения остается неизменным в пределах кодированного изображения. Структуры набора параметров последовательности и изображения содержат такую ​​информацию, как размер изображения, дополнительные используемые режимы кодирования и карту макроблока для группы слайсов. [48]
    • Гибкое упорядочение макроблоков (FMO), также известное как группы срезов, и произвольное упорядочение срезов (ASO), которые представляют собой методы реструктуризации порядка представления фундаментальных областей ( макроблоков ) в изображениях. FMO и ASO, которые обычно считаются функцией устойчивости к ошибкам/потерям, также могут использоваться для других целей.
    • Разделение данных (DP) — функция, обеспечивающая возможность разделения более важных и менее важных элементов синтаксиса на разные пакеты данных, что позволяет применять защиту от неравных ошибок (UEP) и другие типы повышения устойчивости к ошибкам/потерям.
    • Избыточные фрагменты (RS), функция устойчивости к ошибкам/потерям, которая позволяет кодировщику отправлять дополнительное представление области изображения (обычно с более низкой точностью), которое можно использовать, если первичное представление повреждено или потеряно.
    • Нумерация кадров - функция, которая позволяет создавать «подпоследовательности», обеспечивая временную масштабируемость за счет дополнительного включения дополнительных изображений между другими изображениями, а также обнаружение и сокрытие потерь целых изображений, которые могут возникнуть из-за потерь сетевых пакетов или каналов. ошибки.
  • Слайсы переключения, называемые слайсами SP и SI, позволяют кодеру направить декодер на переход к текущему видеопотоку для таких целей, как переключение скорости передачи видеопотока и работа в «хитром режиме». Когда декодер переходит в середину видеопотока с помощью функции SP/SI, он может получить точное совпадение с декодированными изображениями в этом месте видеопотока, несмотря на использование других изображений или отсутствие изображений вообще в качестве эталонных изображений перед Переключатель.
  • Простой автоматический процесс предотвращения случайной эмуляции стартовых кодов , представляющих собой специальные последовательности битов в закодированных данных, обеспечивающие произвольный доступ к битовому потоку и восстановление выравнивания байтов в системах, которые могут потерять синхронизацию байтов.
  • Дополнительная информация улучшения (SEI) и информация об удобстве использования видео (VUI), которые представляют собой дополнительную информацию, которую можно вставлять в битовый поток для различных целей, например, для указания цветового пространства, используемого видеоконтентом, или различных ограничений, применимых к кодированию. Сообщения SEI могут содержать произвольные пользовательские полезные данные метаданных или другие сообщения с синтаксисом и семантикой, определенными в стандарте.
  • Вспомогательные картинки, которые можно использовать для таких целей, как альфа-композитинг .
  • (4:0:0), 4:2:0, 4:2:2 и 4:4:4 Поддержка монохромной выборки цветности (в зависимости от выбранного профиля).
  • Поддержка точности разрядности выборки от 8 до 14 бит на выборку (в зависимости от выбранного профиля).
  • Возможность кодирования отдельных цветовых плоскостей как отдельных изображений с их собственными структурами срезов, режимами макроблоков, векторами движения и т. д., что позволяет разрабатывать кодеры с простой структурой распараллеливания (поддерживается только в трех профилях с поддержкой формата 4:4:4). .
  • Подсчет порядка изображений - функция, которая служит для сохранения порядка изображений и значений выборок в декодированных изображениях, изолированных от информации о синхронизации, позволяя системе передавать и контролировать/изменять информацию о синхронизации отдельно, не затрагивая содержимое декодированного изображения.

Эти методы, наряду с некоторыми другими, помогают H.264 работать значительно лучше, чем любой предыдущий стандарт, в самых разных обстоятельствах и в самых разных прикладных средах. H.264 часто может работать радикально лучше, чем видео MPEG-2, обычно обеспечивая такое же качество при половине скорости передачи данных или меньше, особенно для видеоконтента с высокой скоростью передачи данных и высоким разрешением. [49]

Как и другие видеостандарты ISO/IEC MPEG, H.264/AVC имеет эталонную программную реализацию, которую можно бесплатно загрузить. [50] Его основная цель — предоставить примеры функций H.264/AVC, а не быть полезным приложением как таковым . Некоторые работы по проектированию эталонного аппаратного обеспечения также проводились в группе экспертов по движущимся изображениям . Вышеупомянутые аспекты включают в себя функции всех профилей H.264. Профиль кодека — это набор характеристик этого кодека, определенных для соответствия определенному набору спецификаций предполагаемых приложений. Это означает, что многие из перечисленных функций не поддерживаются в некоторых профилях. Различные профили H.264/AVC обсуждаются в следующем разделе.

Профили [ править ]

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

Профили для немасштабируемых 2D-видеоприложений включают следующее:

Ограниченный базовый профиль (CBP, 66 с набором ограничений 1)
В первую очередь для недорогих приложений этот профиль чаще всего используется в видеоконференциях и мобильных приложениях. Он соответствует подмножеству функций, которые являются общими для базового, основного и высокого профилей.
Базовый профиль (BP, 66)
В первую очередь для недорогих приложений, требующих дополнительной защиты от потери данных, этот профиль используется в некоторых приложениях для видеоконференций и мобильных приложениях. Этот профиль включает в себя все функции, которые поддерживаются в ограниченном базовом профиле, а также три дополнительные функции, которые можно использовать для обеспечения устойчивости к потерям (или для других целей, таких как композиция многоточечного видеопотока с малой задержкой). Важность этого профиля несколько снизилась после определения ограниченного базового профиля в 2009 году. Все битовые потоки ограниченного базового профиля также считаются битовыми потоками базового профиля, поскольку эти два профиля имеют одно и то же значение кода идентификатора профиля.
Расширенный профиль (XP, 88)
Задуманный как профиль потокового видео, этот профиль имеет относительно высокую степень сжатия и некоторые дополнительные возможности, обеспечивающие устойчивость к потерям данных и переключению потоков сервера.
Основной профиль (МП, 77)
Этот профиль используется для цифрового телевещания стандартной четкости, в котором используется формат MPEG-4, определенный в стандарте DVB. [51] Однако он не используется для телевизионных трансляций высокой четкости, поскольку важность этого профиля исчезла, когда в 2004 году для этого приложения был разработан High Profile.
Высокий профиль (HiP, 100)
Основной профиль для приложений вещания и хранения дисков, особенно для приложений телевидения высокой четкости (например, это профиль, принятый в формате хранения дисков Blu-ray и службе вещания DVB HDTV).
Прогрессивный высокий профиль (PHiP, 100 с набором ограничений 4)
Аналогичен профилю High, но без поддержки функций кодирования полей.
Ограниченный высокий профиль (100 с набором ограничений 4 и 5)
Аналогичен профилю Progressive High, но без поддержки срезов B (би-предсказания).
Профиль Высокий 10 (Hi10P, 110)
Выходя за рамки типичных возможностей потребительских продуктов, этот профиль построен на основе High Profile, добавляя поддержку до 10 бит на выборку точности декодированного изображения.
Высокий профиль 4:2:2 (Hi422P, 122)
Этот профиль, ориентированный в первую очередь на профессиональные приложения, использующие чересстрочное видео, создан на основе профиля High 10, добавляя поддержку формата выборки цветности 4:2:2 с использованием до 10 бит на выборку точности декодированного изображения.
Прогнозирующий профиль High 4:4:4 (Hi444PP, 244)
Этот профиль создан на основе профиля High 4:2:2 и поддерживает выборку цветности до 4:4:4, до 14 бит на выборку, а также поддерживает эффективное кодирование областей без потерь и кодирование каждого изображения как три отдельных цвета. самолеты.

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

Высокий 10 Внутрипрофиль (110 с набором ограничений 3)
Профиль High 10 предназначен только для внутреннего использования.
Высокий внутренний профиль 4:2:2 (122 с набором ограничений 3)
Профиль High 4:2:2 предназначен только для внутреннего использования.
Высокий внутренний профиль 4:4:4 (244 с набором ограничений 3)
Профиль High 4:4:4 предназначен только для внутреннего использования.
CAVLC 4:4:4 Внутренний профиль (44)
Профиль High 4:4:4 ограничен использованием all-Intra и энтропийным кодированием CAVLC (т. е. не поддерживает CABAC).

В результате расширения Scalable Video Coding (SVC) стандарт содержит пять дополнительных масштабируемых профилей , которые определяются как комбинация профиля H.264/AVC для базового уровня (определяемого вторым словом в имени масштабируемого профиля). ) и инструменты, обеспечивающие масштабируемое расширение:

Масштабируемый базовый профиль (83)
Этот профиль, предназначенный в первую очередь для приложений видеоконференций, мобильных устройств и наблюдения, создан на основе профиля Constrained Baseline, которому должен соответствовать базовый уровень (подмножество битового потока). Для инструментов масштабирования включено подмножество доступных инструментов.
Масштабируемый ограниченный базовый профиль (83 с набором ограничений 5)
Подмножество масштабируемого базового профиля, предназначенное в первую очередь для приложений связи в реальном времени.
Масштабируемый высокий профиль (86)
Этот профиль, ориентированный в первую очередь на приложения вещания и потоковой передачи, построен на основе высокого профиля H.264/AVC, которому должен соответствовать базовый уровень.
Масштабируемый высокий профиль с ограничениями (86 с набором ограничений 5)
Подмножество масштабируемого высокого профиля, предназначенное в первую очередь для приложений связи в реальном времени.
Масштабируемый высокий внутренний профиль (86 с набором ограничений 3)
Этот профиль, ориентированный в первую очередь на производственные приложения, представляет собой масштабируемый высокий профиль, предназначенный только для внутреннего использования.

В результате расширения Multiview Video Coding (MVC) стандарт содержит два многовидовых профиля :

Стерео высокий профиль (128)
3D-видео с двумя изображениями Этот профиль предназначен для стереоскопического и сочетает в себе инструменты профиля High с возможностями межпросмотрового прогнозирования расширения MVC.
Многовидовой высокий профиль (118)
Этот профиль поддерживает два или более представлений, используя как межкадровое (временное), так и межвидовое предсказание MVC, но не поддерживает изображения полей и адаптивное к макроблокам кодирование полей кадров.

Расширение Multi-Resolve Frame-Compatible (MFC) добавило еще два профиля:

Высокий профиль МФЦ (134)
Профиль для стереоскопического кодирования с двухуровневым повышением разрешения.
Глубина MFC, высокий профиль (135)

Расширение 3D-AVC добавило еще два профиля:

Многовидовая глубина, высокий профиль (138)
Этот профиль поддерживает совместное кодирование карты глубины и информации о видеотекстуре для улучшения сжатия 3D-видеоконтента.
Улучшенный многовидовый, глубина, высокий профиль (139)
Расширенный профиль для комбинированного многовидового кодирования с информацией о глубине.

Поддержка функций в определенных профилях [ править ]

Особенность таможенно-пограничная служба БП XP член парламента ПроХиП Бедро Привет10P Привет422P Привет444PP
I and P slices Yes Yes Yes Yes Yes Yes Yes Yes Yes
Разрядность (на выборку) 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) Нет Да Да Нет Нет Нет Нет Нет Нет
Произвольный порядок срезов (ASO) Нет Да Да Нет Нет Нет Нет Нет Нет
Резервные срезы (RS) Нет Да Да Нет Нет Нет Нет Нет Нет
Разделение данных Нет Нет Да Нет Нет Нет Нет Нет Нет
Срезы SI и SP Нет Нет Да Нет Нет Нет Нет Нет Нет
Чересстрочное кодирование (PicAFF, MBAFF) Нет Нет Да Да Нет Да Да Да Да
Б-ломтики Нет Нет Да Да Да Да Да Да Да
Multiple reference frames Yes Yes Yes Yes Yes Yes Yes Yes Yes
In-loop deblocking filter Yes Yes Yes Yes Yes Yes Yes Yes Yes
CAVLC entropy coding Yes Yes Yes Yes Yes Yes Yes Yes Yes
Энтропийное кодирование CABAC Нет Нет Нет Да Да Да Да Да Да
4:0:0 ( Монохромный ) Нет Нет Нет Нет Да Да Да Да Да
Адаптивность преобразования 8×8 против 4×4 Нет Нет Нет Нет Да Да Да Да Да
Матрицы масштабирования квантования Нет Нет Нет Нет Да Да Да Да Да
Раздельное управление C B и C R QP Нет Нет Нет Нет Да Да Да Да Да
Отдельное кодирование цветовой плоскости Нет Нет Нет Нет Нет Нет Нет Нет Да
Прогнозирующее кодирование без потерь Нет Нет Нет Нет Нет Нет Нет Нет Да

Уровни [ править ]

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

Уровни с максимальными значениями свойств [28]
Уровень
Максимум
скорость декодирования
(макроблоков/с) 		Максимум
Размер рамки
(макроблоки) 		Максимум видео
битрейт для видео
уровень кодирования (VCL)
(Ограниченная базовая линия,
Базовый, расширенный
и основные профили)
(кбит/с) 		Примеры для высокого разрешения
@ самая высокая частота кадров
(максимальное количество сохраненных кадров)
Переключить дополнительные сведения

1 1,485 99 64 176×[email protected] (4)
1б 1,485 99 128 176×[email protected] (4)
1.1 3,000 396 192 352×[email protected] (2)
1.2 6,000 396 384 352×[email protected] (6)
1.3 11,880 396 768 352×[email protected] (6)
2 11,880 396 2,000 352×[email protected] (6)
2.1 19,800 792 4,000 352×[email protected] (6)
2.2 20,250 1,620 4,000 720×[email protected] (5)
3 40,500 1,620 10,000 720×[email protected] (5)
3.1 108,000 3,600 14,000 1,280×[email protected] (5)
3.2 216,000 5,120 20,000
1,280×[email protected] (5)
1,280×1,[email protected] (4)
4 245,760 8,192 20,000
1,280×[email protected] (9)
1,920×1,[email protected] (4)
2,048×1,[email protected] (4)
4.1 245,760 8,192 50,000
1,280×[email protected] (9)
1,920×1,[email protected] (4)
2,048×1,[email protected] (4)
4.2 522,240 8,704 50,000
1,280×[email protected] (9)
1,920×1,[email protected] (4)
2,048×1,[email protected] (4)
5 589,824 22,080 135,000
1,920×1,[email protected] (13)
2,048×1,[email protected] (13)
2,048×1,[email protected] (12)
2,560×1,[email protected] (5)
3,672×1,[email protected] (5)
5.1 983,040 36,864 240,000
1,920×1,[email protected] (16)
2,560×1,[email protected] (9)
3,840×2,[email protected] (5)
4,096×2,[email protected] (5)
4,096×2,[email protected] (5)
4,096×2,[email protected] (5)
5.2 2,073,600 36,864 240,000
1,920×1,[email protected] (16)
2,560×1,[email protected] (9)
3,840×2,[email protected] (5)
4,096×2,[email protected] (5)
4,096×2,[email protected] (5)
4,096×2,[email protected] (5)
6 4,177,920 139,264 240,000
3,840×2,[email protected] (16)
7,680×4,[email protected] (5)
8,192×4,[email protected] (5)
6.1 8,355,840 139,264 480,000
3,840×2,[email protected] (16)
7,680×4,[email protected] (5)
8,192×4,[email protected] (5)
6.2 16,711,680 139,264 800,000
3,840×2,[email protected] (16)
7,680×4,[email protected] (5)
8,192×4,[email protected] (5)

Максимальная скорость передачи данных для высокого профиля в 1,25 раза выше, чем для ограниченного базового, базового, расширенного и основного профилей; 3 раза для Hi10P и 4 раза для Hi422P/Hi444PP.

Количество выборок яркости в 16×16=256 раз превышает количество макроблоков (а количество выборок яркости в секунду в 256 раз превышает количество макроблоков в секунду).

Буферизация декодированного изображения [ править ]

Ранее закодированные изображения используются кодировщиками H.264/AVC для прогнозирования значений выборок в других изображениях. Это позволяет кодировщику принимать эффективные решения о наилучшем способе кодирования данного изображения. В декодере такие изображения сохраняются в виртуальном буфере декодированных изображений (DPB). Максимальная емкость DPB в единицах кадров (или парах полей), как показано в скобках в правом столбце таблицы выше, может быть рассчитана следующим образом:

DpbCapacity = min(floor( MaxDpbMbs / ( PicWidthInMbs * FrameHeightInMbs )), 16)

Где MaxDpbMbs — это постоянное значение, представленное в таблице ниже как функция номера уровня, и ПикВидсИнМбс и FrameHeightInMbs — это ширина изображения и высота кадра для кодированных видеоданных, выраженные в единицах макроблоков (округленные до целых значений и с учетом обрезки и спаривания макроблоков, когда это применимо). Эта формула указана в разделах A.3.1.h и A.3.2.f редакции стандарта 2017 года. [28]

Уровень 1 1б 1.1 1.2 1.3 2 2.1 2.2 3 3.1 3.2 4 4.1 4.2 5 5.1 5.2 6 6.1 6.2
МаксДпбМбс 396 396 900 2,376 2,376 2,376 4,752 8,100 8,100 18,000 20,480 32,768 32,768 34,816 110,400 184,320 184,320 696,320 696,320 696,320

Например, для изображения HDTV шириной 1920 отсчетов ( ПикВидсИнМбс = 120 ) и высотой 1080 семплов ( ФреймХайтИнМбс = 68 ), декодер уровня 4 имеет максимальную емкость памяти DPB пол(32768/(120*68)) = 4 кадра (или 8 полей). Так, в таблице выше в правом столбце строки для Уровня 4 с размером кадра 1920х1080 в скобках показано значение 4.

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

Реализации [ править ]

Статистика видео YouTube с видеокодеком AVC (H.264) и Opus. аудиоформатом

В 2009 году рабочая группа HTML5 разделилась на сторонников Ogg Theora , бесплатного видеоформата, который, как считается, не обременен патентами, и H.264, содержащего запатентованную технологию. Еще в июле 2009 года сообщалось, что Google и Apple поддерживают H.264, а Mozilla и Opera поддерживают Ogg Theora (теперь Google, Mozilla и Opera поддерживают Theora и WebM с VP8 ). [52] Microsoft с выпуском Internet Explorer 9 добавила поддержку видео HTML 5, закодированного с использованием H.264. На симпозиуме Gartner/ITXpo в ноябре 2010 года генеральный директор Microsoft Стив Балмер ответил на вопрос «HTML 5 или Silverlight ?» сказав: «Если вы хотите сделать что-то универсальное, нет никаких сомнений в том, что мир переходит на HTML5». [53] В январе 2011 года Google объявила, что прекращает поддержку H.264 в своем браузере Chrome и поддерживает Theora и WebM / VP8 для использования только открытых форматов. [54]

18 марта 2012 года Mozilla объявила о поддержке H.264 в Firefox на мобильных устройствах из-за преобладания видео в кодировке H.264 и повышенной энергоэффективности за счет использования специального аппаратного декодера H.264, обычного для таких устройств. [55] 20 февраля 2013 г. Mozilla реализовала в Firefox поддержку декодирования H.264 в Windows 7 и более поздних версиях. Эта функция опирается на встроенные библиотеки декодирования Windows. [56] Firefox 35.0, выпущенный 13 января 2015 г., поддерживает H.264 в OS X 10.6 и выше. [57]

30 октября 2013 года Роуэн Троллоп из Cisco Systems объявил, что Cisco выпустит как двоичные файлы, так и исходный код видеокодека H.264 под названием OpenH264 под лицензией Simplified BSD , а также выплатит все гонорары за его использование MPEG LA для любых программных проектов. которые используют предварительно скомпилированные двоичные файлы Cisco, что делает двоичные файлы Cisco OpenH264 бесплатными для использования. Однако любые программные проекты, использующие исходный код Cisco вместо ее двоичных файлов, будут нести юридическую ответственность за выплату всех гонораров MPEG LA. Целевые архитектуры ЦП включают x86 и ARM, а целевые операционные системы включают Linux, Windows XP и более поздние версии, Mac OS X и Android; iOS в этом списке отсутствовала, поскольку она не позволяет приложениям получать и устанавливать бинарные модули из Интернета. [58] [59] [60] Также 30 октября 2013 г. Брендан Эйх из Mozilla написал, что он будет использовать двоичные файлы Cisco в будущих версиях Firefox, чтобы добавить поддержку H.264 в Firefox, где кодеки платформы недоступны. [61] Cisco опубликовала исходный код OpenH264 9 декабря 2013 г. [62]

Хотя iOS не поддерживалась выпуском программного обеспечения Cisco 2013 года, Apple обновила свою платформу Video Toolbox Framework до iOS 8 (выпущенной в сентябре 2014 года), чтобы обеспечить прямой доступ к аппаратному кодированию и декодированию видео H.264/AVC. [59]

Программные кодеры [ править ]

Реализации программного обеспечения AVC
Особенность QuickTime Черный OpenH264 х264 Основной-
Концепция 		Элекард ТСЕ Про-
Кодер 		Авива Элементаль ИПП
Б-ломтики Да Да Да Да Да Да Да Да Нет Да Да
Несколько опорных систем Да Да Да Да Да Да Да Да Нет Да Да
Чересстрочное кодирование (PicAFF, MBAFF) Нет МБАФФ МБАФФ МБАФФ Да Да Нет Да МБАФФ Да Нет
Энтропийное кодирование CABAC Да Да Да Да Да Да Да Да Нет Да Да
Адаптивность преобразования 8×8 против 4×4 Нет Да Да Да Да Да Да Да Нет Да Да
Матрицы масштабирования квантования Нет Нет Да Да Да Нет Нет Нет Нет Нет Нет
Раздельное управление C B и C R QP Нет Нет Да Да Да Да Нет Нет Нет Нет Нет
Расширенные форматы цветности Нет Нет Нет 4:0:0 [63]
4:2:0
4:2:2 [64]
4:4:4 [65]   		 4:2:2 4:2:2 4:2:2 Нет Нет 4:2:0
4:2:2 		Нет
Наибольшая глубина выборки (бит) 8 8 8 10 [66] 10 8 8 8 8 10 12
Прогнозирующее кодирование без потерь Нет Нет Нет Да [67] Нет Нет Нет Нет Нет Нет Нет

Аппаратное обеспечение [ править ]

См. также: Продукты и реализации H.264/MPEG-4 AVC.

Поскольку кодирование и декодирование H.264 требует значительной вычислительной мощности для определенных типов арифметических операций, программные реализации, работающие на процессорах общего назначения, обычно менее энергоэффективны. Однако последние [ когда? ] Четырехъядерные процессоры общего назначения x86 обладают достаточной вычислительной мощностью для выполнения кодирования SD и HD в реальном времени. Эффективность сжатия зависит от реализации алгоритмов видео, а не от того, используется ли аппаратная или программная реализация. Таким образом, разница между аппаратной и программной реализацией больше заключается в энергоэффективности, гибкости и стоимости. Чтобы повысить энергоэффективность и уменьшить форм-фактор аппаратного обеспечения, можно использовать специальное оборудование либо для полного процесса кодирования или декодирования, либо для ускорения процесса в среде, управляемой ЦП.

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

второго поколения Процессоры Intel Sandy Bridge представленные Core i3/i5/i7, на выставке CES ( Consumer Electronics Show ) в январе 2011 года, оснащены встроенным аппаратным кодировщиком Full HD H.264, известным как Intel Quick Sync Video . [68] [69]

Аппаратный кодер H.264 может представлять собой ASIC или FPGA .

Кодеры ASIC с функциональностью кодировщика H.264 доступны от многих различных полупроводниковых компаний, но основная конструкция, используемая в ASIC, обычно лицензируется у одной из немногих компаний, таких как Chips&Media , Allegro DVT, On2 (ранее Hantro, приобретенная Google), Imagination Technologies , NGCodec. Некоторые компании предлагают продукты как FPGA, так и ASIC. [70]

Texas Instruments производит линейку ядер ARM + DSP, которые выполняют кодирование DSP H.264 BP 1080p со скоростью 30 кадров в секунду. [71] Это обеспечивает гибкость в отношении кодеков (которые реализованы в виде высокооптимизированного кода DSP), будучи более эффективными, чем программное обеспечение на обычном ЦП.

Лицензирование [ править ]

См. также: Microsoft Corp. против Motorola Inc. и Qualcomm Inc. против Broadcom Corp.

В странах, где патенты на программные алгоритмы сохраняются, ожидается, что поставщики и коммерческие пользователи продуктов, использующих H.264/AVC, будут платить лицензионные отчисления за патенты на запатентованную технологию, которую используют их продукты. [72] Это относится и к базовому профилю. [73]

Частная организация, известная как MPEG LA , которая никоим образом не связана с организацией по стандартизации MPEG, управляет лицензиями на патенты, применимые к этому стандарту, а также другие пулы патентов , такие как MPEG-4 Part 2 Video, HEVC и MPEG-ДАШ. В число патентообладателей входят Fujitsu , Panasonic , Sony , Mitsubishi , Apple , Колумбийский университет , KAIST , Dolby , Google , JVC Kenwood , LG Electronics , Microsoft , NTT Docomo , Philips , Samsung , Sharp , Toshiba и ZTE . [74] хотя большинство патентов в пуле принадлежат Panasonic (1197 патентов), Godo Kaisha IP Bridge (1130 патентов) и LG Electronics (990 патентов). [75]

26 августа 2010 года MPEG LA объявил, что гонорары не будут взиматься за интернет-видео в формате H.264, которое бесплатно для конечных пользователей. [76] Все остальные роялти остаются в силе, например, роялти за продукты, декодирующие и кодирующие видео H.264, а также операторам бесплатного телевидения и каналов по подписке. [77] Условия лицензии обновляются блоками по 5 лет. [78]

Поскольку первая версия стандарта была завершена в мае 2003 г. ( 21 год назад), а наиболее часто используемый профиль (Высокий профиль) был завершен в июне 2004 г. [ нужна цитата ] ( 19–20 лет назад), срок действия всех оригинальных патентов к настоящему времени истек, [75] хотя один из патентов США в пуле MPEG LA H.264 (выданный в 2016 году) действует как минимум до ноября 2030 года. [79]

В 2005 году Qualcomm подала иск против Broadcom в окружной суд США, утверждая, что Broadcom нарушила два ее патента, создав продукты, соответствующие стандарту сжатия видео H.264. [80] В 2007 году окружной суд установил, что патенты не имеют исковой силы, поскольку Qualcomm не раскрыла их JVT до выпуска стандарта H.264 в мае 2003 года. [80] В декабре 2008 года Апелляционный суд Федерального округа США подтвердил постановление Окружного суда о признании патентов неисполнимыми, но вернул их в Окружной суд с инструкциями ограничить сферу неисполнимости продуктами, совместимыми с H.264. [80]

В октябре 2023 года Nokia подала в суд на HP и Amazon за нарушение патентных прав H.264/H.265 в США, Великобритании и других странах. [81]

См. также [ править ]

Ссылки [ править ]

  1. ^ MPEG-4, Расширенное кодирование видео (Часть 10) (H.264) (Полный проект). Устойчивость цифровых форматов. Вашингтон, округ Колумбия: Библиотека Конгресса. 5 декабря 2011 года . Проверено 1 декабря 2021 г.
  2. ^ «H.264: Расширенное кодирование видео для общих аудиовизуальных услуг» . www.itu.int . Архивировано из оригинала 31 октября 2019 года . Проверено 22 ноября 2019 г.
  3. ^ «Отчет разработчиков видео за 2018 год» (PDF) . Битмовин . Сентябрь 2019.
  4. ^ «Отчет разработчиков видео 2019» . Битмовин . Сентябрь 2019.
  5. ^ «Передача 8K с использованием AVC/H.264» . Таинственный ящик . Архивировано из оригинала 25 марта 2021 года . Проверено 23 августа 2017 г.
  6. ^ Перейти обратно: а б Ван, Ханли; Квонг, С.; Кок, К. (2006). «Эффективный алгоритм прогнозирования целочисленных коэффициентов DCT для оптимизации H.264/AVC». Транзакции IEEE по схемам и системам видеотехнологий . 16 (4): 547–552. дои : 10.1109/TCSVT.2006.871390 . S2CID   2060937 .
  7. ^ Перейти обратно: а б Томсон, Гэвин; Шах, Атар (2017). «Представляем HEIF и HEVC» (PDF) . Apple Inc. Проверено 5 августа 2019 г ..
  8. ^ Озер, январь (8 мая 2023 г.), через переговоры Хита Хоглунда из Лос-Анджелеса о MPEG LA/через слияние лицензионного патентного пула , StreamingMedia.com
  9. ^ «Рекомендации МСЭ-Т» . МСЭ . Проверено 1 ноября 2022 г.
  10. ^ «H.262: Информационные технологии. Общее кодирование движущихся изображений и связанной с ними аудиоинформации: Видео» . Проверено 15 апреля 2007 г.
  11. ^ Объединенная видеогруппа , веб-сайт ITU-T .
  12. ^ «Рекомендация МСЭ-Т H.264 (05/2003)» . МСЭ. 30 мая 2003 года . Проверено 18 апреля 2013 г.
  13. ^ «Рекомендация МСЭ-Т H.264 (05/2003) Кор. 1 (05/2004)» . МСЭ. 7 мая 2004 года . Проверено 18 апреля 2013 г.
  14. ^ «Рекомендация МСЭ-Т H.264 (03/2005)» . МСЭ. 1 марта 2005 года . Проверено 18 апреля 2013 г.
  15. ^ «Рекомендация МСЭ-Т H.264 (2005 г.), Кор. 1 (09/2005 г.)» . МСЭ. 13 сентября 2005 года . Проверено 18 апреля 2013 г.
  16. ^ Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (2005 г.), поправка 1 (06/2006 г.)» . МСЭ. 13 июня 2006 года . Проверено 18 апреля 2013 г.
  17. ^ «Рекомендация МСЭ-Т H.264 (2005 г.), поправка 2 (04/2007 г.)» . МСЭ. 6 апреля 2007 года . Проверено 18 апреля 2013 г.
  18. ^ «Рекомендация МСЭ-Т H.264 (11/2007)» . МСЭ. 22 ноября 2007 года . Проверено 18 апреля 2013 г.
  19. ^ «Рекомендация МСЭ-Т H.264 (2007 г.), Кор. 1 (01/2009 г.)» . МСЭ. 13 января 2009 года . Проверено 18 апреля 2013 г.
  20. ^ Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (03/2009)» . МСЭ. 16 марта 2009 года . Проверено 18 апреля 2013 г.
  21. ^ Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (03/2010)» . МСЭ. 9 марта 2010 года . Проверено 18 апреля 2013 г.
  22. ^ Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (06/2011)» . МСЭ. 29 июня 2011 года . Проверено 18 апреля 2013 г.
  23. ^ «Рекомендация МСЭ-Т H.264 (01/2012)» . МСЭ. 13 января 2012 года . Проверено 18 апреля 2013 г.
  24. ^ Перейти обратно: а б с д «Рекомендация МСЭ-Т H.264 (04/2013)» . МСЭ. 12 июня 2013 года . Проверено 16 июня 2013 г.
  25. ^ Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (02/2014)» . МСЭ. 28 ноября 2014 года . Проверено 28 февраля 2016 г.
  26. ^ «Рекомендация МСЭ-Т H.264 (02/2016)» . МСЭ. 13 февраля 2016 года . Проверено 14 июня 2017 г.
  27. ^ «Рекомендация МСЭ-Т H.264 (10/2016)» . МСЭ. 14 октября 2016 года . Проверено 14 июня 2017 г.
  28. ^ Перейти обратно: а б с «Рекомендация МСЭ-Т H.264 (04/2017)» . МСЭ. 13 апреля 2017 г. Таблицы возможностей, зависящих от уровня, см. в таблицах A-1, A-6 и A-7 . Проверено 14 июня 2017 г.
  29. ^ «H.264: Расширенное кодирование видео для общих аудиовизуальных услуг - Версия 26 (Редакция 13)» . www.itu.int . 13 июня 2019 года. Архивировано из оригинала 4 ноября 2021 года . Проверено 3 ноября 2021 г.
  30. ^ «H.264: Расширенное кодирование видео для общих аудиовизуальных услуг - Версия 27 (Редакция 14)» . www.itu.int . 22 августа 2021 года. Архивировано из оригинала 4 ноября 2021 года . Проверено 3 ноября 2021 г.
  31. ^ Перейти обратно: а б «AVC/H.264 – Список патентов» (PDF) . MPEG Лос-Анджелес . Проверено 22 декабря 2022 г.
  32. ^ «Лицензиары AVC/H.264» . MPEG-LA. Архивировано из оригинала 30 мая 2015 года . Проверено 19 мая 2013 г.
  33. ^ Венгер; и другие. (февраль 2005 г.). «RFC 3984: Формат полезной нагрузки RTP для видео H.264» . Ietf Datatracker : 2. doi : 10.17487/RFC3984 .
  34. ^ «Какой режим записи эквивалентен качеству изображения формата видео высокой четкости (HDV)?» . Электронная поддержка Sony . Архивировано из оригинала 9 ноября 2017 года . Проверено 8 декабря 2018 г.
  35. ^ «Стандарт ATSC A/72, часть 1: Характеристики видеосистемы AVC в системе цифрового телевидения ATSC» (PDF) . Архивировано из оригинала (PDF) 7 августа 2011 года . Проверено 30 июля 2011 г.
  36. ^ «Стандарт ATSC A/72, часть 2: Характеристики подсистемы передачи видео AVC» (PDF) . Архивировано из оригинала (PDF) 7 августа 2011 года . Проверено 30 июля 2011 г.
  37. ^ «Стандарт ATSC A/153, часть 7: Характеристики видеосистем AVC и SVC» (PDF) . Архивировано из оригинала (PDF) 26 июля 2011 года . Проверено 30 июля 2011 г.
  38. ^ Перейти обратно: а б «Sony представляет новый формат записи XAVC для ускорения развития 4K на профессиональном и потребительском рынках» . Сони. 30 октября 2012 года . Проверено 1 ноября 2012 г.
  39. ^ Перейти обратно: а б «Sony представляет новый формат записи XAVC для ускорения развития 4K на профессиональном и потребительском рынках» (PDF) . Сони. 30 октября 2012 года . Проверено 1 ноября 2012 г. [ постоянная мертвая ссылка ]
  40. ^ Стив Дент (30 октября 2012 г.). «Sony выходит на «красную охоту» с камкордерами PMW-F55 и PMW-F5 pro CineAlta с сенсором Super 35 мм 4K» . Engadget . Проверено 5 ноября 2012 г.
  41. ^ «F55 CineAlta 4K — будущее, опережающее график» (PDF) . Сони. 30 октября 2012 г. Архивировано из оригинала (PDF) 19 ноября 2012 г. . Проверено 1 ноября 2012 г.
  42. ^ «Сверхбыстрые карты памяти SxS PRO+ преобразуют захват видео 4K» . Сони. Архивировано из оригинала 8 марта 2013 года . Проверено 5 ноября 2012 г.
  43. ^ «Сверхбыстрые карты памяти SxS PRO+ преобразуют захват видео 4K» (PDF) . Сони. Архивировано из оригинала (PDF) 2 апреля 2015 г. Проверено 5 ноября 2012 г.
  44. ^ Перейти обратно: а б Станкович, Радомир С.; Астола, Яакко Т. (2012). «Воспоминания о ранней работе в DCT: интервью с К.Р. Рао» (PDF) . Отпечатки первых дней информационных наук . 60:17 ​ . Проверено 13 октября 2019 г.
  45. ^ Квон, Сун-Ён; Ли, Джу Кён; Чунг, Ки-дон (2005). «Полупиксельная коррекция для транскодирования MPEG-2/H.264». Анализ и обработка изображений – ICIAP 2005 . Конспекты лекций по информатике. Том. 3617. Шпрингер Берлин Гейдельберг. стр. 576–583. дои : 10.1007/11553595_71 . ISBN  978-3-540-28869-5 .
  46. ^ Британак, Владимир; Да, Патрик С.; Рао, КР (2010). Дискретные косинусные и синусоидальные преобразования: общие свойства, быстрые алгоритмы и целочисленные аппроксимации . Эльзевир . стр. ix, xiii, 1, 141–304. ISBN  9780080464640 .
  47. ^ «Стандарт расширенного кодирования видео H.264/AVC: обзор и введение в расширения диапазона точности» (PDF) . Проверено 30 июля 2011 г.
  48. ^ Перейти обратно: а б с RFC 3984, стр. 3
  49. ^ Apple Inc. (26 марта 1999 г.). «Часто задаваемые вопросы по H.264» . Яблоко. Архивировано из оригинала 7 марта 2010 года . Проверено 17 мая 2010 г.
  50. ^ Карстен Зюринг. «Загрузка эталонного программного обеспечения H.264/AVC JM» . Iphome.hhi.de . Проверено 17 мая 2010 г.
  51. ^ «TS 101 154 – V1.9.1 – Цифровое видеовещание (DVB); Спецификация использования кодирования видео и аудио в приложениях вещания на основе транспортного потока MPEG-2» (PDF) . Проверено 17 мая 2010 г.
  52. ^ «Расшифровка дебатов о видеокодеке HTML 5» . Арс Техника . 6 июля 2009 года . Проверено 12 января 2011 г.
  53. ^ «Стив Балмер, генеральный директор Microsoft, дал интервью на симпозиуме Gartner/ITxpo в Орландо 2010» . Гартнервидео. Ноябрь 2010 г. Архивировано из оригинала 30 октября 2021 г. Проверено 12 января 2011 г.
  54. ^ «Поддержка видеокодеков HTML в Chrome» . 11 января 2011 года . Проверено 12 января 2011 г.
  55. ^ «Видео, мобильные устройства и открытая сеть» . 18 марта 2012 года . Проверено 20 марта 2012 г.
  56. ^ «WebRTC включен, поддержка H.264/MP3 в Win 7 включена по умолчанию, пользовательский интерфейс Metro для Windows 8 и многое другое — основные моменты разработки Firefox» . hacks.mozilla.org . Мозилла. 20 февраля 2013 года . Проверено 15 марта 2013 г.
  57. ^ «Firefox — Заметки (35.0)» . Мозилла .
  58. ^ «H.264 с открытым исходным кодом устраняет барьеры для WebRTC» . 30 октября 2013. Архивировано из оригинала 6 июля 2015 года . Проверено 1 ноября 2013 г.
  59. ^ Перейти обратно: а б «Часто задаваемые вопросы по проекту Cisco OpenH264» . Проверено 26 сентября 2021 г.
  60. ^ «Упрощенная лицензия BSD OpenH264» . Гитхаб . 27 октября 2013 года . Проверено 21 ноября 2013 г.
  61. ^ «Взаимодействие видео в Интернете улучшается благодаря кодеку Cisco H.264» . 30 октября 2013 года . Проверено 1 ноября 2013 г.
  62. ^ «Обновленный README · cisco/openh264@59dae50» . Гитхаб .
  63. ^ «Поддержка кодирования x264 4:0:0 (монохромное)» , дата обращения 05 июня 2019 г.
  64. ^ «Поддержка кодирования x264 4:2:2» , дата обращения 05 июня 2019 г.
  65. ^ «Поддержка кодирования x264 4:4:4» , дата обращения 05 июня 2019 г.
  66. ^ «Поддержка x264 для 9- и 10-битного кодирования» , дата обращения 22 июня 2011 г.
  67. ^ «x264 заменяет профиль High 4:4:4 без потерь на High 4:4:4 Predictive» , дата обращения 22 июня 2011 г.
  68. ^ «Краткое справочное руководство по созданию встроенных визуальных элементов процессора Intel Core» . Сеть программного обеспечения Intel. 1 октября 2010 года . Проверено 19 января 2011 г.
  69. ^ «Intel Quick Sync Video» . www.intel.com. 1 октября 2010 года . Проверено 19 января 2011 г.
  70. ^ «Design-reuse.com» . Design-reuse.com. 1 января 1990 года . Проверено 17 мая 2010 г.
  71. ^ «Категория: DM6467 — Wiki по встраиваемым процессорам Texas Instruments» . Processors.wiki.ti.com. 12 июля 2011. Архивировано из оригинала 17 июля 2011 года . Проверено 30 июля 2011 г.
  72. ^ «Портфолио брифингов» (PDF) . www.mpegla.com .
  73. ^ «OMS Video, проект Sun Open Media Commons Initiative» . Архивировано из оригинала 11 мая 2010 года . Проверено 26 августа 2008 г.
  74. ^ «Лицензиары, включенные в лицензию на портфель патентов AVC/H.264» . MPEG Лос-Анджелес . Проверено 18 июня 2019 г.
  75. ^ Перейти обратно: а б «AVC/H.264 – Список патентов» . Через Лицензионный Альянс . Проверено 28 апреля 2024 г.
  76. ^ «Лицензия AVC MPEG LA не взимает роялти за интернет-видео, которое бесплатно предоставляется конечным пользователям в течение всего срока действия лицензии» (PDF) . MPEG Лос-Анджелес. 26 августа 2010 г. Архивировано из оригинала (PDF) 7 ноября 2013 г. . Проверено 26 августа 2010 г.
  77. ^ Хачман, Марк (26 августа 2010 г.). «MPEG LA навсегда сокращает гонорары за бесплатное веб-видео» . pcmag.com . Проверено 26 августа 2010 г.
  78. ^ «Часто задаваемые вопросы по АВК» . MPEG Лос-Анджелес. 1 августа 2002 года. Архивировано из оригинала 7 мая 2010 года . Проверено 17 мая 2010 г.
  79. ^ «Патент США 9 356 620 Бэезе и др.» . Проверено 1 августа 2022 г. с самой ранней датой приоритета 14 сентября 2001 г., срок продлен на 2998 дней.
  80. ^ Перейти обратно: а б с См . Qualcomm Inc. против Broadcom Corp. , № 2007-1545, 2008-1162 (Федеральный суд от 1 декабря 2008 г.). Статьи в популярной прессе см. на сайте Signonsandiego.com, «Qualcomm проигрывает дело о патентных правах» и «Патентное дело Qualcomm передается на рассмотрение присяжных» ; и Bloomberg.com «Broadcom выигрывает первое судебное разбирательство по патентному спору Qualcomm»
  81. ^ «Нокиа h264» .

Дальнейшее чтение [ править ]

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Advanced_Video_Coding&oldid=1227369315"