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

高度なビデオコーディング / H.264 / MPEG-4 パート10
一般的なオーディオビジュアルサービス向けの高度なビデオコーディング
状態有効
年が始まった2003年（22年前） （2003年）
初版2004年8月17日 （2004年8月17日）
最新バージョン15.0
2024年8月13日 ( 2024-08-13 )
組織ITU-T、ISO、IEC
委員会SG16（VCEG）、MPEG
基本基準H.261、H.262（別名MPEG-2ビデオ）、H.263、ISO/IEC 14496-2（別名MPEG-4パート2）
関連規格H.265 (別名 HEVC)、H.266 (別名 VVC)
前任者H.263
後継H.265
ドメインビデオ圧縮
ライセンスMPEG LA [1]
Webサイトwww.itu.int/rec/T-REC-H.264
知覚品質スコア付きH.264エンコーダのビデオコーディング層のブロック図

高度ビデオ符号化（AVC ）は、 H.264またはMPEG-4 Part 10とも呼ばれ、ブロック指向の動き補償符号化に基づくビデオ圧縮規格です。[2]ビデオコンテンツの記録、圧縮、配信に最も一般的に使用されているフォーマットであり、2024年12月時点でビデオ業界の開発者の79%が使用しています。[3]最大解像度は8K UHDです。[4] [5]

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

H.264は、ITU-T 研究グループ16のビデオ符号化専門家グループ（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（最近ではVP9およびAV1に移行）、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と呼ばれる新しい特許プール管理会社を設立しました。[7] 特許取得済みの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：動画の符号化」に分類される。 [8] 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として知られている。[9] ）一部のソフトウェアプログラム（ VLCメディアプレーヤーなど）は、内部的にこの規格をAVC1として識別する。

歴史

全体的な歴史

1998年初頭、ビデオ符号化専門家グループ（VCEG – ITU-T SG16 Q.6）は、H.26Lと呼ばれるプロジェクトの提案募集を開始しました。このプロジェクトの目標は、幅広いアプリケーションにおいて、既存のビデオ符号化規格と比較して符号化効率を2倍にすること（つまり、一定レベルの忠実度に必要なビットレートを半分にすること）でした。VCEGの議長は、ゲイリー・サリバン氏（Microsoft、旧PictureTel、米国）でした。この新しい規格の最初の設計草案は、1999年8月に採択されました。2000年には、トーマス・ヴィーガンド氏（ハインリッヒ・ヘルツ研究所、ドイツ）がVCEGの共同議長に就任しました。

2001年12月、VCEGとMoving Picture Experts Group（MPEG  – ISO/IEC JTC 1/SC 29 /WG 11）は、ビデオ符号化規格を最終決定する憲章に基づき、合同ビデオチーム（JVT）を結成した。[10]仕様の正式な承認は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の拡張に取り組んでいた。 2006年7月から2009年11月にかけて、JVTはH.264/AVCを3Dテレビおよび限定範囲自由視点テレビ向けに拡張したマルチビュービデオコーディング（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-AVCとMFC立体視コーディング

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

バージョン

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

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

アプリケーション

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です​​。[31]ソニーは、9 Mbit/sのAVC録画モードは、約18～25 Mbit/sを使用するHDVフォーマットの画質と同等であると主張しています。[32]

H.264/AVCの互換性とスムーズな導入を確保するため、多くの標準化団体がビデオ関連規格の修正や追加を行い、これらの規格のユーザーがH.264/AVCを利用できるようにしています。Blu -ray Discフォーマットと、現在は廃止されているHD DVDフォーマットの両方で、H.264/AVCハイプロファイルが3つの必須ビデオ圧縮フォーマットの1つとして採用されています。デジタルビデオ放送プロジェクト（DVB）は、2004年後半にテレビ放送におけるH.264/AVCの使用を承認しました。

米国の標準化団体である先進テレビシステム委員会（ ATSC）は、2008年7月にH.264/AVCのテレビ放送への使用を承認したが、この規格は米国内の固定ATSC放送にはまだ使用されていない。 [33] [34]また、H.264のAVCとSVC部分を使用して、より最近のATSC-M/H（モバイル/ハンドヘルド）規格での使用も承認されている。 [35]

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

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

派生形式

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

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

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

デザイン

特徴

H.264のブロック図

H.264/AVC/MPEG-4 Part 10には、従来の規格よりもはるかに効率的にビデオを圧縮し、幅広いネットワーク環境への適用において柔軟性を高める多くの新機能が含まれています。特に重要な機能には以下が含まれます。

  • 以下の機能を含むマルチピクチャーインターピクチャー予測:
  • MPEG-2 パート 2 の「DC」のみの予測や、H.263v2 および MPEG-4 パート 2 の変換係数予測ではなく、隣接ブロックのエッジからの空間予測による「イントラ」コーディング。これには、16×16、8×8、4×4 の輝度予測ブロック サイズが含まれます (各マクロブロック内では 1 つのタイプのみ使用できます)。
  • 整数離散コサイン変換（整数DCT）[5] [42] [43]は離散コサイン変換（DCT） [42]の一種であり、標準DCTの整数近似値となる。[44]選択可能なブロックサイズ[6]と、複雑さを軽減するための完全一致整数計算を備えている。
    • 完全一致の整数4×4空間ブロック変換。従来のコーデック設計でよく見られる「リンギング」を最小限に抑え、残差信号を正確に配置できます。以前の規格で使用されていた標準DCTに似ていますが、ブロックサイズが小さく、整数処理が単純です。以前の規格（H.261やMPEG-2など）で用いられていたコサインベースの式や許容値とは異なり、整数処理は正確に指定されたデコード結果を提供します。
    • 完全一致の整数8×8空間ブロック変換。相関の高い領域を4×4変換よりも効率的に圧縮できます。この設計は標準的なDCTに基づいていますが、簡素化され、厳密に指定されたデコードを実現できるように設計されています。
    • 整数変換演算のための 4×4 と 8×8 の変換ブロック サイズ間の適応型エンコーダ選択。
    • クロマ DC 係数 (および特殊なケースでは輝度) に適用された一次空間変換の「DC」係数に対して実行される二次アダマール変換により、滑らかな領域でさらに圧縮が行われます。
  • ロスレスマクロブロック コーディング機能には以下が含まれます。
    • ビデオデータサンプルが直接表現されるロスレス「PCMマクロブロック」表現モード[45]により、特定の領域を完全に表現することができ、各マクロブロックの符号化データの量に厳密な制限を設けることができる。
    • 通常は PCM モードよりも大幅に少ないビット数で特定の領域を完璧に表現できる、強化されたロスレス マクロブロック表現モードです。
  • 柔軟なインターレーススキャン ビデオ コーディング機能:
    • マクロブロック適応型フレーム フィールド (MBAFF) コーディングは、フレームとしてコード化された画像にマクロブロック ペア構造を使用し、フィールド モードで 16×16 マクロブロックを可能にします (フレームとしてコード化された画像でのフィールド モード処理により 16×8 ハーフ マクロブロックの処理が行われる MPEG-2 と比較)。
    • 画像適応型フレーム フィールド コーディング (PAFF または PicAFF) では、エンコード時に両方のフィールドが組み合わされた完全なフレームとして、または個別の単一フィールドとしてコード化された画像を自由に組み合わせることができます。
  • 以下を含む量子化設計:
    • 対数ステップサイズ制御により、エンコーダによるビットレート管理が容易になり、逆量子化スケーリングが簡素化されます。
    • 知覚ベースの量子化最適化のためにエンコーダによって選択された周波数カスタマイズされた量子化スケーリング行列
  • 他のDCTベースの画像圧縮技術に共通するブロッキングアーティファクトを防ぐのに役立つインループデブロッキングフィルタにより、視覚的な外観と圧縮効率が向上します。
  • 以下を含むエントロピー符号化設計:
    • コンテキスト適応型二値算術符号化（CABAC）は、特定のコンテキストにおける構文要素の確率を考慮しながら、ビデオストリーム内の構文要素をロスレス圧縮するアルゴリズムです。CABACはCAVLCよりも効率的にデータを圧縮しますが、デコードにはかなりの処理量が必要です。
    • コンテキスト適応型可変長符号化（CAVLC）は、量子化された変換係数値の符号化において、CABACよりも低複雑度の代替手法です。CABACよりも低複雑度ですが、CAVLCは従来の設計で係数を符号化するために一般的に使用される手法よりも複雑で効率的です。
    • CABAC または CAVLC でコード化されない多くの構文要素に共通する、単純かつ高度に構造化された可変長コード化(VLC) 手法。指数ゴロムコード化(または Exp-Golomb)と呼ばれます。
  • 損失耐性機能には以下が含まれます:
    • ネットワーク抽象化層（NAL）の定義により、多くのネットワーク環境で同一のビデオ構文を利用できるようになります。H.264の非常に基本的な設計概念の一つは、MPEG-4のヘッダー拡張コード（HEC）のようにヘッダーの重複を排除し、自己完結型パケットを生成することです。[46]これは、複数のスライスに関連する情報をメディアストリームから分離することで実現されました。高レベルパラメータの組み合わせはパラメータセットと呼ばれます。[46] H.264仕様には、シーケンスパラメータセット（SPS）とピクチャパラメータセット（PPS）の2種類のパラメータセットが含まれています。アクティブなシーケンスパラメータセットは、符号化されたビデオシーケンス全体を通して変更されず、アクティブなピクチャパラメータセットは、符号化されたピクチャ内で変更されません。シーケンスパラメータセットとピクチャパラメータセットの構造には、画像サイズ、オプションの符号化モード、マクロブロックとスライスグループのマッピングなどの情報が含まれます。[46]
    • フレキシブル・マクロブロック・オーダリング（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ビデオよりも大幅に優れたパフォーマンスを発揮することが多く、特に高ビットレート・高解像度のビデオコンテンツにおいては、通常、半分以下のビットレートで同等の品質が得られます。[47]

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

プロフィール

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

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

制約ベースラインプロファイル（CBP、制約セット1を含む66）
このプロファイルは主に低コストのアプリケーション向けで、ビデオ会議やモバイルアプリケーションで最もよく使用されます。ベースラインプロファイル、メインプロファイル、ハイプロファイルに共通する機能のサブセットに対応しています。
ベースラインプロファイル（BP、66）
このプロファイルは、主にデータ損失に対する堅牢性をさらに高める必要がある低コストのアプリケーション向けに、一部のビデオ会議アプリケーションやモバイルアプリケーションで使用されています。このプロファイルには、制約付きベースラインプロファイルでサポートされているすべての機能に加え、損失に対する堅牢性（または低遅延マルチポイントビデオストリーム合成などの他の目的）に使用できる3つの追加機能が含まれています。このプロファイルの重要性は、2009年の制約付きベースラインプロファイルの定義以来、やや薄れています。制約付きベースラインプロファイルのビットストリームはすべて、ベースラインプロファイルのビットストリームとみなされます。これは、これら2つのプロファイルが同じプロファイル識別子コード値を共有しているためです。
拡張プロファイル（XP、88）
ストリーミング ビデオ プロファイルとして意図されたこのプロファイルは、比較的高い圧縮能力と、データ損失やサーバー ストリームの切り替えに対する堅牢性を高めるための追加のトリックを備えています。
メインプロフィール（MP、77）
このプロファイルは、DVB規格で定義されているMPEG-4フォーマットを使用する標準解像度のデジタルテレビ放送に使用されます。[49]しかし、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クロマ サンプリング形式のサポートを追加します。
High 4:4:4予測プロファイル（Hi444PP、244）
このプロファイルは、High 4:2:2 プロファイルをベースに構築され、最大 4:4:4 クロマ サンプリング、サンプルあたり最大 14 ビットをサポートし、さらに効率的なロスレス領域コーディングと、各画像を 3 つの個別のカラー プレーンとしてコーディングすることをサポートします。

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

High 10 イントラプロファイル（制約セット 3 で 110）
High 10 プロファイルは、すべて Intra 使用に制限されています。
High 4:2:2 イントラプロファイル（制約セット 3 で 122）
すべて Intra の使用に制限された High 4:2:2 プロファイル。
High 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）
このプロファイルは主に実稼働アプリケーションを対象としており、オールイントラ使用に制限されたスケーラブル ハイ プロファイルです。

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

ステレオハイプロファイル（128）
このプロファイルは、2 ビュー立体3D ビデオを対象とし、High プロファイルのツールと MVC 拡張機能のビュー間予測機能を組み合わせています。
マルチビューハイプロファイル（118）
このプロファイルは、インターピクチャ（時間的）と MVC インタービュー予測の両方を使用して 2 つ以上のビューをサポートしますが、フィールドピクチャとマクロブロック適応型フレームフィールドコーディングはサポートしません。

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

MFCハイプロファイル（134）
2 層の解像度拡張による立体符号化用のプロファイル。
MFC デプス ハイ プロファイル (135)

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

マルチビュー深度ハイプロファイル (138)
このプロファイルは、深度マップとビデオ テクスチャ情報の共同コーディングをサポートし、3D ビデオ コンテンツの圧縮率を向上させます。
強化されたマルチビュー深度ハイプロファイル（139）
深度情報と組み合わせたマルチビュー コーディング用の拡張プロファイル。

特定のプロファイルでの機能サポート

特徴CBPBPXP国会議員プロヒップヒップHi10PHi422PHi444PP
IスライスとPスライスはいはいはいはいはいはいはいはいはい
ビット深度（サンプルあたり）8888888～108～108～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）いいえいいえはいはいいいえはいはいはいはい
Bスライスいいえいいえはいはいはいはいはいはいはい
複数の参照フレームはいはいはいはいはいはいはいはいはい
インループデブロッキングフィルタはいはいはいはいはいはいはいはいはい
CAVLCエントロピー符号化はいはいはいはいはいはいはいはいはい
CABACエントロピー符号化いいえいいえいいえはいはいはいはいはいはい
4:0:0 (グレースケール)いいえいいえいいえいいえはいはいはいはいはい
8×8と4×4の変換適応性いいえいいえいいえいいえはいはいはいはいはい
量子化スケーリング行列いいえいいえいいえいいえはいはいはいはいはい
C BとC RのQPコントロールを 個別にいいえいいえいいえいいえはいはいはいはいはい
別々のカラープレーンコーディングいいえいいえいいえいいえいいえいいえいいえいいえはい
予測ロスレス符号化いいえいいえいいえいいえいいえいいえいいえいいえはい

レベル

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

最大のプロパティ値を持つレベル[27]
レベル
最大
デコード速度
（マクロブロック/秒）		最大
フレームサイズ
（マクロブロック）		ビデオコーディング レイヤー (VCL)の最大ビデオ
ビット レート(制約ベースライン、ベースライン、拡張およびメイン プロファイル) (kbits/s)





最高フレームレート
（最大保存フレーム数）での高解像度の例
追加の詳細を切り替える

11,4859964176×[email protected] (4)
1b1,48599128176×[email protected] (4)
1.13,000396192352×[email protected] (2)
1.26,000396384352×[email protected] (6)
1.311,880396768352×[email protected] (6)
211,8803962,000352×[email protected] (6)
2.119,8007924,000352×[email protected] (6)
2.220,2501,6204,000720×[email protected] (5)
340,5001,62010,000720×[email protected] (5)
3.110万80003,60014,0001,280×[email protected] (5)
3.221万60005,1202万1,280×1,[email protected] (4)
4245,7608,1922万
1,280×[email protected] (9)
1,920×1,[email protected] (4)
2,048×1,[email protected] (4)
4.1245,7608,1925万
1,280×[email protected] (9)
1,920×1,[email protected] (4)
2,048×1,[email protected] (4)
4.2522,2408,7045万
1,280×[email protected] (9)
1,920×1,[email protected] (4)
2,048×1,[email protected] (4)
5589,82422,08013万5000
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.1983,04036,86424万
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.22,073,60036,86424万
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)
64,177,920139,26424万
3,840×2,[email protected] (16)
7,680×4,[email protected] (5)
8,192×4,[email protected] (5)
6.18,355,840139,26448万
3,840×2,[email protected] (16)
7,680×4,[email protected] (5)
8,192×4,[email protected] (5)
6.216,711,680139,26480万
3,840×2,[email protected] (16)
7,680×4,[email protected] (5)
8,192×4,[email protected] (5)

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

輝度サンプルの数は、マクロブロックの数の 16×16 = 256 倍です (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に規定されています。[27]

レベル11b1.11.21.322.12.233.13.244.14.255.15.266.16.2
最大DpbMbs3963969002,3762,3762,3764,7528,1008,10018,00020,48032,76832,76834,816110,400184,320184,320696,320696,320696,320

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

デコード中の現在のピクチャは、 DPBの占有量の計算には含まれません（エンコーダが、他のピクチャのデコード時の参照用、または遅延出力タイミング用として、そのピクチャを保存するよう指示した場合を除きます）。したがって、デコーダは、上記で計算したDPBの最大容量よりも （少なくとも）1フレーム多く処理できるだけの十分なメモリを実際に備えている必要があります。

実装

AVC（H.264）ビデオコーデックとOpusオーディオフォーマットを使用したYouTubeビデオの統計

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

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

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はこのリストに含まれていないのは、アプリケーションがインターネットからバイナリモジュールを取得してインストールすることを許可していないためである。[56] [57] [58]また、2013年10月30日、 MozillaのBrendan Eichは、プラットフォームコーデックが利用できないFirefoxにH.264のサポートを追加するために、将来のFirefoxバージョンでCiscoのバイナリを使用する予定であると書きました。[59] Ciscoは2013年12月9日にOpenH264にソースコードを公開しました。[60]

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

ソフトウェアエンコーダ

AVCソフトウェア実装
特徴クイックタイムネロオープンH264x264メイン
コンセプト		エレカード 東証 プロ
コーダー		アビボエレメンタル IPP 
Bスライスはいはいはいはいはいはいはいはいいいえはいはい
複数の参照フレームはいはいはいはいはいはいはいはいいいえはいはい
インターレース符号化（PicAFF、MBAFF）いいえMBAFFMBAFFMBAFFはいはいいいえはいMBAFFはいいいえ
CABACエントロピー符号化はいはいはいはいはいはいはいはいいいえはいはい
8×8と4×4の変換適応性いいえはいはいはいはいはいはいはいいいえはいはい
量子化スケーリング行列いいえいいえはいはいはいいいえいいえいいえいいえいいえいいえ
C BとC RのQPコントロールを 個別にいいえいいえはいはいはいはいいいえいいえいいえいいえいいえ
拡張クロマフォーマットいいえいいえいいえ4:0:0 [61]
4:2:0
4:2:2 [62]
4:4:4 [63]  		4:2:24:2:24:2:2いいえいいえ4:2:0
4:2:2		いいえ
最大サンプル深度（ビット）88810 [64]1088881012
予測ロスレス符号化いいえいいえいいえはい[65]いいえいいえいいえいいえいいえいいえいいえ

ハードウェア

H.264 のエンコードとデコードでは、特定の種類の算術演算にかなりの計算能力が必要になるため、汎用 CPU で実行されるソフトウェア実装は通常、電力効率が低くなります。ただし、2020 年 1 月現在、最新のクアッドコア汎用 x86 CPU は、リアルタイム SD および HD エンコードを実行するのに十分な計算能力を備えています。また、2016 年頃からは、6 コアまたは 8 コアのコンシューマーグレード CPU も実行しています。圧縮効率は、ハードウェア実装とソフトウェア実装のどちらが使用されているかではなく、ビデオ アルゴリズムの実装に依存します。したがって、ハードウェア ベースとソフトウェア ベースの実装の違いは、電力効率、柔軟性、およびコストにあります。電力効率を改善し、ハードウェア フォーム ファクターを削減するために、完全なエンコードまたはデコード プロセス用、または CPU 制御環境内での加速支援用に、専用のハードウェアが採用される場合があります。

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

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

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

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

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

ライセンス

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

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

2010年8月26日、MPEG LAは、エンドユーザーが無料で利用できるH.264エンコードされたインターネットビデオについては、ロイヤリティを課さないと発表した。[74] H.264ビデオのデコードおよびエンコードを行う製品や、無料テレビおよび有料チャンネルの運営者に対するロイヤリティなど、その他のロイヤリティは引き続き適用される。 [75]ライセンス条件は5年ごとに更新される。[76]

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

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

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

参照

参考文献

  1. ^ MPEG-4、高度なビデオ符号化（パート10）（H.264）（ドラフト全文）。デジタルフォーマットの持続可能性。ワシントンD.C.：米国議会図書館。2011年12月5日。 2021年12月1日閲覧。
  2. ^ 「H.264：汎用オーディオビジュアルサービス向けの高度なビデオコーディング」www.itu.int。2019年10月31日時点のオリジナルよりアーカイブ。2019年11月22日閲覧。
  3. ^ 「ビデオ開発者レポート 2024/2025」（PDF） . Bitmovin . 2024年12月.
  4. ^ “Delivering 8K using AVC/H.264”. Mystery Box . 2021年3月25日時点のオリジナルよりアーカイブ。2017年8月23日閲覧。
  5. ^ ab Wang, Hanli; Kwong, S.; Kok, C. (2006). 「H.264/AVC最適化のための整数DCT係数の効率的な予測アルゴリズム」. IEEE Transactions on Circuits and Systems for Video Technology . 16 (4): 547– 552. Bibcode :2006ITCSV..16..547W. doi :10.1109/TCSVT.2006.871390. S2CID  2060937.
  6. ^ ab Thomson, Gavin; Shah, Athar (2017). 「HEIFとHEVCの紹介」(PDF) . Apple Inc. 2019年8月5日閲覧。
  7. ^ Ozer, Jan (2023年5月8日)、Via LAのHeath HoglundがMPEG LAとViaライセンス特許プールの合併について語る、StreamingMedia.com
  8. ^ 「ITU-T 勧告」. ITU 。2022 年11 月 1 日に取得。
  9. ^ 「H.262：情報技術 - 動画および関連音声情報の汎用符号化：ビデオ」 。 2007年4月15日閲覧。
  10. ^ Joint Video Team、ITU-T Web サイト。
  11. ^ “ITU-T 勧告 H.264 (05/2003)”. ITU。 2003 年 5 月 30 日。2013 年4 月 18 日に取得。
  12. ^ 「ITU-T 勧告 H.264 (05/2003) Cor. 1 (05/2004)」。 ITU。 2004 年 5 月 7 日。2013 年4 月 18 日に取得。
  13. ^ “ITU-T 勧告 H.264 (03/2005)”. ITU。 2005 年 3 月 1 日。2013 年4 月 18 日に取得。
  14. ^ 「ITU-T 勧告 H.264 (2005) Cor. 1 (09/2005)」。 ITU。 2005 年 9 月 13 日。2013 年4 月 18 日に取得。
  15. ^ ab 「ITU-T勧告H.264 (2005) Amd. 1 (06/2006)」。ITU。2006年6月13日。 2013年4月18日閲覧。
  16. ^ 「ITU-T勧告H.264 (2005) Amd. 2 (04/2007)」ITU、2007年4月6日。 2013年4月18日閲覧。
  17. ^ “ITU-T 勧告 H.264 (2007 年 11 月)”. ITU。 2007 年 11 月 22 日。2013 年4 月 18 日に取得。
  18. ^ 「ITU-T 勧告 H.264 (2007) Cor. 1 (01/2009)」。 ITU。 2009 年 1 月 13 日。2013 年4 月 18 日に取得。
  19. ^ ab 「ITU-T 勧告 H.264 (03/2009)」。 ITU。 2009 年 3 月 16 日。2013 年4 月 18 日に取得。
  20. ^ ab 「ITU-T 勧告 H.264 (03/2010)」。 ITU。 2010 年 3 月 9 日。2013 年4 月 18 日に取得。
  21. ^ ab 「ITU-T 勧告 H.264 (06/2011)」。 ITU。 2011 年 6 月 29 日。2013 年4 月 18 日に取得。
  22. ^ “ITU-T 勧告 H.264 (01/2012)”. ITU。 2012 年 1 月 13 日。2013 年4 月 18 日に取得。
  23. ^ abcd 「ITU-T 勧告 H.264 (04/2013)」。 ITU。 2013 年 6 月 12 日。2013 年6 月 16 日に取得。
  24. ^ ab 「ITU-T勧告H.264（02/2014）」ITU、2014年11月28日。 2016年2月28日閲覧。
  25. ^ 「ITU-T勧告H.264（2016年2月）」ITU、2016年2月13日。 2017年6月14日閲覧。
  26. ^ “ITU-T 勧告 H.264 (2016 年 10 月)”. ITU。 2016 年 10 月 14 日。2017 年6 月 14 日に取得。
  27. ^ abc "ITU-T勧告H.264 (04/2017)". ITU. 2017年4月13日. 表A-1、A-6、A-7にレベル依存の能力の一覧を示す。 2017年6月14日閲覧。
  28. ^ “H.264: 汎用オーディオビジュアルサービス向け高度なビデオコーディング - バージョン26（第13版）”. www.itu.int . 2019年6月13日. 2021年11月4日時点のオリジナルよりアーカイブ。 2021年11月3日閲覧。
  29. ^ “H.264: 汎用オーディオビジュアルサービス向け高度なビデオコーディング - バージョン27（第14版）”. www.itu.int . 2021年8月22日. 2021年11月4日時点のオリジナルよりアーカイブ。 2021年11月3日閲覧。
  30. ^ 「H.264: 汎用オーディオビジュアルサービスのための高度なビデオコーディング - バージョン28（第15版）」www.itu.int . 2024年8月13日. 2025年2月12日閲覧。
  31. ^ Wenger他 (2005年2月). 「RFC 3984: H.264ビデオのRTPペイロードフォーマット」 . Ietf Datatracker : 2. doi :10.17487/RFC3984.
  32. ^ 「ハイビジョンビデオ（HDV）形式の画質に相当する録画モードはどれですか？」Sony eSupport . 2017年11月9日時点のオリジナルよりアーカイブ。 2018年12月8日閲覧。
  33. ^ 「ATSC規格A/72 パート1：ATSCデジタルテレビシステムにおけるAVCのビデオシステム特性」（PDF） 。 2011年8月7日時点のオリジナル（PDF）からアーカイブ。 2011年7月30日閲覧。
  34. ^ 「ATSC規格A/72 パート2：AVCビデオトランスポートサブシステムの特性」（PDF） 。 2011年8月7日時点のオリジナル（PDF）からアーカイブ。 2011年7月30日閲覧。
  35. ^ 「ATSC規格A/153 パート7：AVCおよびSVCビデオシステム特性」（PDF） 。 2011年7月26日時点のオリジナル（PDF）からアーカイブ。 2011年7月30日閲覧。
  36. ^ ab 「ソニー、プロ市場とコンシューマー市場における4K開発を加速させるため、新たなXAVC録画フォーマットを導入」ソニー、2012年10月30日。 2012年11月1日閲覧。
  37. ^ ab 「ソニー、プロ市場とコンシューマー市場における4K開発を加速させる新たなXAVC録画フォーマットを発表」(PDF) 。ソニー。2012年10月30日。 2023年3月23日時点のオリジナル(PDF)からアーカイブ。 2012年11月1日閲覧。
  38. ^ Steve Dent (2012年10月30日). 「ソニー、CineAlta 4Kスーパー35mmセンサー搭載カムコーダーPMW-F55とPMW-F5 proでレッドレンズに挑戦」Engadget . 2012年11月5日閲覧。
  39. ^ 「F55 CineAlta 4K 未来へ、予定より早く」(PDF)ソニー、2012年10月30日。 2012年11月19日時点のオリジナル(PDF)からアーカイブ。 2012年11月1日閲覧。
  40. ^ 「超高速「SxS PRO+」メモリーカードが4K動画撮影を変革」ソニー. 2013年3月8日時点のオリジナルよりアーカイブ。 2012年11月5日閲覧。
  41. ^ 「超高速「SxS PRO+」メモリーカードが4K動画撮影を変革」（PDF）ソニー。 2015年4月2日時点のオリジナル（PDF）からアーカイブ。 2012年11月5日閲覧。
  42. ^ ab Stanković, Radomir S.; Astola, Jaakko T. (2012). 「DCT初期の研究の回想：KR Rao氏へのインタビュー」（PDF） .情報科学黎明期の再録. 60:17 . 2019年10月13日閲覧。
  43. ^ クォン・スンヨン、イ・ジュギョン、チョン・キドン (2005). 「MPEG-2/H.264トランスコーディングにおけるハーフピクセル補正」.画像解析と処理 – ICIAP 2005 . コンピュータサイエンス講義ノート. 第3617巻. シュプリンガー・ベルリン・ハイデルベルク. pp.  576– 583. doi : 10.1007/11553595_71 . ISBN 978-3-540-28869-5。
  44. ^ ブリタナック, ウラジミール; イップ, パトリック C.;ラオ, KR (2010). 離散コサイン変換とサイン変換：一般的な特性、高速アルゴリズム、整数近似.エルゼビア. pp. ix, xiii, 1, 141–304 . ISBN 9780080464640。
  45. ^ 「H.264/AVC高度ビデオ符号化規格：概要と忠実度範囲拡張の紹介」（PDF）2011年7月30日閲覧。
  46. ^ abc RFC 3984、p.3
  47. ^ Apple Inc. (1999年3月26日). 「H.264 FAQ」. Apple. 2010年3月7日時点のオリジナルよりアーカイブ。2010年5月17日閲覧。
  48. ^ Karsten Suehring. 「H.264/AVC JMリファレンスソフトウェアダウンロード」. Iphome.hhi.de . 2010年5月17日閲覧。
  49. ^ 「TS 101 154 – V1.9.1 – デジタルビデオ放送（DVB）; MPEG-2トランスポートストリームに基づく放送アプリケーションにおけるビデオおよびオーディオ符号化の使用に関する仕様」（PDF） 。 2010年5月17日閲覧。
  50. ^ 「HTML 5ビデオコーデック論争を解読する」Ars Technica、2009年7月6日。 2011年1月12日閲覧。
  51. ^ “スティーブ・バルマー、マイクロソフトCEO、ガートナー・シンポジウム/ITxpoオーランド2010でのインタビュー”. Gartnervideo. 2010年11月. 2021年10月30日時点のオリジナルよりアーカイブ。2011年1月12日閲覧。
  52. ^ 「Chrome での HTML ビデオ コーデックのサポート」. 2011年1月11日. 2011年1月12日閲覧。
  53. ^ 「ビデオ、モバイル、そしてオープンウェブ」2012年3月18日。 2012年3月20日閲覧。
  54. ^ 「WebRTC 有効化、Windows 7 で H.264/MP3 がデフォルトでサポート、Windows 8 向け Metro UI など - Firefox 開発ハイライト」hacks.mozilla.org . mozilla. 2013年2月20日. 2013年3月15日閲覧。
  55. ^ 「Firefox — ノート (35.0)」。Mozilla。
  56. ^ 「オープンソースのH.264がWebRTCの障壁を取り除く」2013年10月30日。2015年7月6日時点のオリジナルよりアーカイブ。2013年11月1日閲覧。
  57. ^ ab 「Cisco OpenH264プロジェクトFAQ」 。 2021年9月26日閲覧。
  58. ^ 「OpenH264 簡易BSDライセンス」GitHub 2013年10月27日. 2013年11月21日閲覧。
  59. ^ 「シスコのH.264コーデックによりWeb上のビデオ相互運用性が向上」2013年10月30日。 2013年11月1日閲覧。
  60. ^ 「README を更新しました · cisco/openh264@59dae50」。GitHub。
  61. ^ "x264 4:0:0 (モノクロ) エンコーディング サポート", 2019年6月5日閲覧。
  62. ^ "x264 4:2:2 エンコーディングのサポート", 2019年6月5日閲覧。
  63. ^ "x264 4:4:4 エンコーディングサポート", 2019年6月5日閲覧。
  64. ^ 「9 ビットおよび 10 ビット エンコーディングの x264 サポート」、2011 年 6 月 22 日閲覧。
  65. ^ "x264 replace High 4:4:4 profile lossless with High 4:4:4 Predictive", 2011年6月22日閲覧。
  66. ^ 「第3世代Intel Coreプロセッサー内蔵ビジュアル機能のクイック・リファレンス・ガイド」Intel Software Network、2010年10月1日。 2011年1月19日閲覧。
  67. ^ 「Intel Quick Sync Video」 www.intel.com. 2010年10月1日. 2011年1月19日閲覧。
  68. ^ "Design-reuse.com". Design-reuse.com. 1990年1月1日. 2010年5月17日閲覧。
  69. ^ “Category:DM6467 - Texas Instruments Embedded Processors Wiki”. Processors.wiki.ti.com. 2011年7月12日. 2011年7月17日時点のオリジナルよりアーカイブ。2011年7月30日閲覧。
  70. ^ 「ブリーフィングポートフォリオ」（PDF）www.mpegla.com。2016年11月28日時点のオリジナル（PDF）からアーカイブ。 2016年12月1日閲覧。
  71. ^ 「OMS Video、SunのOpen Media Commons Initiativeのプロジェクト」。2010年5月11日時点のオリジナルよりアーカイブ。2008年8月26日閲覧。
  72. ^ 「AVC/H.264特許ポートフォリオライセンスに含まれるライセンサー」MPEG LA . 2021年10月11日時点のオリジナルよりアーカイブ。 2019年6月18日閲覧。
  73. ^ ab 「AVC/H.264 – 特許リスト」。Via Licensing Alliance . 2024年4月28日閲覧。
  74. ^ 「MPEG LAのAVCライセンスは、ライセンスの有効期間中、エンドユーザーに無料で提供されるインターネットビデオに対してロイヤリティを請求しない」（PDF） 。MPEG LA。2010年8月26日。 2013年11月7日時点のオリジナル（PDF）からアーカイブ。 2010年8月26日閲覧。
  75. ^ Hachman, Mark (2010年8月26日). 「MPEG LA、無料ウェブビデオのロイヤリティを永久に削減」. pcmag.com . 2010年8月26日閲覧。
  76. ^ 「AVC FAQ」MPEG LA、2002年8月1日。2010年5月7日時点のオリジナルよりアーカイブ。2010年5月17日閲覧。
  77. ^ 「米国特許9,356,620 Baese他」2022年8月1日閲覧。最も早い優先日が 2001 年 9 月 14 日である特許には、2,998 日間の期間延長があります。
  78. ^ abc Qualcomm Inc. v. Broadcom Corp., No. 2007-1545, 2008-1162 (Fed. Cir. December 1, 2008)を参照。一般紙の記事については、signonsandiego.com「Qualcomm、特許権訴訟で敗訴」および「Qualcommの特許訴訟、陪審へ」、bloomberg.com「Broadcom、Qualcomm特許紛争で初審に勝利」を参照。
  79. ^ 「ノキア h264」.

さらに読む

  • Wiegand, Thomas; Sullivan, Gary J.; Bjøntegaard, Gisle; Luthra, Ajay (2003年7月). 「H.264/AVCビデオ符号化規格の概要」(PDF) . IEEE Transactions on Circuits and Systems for Video Technology . 13 (7): 560– 576. Bibcode :2003ITCSV..13..560W. doi :10.1109/TCSVT.2003.815165. オリジナル(PDF)から2011年4月29日アーカイブ. 2011年1月31日閲覧.
  • Topiwala, Pankaj; Sullivan, Gary J.; Luthra, Ajay (2004年8月). Tescher, Andrew G (編). 「H.264/AVC高度ビデオ符号化規格：概要と忠実度範囲拡張の紹介」(PDF) . SPIEデジタル画像処理アプリケーションXXVII . デジタル画像処理アプリケーションXXVII. 5558 :454. Bibcode :2004SPIE.5558..454S. doi :10.1117/12.564457. S2CID  2308860. 2011年1月31日閲覧.
  • Ostermann, J.; Bormans, J.; List, P.; Marpe, D.; Narroschke, M.; Pereira, F.; Stockhammer, T.; Wedi, T. (2004). 「H.264/AVCによるビデオ符号化：ツール、性能、複雑性」（PDF） . IEEE Circuits and Systems Magazine ( FTP ). pp.  7– 28. doi :10.1109/MCAS.2004.1286980. S2CID  11105089. 2011年1月31日閲覧.[デッド FTP リンク] (ドキュメントを表示するには、ヘルプ:FTP を参照してください)
  • Puri, Atul; Chen, Xuemin; Luthra, Ajay (2004年10月). 「H.264/MPEG-4 AVC圧縮規格を用いたビデオ符号化」(PDF) .信号処理：画像通信. 19 (9): 793– 849. doi :10.1016/j.image.2004.06.003 . 2011年3月30日閲覧.
  • Sullivan, Gary J.; Wiegand, Thomas (2005年1月). 「ビデオ圧縮 ― 概念からH.26​​4/AVC規格まで」(PDF) . Proceedings of the IEEE . 93 (1): 18– 31. Bibcode :2005IEEEP..93...18S. doi :10.1109/jproc.2004.839617. S2CID  1362034. 2011年1月31日閲覧.
  • Richardson, Iain EG (2011年1月). 「ビデオ圧縮とH.264について学ぶ」. VCODEX . Vcodex Limited. 2011年1月28日時点のオリジナルよりアーカイブ。 2011年1月31日閲覧。
  • ITU-T 出版物ページ: H.264: 汎用オーディオビジュアルサービスのための高度なビデオ符号化
  • MPEG-4 AVC/H.264 情報 Doom9 のフォーラム
  • H.264/MPEG-4 パート10チュートリアル（リチャードソン）
  • 「パート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クイックガイド」。ETC. 2018年5月14日。
「https://en.wikipedia.org/w/index.php?title=Advanced_Video_Coding&oldid=1322154212」より取得