Редактирование: H.264

{{переработать}}
'''H.264''', '''MPEG-4 Part 10''' или '''AVC''' (''Advanced Video Coding'') — лицензируемый стандарт [[сжатие видео|сжатия видео]], предназначенный для достижения высокой степени сжатия видеопотока при сохранении высокого качества.

== О стандарте ==
Создан [[ITU-T]] Video Coding Experts Group (VCEG) совместно с [[ISO]] / [[Международная электротехническая комиссия|IEC]] [[Moving Picture Experts Group]] (MPEG) в рамках совместной программы Joint Video Team (JVT).

Стандарты ITU-T H.264 и ISO/IEC [[MPEG-4]] Part 10 (формальное название — ISO/IEC 14496-10) технически полностью идентичны. Финальный вариант первой версии стандарта был закончен в мае [[2003 год]]а.

Используется в цифровом [[Телевидение высокой чёткости|телевидении высокой четкости HDTV]] и во многих других областях цифрового видео.

== Возможности ==
Стандарт H.264 / AVC / MPEG-4 Part 10 содержит ряд возможностей, позволяющих значительно повысить эффективность сжатия видео по сравнению с предыдущими (такими, как [[Advanced Simple Profile|ASP]]) стандартами, обеспечивая также большую гибкость применения в разнообразных сетевых средах. Основные из них:

* Многокадровое предсказание:
** Использование сжатых ранее кадров в качестве опорных (то есть с заимствованием части материала из них) куда более гибко, чем в предыдущих стандартах. Позволяется использование до 32 ссылок на другие кадры, тогда как в ASP и более ранних число ссылок ограничено одним или, в случае [[Типы кадров|B-кадров]], двумя кадрами. Это поднимает эффективность кодирования, так как позволяет кодеру выбирать для компенсации движения между большим количеством изображений. В большинстве сцен данная функция обеспечивает не очень большое улучшение в качестве и не даёт заметного понижения [[битрейт]]а. Однако, для некоторых сцен, например, с частыми повторяющимися участками, возвратно-поступательным движением и т. п. данный подход при сохранении качества позволяет очень сильно снизить затраты битрейта.
** Независимость порядка воспроизведения изображений и порядка опорных изображений. В предшествующих стандартах устанавливалась жёсткая зависимость между порядком следования изображений для использования при компенсации движения и порядком следования изображений при воспроизведении. В новом стандарте эти ограничения в значительной мере устранены, что позволяет кодеру выбирать порядок изображений для компенсации движения и для воспроизведения с высокой степенью гибкости, которая ограничена только объёмом памяти, который гарантирует возможность декодирования. Устранение ограничения также позволяет в ряде случаев устранить дополнительную задержку, ранее связанную с двунаправленным предсказанием.
** Независимость методов обработки изображений и возможности их использования для предсказания движения. В предшествующих стандартах изображения, закодированные с использованием некоторых методов (например, двунаправленного предсказания), не могли использоваться в качестве опорных для предсказания движения других изображений видеопоследовательности. Устраняя это ограничение, новый стандарт обеспечивает кодеру большую гибкость и, во многих случаях, возможность использовать для предсказания движения изображение, более близкое по содержанию к кодируемому.
** [[Компенсация движения]] с переменным размером блока (от 16x16 до 4x4 пикселя) позволяет крайне точно выделять области движения.
** Векторы движения, выводящие за границы изображения. В [[MPEG-2]] и предшествовавших ему стандартах векторы движения могли указывать только на пикселы, находящиеся в границах декодированного опорного изображения. Методика экстраполяции за границы изображения, появившаяся как опция в [[H.263]], включена в новый стандарт.
** Шеститочечная фильтрация компонента яркости для полупиксельного предсказания с целью уменьшения зубчатости краев и, в конечном счёте, обеспечения большей чёткости изображения.
** Точность до четверти пиксела (Qpel) при компенсации движения обеспечивает очень высокую точность описания движущихся областей (что особенно актуально для медленного движения). Цветность, как правило, хранится с разрешением, уменьшенным вдвое по вертикали и горизонтали ([[прореживание цвета]]), поэтому компенсация движения для компонента цветности использует точность в одну восьмую пиксела цветности.
** Взвешенное предсказание, позволяющее использовать масштабирование и сдвиг после компенсации движения на величины, указанные кодером. Такая методика может чрезвычайно сильно поднять эффективность кодирования для сцен с изменением освещённости, например при эффектах затемнения, постепенного появления изображения.
* Пространственное предсказание от краёв соседних блоков для [[Типы кадров|I-кадров]] (в отличие от предсказания только коэффициента трансформации в [[H.263]]+ и MPEG-4 Part 2, и дискретно-косинусного коэффициента в MPEG-2 Part 2). Новая методика экстраполяции краёв ранее декодированных частей текущего изображения повышает качество сигнала, используемого для предсказания.
* Сжатие макроблоков без потерь:
** Метод представления макроблоков без потерь в [[PCM]], при котором видеоданные представлены непосредственно, позволяющий точно описывать определённые области и допускающий строгое ограничение на количество закодированных данных для каждого макроблока.
** Улучшенный метод представления макроблоков без потерь, позволяющий точно описывать определённые области, при этом обычно затрачивая существенно меньше битов, чем PCM (поддерживается не во всех профилях).
* Гибкие функции [[Чересстрочная развёртка|чересстрочного]] сжатия (поддерживается не во всех профилях):
** Адаптивное к изображению кодирование полей ([[PAFF]]), позволяющее кодировать каждый кадр как кадр или как пару полей (полукадров) — в зависимости от отсутствия\наличия движения.
** Адаптивное к макроблокам кодирование полей ([[MBAFF]]), позволяющее независимо кодировать каждую вертикальную пару макроблоков (блок 16×32) как прогрессивные или чересстрочные. Позволяет использовать макроблоки 16×16 в режиме разбиения на поля (сравните с 16×8 полумакроблоками в [[MPEG-2]]). Почти всегда эффективнее PAFF.
* Новые функции преобразования:
** Точное целочисленное преобразование пространственных блоков 4×4 (концептуально подобное широко известному [[DCT]], но упрощенное и способное обеспечить точное декодирование<ref>В предшествующих стандартах преобразование оговаривалось только в рамках допустимых ошибок из-за практической нереализуемости точного обратного преобразования. В итоге, каждая реализация декодера могла давать слегка различное декодированное видео (что обуславливалось несовпадением представления декодированного видео на кодере и декодере), что приводит к снижению эффективного качества видео.</ref>), позволяющее точное размещение разностных сигналов с минимумом шума, часто возникающего в предыдущих кодеках.
** Точное целочисленное преобразование пространственных блоков 8x8 (концептуально подобное широко известному DCT, но упрощенное и способное обеспечить точное декодирование; поддерживается не во всех профилях), обеспечивающее большую эффективность сжатия схожих областей, чем 4×4.
** Адаптивный выбор кодеком между размерами блока 4×4 и 8×8 (поддерживается не во всех профилях).
** Дополнительное [[преобразование Адамара]], применяемое к дискретно-косинусным коэффициентам основного пространственного преобразования (к коэффициентов яркости, и, в особом случае, цветности) для достижения большей степени сжатия в однородных областях.
* Квантование:
** Логарифмическое управление длиной шага для упрощения распределения битрейта кодером и упрощенного вычисления обратной длины квантования.
** Частотно-оптимизированные матрицы масштабирования квантования, выбираемые кодером для оптимизации квантования на основе человеческих особенностей восприятия (поддерживается не во всех профилях).
* Внутренний фильтр [[деблокинг]]а в цикле кодирования, устраняющий [[Артефакты сжатия|артефакты]] блочности, часто возникающие при использовании основанных на [[DCT]] техниках сжатия изображений.
* [[Энтропийное кодирование]] квантованных коэффициентов трансформации:
** Context-adaptive binary arithmetic coding ([[CABAC]], контекстнозависимое адаптивное бинарное [[арифметическое кодирование]]) — алгоритм сжатия без потерь для синтаксических элементов видеопотока на основе вероятности их появления. Поддерживается только в Main Profile и выше. Обеспечивает более эффективное сжатие, чем [[CAVLC]], но требует значительно больше времени на декодирование.
** Context-adaptive variable-length coding (CAVLC, контекстнозависимое адаптивное кодирование с переменной длиной кодового слова) — альтернатива CABAC меньшей сложности. Тем не менее, оно сложнее и эффективнее, чем алгоритмы, применяемые для тех же целей в более ранних технологиях сжатия видео (как правило это [[алгоритм Хаффмана]]).
** Часто используемое, простое и высоко структурированное кодирование словами переменной длины многих элементов синтаксиса, не закодированных CABAC или CAVLC, известное как [[коды Голомба]] (экспоненциальное кодирование Голомба).
* Функции устойчивости к ошибкам:
** Определение уровня сетевой абстракции ([[Network Abstraction Layer|NAL]]), позволяющее использовать один и тот же синтаксис видео в различных сетевых окружениях, включая наборы параметров последовательности (sequence parameter sets, SPSs) и наборы параметров изображения (picture parameter sets, PPSs), которые обеспечивают большую надёжность и гибкость, чем предыдущие технологии.
** Гибкое упорядочивание макроблоков ([[Flexible Macroblock Ordering|FMO]]), также известное как группы частей (поддерживается не во всех профилях) и произвольное упорядочивание частей ([[Arbitrary Slice Ordering|ASO]]) — методы реструктурирования порядка представления фундаментальных областей (макроблоков) в изображениях. При эффективном использовании гибкое упорядочивание макроблоков может существенно повысить устойчивость к потере данных.
Благодаря ASO, так как каждая часть изображения может быть декодирована независимо от других (при определённых ограничениях кодирования), новый стандарт позволяет посылать и получать их в произвольном порядке друг относительно друга. Это может снизить задержку в приложениях реального времени, особенно при использовании на сетях, имеющих режим работы '''доставка вне очереди'''.
Эти функции могут также использоваться для множества других целей помимо восстановления ошибок.
** Разбиение данных — функция, обеспечивающая разделение данных разной важности (например, векторы движения и другая информация предсказания имеет большую значимость для представления видеоконтента) по разным пакетам данных с разными уровнями защиты от ошибок (поддерживается не во всех профилях).
** Избыточные части. Возможность посылки кодером избыточного представления областей изображений, позволяя воспроизвести области изображений (обычно с некоторой потерей качества), данные о которых были потеряны в процессе передачи (поддерживается не во всех профилях).
** Нумерация кадров, позволяющая создание «подпоследовательностей» (включая временно́е масштабирование включением дополнительных кадров между другими) а также обнаружение (и скрытие) потерь целых кадров при сбоях канала или пропаже пакетов.

== Профили ==
Стандарт определяет комплекты возможностей, которые называются профили, ориентированные на конкретные классы приложений.<!-- Следующая информация взята из англоязычной версии статьи http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles -->

;Baseline Profile (Базовый профиль): Применяется в недорогих продуктах, требующих дополнительной устойчивости к потерям. Используется для видеоконференций и в мобильных продуктах. Включает все возможности Constrained Baseline Profile и, дополнительно, возможности для большей устойчивости к потерям при передаче. С появлением Constrained Baseline Profile отошёл на второй план, так как все потоки Constrained Baseline Profile соответствуют Baseline Profile, и оба этих профиля имеют общий код идентификатора.
;Constrained Baseline Profile (Ограниченный базовый профиль): Рассчитан на применение в недорогих продуктах. Включает набор возможностей, общих для профилей Baseline, Main, и High профилей.
;Main Profile (Основной профиль): Применяется для цифрового телевидения стандартной четкости в трансляциях, использующих сжатие MPEG-4 в соответствии со стандартом DVB.
;Extended Profile (Расширенный профиль): Предназначен для потокового видео, имеет относительно высокую степень сжатия и дополнительные возможности для повышения устойчивости к потере данных.
;High Profile (Высокий профиль): Является основным для цифрового вещания и видео на оптических носителях, особенно для телевидения высокой четкости. Используется для Blu-Ray видеодисков и DVB HDTV вещания.
;High 10 Profile (Высокий профиль 10): Дополнительно поддерживает 10-битовую глубину кодирования изображения.
;<nowiki>High 4:2:2 Profile (Hi422P)</nowiki>: В основном нацелен на профессиональное использование при работе с чересстрочным видеопотоком. Поддерживает дополнительный вариант кодирования цветности.
;<nowiki>High 4:4:4 Predictive Profile (Hi444PP)</nowiki>: Базируясь на Hi422P, включает ещё один вариант кодирования цветности и работу с 14-битной глубиной кодирования.

Для профессионального применения стандарт содержит четыре дополнительных all-Intra профиля, которые характеризуются отсутствием межкадрового сжатия. То есть, при кодировании одного кадра информация о соседних не используется:

;High 10 Intra Profile:
;<nowiki>High 4:2:2 Intra Profile</nowiki>:
;<nowiki>High 4:4:4 Intra Profile</nowiki>:
;<nowiki>CAVLC 4:4:4 Intra Profile</nowiki>:

С принятием расширения Scalable Video Coding (SVC) к стандарту были добавлены три профиля, соответствующие базовым, с добавлением возможности включать потоки более низкого разрешения.
;Scalable Baseline Profile:
;Scalable High Profile:
;Scalable High Intra Profile:

Добавление расширения Multiview Video Coding (MVC) принесло ещё два дополнительных профиля:

;Stereo High Profile: Этот профиль рассчитан на стереоскопическое 3D видео (два изображения).
;Multiview High Profile: Этот профиль поддерживает два или несколько изображений (каналов) в потоке с использованием как межкадрового, так и межканального сжатия, но не поддерживает некоторые возможности MVC.

{|class="wikitable"
|+ Функции поддержки в отдельных профилях
!Функции
! style="width:10%;" title="Constrained Baseline Profile"| CBP
! style="width:10%;" title="Baseline Profile"| BP
! style="width:10%;" title="Extended Profile"| XP
! style="width:10%;" title="Main Profile"| MP
! style="width:10%;" title="High Profile"| HiP
! style="width:10%;" title="High 10 Profile"| Hi10P
! style="width:10%;" title="High 4:2:2 Profile"| Hi422P
! style="width:10%;" title="High 4:4:4 Predictive Profile"| Hi444PP
|- style="display:none"
! I and P slices
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Chroma formats
| {{Yes|4:2:0}} || {{Yes|4:2:0}} || {{Yes|4:2:0}} || {{Yes|4:2:0}} || {{Yes|4:2:0}} || {{Yes|4:2:0}} || {{yes|4:2:0/4:2:2}} || {{yes|4:2:0/4:2:2/4:4:4}}
|-
! Sample depths (bits)
| {{Yes|8}} || {{Yes|8}} || {{Yes|8}} || {{Yes|8}} || {{Yes|8}} || {{yes|8 to 10}} || {{yes|8 to 10}} || {{yes|8 to 14}}
|-
! Flexible macroblock ordering (FMO)
| {{no}} || {{yes}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! Arbitrary slice ordering (ASO)
| {{no}} || {{yes}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! Redundant slices (RS)
| {{no}} || {{yes}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! Data partitioning
| {{no}} || {{no}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! SI and SP slices
| {{no}} || {{no}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! B slices
| {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Interlaced coding (PicAFF, MBAFF)
| {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|- style="display:none"
! Multiple reference frames
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|- style="display:none"
! In-loop deblocking filter
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|- style="display:none"
! CAVLC entropy coding
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! CABAC entropy coding
| {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! 8×8 vs. 4×4 transform adaptivity
| {{no}} || {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Quantization scaling matrices
| {{no}} || {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Separate C<sub>b</sub> and C<sub>r</sub> QP control
| {{no}} || {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Monochrome (4:0:0)
| {{no}} || {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Separate color plane coding
| {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{yes}}
|-
! Predictive lossless coding
| {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{yes}}
|}

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

{| class="wikitable" cellpadding="1" cellspacing="1" style="text-align:right;"
|+ Уровни с максимальными параметрами
|-
!rowspan="2"| Уровень
!colspan="2"| Макс. кол-во макроблоков
!colspan="4"| Макс. скорость видеопотока (VCL) кбит/с
!rowspan="2"| Примеры максимального <br>разрешения@частоты кадров <br>(макс. кол-во сохранённых кадров)
|-
! в секунду<!--<br>(s<sup>−1</sup>)-->
! в кадре
!BP, XP, MP
!HiP
!Hi10P
!Hi422P, Hi444PP
|-
! 1
| 1,485
| 99
| 64 || 80 || 192 || 256
| 128×96@30,9 (8)<br>176×144@15,0 (4)
|-
! 1b
| 1,485
| 99
| 128 || 160 || 384 || 512
| 128×96@30,9 (8)<br>176×144@15,0 (4)
|-
! 1.1
| 3,000
| 396
| 192 || 240 || 576 || 768
| 176×144@30,3 (9)<br>320×240@10,0 (3)<br>352×288@7,5 (2)
|-
! 1.2
| 6,000
| 396
| 384 || 480 || 1,152 || 1,536
| 320×240@20,0 (7)<br>352×288@15,2 (6)
|-
! 1.3
| 11,880
| 396
| 768 || 960 || 2,304 || 3,072
| 320×240@36,0 (7)<br>352×288@30,0 (6)
|-
! 2
| 11,880
| 396
| 2,000 || 2,500 || 6,000 || 8,000
| 320×240@36,0 (7)<br>352×288@30,0 (6)
|-
! 2.1
| 19,800
| 792
| 4,000 || 5,000 || 12,000 || 16,000
| 352×480@30,0 (7)<br>352×576@25,0 (6)
|-
! 2.2
| 20,250
| 1,620
| 4,000 || 5,000 || 12,000 || 16,000
| 352×480@30,7 (10)<br>352×576@25,6 (7)<br>720×480@15,0 (6)<br>720×576@12,5 (5)
|-
! 3
| 40,500
| 1,620
| 10,000 || 12,500 || 30,000 || 40,000
| 352×480@61,4 (12)<br>352×576@51,1 (10)<br>720×480@30,0 (6)<br>720×576@25,0 (5)
|-
! 3.1
| 108,000
| 3,600
| 14,000 || 17,500 || 42,000 || 56,000
| 720×480@80,0 (13)<br>720×576@66,7 (11)<br>1280×720@30,0 (5)
|-
! 3.2
| 216,000
| 5,120
| 20,000 || 25,000 || 60,000 || 80,000
| 1280×720@60,0 (5)<br>1280×1024@42,2 (4)
|-
! 4
| 245,760
| 8,192
| 20,000 || 25,000 || 60,000 || 80,000
| 1280×720@68,3 (9)<br>1920×1080@30,1 (4)<br>2048×1024@30,0 (4)
|-
! 4.1
| 245,760
| 8,192
| 50,000 || 62,500 || 150,000 || 200,000
| 1280×720@68,3 (9)<br>1920×1080@30,1 (4)<br>2048×1024@30,0 (4)
|-
! 4.2
| 522,240
| 8,704
| 50,000 || 62,500 || 150,000 || 200,000
| 1920×1080@64,0 (4)<br>2048×1080@60,0 (4)
|-
! 5
| 589,824
| 22,080
| 135,000 || 168,750 || 405,000 || 540,000
| 1920×1080@72,3 (13)<br>2048×1024@72,0 (13)<br>2048×1080@67,8 (12)<br>2560×1920@30,7 (5)<br>3680×1536@26,7 (5)
|-
! 5.1
| 983,040
| 36,864
| 240,000 || 300,000 || 720,000 || 960,000
| 1920×1080@120,5 (16)<br>4096×2048@30,0 (5)<br>4096×2304@26,7 (5)
|-
! 5.2
| 2,073,600
| 36,864
| 240,000 || ? || ? || ?
| 1,920×1,080@172 (?)<br>2,048×1,536@160 (?)<br>4,096×2,160@60 (?)
|-
! 6
| 4,177,920
| 139,264
| 240,000 || ? || ? || ?
| 2,048×1,536@300 (?)<br>4,096×2,160@120 (?)<br>8,192×4,320@30 (?)
|-
! 6.1
| 8,355,840
| 139,264
| 480,000 || ? || ? || ?
| 2,048×1,536@300 (?)<br>4,096×2,160@240 (?)<br>8,192×4,320@60 (?)
|-
! 6.2
| 16,711,680
| 139,264
| 800,000 || ? || ? || ?
| 4,096*2,304@300 (?)<br>8,192×4,320@120 (?)
|}

== Патенты ==
В странах, где действуют [[Патент на программное обеспечение|патенты на программное обеспечение]], разработчики программного обеспечения, использующего алгоритмы H.264/AVC, обязаны платить лицензионные отчисления держателям патентов. Держателями таковых, в частности, являются Microsoft, Fujitsu, Philips, Apple, Samsung, Cisco, Toshiba, Panasonic<ref name=autogenerated1>{{Cite web |url=http://www.mpegla.com/main/programs/avc/Documents/avc-att1.pdf |title=Архивированная копия |accessdate=2010-01-30 |archiveurl=https://web.archive.org/web/20150514191648/http://www.mpegla.com/main/programs/avc/Documents/avc-att1.pdf |archivedate=2015-05-14 |deadlink=yes }}</ref><ref>{{Cite web |url=http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx |title=MPEG LA — The Standard for Standards — AVC Patent List |accessdate=2010-01-30 |archiveurl=https://web.archive.org/web/20100208234638/http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx |archivedate=2010-02-08 |deadlink=yes }}</ref>. Также существует организация [[MPEG LA]], которая является администратором консолидированного пула патентов<ref>{{статья|ссылка=http://www.microsoft.com/windows/windowsmedia/licensing/mpeg4faq.aspx#MPEG4VideoFAQ_1_1|заглавие=MPEG LA License for MPEG-4 Video FAQ}}</ref><ref>{{Cite web |url=http://www.mpegla.com/main/programs/AVC/Pages/Intro.aspx |title=MPEG LA — The Standard for Standards — AVC Introduction |accessdate=2010-01-30 |archiveurl=https://web.archive.org/web/20100123052401/http://www.mpegla.com/main/programs/AVC/Pages/Intro.aspx |archivedate=2010-01-23 |deadlink=yes }}</ref>. Всего существует более сотни патентов, так или иначе затрагивающих или описывающих алгоритмы H.264. Сроки действия части из них уже истекли, однако некоторые будут продолжать действовать в США вплоть до 2028 года<ref>[http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020737.html &#91;whatwg&#93; Codecs for <audio> and <video>]</ref><ref name=autogenerated1 />.

В марте 2011 г. [[Министерство юстиции США]] начало расследование против MPEG LA по подозрению в использовании [[Патентное право|патентного права]] с целью устранения конкурента — [[WebM]] от [[Google (компания)|Google]]. Поводом к началу расследования стали обвинения в нарушении патентов третьих разработчиков<ref>{{cite web|url=http://itc.ua/news/v_ssha_mpeg_la_podozrevayut_v_popytkah_nechestno_konkurirovat_s_google_52234|title=В США MPEG LA подозревают в попытках нечестно конкурировать с Google|author=|date=2011-03-07|work=ITC.ua|publisher=|accessdate=2011-03-07|lang=|archiveurl=https://www.webcitation.org/65TLG3OOK?url=http://itc.ua/news/v_ssha_mpeg_la_podozrevayut_v_popytkah_nechestno_konkurirovat_s_google_52234/|archivedate=2012-02-15}}</ref>.

== Недостатки ==
Кодеки для MPEG-4 AVC более требовательны к ресурсам, нежели кодеки на основе MPEG-4 ASP (такие, как [[DivX]] и [[Xvid|XviD]])<ref name="computerra">{{статья|ссылка=https://old.computerra.ru/290258/|автор=Филипп Казаков.|заглавие=h264. Год спустя: Технология кодирования видео в MPEG-4 AVC. Часть первая|год=2006|язык=|издание=[[Компьютерра-онлайн]]|тип=|месяц=10|число=16|том=|номер=|страницы=|issn=}}</ref>, однако это компенсируется другими достоинствами<ref>{{статья|автор=Олейник И. В.|часть=Н.264 более требователен к ресурсам?|заглавие=Н.264. Некоторая правда о заблуждениях|ссылка=http://secuteck.ru/articles2/ip-security/h-264-nekotoraya-pravda-o-zablujdeniyah|издание=Системы безопасности|тип=журнал|номер=2|год=2009}}</ref>.

Формат запатентован, и создатели кодеков обязаны платить за их распространение путём покупки лицензий. С 2011 года MPEG LA могла бы начать взимать плату и с тех, кто участвует в кодировании и/или бесплатном предоставлении пользователям видеопотока в AVC<ref>{{Cite web
 |url           = http://streaminglearningcenter.com/articles/46/1/H264-Royalties-what-you-need-to-know/Page1.html
 |title         = H.264 Royalties: what you need to know
 |author        = Jan Ozer
 |publisher     = [[Streaming Learning Center]]
 |lang          = en
 |datepublished = 2009-06-22
 |accessdate    = 2009-07-07
 |archiveurl    = https://www.webcitation.org/65TLKl93I?url=http://streaminglearningcenter.com/articles/h264-royalties-what-you-need-to-know.html
 |archivedate   = 2012-02-15
 }}</ref><ref>{{Cite web
 |url           = http://streamingmedia.com/r/printerfriendly.asp?id=11011
 |title         = The H.264 Licensing Labyrinth
 |author        = Tim Siglin
 |publisher     = [[Streaming Media Inc.]] / [[Information Today Inc.]]
 |lang          = en
 |datepublished = 2009-02-12
 |accessdate    = 2009-07-07
 |deadlink      =yes
 |archiveurl    = https://web.archive.org/web/20100102085333/http://streamingmedia.com/r/printerfriendly.asp?id=11011
 |archivedate   = 2010-01-02
 }}</ref>. Однако позже этот срок был изменён на 2015 год, а 26 августа 2010 года компания MPEG LA объявила, что за бесплатное предоставление пользователям видеопотока в H.264 плата взиматься не будет<ref>[http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/231/n-10-08-26.pdf MPEG LA’s AVC License Will Not Charge Royalties for Internet Video that is Free to End Users through Life of License] {{webarchive|url=https://web.archive.org/web/20100922194859/http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/231/n-10-08-26.pdf |date=2010-09-22 }} {{ref-en}}</ref>.

== Примечания ==
{{примечания}}

== См. также ==
* [[x264]]
* [[Digital Rights Management|DRM]]
* [[AVC-Intra]]
* [[AVCHD]]
* [[H.265]]
* [[VP8]]

== Ссылки ==
* {{cite web
 |author      = MSU Video Group.
 |date        = 2010-05-25
 |url         = http://compression.ru/video/codec_comparison/h264_2010
 |title       = Sixth MPEG-4 AVC/H.264 Video Codecs Comparison — Short Version
 |publisher   = compression.ru
 |accessdate  = 2010-07-10
 |lang        = en
 |archiveurl  = https://www.webcitation.org/65TLMfdEN?url=http://compression.ru/video/codec_comparison/h264_2010
 |archivedate = 2012-02-15
 }}
* {{cite web
 |date        = 2009-03-27
 |url         = http://www.secnews.ru/articles/13219.htm
 |title       = Суета вокруг кодека. Правда и домыслы о «чудесном» H.264
 |publisher   = Security News
 |accessdate  = 2010-07-11
 |lang        = ru
 |archiveurl  =
 |archivedate =
}}
* {{cite web
 |url         = http://compression-links.info/MPEG-4_AVC_H264
 |title       = MPEG-4 AVC / H.264 area
 |publisher   = Compression Links
 |description = Список ресурсов и кодеков H.264/AVC
 |accessdate  = 2010-07-10
 |lang        = en
 |archiveurl  = https://web.archive.org/web/20191125042401/http://compression.ru/?linksMPEG-4_AVC_H264
 |archivedate = 2019-11-25
 |deadlink    = yes
 }}
* [http://download.microsoft.com/download/2/D/0/2D02E72E-7890-430F-BA91-4A363F72F8C8/DXVA_H264_MVC.pdf DirectX Video Acceleration Specification for H.264/MPEG-4 AVC Multiview Video Coding (MVC), Including the Stereo High Profile]
* [https://habrahabr.ru/post/316580/ Магия H.264] - Приёмы сжатия используемые в кодеке H.264

{{MPEG}}
{{Стандарты ISO}}
{{Сжатие видео}}

[[Категория:Видеокодеки]]
[[Категория:MPEG]]
[[Категория:Стандарты ISO]]
[[Категория:Рекомендации ITU-T]]
[[Категория:Видеоконференция]]