高度なビデオコーディング

アドバンストビデオコーディング（AVC ）は、 H.264またはMPEG-4パート10とも呼ばれ、ブロック指向の動き補償コーディングに基づくビデオ圧縮規格です。 ^[2]これは、ビデオコンテンツの記録、圧縮、配信に最も一般的に使用されている形式であり、2019年9月現在、ビデオ業界開発者の91％が使用しています。^{[3] [4]}最大解像度8K UHDをサポートしています。^{[5] [6][アップデート]}

H.264/AVC プロジェクトの目的は、設計の複雑さを増大させすぎて実装が非現実的になったり、過度に高価になったりすることなく、以前の標準よりも大幅に低いビット レート(つまり、 MPEG-2、H.263、またはMPEG-4 Part 2のビット レートの半分以下) で優れたビデオ品質を提供できる標準を作成することでした。これは、複雑さを軽減した整数離散コサイン変換(整数 DCT)、^[7]可変ブロック サイズ セグメンテーション、およびマルチ ピクチャインター ピクチャ予測などの機能によって達成されました。追加の目標は、低ビット レートと高ビット レート、低解像度と高解像度のビデオ、ブロードキャスト、DVDストレージ、RTP / IPパケット ネットワーク、およびITU-Tマルチメディア電話システムなど、さまざまなネットワークとシステム上のさまざまなアプリケーションに標準を適用できるように十分な柔軟性を提供することでした。 H.264 規格は、多数の異なるプロファイルで構成される「規格ファミリー」と見なすことができますが、その「ハイ プロファイル」が圧倒的に最も一般的に使用されている形式です。特定のデコーダーは、少なくとも 1 つのプロファイルをデコードしますが、必ずしもすべてのプロファイルをデコードするわけではありません。この規格では、エンコードされたデータの形式とデータのデコード方法を説明していますが、ビデオをエンコードするためのアルゴリズムは指定していません。これはエンコーダー設計者が自分で選択する問題として残されており、さまざまなエンコード方式が開発されています。H.264 は通常、非可逆圧縮に使用されますが、非可逆コード化された画像内に完全に可逆コード化された領域を作成したり、エンコード全体が可逆であるまれなユース ケースをサポートしたりすること もできます。

H.264 は、研究グループ 16のITU-T ビデオ コーディング専門家グループ(VCEG)とISO/IEC JTC 1動画専門家グループ(MPEG) によって標準化されました。このプロジェクトのパートナーシップは、ジョイント ビデオ チーム (JVT) と呼ばれています。ITU-T H.264 規格と ISO/IEC MPEG-4  AVC 規格 (正式には ISO/IEC 14496-10 – MPEG-4 パート 10、高度なビデオ コーディング) は、同一の技術的内容を持つように共同で管理されています。この規格の最初のバージョンの最終的な起草作業は 2003 年 5 月に完了し、その後の版ではさまざまな機能拡張が追加されました。高効率ビデオ コーディング(HEVC)、別名 H.265 および MPEG-H パート 2 は、同じ組織によって開発された H.264/MPEG-4 AVC の後継ですが、以前の規格も現在でも広く使用されています。

H.264 は、おそらく、ブルーレイ ディスクで最も一般的に使用されているビデオ エンコーディング形式として最もよく知られています。また、 Netflix、Hulu、Amazon Prime Video、Vimeo、YouTube、iTunes Storeなどのビデオなどのインターネット ソースのストリーミング、Adobe Flash PlayerやMicrosoft Silverlightなどの Web ソフトウェア、地上波 ( ATSC、ISDB-T、DVB-TまたはDVB-T2 )、ケーブル ( DVB-C )、衛星 ( DVB-SおよびDVB-S2 ) システムを介したさまざまなHDTV放送でも広く使用されています。

H.264は、様々な団体が所有する特許によって制限されています。H.264に必須の特許のほとんど（すべてではない^{[要出典] ）をカバーするライセンスは、以前は}MPEG LAが管理していた特許プールによって管理されています。Via Licensing Corpは2023年4月にMPEG LAを買収し、 Via Licensing Allianceと呼ばれる新しい特許プール管理会社を設立しました。^[8] 特許取得済みのH.264技術を商用利用するには、Viaや他の特許所有者にロイヤリティを支払う必要があります。MPEG LAは、エンドユーザーが無料で利用できるインターネットビデオのストリーミングにH.264技術を自由に使用することを許可しており、シスコはオープンソースのH.264エンコーダopenH264のバイナリのユーザーに代わってMPEG LAにロイヤリティを支払いました。

H.264の名前はITU-T 命名規則に従っており、勧告にはシリーズに対応する文字とシリーズ内の勧告番号が与えられている。H.264は「Hシリーズ勧告：オーディオビジュアルおよびマルチメディアシステム」の一部である。H.264はさらに「H.200-H.499：オーディオビジュアルサービスのインフラストラクチャ」と「H.260-H.279：動画の符号化」に分類される。 ^[9] MPEG-4 AVCの名前はISO / IEC MPEGの命名規則に関連しており、この規格はMPEG-4として知られる規格スイートであるISO/IEC 14496のパート10である。この規格は、ITU-TでのH.26Lと呼ばれるVCEGプロジェクトとしての初期の開発作業の後、VCEGとMPEGのパートナーシップで共同で開発された。そのため、共通の遺産を強調するために、この標準規格を H.264/AVC、AVC/H.264、H.264/MPEG-4 AVC、または MPEG-4/H.264 AVC などの名前で参照するのが一般的です。時には、これを開発した Joint Video Team (JVT) 組織にちなんで、「JVT コーデック」と呼ばれることもあります。(このようなパートナーシップと複数の命名は珍しいことではありません。たとえば、MPEG-2 として知られるビデオ圧縮標準規格も、MPEGと ITU-T のパートナーシップから生まれました。MPEG-2 ビデオは、ITU-T コミュニティでは H.262 として知られています。^{[10] ) 一部のソフトウェア プログラム (} VLC メディア プレーヤーなど) は、内部的にこの標準規格を AVC1 として識別します。

1998 年初頭、ビデオ コーディング専門家グループ(VCEG – ITU-T SG16 Q.6) は、H.26L と呼ばれるプロジェクトの提案募集を開始しました。このプロジェクトの目標は、さまざまなアプリケーションで既存のビデオ コーディング標準と比較して、コーディング効率を 2 倍にする (つまり、特定の忠実度レベルに必要なビット レートを半分にする) ことでした。VCEGの議長は、 Gary Sullivan ( Microsoft、旧PictureTel 、米国)でした。この新しい標準の最初の設計草案は、1999 年 8 月に採用されました。2000 年には、Thomas Wiegand ( Heinrich Hertz Institute、ドイツ) が VCEG の共同議長に就任しました。

2001年12月、VCEGとMoving Picture Experts Group（MPEG  – ISO/IEC JTC 1/SC 29 /WG 11）は、ビデオコーディング規格を最終決定する憲章を掲げ、合同ビデオチーム（JVT）を結成した。^{[11]仕様の正式な承認は2003年3月に行われた。JVTの議長は、} Gary Sullivan、Thomas Wiegand、Ajay Luthra（Motorola、米国：後にArris 、米国）であった。2004年7月、Fidelity Range Extensions（FRExt）プロジェクトが完成した。2005年1月から2007年11月まで、JVTは、Scalable Video Coding（SVC）と呼ばれるAnnex（G）によるスケーラビリティに向けたH.264/AVCの拡張に取り組んでいた。JVT管理チームにJens-Rainer Ohm（RWTH Aachen University、ドイツ）が加わった。 2006 年 7 月から 2009 年 11 月まで、JVT は、 3D テレビおよび限定範囲の自由視点テレビに向けた H.264/AVC の拡張であるマルチビュー ビデオ コーディング(MVC) に取り組みました。その作業には、標準の 2 つの新しいプロファイル、マルチビュー ハイ プロファイルとステレオ ハイ プロファイルの開発が含まれていました。

標準の開発を通じて、補足拡張情報 (SEI) を格納するための追加のメッセージが開発されました。SEI メッセージには、ビデオ画像のタイミングを示すさまざまなタイプのデータ、コード化されたビデオのさまざまなプロパティ、またはその使用方法や拡張方法を記述するさまざまなタイプのデータを含めることができます。任意のユーザー定義データを含めることができる SEI メッセージも定義されています。SEI メッセージはコア デコード プロセスには影響しませんが、ビデオを後処理または表示する方法の推奨事項を示すことができます。ビデオ コンテンツのその他の高レベル プロパティは、ビデオ ユーザビリティ情報 (VUI) で伝えられます。たとえば、ビデオ コンテンツを解釈するための色空間の指示などです。高ダイナミック レンジや広色域ビデオなどの新しい色空間が開発されると、それらを示す追加の VUI 識別子が追加されました。

H.264/AVC の最初のバージョンの標準化は、2003 年 5 月に完了しました。元の標準を拡張する最初のプロジェクトで、JVT は Fidelity Range Extensions (FRExt) と呼ばれるものを開発しました。これらの拡張機能により、サンプル ビット深度の精度の向上と、Y′C _B C _R 4:2:2 (別名YUV 4:2:2 ) および 4:4:4 として知られるサンプリング構造を含む高解像度の色情報をサポートすることで、より高品質のビデオ コーディングが可能になりました。FRExt プロジェクトには、4×4 と 8×8 変換間の適応切り替えを備えた 8×8 整数離散コサイン変換(整数 DCT) の追加、エンコーダー指定の知覚ベースの量子化重み付けマトリックス、効率的なインター ピクチャ ロスレス コーディング、追加の色空間のサポートなど、他のいくつかの機能も含まれていました。 FRExt プロジェクトの設計作業は 2004 年 7 月に完了し、その製図作業は 2004 年 9 月に完了しました。

その後、主にプロフェッショナル アプリケーション向けの 5 つの新しいプロファイル (以下のバージョン 7 を参照) が開発され、拡張色域カラー スペースのサポートが追加され、追加のアスペクト比インジケーターが定義され、2 つの追加の「補足拡張情報」(ポスト フィルター ヒントとトーン マッピング) が定義され、業界のフィードバック^{[誰が? ]}で別の設計にすべきであると示された以前の FRExt プロファイルの 1 つ (High 4:4:4 プロファイル) が廃止されました。

標準に追加された次の主要な機能は、スケーラブル ビデオ コーディング (SVC) です。H.264/AVC の Annex G で指定されている SVC を使用すると、標準に準拠するサブビットストリームのレイヤーを含むビットストリームを構築できます。これには、SVC をサポートしない H.264/AVCコーデックでデコードできる「ベース レイヤー」と呼ばれるビットストリームが含まれます。時間的なビットストリームのスケーラビリティ (つまり、メイン ビットストリームよりも時間的なサンプリング レートが低いサブビットストリームの存在) の場合、サブビットストリームを派生するときに、ビットストリームから完全なアクセス ユニットが削除されます。この場合、ビットストリーム内の高レベル構文とインター予測参照画像はそれに応じて構築されます。一方、空間的および品質的なビットストリームのスケーラビリティ (つまり、メイン ビットストリームよりも空間解像度/品質が低いサブビットストリームの存在) の場合、サブビットストリームを派生するときに、ビットストリームからNAL (ネットワーク抽象化レイヤー) が削除されます。この場合、効率的なコーディングのために、通常、レイヤー間予測 (つまり、空間解像度/品質の低い信号のデータから空間解像度/品質の高い信号を予測すること) が使用されます。スケーラブル ビデオ コーディングの拡張は、2007 年 11 月に完了しました。

標準に追加された次の主要機能は、マルチビュー ビデオ コーディング(MVC) です。H.264/AVC の Annex H で指定されている MVC を使用すると、ビデオ シーンの複数のビューを表すビットストリームを構築できます。この機能の重要な例として、立体 3Dビデオ コーディングがあります。MVC 作業では 2 つのプロファイルが開発されました。マルチビュー ハイ プロファイルは任意の数のビューをサポートし、ステレオ ハイ プロファイルは 2 ビュー立体ビデオ専用に設計されています。マルチビュー ビデオ コーディングの拡張は 2009 年 11 月に完了しました。

その後、深度マップとテクスチャの共同コーディングによる 3D ビデオ コーディング(3D-AVC と呼ばれる)、マルチ解像度フレーム互換 (MFC) 立体視および 3D-MFC コーディング、さまざまな追加機能の組み合わせ、およびより高いフレーム サイズとフレーム レートを含む追加の拡張機能が開発されました。

H.264/AVC 規格のバージョンには、次の完了した改訂、訂正、および修正が含まれています (日付は ITU-T での最終承認日ですが、ISO/IEC での最終的な「国際規格」承認日は多少異なり、ほとんどの場合、わずかに後になります)。各バージョンは、テキストに統合されている次の下位バージョンに対する変更を表します。

• バージョン1（第1版）:（2003年5月30日）ベースライン、メイン、拡張プロファイルを含むH.264/AVCの最初の承認バージョン。^[12]
• バージョン2（第1.1版）：（2004年5月7日）様々な小さな修正を含む訂正。^[13]
• バージョン3（第2版）：（2005年3月1日）最初の修正を含む主要な追加で、忠実度範囲拡張（FRExt）を確立しました。このバージョンでは、High、High 10、High 4:2:2、およびHigh 4:4:4プロファイルが追加されました。^[14]数年後、Highプロファイルがこの規格で最も一般的に使用されるプロファイルになりました。
• バージョン4（エディション2.1）：（2005年9月13日）訂正には、さまざまな小さな修正と3つのアスペクト比インジケーターの追加が含まれています。^[15]
• バージョン5（エディション2.2）：（2006年6月13日）以前のHigh 4:4:4プロファイルの削除を含む修正（ISO/IECで訂正として処理）。^[16]
• バージョン6（エディション2.2）:（2006年6月13日）拡張色域色空間サポートなどのマイナーな拡張を含む修正（ISO/IECの上記のアスペクト比インジケータにバンドルされています）。^[16]
• バージョン7（エディション2.3）：（2007年4月6日）High 4:4:4予測プロファイルと4つのIntraのみのプロファイル（High 10 Intra、High 4:2:2 Intra、High 4:4:4 Intra、CAVLC 4:4:4 Intra）の追加を含む修正。^[17]
• バージョン8（第3版）:（2007年11月22日）スケーラブルベースライン、スケーラブルハイ、スケーラブルハイイントラプロファイルを含むスケーラブルビデオコーディング（SVC）の修正を含むH.264/AVCへの主要な追加。^[18]
• バージョン9（第3.1版）：（2009年1月13日）軽微な修正を含む訂正。^[19]
• バージョン10（第4版）:（2009年3月16日）以前に指定されたさまざまなプロファイルでサポートされている機能の共通サブセットのみを含む新しいプロファイル（制約付きベースラインプロファイル）の定義を含む修正。^[20]
• バージョン11（第4版）:（2009年3月16日）H.264/AVCへの主要な追加。マルチビューハイプロファイルを含むマルチビュービデオコーディング（MVC）拡張の修正が含まれています。 ^[20]
• バージョン12（第5版）:（2010年3月9日）インターレースコーディングツールをサポートする2ビュービデオコーディング用の新しいMVCプロファイル（ステレオハイプロファイル）の定義と、フレームパッキングアレンジメントSEIメッセージと呼ばれる追加の補足拡張情報（SEI）メッセージの指定を含む修正。^[21]
• バージョン13（第5版）：（2010年3月9日）軽微な修正を含む訂正。^[21]
• バージョン14（第6版）:（2011年6月29日）1秒あたりの最大マクロブロック数に関してより高い処理速度をサポートする新しいレベル（レベル5.2）と、以前に指定されたハイプロファイルのフレームコーディングツールのみをサポートする新しいプロファイル（プログレッシブハイプロファイル）を規定する修正。^[22]
• バージョン15（第6版）：（2011年6月29日）軽微な修正を含む訂正。^[22]
• バージョン16（第7版）：（2012年1月13日）リアルタイム通信アプリケーションを主な対象とした3つの新しいプロファイル（制約付き高、スケーラブル制約付きベースライン、スケーラブル制約付き高）の定義を含む修正。^[23]
• バージョン17（第8版）：（2013年4月13日）SEIメッセージインジケータを追加した修正。^[24]
• バージョン18（第8版）：（2013年4月13日）マルチビューデプスハイプロファイルを含む3D立体視ビデオのデプスマップデータのコーディングを指定するための修正。^[24]
• バージョン19（第8版）：（2013年4月13日）マルチビュービデオのサブビットストリーム抽出プロセスにおけるエラーを修正するための訂正。^[24]
• バージョン20（第8版）：（2013年4月13日）トーンマッピング情報SEIメッセージに追加の色空間識別子（UHDTVのITU-R勧告BT.2020のサポートを含む）と追加モデルタイプを指定するための修正。 ^[24]
• バージョン21（第9版）：（2014年2月13日）Enhanced Multiview Depth Highプロファイルを指定するための修正。^[25]
• バージョン22（第9版）：（2014年2月13日）3D立体視ビデオのマルチ解像度フレーム互換（MFC）拡張機能、MFCハイプロファイル、およびマイナーな修正を指定するための修正。^[25]
• バージョン23（エディション10）：（2016年2月13日）深度マップ付きMFC立体視ビデオ、MFC Depth Highプロファイル、マスタリングディスプレイカラーボリュームSEIメッセージ、および追加の色関連VUIコードポイント識別子を指定するための修正。^[26]
• バージョン24（第11版）:（2016年10月14日）より大きな画像サイズ（レベル6、6.1、および6.2）、緑のメタデータSEIメッセージ、代替深度情報SEIメッセージ、および追加の色関連VUIコードポイント識別子をサポートするデコーダー機能の追加レベルを指定するための修正。^[27]
• バージョン25（第12版）：（2017年4月13日）プログレッシブハイ10プロファイル、ハイブリッドログガンマ（HLG）、および追加の色関連のVUIコードポイントとSEIメッセージを指定するための修正。^[28]
• バージョン26（エディション13）：（2019年6月13日）周囲の視聴環境、コンテンツの光レベル情報、コンテンツの色ボリューム、正距円筒図法、キューブマップ投影、球面回転、領域ごとのパッキング、全方向ビューポート、SEIマニフェスト、およびSEIプレフィックスに関する追加のSEIメッセージを指定するための修正。^[29]
• バージョン27（第14版）：（2021年8月22日）注釈付き領域とシャッター間隔情報に関する追加のSEIメッセージを指定するための修正、およびその他の軽微な修正と明確化。^[30]

以下の組織は、MPEG LA のH.264/AVC特許プールで 1 つ以上の特許を保有しています。

H.264 ビデオ形式は、低ビットレートのインターネット ストリーミング アプリケーションから HDTV 放送、デジタル シネマ アプリケーションまで、ほぼロスレス コーディングによるあらゆる形式のデジタル圧縮ビデオをカバーする、非常に幅広いアプリケーション範囲を備えています。H.264 を使用すると、MPEG-2 Part 2と比較して 50% 以上のビットレート節約が報告されています。たとえば、H.264 は、現在の MPEG-2 実装と同じデジタル衛星テレビ品質を半分以下のビットレートで実現すると報告されています。現在の MPEG-2 実装は約 3.5 Mbit/s で動作していますが、H.264 はわずか 1.5 Mbit/s です。^{[33]ソニーは、9 Mbit/s の AVC 録画モードは、約 18～25 Mbit/s を使用する}HDV形式の画質と同等であると主張しています。^[34]

H.264/AVC の互換性と問題なく採用できるように、多くの標準化団体がビデオ関連の標準を修正または追加し、これらの標準のユーザーが H.264/AVC を利用できるようにしています。Blu -ray ディスク形式と、現在は廃止されているHD DVD形式の両方に、3 つの必須ビデオ圧縮形式の 1 つとして H.264/AVC ハイ プロファイルが含まれています。デジタル ビデオ ブロードキャスト プロジェクト ( DVB ) は、2004 年後半にテレビ放送での H.264/AVC の使用を承認しました。

米国の標準化団体ATSC（Advanced Television Systems Committee）は、2008年7月にH.264/AVCのテレビ放送での使用を承認したが、この規格は米国内の固定ATSC放送にはまだ使用されていない。[ 35 ^{] [36]また、H.264のAVCとSVC部分を使用して、より最近の}ATSC-M/H （モバイル/ハンドヘルド）規格での使用も承認されている。^[37]

閉回路テレビやビデオ監視市場では、多くの製品にこの技術が取り入れられています。

多くの一般的なDSLR では、ネイティブ録画形式として、QuickTime MOV コンテナにラップされた H.264 ビデオが使用されます。

AVCHD は、ソニーとパナソニックが設計した、H.264 を使用する高解像度録画形式です(H.264 に準拠しながら、アプリケーション固有の機能と制約が追加されています)。

AVC-Intra は、パナソニックが開発したイントラフレームのみの圧縮形式です。

XAVCはソニーが設計した録画フォーマットで、H.264/MPEG-4 AVCのレベル5.2を採用しており、このビデオ規格でサポートされている最高レベルである。 [ ^{38 ] [39]} XAVCは、最大60 フレーム/秒（fps）で4K解像度（4096 × 2160および3840 × 2160）をサポートできる。 [38] ^[39]ソニーは、XAVCをサポートするカメラには、2台のCineAltaカメラ、ソニーPMW-F55とソニーPMW-F5が含まれると発表している。^[40]ソニーPMW-F55は、4K解像度30fps、300Mbit /s、2K解像度30fps、100Mbit/sでXAVCを録画できる。^[41] XAVCは、4K解像度を60fps、4:2:2クロマサンプリング、600Mbit/sで録画できる。^{[42] [43]}

H.264/AVC/MPEG-4 Part 10 には、従来の標準よりもはるかに効率的にビデオを圧縮し、さまざまなネットワーク環境への適用に柔軟性を提供できる新しい機能が多数含まれています。特に、次のような重要な機能があります。

• 以下の機能を含む マルチピクチャーインターピクチャー予測:
  • 以前の標準よりもはるかに柔軟な方法で、以前にエンコードされた画像を参照として使用し、場合によっては最大 16 個の参照フレーム (インターレース エンコードの場合は 32 個の参照フィールド) を使用できるようにします。非IDRフレームをサポートするプロファイルでは、ほとんどのレベルで、最大解像度で少なくとも 4 個または 5 個の参照フレームを使用できるように十分なバッファリングが利用可能であることが指定されています。これは、制限が通常 1 個、または従来の「 B 画像」(B フレーム)の場合は2 個であった以前の標準とは対照的です。
  • ブロック サイズが最大 16×16、最小 4×4 の可変ブロック サイズモーション補償(VBSMC) により、動きのある領域を正確に分割できます。サポートされている輝度予測ブロック サイズには、16×16、16×8、8×16、8×8、8×4、4×8、4×4 があり、その多くは 1 つのマクロ ブロックで一緒に使用できます。彩度サブサンプリングを使用すると、彩度予測ブロック サイズもそれに応じて小さくなります。
  • マクロブロックごとに複数のモーション ベクトル (パーティションごとに 1 つまたは 2 つ) を使用する機能。16 個の 4×4 パーティションで構成された B マクロブロックの場合は、最大 32 個まで使用できます。8×8 以上のパーティション領域ごとのモーション ベクトルは、異なる参照画像を指すことができます。
  • I マクロブロックを含む、 B フレーム内の任意のマクロブロック タイプを使用できるようになり、B フレームを使用する際のエンコードの効率が大幅に向上します。この機能は、MPEG-4 ASPから省略されました。
  • よりシャープなサブピクセルの動き補正のために、ハーフピクセルの輝度サンプル予測を導出するための 6 タップ フィルタリング。クォーターピクセルの動きはハーフピクセル値の線形補間によって導出され、処理能力を節約します。
  • 動き補正の1/4 ピクセル精度により、動く領域の変位を正確に記述できます。 クロマの場合、解像度は通常、垂直方向と水平方向の両方で半分になります ( 4:2:0を参照)。そのため、クロマの動き補正では、1/8 クロマ ピクセル グリッド単位が使用されます。
  • 加重予測により、エンコーダーはモーション補正を実行するときにスケーリングとオフセットの使用を指定でき、フェード ツー ブラック、フェードイン、クロスフェード遷移などの特殊なケースでパフォーマンスが大幅に向上します。これには、B フレームの暗黙的な加重予測と、P フレームの明示的な加重予測が含まれます。
• MPEG-2 パート 2 の「DC」のみの予測や、H.263v2 および MPEG-4 パート 2 の変換係数予測ではなく、隣接するブロックのエッジからの空間予測による「イントラ」コーディング。これには、16×16、8×8、および 4×4 の輝度予測ブロック サイズが含まれます (各マクロブロック内では 1 つのタイプのみを使用できます)。
• 整数離散コサイン変換（整数DCT）^{[6] [44] [45]}は離散コサイン変換（DCT）の一種^[44]で、変換は標準DCTの整数近似です。^[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ベースの画像圧縮技術に共通するブロッキングアーティファクトを防ぐのに役立つループ内デブロッキングフィルタにより、視覚的な外観と圧縮効率が向上します。
• 以下を含むエントロピー符号化設計:
  • コンテキスト適応型バイナリ算術符号化(CABAC) は、特定のコンテキストにおける構文要素の確率を認識しながら、ビデオ ストリーム内の構文要素をロスレスで圧縮するアルゴリズムです。CABAC は CAVLC よりも効率的にデータを圧縮しますが、デコードにはかなりの処理が必要です。
  • コンテキスト適応型可変長符号化(CAVLC) は、量子化された変換係数値の符号化における CABAC よりも複雑度の低い代替手段です。CABAC よりも複雑度は低いものの、CAVLC は、他の従来の設計で係数を符号化するために通常使用される方法よりも複雑で効率的です。
  • CABAC または CAVLC でコード化されない多くの構文要素に対する一般的なシンプルで高度に構造化された可変長コード化(VLC) 手法。指数ゴロムコード化(または Exp-Golomb) と呼ばれます。
• 損失耐性機能には以下が含まれます:
  • ネットワーク抽象化レイヤー( NAL) の定義により、多くのネットワーク環境で同じビデオ構文を使用できるようになります。H.264 の非常に基本的な設計概念の 1 つは、MPEG-4 のヘッダー拡張コード (HEC) のようにヘッダーの重複を排除し、自己完結型のパケットを生成することです。^[48]これは、メディア ストリームから複数のスライスに関連する情報を分離することで実現しました。上位レベルのパラメーターの組み合わせは、パラメーター セットと呼ばれます。^[48] H.264 仕様には、シーケンス パラメーター セット (SPS) とピクチャ パラメーター セット (PPS) の 2 種類のパラメーター セットが含まれています。アクティブなシーケンス パラメーター セットは、コード化されたビデオ シーケンス全体で変更されず、アクティブなピクチャ パラメーター セットは、コード化されたピクチャ内で変更されません。シーケンス パラメーター セットとピクチャ パラメーター セットの構造には、画像サイズ、オプションで採用されているコーディング モード、マクロブロックからスライス グループへのマップなどの情報が含まれます。^[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 ビットの範囲でサポートされます (選択したプロファイルによって異なります)。
• 個々のカラープレーンを、独自のスライス構造、マクロブロック モード、モーション ベクトルなどを持つ個別の画像としてエンコードする機能。これにより、エンコーダーを単純な並列化構造で設計できるようになります (3 つの 4:4:4 対応プロファイルでのみサポートされます)。
• 画像順序カウントは、画像の順序とデコードされた画像内のサンプルの値をタイミング情報から分離して保持する機能であり、デコードされた画像の内容に影響を与えることなく、タイミング情報をシステムによって個別に伝送および制御/変更できるようにします。

これらの技術と他のいくつかの技術により、H.264は、さまざまな状況やさまざまなアプリケーション環境において、これまでの標準よりもはるかに優れたパフォーマンスを発揮します。H.264は、多くの場合、MPEG-2ビデオよりも大幅に優れたパフォーマンスを発揮します。特に、高ビットレートおよび高解像度のビデオコンテンツでは、通常、半分のビットレート以下で同じ品質が得られます。^[49]

他の ISO/IEC MPEG ビデオ規格と同様に、H.264/AVC には、自由にダウンロードできるリファレンス ソフトウェア実装があります。^{[50]その主な目的は、}それ自体が有用なアプリケーションであるというよりも、H.264/AVC の機能の例を示すことです。Moving Picture Experts Groupでは、いくつかのリファレンス ハードウェア設計作業も行われています。上記の側面には、H.264 のすべてのプロファイルの機能が含まれます。コーデックのプロファイルは、対象アプリケーションの特定の仕様セットを満たすように識別されたコーデックの機能セットです。つまり、リストされている機能の多くは、一部のプロファイルではサポートされていません。H.264/AVC のさまざまなプロファイルについては、次のセクションで説明します。

この規格では、特定のクラスのアプリケーションを対象とした、プロファイルと呼ばれる機能セットがいくつか定義されています。これらはプロファイル コード (profile_idc) を使用して宣言され、場合によってはエンコーダーに適用される追加の制約セットも使用されます。プロファイル コードと指定された制約により、デコーダーは特定のビットストリームをデコードするための要件を認識できます。(多くのシステム環境では、1 つまたは 2 つのプロファイルしか使用できないため、これらの環境のデコーダーは、あまり一般的に使用されないプロファイルを認識する必要はありません。) これまでのところ、最も一般的に使用されるプロファイルは High Profile です。

スケーラブルでない 2D ビデオ アプリケーションのプロファイルには、次のものがあります。

制約ベースライン プロファイル (CBP、制約セット 1 を含む 66)

このプロファイルは主に低コストのアプリケーション向けで、ビデオ会議やモバイル アプリケーションで最もよく使用されます。これは、ベースライン プロファイル、メイン プロファイル、およびハイ プロファイルに共通する機能のサブセットに対応します。

ベースラインプロファイル（BP、66）

このプロファイルは、主に、追加のデータ損失堅牢性を必要とする低コストのアプリケーション向けに、一部のビデオ会議およびモバイル アプリケーションで使用されます。このプロファイルには、制約付きベースライン プロファイルでサポートされているすべての機能に加えて、損失堅牢性 (または低遅延マルチポイント ビデオ ストリーム合成などの他の目的) に使用できる 3 つの追加機能が含まれています。このプロファイルの重要性は、2009 年の制約付きベースライン プロファイルの定義以来、やや薄れています。制約付きベースライン プロファイルのすべてのビットストリームは、ベースライン プロファイル ビットストリームであると見なされます。これは、これら 2 つのプロファイルが同じプロファイル識別子コード値を共有しているためです。

拡張プロファイル (XP、88)

ストリーミング ビデオ プロファイルとして意図されたこのプロファイルは、比較的高い圧縮機能と、データ損失やサーバー ストリームの切り替えに対する堅牢性を高めるための追加のトリックを備えています。

メインプロフィール（MP、77）

このプロファイルは、DVB規格で定義されているMPEG-4形式を使用する標準解像度のデジタルテレビ放送に使用されます。^[51]ただし、2004年にハイプロファイルがその用途向けに開発されたため、このプロファイルの重要性は薄れたため、高解像度のテレビ放送には使用されていません。

ハイプロファイル（HiP、100）

放送およびディスク ストレージ アプリケーション、特に高精細テレビ アプリケーション向けの主要なプロファイルです (たとえば、これはBlu-ray ディスクストレージ形式およびDVB HDTV 放送サービスで採用されているプロファイルです)。

プログレッシブ ハイ プロファイル (PHiP、制約セット 4 の 100)

High プロファイルに似ていますが、フィールド コーディング機能はサポートされていません。

制約付きハイプロファイル（制約セット 4 および 5 を含む 100）

Progressive High プロファイルに似ていますが、B (双方向予測) スライスはサポートされていません。

ハイ10プロファイル（Hi10P、110）

このプロファイルは、一般的な主流の消費者向け製品の機能を超えて、ハイ プロファイルの上に構築され、デコードされた画像の精度のサンプルあたり最大 10 ビットのサポートを追加します。

ハイ4:2:2プロファイル（Hi422P、122）

このプロファイルは、主にインターレース ビデオを使用するプロフェッショナル アプリケーションを対象としており、High 10 プロファイルの上に構築され、デコードされた画像の精度のサンプルあたり最大 10 ビットを使用しながら、4:2:2クロマ サンプリング形式のサポートを追加します。

ハイ 4:4:4 予測プロファイル (Hi444PP、244)

このプロファイルは、High 4:2:2 プロファイルの上に構築され、最大 4:4:4 クロマ サンプリング、サンプルあたり最大 14 ビットをサポートし、さらに効率的なロスレス領域コーディングと、各画像を 3 つの個別のカラー プレーンとしてコーディングすることをサポートします。

カムコーダ、編集、およびプロフェッショナル アプリケーション向けに、この規格には、他の対応するプロファイルの単純なサブセットとして定義された 4 つの追加のフレーム内プロファイルが含まれています。これらは主にプロフェッショナル アプリケーション (カメラや編集システムなど) 向けです。

高 10 イントラプロファイル (制約セット 3 で 110)

High 10 プロファイルは、すべて Intra の使用に制限されています。

高 4:2:2 イントラプロファイル (制約セット 3 で 122)

すべて Intra の使用に制限された High 4:2:2 プロファイル。

ハイ 4:4:4 イントラ プロファイル (制約セット 3 で 244)

すべて Intra の使用に制限された High 4:4:4 プロファイル。

CAVLC 4:4:4 イントラプロファイル (44)

High 4:4:4 プロファイルは、すべて Intra の使用と CAVLC エントロピー コーディングに制限されています (つまり、CABAC はサポートされていません)。

スケーラブル ビデオ コーディング (SVC) 拡張の結果として、標準には 5 つの追加のスケーラブル プロファイルが含まれます。これらは、ベース レイヤーの H.264/AVC プロファイル (スケーラブル プロファイル名の 2 番目の単語で識別されます) と、スケーラブル拡張を実現するツールの組み合わせとして定義されます。

スケーラブルベースラインプロファイル (83)

このプロファイルは主にビデオ会議、モバイル、監視アプリケーションを対象としており、ベース レイヤー (ビットストリームのサブセット) が準拠する必要がある制約付きベースライン プロファイルの上に構築されています。スケーラビリティ ツールの場合、使用可能なツールのサブセットが有効になっています。

スケーラブルな制約ベースライン プロファイル (制約セット 5 を含む 83)

主にリアルタイム通信アプリケーションを対象としたスケーラブル ベースライン プロファイルのサブセット。

スケーラブルなハイプロファイル (86)

このプロファイルは、主にブロードキャストおよびストリーミング アプリケーションを対象としており、ベース レイヤーが準拠する必要がある H.264/AVC ハイ プロファイルの上に構築されています。

スケーラブルな制約付きハイプロファイル (制約セット 5 の 86)

主にリアルタイム通信アプリケーション向けのスケーラブル ハイ プロファイルのサブセットです。

スケーラブル ハイ イントラ プロファイル (制約セット 3 で 86)

このプロファイルは主に実稼働アプリケーションを対象としており、すべて Intra での使用に制限された Scalable High Profile です。

マルチビュー ビデオ コーディング(MVC) 拡張の結果として、標準には 2 つのマルチビュー プロファイルが含まれています。

ステレオハイプロファイル (128)

このプロファイルは、2 ビュー立体3D ビデオを対象とし、High プロファイルのツールと MVC 拡張のビュー間予測機能を組み合わせます。

マルチビューハイプロファイル（118）

このプロファイルは、インターピクチャ（時間的）と MVC インタービュー予測の両方を使用して 2 つ以上のビューをサポートしますが、フィールドピクチャとマクロブロック適応型フレームフィールドコーディングはサポートしません。

マルチ解像度フレーム互換 (MFC) 拡張機能により、さらに 2 つのプロファイルが追加されました。

MFCハイプロファイル（134）

2 層の解像度強化による立体符号化用のプロファイル。

MFC デプス ハイプロファイル (135)

3D-AVC 拡張機能により、さらに 2 つのプロファイルが追加されました。

マルチビュー デプス ハイ プロファイル (138)

このプロファイルは、深度マップとビデオ テクスチャ情報の共同コーディングをサポートし、3D ビデオ コンテンツの圧縮を改善します。

強化されたマルチビュー深度ハイプロファイル (139)

深度情報と組み合わせたマルチビュー コーディング用の拡張プロファイル。

標準で使用されている用語「レベル」は、プロファイルに必要なデコーダー パフォーマンスの程度を示す、指定された一連の制約です。たとえば、プロファイル内のサポート レベルは、デコーダーが使用できる最大の画像解像度、フレーム レート、およびビット レートを指定します。特定のレベルに準拠するデコーダーは、そのレベルおよびそれより低いすべてのレベルでエンコードされたすべてのビットストリームをデコードできる必要があります。

ハイ プロファイルの最大ビット レートは、制約付きベースライン プロファイル、ベースライン プロファイル、拡張プロファイル、メイン プロファイルの 1.25 倍、Hi10P の場合は 3 倍、Hi422P/Hi444PP の場合は 4 倍です。

輝度サンプルの数は、マクロブロックの数の 16×16 = 256 倍です (1 秒あたりの輝度サンプルの数は、1 秒あたりのマクロブロックの数の 256 倍です)。

H.264/AVC エンコーダーは、以前にエンコードされた画像を使用して、他の画像のサンプルの値を予測します。これにより、エンコーダーは特定の画像をエンコードする最適な方法を効率的に決定できます。デコーダーでは、このような画像は仮想デコード画像バッファー(DPB) に保存されます。上記の表の右側の列の括弧内に示されているように、フレーム単位 (またはフィールドのペア) での DPB の最大容量は、次のように計算できます。

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

ここで、MaxDpbMbsはレベル番号の関数として以下の表に示される定数値であり、PicWidthInMbsとFrameHeightInMbsは符号化されたビデオデータの画像の幅とフレームの高さであり、マクロブロック単位で表されます（整数値に切り上げられ、該当する場合はクロッピングとマクロブロックのペアリングが考慮されています）。この式は、2017年版の標準のセクションA.3.1.hとA.3.2.fで指定されています。^[28]

例えば、1,920サンプル幅のHDTV画像（画像幅（MBS） = 120）および1,080サンプル高（フレーム高さ（Mbs） = 68）、レベル4デコーダーの最大DPBストレージ容量は床(32768/(120*68))= 4 フレーム (または 8 フィールド)。したがって、上の表では、フレーム サイズが 1920×1080 のレベル 4 の行の右側の列に、値 4 が括弧で表示されます。

デコード中の現在の画像は、 DPB の占有量の計算には含まれません(エンコーダーが他の画像のデコードや遅延出力タイミングの参照用に保存するように指示しない限り)。したがって、デコーダーは、上記で計算した DPB の最大容量より (少なくとも) 1 フレーム多く処理するのに十分なメモリを実際に持っている必要があります。

2009年、HTML5ワーキンググループは、特許に縛られないと考えられているフリーのビデオフォーマットであるOgg Theoraの支持者と、特許技術を含むH.264の支持者に分かれた。2009年7月になっても、GoogleとAppleはH.264をサポートし、MozillaとOperaはOgg Theoraをサポートしていると言われていた（現在、Google、Mozilla、OperaはいずれもVP8を使用したTheoraとWebMをサポートしている）。^[52] Microsoftは、Internet Explorer 9のリリースで、H.264を使用してエンコードされたHTML 5ビデオのサポートを追加した。2010年11月のGartner Symposium/ITXpoで、Microsoft CEOのスティーブ・バルマーは「HTML 5かSilverlightか？」という質問に対して、「普遍的なものをやりたいのであれば、世界がHTML5に向かうのは間違いない」と答えた。^[53] 2011年1月、GoogleはChromeブラウザからH.26​​4のサポートを撤回し、TheoraとWebM / VP8の両方をサポートしてオープンフォーマットのみを使用すると発表した。^[54]

2012年3月18日、Mozillaは、H.264でエンコードされたビデオの普及と、そのようなデバイスで一般的な専用のH.264デコーダハードウェアを使用することで電力効率が向上することから、モバイルデバイス上のFirefoxでH.264をサポートすることを発表しました。 ^[55] 2013年2月20日、MozillaはWindows 7以降でH.264をデコードするためのFirefoxのサポートを実装しました。この機能は、Windowsに組み込まれているデコードライブラリに依存しています。^[56] 2015年1月13日にリリースされたFirefox 35.0は、OS X 10.6以降でH.264をサポートしています。^[57]

2013年10月30日、シスコシステムズのRowan Trollopeは、シスコがOpenH264と呼ばれるH.264ビデオコーデックのバイナリとソースコードの両方をSimplified BSDライセンスの下で公開し、シスコのプリコンパイル済みバイナリを使用するソフトウェアプロジェクトに対してその使用料をMPEG LAに支払うことで、シスコのOpenH264バイナリを無料で使用することを発表した。ただし、シスコのバイナリではなくソースコードを使用するソフトウェアプロジェクトは、MPEG LAにすべての使用料を支払う法的責任を負うことになる。対象となるCPUアーキテクチャにはx86とARMが含まれ、対象となるオペレーティングシステムにはLinux、Windows XP以降、Mac OS X、Androidが含まれる。iOSはこのリストに含まれていない。これは、アプリケーションがインターネットからバイナリモジュールを取得してインストールすることを許可していないためである。^{[58] [59] [60]}また、2013年10月30日、MozillaのBrendan Eichは、プラットフォームコーデックが利用できないFirefoxにH.264のサポートを追加するために、将来のバージョンのFirefoxでCiscoのバイナリを使用すると書いています。^[61] Ciscoは2013年12月9日にOpenH264のソースコードを公開しました。^[62]

iOSは2013年のシスコソフトウェアリリースではサポートされていませんでしたが、AppleはiOS 8（2014年9月リリース）でビデオツールボックスフレームワークを更新し、ハードウェアベースのH.264/AVCビデオエンコーディングとデコーディングに直接アクセスできるようにしました。^[59]

H.264 エンコードおよびデコードでは、特定の種類の算術演算でかなりの計算能力が必要になるため、汎用 CPU で実行されるソフトウェア実装は通常、電力効率が低くなります。ただし、最新の^{[いつ? ]}クアッドコア汎用 x86 CPU には、リアルタイムの SD および HD エンコードを実行するのに十分な計算能力があります。圧縮効率は、ビデオ アルゴリズムの実装によって決まり、ハードウェア実装とソフトウェア実装のどちらが使用されているかには関係ありません。したがって、ハードウェア ベースの実装とソフトウェア ベースの実装の違いは、電力効率、柔軟性、およびコストにあります。電力効率を改善し、ハードウェア フォーム ファクタを削減するために、完全なエンコードまたはデコード プロセス用、または CPU 制御環境内での加速支援用に、専用ハードウェアが使用される場合があります。

CPU ベースのソリューションは、特に複数の形式、複数のビット レートと解像度 (マルチ スクリーン ビデオ) でエンコードを同時に実行する必要がある場合、またコンテナー形式のサポート、高度な統合広告機能などの追加機能が必要な場合に、はるかに柔軟であることが知られています。CPU ベースのソフトウェア ソリューションを使用すると、通常、同じ CPU 内で複数の同時エンコード セッションの負荷分散がはるかに簡単になります。

2011年1月のCES（コンシューマーエレクトロニクスショー）で発表された第2世代Intel「Sandy Bridge」Core i3/i5/i7プロセッサは、 Intel Quick Sync Videoとして知られるオンチップハードウェアフルHD H.264エンコーダを搭載しています。^{[68] [69]}

ハードウェア H.264 エンコーダーは、ASICまたはFPGAになります。

H.264エンコーダ機能を備えたASICエンコーダは多くの異なる半導体企業から提供されていますが、ASICで使用されるコア設計は通常、Chips&Media、Allegro DVT、On2（旧Hantro、Googleが買収）、Imagination Technologies、NGCodecなどの数社からライセンス供与されています。FPGAとASICの両方の製品を提供している企業もあります。^[70]

テキサス・インスツルメンツは、DSP H.264 BPエンコード1080pを30fpsで実行するARM + DSPコアのラインを製造しています。^[71]これにより、コーデック（高度に最適化されたDSPコードとして実装）に関する柔軟性が得られ、汎用CPU上のソフトウェアよりも効率的になります。

ソフトウェアアルゴリズムの特許が認められている国では、H.264/AVCを使用する製品のベンダーと商用ユーザーは、自社製品が使用する特許技術に対して特許ライセンス料を支払うことが求められています。^[72]これはベースラインプロファイルにも当てはまります。^[73]

MPEG LAと呼ばれる民間組織は、MPEG標準化団体とは一切関係がなく、この規格に適用される特許のライセンスのほか、MPEG-4 Part 2 Video、HEVC、MPEG-DASHなどの他の特許プールも管理している。特許保有者には、富士通、パナソニック、ソニー、三菱、アップル、コロンビア大学、KAIST、ドルビー、グーグル、JVCケンウッド、LGエレクトロニクス、マイクロソフト、NTTドコモ、フィリップス、サムスン、シャープ、東芝、ZTEなどが含まれるが^[74]、特許プール内の特許の大部分はパナソニック（1,197件）、合同会社IPブリッジ（1,130件）、LGエレクトロニクス（990件）が保有している。^[75]

2010年8月26日、MPEG LAは、エンドユーザーに無料で提供されるH.264でエンコードされたインターネットビデオには使用料を課さないと発表した。^[76] H.264ビデオをデコードおよびエンコードする製品や、無料テレビや有料チャンネルの運営者に対する使用料など、その他の使用料はすべてそのまま適用される。^[77]ライセンス条件は5年ごとに更新される。^[78]

規格の最初のバージョンは2003年5月に完成して以来（21年前）最も一般的に使用されているプロファイル（ハイプロファイル）は2004年6月に完成しました^{[引用が必要]}（20年前に米国で特許が発行されたが、現在では関連する特許の一部は期限切れとなっている^[75 ]。一方、他の特許は世界中の法域でまだ有効であり、MPEG LA H.264プールの米国特許の1つ（2016年に付与、2001年からの優先権）は少なくとも2030年11月まで有効である^{[79] 。}

2005年、クアルコムはブロードコムを米国地方裁判所に提訴し、ブロードコムがH.264ビデオ圧縮規格に準拠した製品を製造することで自社の特許2件を侵害したと主張した。^[80] 2007年、地方裁判所は、クアルコムが2003年5月のH.264規格の発表前にJVTに特許を開示していなかったため、特許は執行不能であるとの判決を下した。^[80] 2008年12月、米国連邦巡回控訴裁判所は、特許を執行不能とする地方裁判所の命令を支持したが、執行不能の範囲をH.264準拠製品に限定するよう指示して地方裁判所に差し戻した。^[80]

2023年10月、ノキアは米国、英国およびその他の地域でHPとアマゾンをH.264/H.265の特許侵害で訴えた。 ^[81]

• VC-1は、 Microsoftによって設計され、2006 年に SMPTE標準として承認された標準です。
  • H.264とVC-1の比較
• Dirac (ビデオ圧縮形式) は、 BBC Research & Developmentが2008 年にリリースしたビデオ コーディング設計です。
• VP8 は、 On2 Technologies（後にGoogleに買収）が2008年にリリースしたビデオコーディング設計である。
• VP9 は、 2013年にリリースされたGoogleのビデオコーディング設計です。
• 高効率ビデオコーディング（ITU-T H.265またはISO/IEC 23008-2）、2013年にリリースされたITU/ISO/IEC標準
• AV1 は、 Alliance for Open Mediaが2018 年にリリースしたビデオコーディング設計です。
• 2020年にリリースされたITU/ISO/IEC規格である多目的ビデオコーディング（ITU-T H.266またはISO/IEC 23091-3）
• インターネット プロトコル テレビ
• 写真の集合
• フレーム内コーディング
• インターフレーム

• ITU-T 出版ページ: H.264: 汎用オーディオビジュアル サービス向けの高度なビデオ コーディング
• MPEG-4 AVC/H.264 情報 Doom9 のフォーラム
• H.264/MPEG-4 パート 10 チュートリアル (Richardson)
• 「パート 10: 高度なビデオ コーディング」。ISO公開ページ: ISO/IEC 14496-10:2010 – 情報技術 — オーディオビジュアル オブジェクトのコーディング。
• 「H.264/AVC JM リファレンス ソフトウェア」。IPホームページ。2007 年4 月 15 日閲覧。
• 「JVT ドキュメント アーカイブ サイト」。2010 年 8 月 8 日時点のオリジナルよりアーカイブ。2007 年5 月 6 日閲覧。
• 「出版物」。トーマス・ウィーガンド。 2007年6月23日閲覧。
• 「出版物」。Detlev Marpe 。 2007年4月15日閲覧。
• 「第 4 回 H.264 ビデオ コーデック比較」。モスクワ国立大学。（2007年12月）
• 「セキュリティおよび監視業界で使用されている IP カメラに関する H.264 に関する議論」2009 年 4 月 3 日。（2009年4月）
• 「第 6 回 H.264 ビデオ コーデック比較」。モスクワ国立大学。（2010年5月）
• 「SMPTE クイックガイド」など。