ネーミング H.264 という名称は、勧告にシリーズに対応する文字とシリーズ内の勧告番号が与えられるITU-T の 命名規則 に従っています。H.264 は「H シリーズ勧告: 視聴覚およびマルチメディア システム」の一部です。H.264 はさらに「H.200-H.499: 視聴覚サービスのインフラストラクチャ」と「H.260-H.279:動画の符号化」に分類されます。 [ 7 ] MPEG の命名規則に関連しており、この規格は ISO/IEC 14496 のパート 10 であり、これは MPEG-4 として知られる規格群です。この規格は、VCEG と MPEG のパートナーシップで共同開発され、それ以前は ITU-T で H.26L と呼ばれる VCEG プロジェクトとして開発されていました。そのため、共通の起源を強調するために、この規格を 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 のパートナーシップから生まれました。ITU-T コミュニティでは、MPEG-2 ビデオは H.262 として知られています。[ 8 ] ) 一部のソフトウェア プログラム ( VLC メディア プレーヤー など) は、この規格を内部的に AVC1 として識別します。
歴史
Fidelityシリーズの拡張とプロフェッショナル向けプロファイル 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 種類の追加の「補足的な強化情報」(フィルター後のヒントとトーンマッピング) が定義され、業界からのフィードバックで
スケーラブルなビデオコーディング 規格に追加された次の主要な機能は、スケーラブルビデオコーディング （SVC）です。H.264/AVCのAnnex Gで規定されているSVCは、SVCをサポートしていないH.264 /AVCコーデック でもデコードできる「ベースレイヤー」と呼ばれるビットストリームなど、規格に準拠したサブビットストリームのレイヤーを含む ビットストリームの構築を可能にします。時間的ビットストリームのスケーラビリティ（つまり、メインビットストリームよりも時間的サンプリングレートが低いサブビットストリームの存在）の場合、サブビットストリームを導出する際に、完全なアクセスユニットが ビットストリームから削除されます。この場合、ビットストリーム内の高レベル構文とインター予測参照画像がそれに応じて構築されます。一方、空間的および品質的ビットストリームのスケーラビリティ（つまり、メインビットストリームよりも空間解像度/品質が低いサブビットストリームの存在）の場合、サブビットストリームを導出する際に、NAL（ネットワーク抽象化レイヤー ）がビットストリームから削除されます。この場合、効率的な符号化のために、層間予測（すなわち、低空間解像度／低品質信号のデータから高空間解像度／高品質信号を予測すること）が一般的に用いられます。スケーラブルビデオコーディングの 拡張機能は2007年11月に完成しました。
マルチビュービデオコーディング 規格に追加された次の主要機能は、マルチビュービデオコーディング （MVC）です。H.264/AVCの付属書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 の最初の承認バージョン。[ 10 ] バージョン2（エディション1.1）：（2004年5月7日）様々な軽微な修正を含む訂正。[ 11 ] バージョン 3 (エディション 2): (2005 年 3 月 1 日) Fidelity Range Extensions (FRExt) を確立する最初の修正を含む主要な追加。このバージョンでは、High、High 10、High 4:2:2、および High 4:4:4 プロファイルが追加されました。[ 12 ] バージョン4（エディション2.1）：（2005年9月13日）様々な軽微な修正と3つのアスペクト比インジケーターの追加を含む訂正。[ 13 ] バージョン 5 (エディション 2.2): (2006 年 6 月 13 日) 以前の High 4:4:4 プロファイルの削除からなる修正 (ISO/IEC で正誤表として処理)。[ 14 ] バージョン 6 (エディション 2.2): (2006 年 6 月 13 日) 拡張色域カラースペースのサポートなどのマイナーな拡張を含む修正 (ISO/IEC の上記のアスペクト比インジケーターにバンドルされています)。[ 14 ] バージョン 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) の追加を含む修正。[ 15 ] バージョン 8 (エディション 3): (2007 年 11 月 22 日) Scalable Baseline、Scalable High、および Scalable High Intra プロファイルを含むScalable Video Coding (SVC)の修正を含む H.264/AVC への主要な追加。 [ 16 ] バージョン9（エディション3.1）：（2009年1月13日）軽微な修正を含む訂正。[ 17 ] バージョン 10 (第 4 版): (2009 年 3 月 16 日) さまざまな以前のプロファイルでサポートされている機能の共通部分のみを含む新しいプロファイル (制約付きベースライン プロファイル) の定義を含む修正。[ 18 ] バージョン11（第4版）：（2009年3月16日）マルチビュービデオコーディング （MVC）拡張機能の修正を含むH.264/AVCへの主要な追加。これにはマルチビューハイプロファイルが含まれます。[ 18 ] バージョン 12 (第 5 版): (2010 年 3 月 9 日) インターレース コーディング ツールをサポートする 2 ビュー ビデオ コーディング用の新しい MVC プロファイル (ステレオ ハイ プロファイル) の定義と、フレーム パッキング アレンジメント SEI メッセージと呼ばれる追加の補足拡張情報 (SEI) メッセージを指定する修正。[ 19 ] バージョン13（第5版）：（2010年3月9日）軽微な修正を含む訂正。[ 19 ] バージョン 14 (エディション 6): (2011 年 6 月 29 日) 1 秒あたりの最大マクロブロック数に関してより高い処理速度をサポートする新しいレベル (レベル 5.2) と、以前に指定された High プロファイルのフレーム コーディング ツールのみをサポートする新しいプロファイル (プログレッシブ High プロファイル) を指定する修正。[ 20 ] バージョン15（第6版）：（2011年6月29日）軽微な修正を含む訂正。[ 20 ] バージョン 16 (第 7 版): (2012 年 1 月 13 日) 主にリアルタイム通信アプリケーションを目的とした 3 つの新しいプロファイルの定義を含む修正: Constrained High、Scalable Constrained Baseline、および Scalable Constrained High プロファイル。[ 21 ] バージョン17（第8版）：（2013年4月13日）SEIメッセージインジケータを追加した修正。[ 22 ] バージョン18（第8版）：（2013年4月13日）マルチビュー深度ハイプロファイルを含む、3D立体視ビデオの深度マップデータのコーディングを指定するための修正。[ 22 ] バージョン19（第8版）：（2013年4月13日）マルチビュービデオのサブビットストリーム抽出プロセスにおけるエラーを修正するための訂正。[ 22 ] バージョン20（第8版）：（2013年4月13日）トーンマッピング情報SEIメッセージに、追加のカラースペース識別子（ UHDTV 向けITU-R勧告BT.2020 のサポートを含む）と追加のモデルタイプを指定する修正。 [ 22 ] バージョン21（第9版）：（2014年2月13日）拡張マルチビュー深度高プロファイルを指定するための修正。[ 23 ] バージョン22（第9版）：（2014年2月13日）3D立体視ビデオ用のマルチ解像度フレーム互換（MFC）拡張機能、MFCハイプロファイル、および軽微な修正を規定するための改訂。[ 23 ] バージョン23（第10版）：（2016年2月13日）深度マップ付きMFC立体視ビデオ、MFC深度ハイプロファイル、マスタリングディスプレイカラーボリュームSEIメッセージ、および追加の色関連のVUIコードポイント識別子を指定するための修正。[ 24 ] バージョン 24 (エディション 11): (2016 年 10 月 14 日) より大きな画像サイズをサポートするデコーダ機能の追加レベル (レベル 6、6.1、および 6.2)、グリーン メタデータ SEI メッセージ、代替深度情報 SEI メッセージ、および追加の色関連の VUI コードポイント識別子を指定するための修正。[ 25 ] バージョン25（第12版）：（2017年4月13日）プログレッシブハイ10プロファイル、ハイブリッドログガンマ （HLG）、および追加の色関連のVUIコードポイントとSEIメッセージを指定するための修正。[ 26 ] バージョン 26 (エディション 13): (2019 年 6 月 13 日) 周囲の表示環境、コンテンツの光レベル情報、コンテンツのカラーボリューム、正距円筒図法、キューブマップ投影、球体回転、領域ごとのパッキング、全方向ビューポート、SEI マニフェスト、および SEI プレフィックスに関する追加の SEI メッセージを指定する修正。[ 27 ] バージョン27（第14版）：（2021年8月22日）注釈領域とシャッター間隔情報に関する追加のSEIメッセージを指定するための修正、およびその他の軽微な修正と明確化。[ 28 ] バージョン 28 (第 15 版): (2024 年 8 月 13 日) ニューラル ネットワークのポスト フィルタ特性、ニューラル ネットワークのポスト フィルタの活性化、位相表示に関する追加の SEI メッセージ、追加の色タイプ識別子、およびその他の軽微な修正と明確化を指定するための修正。[ 29 ]
アプリケーション 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 です。[ 30 ] HDV フォーマットの画質と同等であると主張しています。[ 31 ]
H.264/AVCの互換性と円滑な導入を確保するため、多くの標準化団体がビデオ関連規格を改訂または追加し、これらの規格の利用者がH.264/AVCを利用できるようにしました。Blu -ray Disc フォーマットと、現在では廃止されているHD DVD フォーマットの両方で、H.264/AVC High Profileが3つの必須ビデオ圧縮フォーマットの1つとして採用されています。デジタルビデオ放送プロジェクト（DVB ）は、2004年末に放送テレビにおけるH.264/AVCの使用を承認しました。
米国の先進テレビシステム委員会 （ ATSC）標準化団体は、2008年7月に放送テレビでのH.264/AVCの使用を承認しました。 [ 32 ] [ 33 ] [ 34 ]
閉回路テレビやビデオ監視の 市場では、この技術が多くの製品に採用されている。
多くの一般的なデジタル一眼レフカメラは 、ネイティブの記録フォーマットとして、QuickTime MOVコンテナに格納されたH.264ビデオを使用しています。
デザイン
特徴 H.264/AVC/MPEG-4 Part 10には、従来の規格よりもはるかに効率的にビデオを圧縮し、多様なネットワーク環境への適用においてより高い柔軟性を提供する多くの新機能が含まれています。特に、以下のような主要な機能があります。
複数画像間の予測に は、以下の機能が含まれます。 以前の規格よりもはるかに柔軟な方法で、以前にエンコードされた画像を参照として使用し、場合によっては最大 16 個の参照フレーム (インターレースエンコードの場合は 32 個の参照フィールド) を使用できます。非IDRフレームをサポートするプロファイルでは、ほとんどのレベルで、最大解像度で少なくとも 4 個または 5 個の参照フレームを使用できるように十分なバッファリングが必要であると規定されています。これは、制限が通常 1 個、または従来の「 B 画像 」(B フレーム)の場合は2 個であった以前の規格とは対照的です。 可変ブロックサイズモーション補償 （VBSMC）は、最大16×16、最小4×4のブロックサイズに対応し、動いている領域の正確なセグメンテーションを可能にします。サポートされている輝度 予測ブロックサイズは、16×16、16×8、8×16、8×8、8×4、4×8、4×4で、これらの多くは単一のマクロブロック内で組み合わせて使用できます。クロマサブサンプリング を使用する場合は、クロマ予測ブロックサイズはそれに応じて小さくなります。 マクロブロックごとに複数のモーションベクトル（パーティションごとに1つまたは2つ）を使用でき、16個の4×4パーティションで構成されるBマクロブロックの場合は最大32個まで使用可能です。8×8以上の各パーティション領域におけるモーションベクトルは、それぞれ異なる参照画像を指すことができます。 Bフレーム 内でIマクロブロックを含むあらゆるマクロブロックタイプを使用できる機能により、Bフレーム使用時のエンコード効率が大幅に向上しました。この機能はMPEG-4 ASP では意図的に省略されていました。サブピクセルの動き補正をより鮮明にするため、6タップフィルタリングを用いてハーフピクセル輝度サンプル予測を導出します。処理能力を節約するため、クォーターピクセルの動きはハーフピクセル値の線形補間によって算出されます。 動き補正には1/4ピクセルの 精度が採用されており、動いている領域の変位を正確に記述できます。クロマ の場合、解像度は通常、垂直方向と水平方向の両方で半分になるため（4:2:0を参照）、クロマの動き補正には1/8クロマピクセルのグリッド単位が使用されます。重み付き予測は、エンコーダが動き補正を実行する際にスケーリングとオフセットの使用を指定できるようにするもので、フェード・トゥ・ブラック、フェード・イン、クロスフェードなどの特殊なケースにおいてパフォーマンスを大幅に向上させます。これには、Bフレームに対する暗黙的な重み付き予測と、Pフレームに対する明示的な重み付き予測が含まれます。 MPEG-2 Part 2 に見られる「DC」のみの予測や、H.263v2 および MPEG-4 Part 2 に見られる変換係数予測とは異なり、 「イントラ」 符号化のために隣接ブロックのエッジから空間予測を行います。これには、16×16、8×8、および 4×4 の輝度予測ブロックサイズが含まれます (各マクロブロック 内では、これらのうち 1 つのタイプのみを使用できます)。整数離散コサイン変換 （整数DCT）[ 5 ] [ 41 ] [ 42 ] [ 41 ] [ 43 ]ブロックサイズを選択可能 [ 44 ] 完全一致型の整数4×4空間ブロック変換により、従来のコーデック設計でよく見られた「リンギング」をほとんど発生させることなく、 残留 信号を正確に配置できます。これは、以前の規格で使用されていた標準的なDCTに似ていますが、ブロックサイズが小さく、単純な整数処理を使用します。以前の規格（H.261やMPEG-2など）で表現されていたコサインベースの式や許容誤差とは異なり、整数処理により、正確に指定された復号結果が得られます。 8×8の完全一致整数空間ブロック変換により、相関の高い領域を4×4変換よりも効率的に圧縮できます。この設計は標準的なDCTをベースにしていますが、簡略化されており、指定されたデコードを正確に実行できるように設計されています。 整数変換演算において、4×4と8×8の変換ブロックサイズ間でエンコーダを適応的に選択する。 一次空間変換の「DC」係数に対して二次アダマール変換 をクロマDC係数（および特殊なケースではルマ）に適用し、滑らかな領域でさらに圧縮率を高める。 ロスレス マクロブロック符号化機能には以下が含まれます。 ビデオデータサンプルを直接表現するロスレス「PCMマクロブロック」表現モード[ 45 ] 特定の領域を完全に表現できる、拡張されたロスレスマクロブロック表現モード。通常、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) のようにヘッダーの重複をなくすことです。[ 46 ] [ 46 ] [ 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ビットのサンプルビット深度精度をサポートします。 個々のカラープレーンを、独自のスライス構造、マクロブロックモード、モーションベクトルなどを持つ個別の画像としてエンコードする機能により、エンコーダをシンプルな並列化構造で設計することが可能になります（4:4:4対応の3つのプロファイルでのみサポート）。 画像順序カウントとは、デコードされた画像内の画像の順序とサンプル値をタイミング情報から分離する機能であり、デコードされた画像の内容に影響を与えることなく、システムがタイミング情報を個別に伝送、制御、変更することを可能にする。 これらの技術は、他のいくつかの技術と相まって、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フォーマットを使用する標準解像度デジタルTV放送に使用されます。[ 49 ] ハイプロファイル（HiP、100） 放送およびディスクストレージ用途、特に高精細テレビ用途向けの主要なプロファイル（例えば、 Blu-ray Disc ストレージフォーマットやDVB HDTV放送サービスで採用されているプロファイル）。プログレッシブ・ハイプロファイル（PHiP、制約セット4で100） ハイプロファイルに似ていますが、フィールドコーディング機能はサポートされていません。 制約付きハイプロファイル（制約セット4および5で100） プログレッシブハイプロファイルに似ていますが、B（バイプレディクティブ）スライスはサポートしていません。 ハイ10プロファイル（Hi10P、110） このプロファイルは、一般的な消費者向け製品の機能を超え、ハイプロファイルをベースに、デコードされた画像の精度をサンプルあたり最大10ビットまでサポートする機能を追加しています。 ハイ4 ｜ 2 ｜ 2プロファイル（Hi422P、122） 主にインターレースビデオを使用するプロフェッショナルアプリケーションを対象としたこのプロファイルは、High 10プロファイルをベースに、4:2:2クロマサンプリング フォーマットのサポートを追加し、デコードされた画像精度をサンプルあたり最大10ビットまで使用できるように拡張されています。 高4 ｜ 4 ｜ 4予測プロファイル（Hi444PP、244） このプロファイルはHigh 4:2:2プロファイルをベースに構築されており、最大4:4:4クロマサンプリング、サンプルあたり最大14ビットをサポートし、さらに効率的なロスレス領域符号化と、各画像を3つの独立したカラープレーンとして符号化することをサポートしています。 カムコーダー、編集、およびプロフェッショナル用途向けに、この規格にはフレーム内のみ のプロファイルが4つ追加されており、これらは対応する他のプロファイルの単純なサブセットとして定義されています。これらは主にプロフェッショナル用途（カメラや編集システムなど）向けです。
高10イントラプロファイル（制約セット3の場合110） High 10 Profileは、Intraでの使用に限定されます。 高4 | 2 | 2 イントラプロファイル（制約セット3の場合122） ハイ4:2:2プロファイルは、イントラでの使用に限定されます。 高4 | 4 | 4 イントラプロファイル（制約セット3の場合244） ハイ4:4:4プロファイルは、Intraでの使用に限定されます。 CAVLC 4 | 4 | 4 イントラプロファイル (44) High 4:4:4 プロファイルは、イントラでの使用と CAVLC エントロピー符号化に限定されます (つまり、CABAC はサポートされません)。 スケーラブルビデオコーディング （SVC）拡張機能の結果として、この規格には5つの追加のスケーラブルプロファイル が含まれています。これらは、ベースレイヤー用のH.264/AVCプロファイル（スケーラブルプロファイル名の2番目の単語で識別されます）と、スケーラブル拡張機能を実現するツールの組み合わせとして定義されています。
スケーラブルなベースラインプロファイル（83） 主にビデオ会議、モバイル、監視アプリケーションを対象としたこのプロファイルは、ベースレイヤー（ビットストリームのサブセット）が準拠しなければならない制約付きベースラインプロファイルを基盤としています。スケーラビリティツールについては、利用可能なツールのサブセットが有効になっています。 スケーラブルな制約付きベースラインプロファイル（制約セット5の場合83） 主にリアルタイム通信アプリケーション向けに設計された、スケーラブルベースラインプロファイルのサブセット。 拡張性の高いハイプロファイル（86） 主に放送およびストリーミングアプリケーションを対象としたこのプロファイルは、ベースレイヤーが準拠しなければならないH.264/AVCハイプロファイルを基盤として構築されています。 スケーラブルな制約付きハイプロファイル（制約セット5で86） スケーラブル・ハイプロファイルのサブセットであり、主にリアルタイム通信アプリケーション向けに設計されている。 スケーラブルな高イントラプロファイル（制約セット3で86） 主に本番環境向けアプリケーションを対象としたこのプロファイルは、イントラネットワークでの使用に限定されたスケーラブルなハイプロファイルです。 マルチビュービデオコーディング （MVC）拡張機能の結果として、この規格には2つのマルチビュープロファイル が含まれています。
ステレオハイプロファイル（128） このプロファイルは、2視点立体視 3Dビデオを対象としており、ハイプロファイルのツールと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 [ 26 ]
例えば、幅が 1,920 サンプルの HDTV 画像の場合 (PicWidthInMbs = 120 ）と1,080サンプル高（フレームの高さ（MB）= 68 ）、レベル4デコーダの最大DPBストレージ容量はfloor(32768/(120*68)) = 4フレーム（または8フィールド）。したがって、上記の表のレベル4（フレームサイズ1920×1080）の行の右列に、値4が括弧で囲んで表示されています。
現在復号中の画像は、 DPBの容量計算には含まれません （エンコーダが他の画像の復号用参照として、または出力タイミングの遅延のために保存するように指定している場合を除く）。したがって、デコーダは、上記で計算されたDPBの最大容量よりも（少なくとも）1フレーム多く処理できるだけの十分なメモリ容量を実際に備えている必要があります。
実装 H.264 AVC と Opus を表示する YouTube 統計。レンダリング用にアップロードされた YouTube 用の H.264 高画質は最大 1080p 60fps です。 2009 年、HTML5 ワーキンググループは、 特許に縛られていないと考えられている無料のビデオ フォーマットである Ogg Theora の支持者と、特許技術を含む H.264 の支持者に分かれました。2009 年 7 月の時点では、Google と Apple は H.264 をサポートし、Mozilla と Opera は Ogg Theora をサポートしていると言われていました (最終的には、Google、Mozilla、Opera のすべてがVP8 を使用した Theora とWebM を サポートしましたが、 Theora のサポートは2023 [ 51 ] [ 52 ] Microsoft まし た 。[ 53 ] [ 54 ]
2012年3月18日、Mozillaは モバイルデバイス上のFirefoxでH.264のサポートを発表しました。これは、H.264エンコードされたビデオが普及していることと、そのようなデバイスで一般的な専用のH.264デコーダハードウェアを使用することで電力効率が向上するためです。[ 55 ] [ 56 ] [ 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 ] Brendan Eich 氏は、プラットフォーム コーデックが利用できない場合に Firefox に H.264 のサポートを追加するために、将来の Firefox バージョンで Cisco のバイナリを使用する予定であると書いた。[ 61 ] [ 62 ]
2013年のCiscoソフトウェアリリースではiOSはサポートされていませんでしたが、AppleはiOS 8 （2014年9月リリース）でVideo Toolbox Frameworkを更新し、ハードウェアベースのH.264/AVCビデオエンコードとデコードに直接アクセスできるようにしました。[ 59 ]
ハードウェア H.264のエンコードとデコードには特定の算術演算にかなりの計算能力が必要となるため、汎用CPU上で動作するソフトウェア実装は一般的に電力効率が劣ります。しかし、2016年頃から登場した6コアまたは8コアのコンシューマー向けCPU、および2020年1月時点のクアッドコア汎用x86 CPUは、リアルタイムSDおよびHDエンコードを実行するのに十分な計算能力を備えています。圧縮効率は、ハードウェア実装かソフトウェア実装かではなく、ビデオアルゴリズムの実装に依存します。したがって、ハードウェアベースの実装とソフトウェアベースの実装の違いは、電力効率、柔軟性、およびコストにあります。電力効率を向上させ、ハードウェアのフォームファクタを縮小するために、エンコードまたはデコード処理全体、あるいはCPU制御環境内でのアクセラレーション支援のために、専用ハードウェアが使用される場合があります。
CPUベースのソリューションは、特に複数のフォーマット、複数のビットレート、解像度（マルチスクリーンビデオ ）で同時にエンコードする必要がある場合や、コンテナフォーマットのサポート、高度な統合広告機能などの追加機能が必要な場合に、はるかに柔軟性が高いことが知られています。CPUベースのソフトウェアソリューションは、一般的に、同じCPU内で複数の同時エンコードセッションの負荷分散をはるかに容易にします。
2011年1月のCES（コンシューマー・エレクトロニクス・ショー ）で発表された第2世代インテル 「サンディブリッジ 」Core i3/i5/i7プロセッサは、 インテルクイックシンクビデオ として知られるオンチップハードウェアフル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 ]
テキサス・インスツルメンツは、1080p 30 fps の DSP H.264 BP エンコードを実行する ARM + DSP コアのラインを製造しています 。[ 71 ]
ライセンス ソフトウェアアルゴリズムの特許が 認められている国では、H.264/AVCを使用する製品のベンダーや商用ユーザーは、製品で使用されている特許技術に対して特許使用料を支払うことが求められます。[ 72 ] [ 73 ]
Via-LA として知られる民間組織が、この規格に適用される特許のライセンス、および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 ] [ 77 ] [ 78 ]
規格の最初のバージョンが2003年5月に完成して以来（23 年前）であり、最も一般的に使用されているプロファイル（ハイプロファイル）は2004年6月に完成しました（22 年前）、関連する特許のいくつかはすでに期限切れになっているが[ 75 ] [ 79 ]
2005年、クアルコムは米国地方裁判所でブロードコムを提訴し、ブロードコムがH.264ビデオ圧縮規格に準拠した製品を製造することで、自社の特許2件を侵害したと主張した。[ 80 ] [ 80 ] [ 80 ]
2023年10月、ノキアは 米国、英国、その他の地域でH.264/H.265特許侵害でHP とアマゾン を提訴した。 [ 81 ]
2026年2月、VIAライセンス機関は、h264仕様のバージョン4以降に適用されるビデオストリーミングを対象とした新しいライセンス制度を発表しました。[ 82 ]
参考文献 ↑ MPEG-4、高度ビデオ符号化（パート10）（H.264） （完全草稿）。デジタルフォーマットの持続可能性。ワシントンDC：米国議会図書館。2011年12月5日。 2021年 12月1日 取得 。↑ 「H.264 : 汎用オーディオビジュアルサービス向け高度ビデオコーディング」 。www.itu.int 。 2019 年10月31日にオリジナルから アーカイブ 。 2019年 11月22日 に取得。 ↑ 「ビデオ開発者レポート 2024/2025」 （PDF） 。Bitmovin 。 2024年12月。 ↑ 「AVC/H.264を使用した8Kの配信」 。 ミステリーボックス 。 2021年3月25日の オリジナルからアーカイブ済み 。 2017年 8月23日 取得。 1 2 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 . ↑ Ozer, Jan (2023年5月8日)、「 Via LAのHeath Hoglund氏がMPEG LA/Via Licensingの特許プール合併について語る」 、StreamingMedia.com ↑ 「ITU-T勧告」 。 ITU 。 2022 年 11 月 1 日 に取得 。 ↑ 「H.262 : 情報技術 - 動画及び関連する音声情報の汎用符号化: ビデオ」 。 2007年 4月15日 取得 。 ↑ ITU-T 合同ビデオチームウェブサイト。 ↑ 「ITU-T 勧告 H.264 (05/2003)」 。 ITU。 2003 年 5 月 30 日 。 2013 年 4 月 18 日 に取得 。 ↑ 「ITU-T 勧告 H.264 (05/2003) Cor. 1 (05/2004)」 。 ITU。 2004 年 5 月 7 日 。 2013 年 4 月 18 日 に取得 。 ↑ 「ITU-T 勧告 H.264 (03/2005)」 。 ITU。 2005 年 3 月 1 日 。 2013 年 4 月 18 日 に取得 。 ↑ 「ITU-T 勧告 H.264 (2005) Cor. 1 (09/2005)」 。 ITU。 2005 年 9 月 13 日 。 2013 年 4 月 18 日 に取得 。 1 2 「ITU-T勧告H.264（2005）改正1（06/2006）」 。ITU。2006年6月13日。 2013年 4月18日 取得 。 ↑ 「ITU-T勧告H.264（2005）改正2（04/2007）」 。ITU。2007年4月6日。 2013年 4月18日 取得 。 ↑ 「ITU-T 勧告 H.264 (2007 年 11 月)」 。 ITU。 2007 年 11 月 22 日 。 2013 年 4 月 18 日 に取得 。 ↑ 「ITU-T 勧告 H.264 (2007) Cor. 1 (01/2009)」 。 ITU。 2009 年 1 月 13 日 。 2013 年 4 月 18 日 に取得 。 1 2 「ITU-T 勧告 H.264 (03/2009)」 。 ITU。 2009 年 3 月 16 日 。 2013 年 4 月 18 日 に取得 。 1 2 「ITU-T 勧告 H.264 (03/2010)」 。 ITU。 2010 年 3 月 9 日 。 2013 年 4 月 18 日 に取得 。 1 2 「ITU-T 勧告 H.264 (06/2011)」 。 ITU。 2011 年 6 月 29 日 。 2013 年 4 月 18 日 に取得 。 ↑ 「ITU-T 勧告 H.264 (01/2012)」 。 ITU。 2012 年 1 月 13 日 。 2013 年 4 月 18 日 に取得 。 1 2 3 4 「ITU-T 勧告 H.264 (04/2013)」 。 ITU。 2013 年 6 月 12 日 。 2013 年 6 月 16 日 に取得 。 1 2 「ITU-T勧告H.264（02/2014）」 。ITU。2014年11月28日。 2016年 2月28日 取得 。 ↑ 「ITU-T勧告H.264（02/2016）」 。ITU。2016年2月13日。 2017年 6月14日 取得 。 ↑ 「ITU-T 勧告 H.264 (10/2016)」 。 ITU。 2016 年 10 月 14 日 。 2017 年 6 月 14 日 に取得 。 1 2 3 「ITU-T勧告H.264（04/2017）」 。ITU。2017年4月13日。表A-1、A-6、A-7に、レベル依存機能の表を示します。 2017年 6月14日 取得 。 ↑ 「H.264: 汎用オーディオビジュアルサービス向け高度ビデオコーディング - バージョン 26 (エディション 13)」 。 www.itu.int 。2019年6月13日。 2021年11月4日にオリジナルから アーカイブ 。 2021年 11月3日 に取得。 ↑ 「H.264: 汎用オーディオビジュアルサービス向け高度ビデオコーディング - バージョン 27 (エディション 14)」 。 www.itu.int 。2021年8月22日。 2021年11月4日のオリジナルから アーカイブ。 2021年 11月3日 取得 。 ↑ 「H.264: 汎用オーディオビジュアルサービス向け高度ビデオコーディング - バージョン28（第15版）」 。 www.itu.int 。2024年8月13日。 2025年 2月12日 取得 。 ↑ Wenger; et al. (2005 年 2 月). "RFC 3984 : H.264 ビデオの RTP ペイロード フォーマット" . Ietf Datatracker : 2. doi : 10.17487/RFC3984 . ↑ 「どの録画モードが高解像度ビデオ（HDV）フォーマットの画質に相当しますか？」 。 ソニーeサポート 。 2017年11月9日に オリジナル からアーカイブ 。 2018年 12月8日 に取得。 ↑ 「ATSC規格A/72パート1：ATSCデジタルテレビシステムにおけるAVCのビデオシステム特性」 （PDF） 。 2011年8月7日に オリジナル （PDF） からアーカイブ。 2011年 7月30日 に取得 。 ↑ 「ATSC規格A/72パート2：AVCビデオ伝送サブシステム特性」 （PDF） 。 2011年8月7日に オリジナル （PDF） からアーカイブ。 2011年 7月30日 に取得 。 ↑ 「ATSC規格A/153パート7：AVCおよびSVCビデオシステム特性」 （PDF） 。 2011年7月26日に オリジナル （PDF） からアーカイブ。 2011年 7月30日 に取得 。 1 2 「ソニー、プロフェッショナル市場とコンシューマー市場における4K開発を加速させる新記録フォーマットXAVCを発表」 ソニー。2012年10月30日。 2012年 11月1日 閲覧 。 1 2 「ソニー、プロフェッショナル市場とコンシューマー市場における4K開発を加速させる新記録フォーマットXAVCを発表」 (PDF) 。ソニー。2012年10月30日。 2023年3月23日に オリジナル (PDF)からアーカイブ。 2012年 11月1日 に取得 。 ↑ Steve Dent (2012年10月30日) 「ソニー、PMW-F55とPMW-F5 pro CineAlta 4K Super 35mmセンサーカムコーダーでRedを狙う」 Engadget 。 2012年 11月5日 閲覧 。 ↑ 「F55 CineAlta 4K 未来を先取り」 （PDF） 。ソニー。2012年10月30日。 2012年11月19日に オリジナル （PDF）からアーカイブ 。 2012年 11月1日 に取得。 ↑ 「超高速「SxS PRO+」メモリーカードが4Kビデオ撮影を変革」 。ソニー。 2013年3月8日の オリジナルからアーカイブ 。 2012年 11月5日 取得。 ↑ 「超高速「SxS PRO+」メモリーカードが4Kビデオ撮影を変革」 （PDF） 。ソニー。 2015年4月2日に オリジナル （PDF）からアーカイブ 。 2012年 11月5日 に取得。 1 2 Stanković, Radomir S.; Astola, Jaakko T. (2012). "DCTにおける初期の研究の回想：KR Raoへのインタビュー" (PDF) . Reprints from the Early Days of Information Sciences . 60 : 17 . 2019年 10月13日 取得 . ↑ クォン・スンヨン、イ・ジュギョン、チョン・キドン (2005)「MPEG-2/H.264トランスコーディングのためのハーフピクセル補正」 Image Analysis and Processing – ICIAP 2005. Lecture Notes in Computer Science. Vol. 3617. Springer Berlin Heidelberg. pp. 576–583 . doi : 10.1007/11553595_71 . ISBN 978-3-540-28869-5 。↑ Britanak, Vladimir; Yip, Patrick C.; Rao, KR (2010). Discrete Cosine and Sine Transforms: General Properties, Fast Algorithms and Integer Approximations . Elsevier . pp. ix, xiii, 1, 141–304 . ISBN 9780080464640 。↑ Thomson, Gavin; Shah, Athar (2017). "Introducing HEIF and HEVC" (PDF) . Apple Inc. 2019年 8月5日 取得 。 ↑ 「H.264/AVC 高度ビデオ符号化規格：概要と忠実度範囲拡張の紹介」 （PDF） 。 2011年 7月30日 取得 。 1 2 3 RFC 3984、p.3 ↑ Apple Inc. (1999年3月26日)。 「H.264 FAQ」 。Apple。 2010年3月7日の オリジナルからアーカイブ 。 2010年 5月17日 取得。 ↑ Karsten Suehring. "H.264/AVC JM リファレンス ソフトウェア ダウンロード" . Iphome.hhi.de . 2010 年 5 月 17 日 取得. ↑ 「TS 101 154 – V1.9.1 – デジタルビデオ放送（DVB）；MPEG-2トランスポートストリームに基づく放送アプリケーションにおけるビデオおよびオーディオコーディングの使用に関する仕様」 （PDF） 。 2010年 5月17日 取得 。 ↑ 「HTML 5 ビデオコーデック論争の解読」 . Ars Technica . 2009 年 7 月 6 日. 2011 年 1 月 12 日 取得 . ↑ 「Theora サポートの削除を調査する」 。Bugzilla。2023 年 10 月 23 日 。2026 年 2 月 3 日 取得 。 ↑ 「Google ChromeがTheoraのサポートを終了」 。Phoronix 。 2023年11月1日。 2026年 2月3日 閲覧 。 ↑ 「マイクロソフトCEOのスティーブ・バルマー氏、ガートナーシンポジウム/ITxpoオーランド2010でのインタビュー」 。ガートナービデオ。2010年11月。 2021年10月30日に オリジナルからアーカイブ 。 2011年 1月12日 に取得。 ↑ 「Chrome での HTML ビデオ コーデックのサポート」 。2011 年 1 月 11 日。2011 年 1 月 12 日 に取得 。 ↑ 「ビデオ、モバイル、そしてオープンウェブ」 。2012年3月18日。 2012年 3月20日 取得 。 ↑ 「WebRTC が有効化、Windows 7 で H.264/MP3 がデフォルトでサポート、Windows 8 に Metro UI を追加 - Firefox 開発ハイライト」 。hacks.mozilla.org。mozilla。2013年 2 月 20 日。2013 年 3 月 15 日 取得 。 ↑ 「Firefox — ノート (35.0)」 。 Mozilla 。 ↑ 「オープンソースのH.264がWebRTCの障壁を取り除く」 。2013年10月30日。 2015年7月6日の オリジナル からアーカイブ 。 2013年 11月1日 に取得。 1 2 「Cisco OpenH264 プロジェクト FAQ」 。2021 年 9 月 26 日 に取得。 ↑ 「OpenH264 Simplified BSD License」 . GitHub . 2013年10月27日. 2013年 11月21日 取得 . ↑ 「シスコのH.264コーデックにより、Web上のビデオ相互運用性が向上」 2013年10月30日 2013年 11月1日 閲覧 . ↑ "READMEを更新しました · cisco/openh264@59dae50" . GitHub . ↑ 「x264 4:0:0 (モノクロ) エンコーディングのサポート」、2019年6月5日取得。 ↑ 「x264 4:2:2 エンコーディングのサポート」、2019年6月5日取得。 ↑ 「x264 4:4:4 エンコーディングのサポート」、2019年6月5日取得。 ↑ 「x264の9ビットおよび10ビットエンコーディングのサポート」、2011年6月22日取得。 ↑ "x264 で High 4:4:4 profile lossless を High 4:4:4 Predictive に置き換える"、2011-06-22 に取得。 ↑ 「Intel Coreプロセッサー内蔵ビジュアルの生成に関するクイックリファレンスガイド」 。Intel Software Network。2010年10月1日。 2011年 1月19日 取得 。 ↑ 「Intel Quick Sync Video」 。www.intel.com。2010年10月1日。 2011年 1月19日 取得 。 ↑ "Design-reuse.com" . Design-reuse.com. 1990年1月1日. 2010年 5月17日 取得 . ↑ "カテゴリ:DM6467 - Texas Instruments Embedded Processors Wiki" . Processors.wiki.ti.com. 2011年7月12日。 2011年7月17日の オリジナルからアーカイブ済み 。 2011年 7月30日 取得。 ↑ 「ブリーフィングポートフォリオ」 （PDF） 。www.mpegla.com 。 2016年11月28日に オリジナル （PDF） からアーカイブ済み 。 2016年 12月1日 に取得。 ↑ 「OMS Video、サン・マイクロシステムズのオープンメディアコモンズイニシアチブのプロジェクト」 。 2010年5月11日に オリジナルからアーカイブ済み 。 2008年 8月26日 に取得。 ↑ 「AVC/H.264特許ポートフォリオライセンスに含まれるライセンサー」 。MPEG LA 。 2021年10月11日に オリジナル からアーカイブ済み 。 2019年 6月18日 に取得。 1 2 「AVC/H.264 – 特許リスト」 。Licensing Alliance 経由 。2024 年 4 月 28 日 に取得。 ↑ 「MPEG LAのAVCライセンスは、ライセンス期間中エンドユーザーが無料で利用できるインターネットビデオに対してロイヤリティを請求しません」 （PDF） 。MPEG LA。2010年8月26日。 2013年11月7日に オリジナル （PDF） からアーカイブ。 2010年 8月26日 に取得 。 ↑ ハックマン、マーク（2010年8月26日）。 「MPEG LA、無料ウェブビデオのロイヤリティを永久に削減」 。pcmag.com 。 2010年 8月26日 取得 。 ↑ 「AVC FAQ」 。MPEG LA。2002年8月1日。 2010年5月7日に オリジナルからアーカイブ済み 。 2010年 5月17日 に取得。 ↑ 「米国特許第9,356,620号 Baese 他」 。 2022年 8月1日 取得 。 1 2 3 クアルコム社対ブロードコム社事件 、事件番号2007-1545、2008-1162（連邦巡回控訴裁判所、2008年12月1日）を 参照。一般メディアの記事については、signonsandiego.comの「クアルコム、特許権訴訟で敗訴」および「クアルコムの特許訴訟、陪審裁判へ」、bloomberg.comの「ブロードコム、クアルコム特許紛争で初審に勝利」を参照。 ↑ 「nokia h264」 。 ↑ 「AVC/H264 必須性の概要」 。Licensing Alliance 経由。2026 年 4 月 8 日 取得 。
さらに読む 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 . 2011 年 4 月 29 日にオリジナル(PDF)からアーカイブ済み。2011 年 1 月 31 日に 取得 。 Topiwala, Pankaj; Sullivan, Gary J.; Luthra, Ajay (2004 年 8 月)。Tescher, Andrew G (編)。「H.264/AVC 高度ビデオ符号化規格: 概要と忠実度範囲拡張の紹介」(PDF) 。SPIE Applications of Digital Image Processing XXVII。Applications of Digital Image Processing XXVII。5558 : 454。Bibcode : 2004SPIE.5558..454S。doi : 10.1117 / 12.564457。S2CID 2308860。2011年 1 月 日 取得 。 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を参照してください） Puri, Atul; Chen, Xuemin; Luthra, Ajay (2004年10月) 「H.264/MPEG-4 AVC圧縮規格を用いたビデオ符号化」(PDF) . Signal Processing: Image Communication . 19 (9): 793– 849. doi : 10.1016/j.image.2004.06.003 . 2011年3月30日 取得. Sullivan, Gary J.; Wiegand, Thomas (2005 年 1 月). "ビデオ圧縮 ― 概念から H.264/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日 取得. 「出版物」 . デトレフ・マルペ. 2007年 4月15日 取得 。 「第4回H.264ビデオコーデック比較」。モスクワ州立大学。 「セキュリティおよび監視業界で使用されているIPカメラに関するH.264についての議論」。2009年4月3日。 「第6回H.264ビデオコーデック比較」。モスクワ国立大学 。 「SMPTEクイックガイド」など。2018年5月14日。 「AVC/H264 必須性の概要」。Licensing Alliance 経由。2026 年 4 月 8 日 取得 。
