H.264
H.264（エイチにろくよん）、MPEG-4 AVC（エムペグフォーエーブイシー）は、動画圧縮規格の一つ。
ITU-Tでは「H.264」として、2003年初めに勧告された。ISO/IECでは、ISO/IEC 14496-10「MPEG-4 Part 10 Advanced Video Coding（通称：MPEG-4 AVC）」として規定されている。どちらも技術的には同一のものであり、ITU-TとISO/IECが共同で策定したため、両者の呼称を「H.264/MPEG-4 AVC」「MPEG-4 AVC/H.264」と併記することが多い。規格文書では「ITU-T Rec. H.264 | ISO/IEC 14496-10 Advanced Video Coding」と縦線で区切られているため、「H.264|MPEG-4 AVC」などとすることもある。主にソフトウェア内部の識別子として「AVC1」も使われている。
従来方式であるMPEG-2などの2倍以上の圧縮効率を実現する。携帯電話などの低ビットレート用途から、HDTVクラスの高ビットレート用途に至るまで幅広く利用されることを想定している。
圧縮アルゴリズムの原理は、従来方式のMPEG-1、MPEG-2、H.261、H.263、MPEG-4などと基本的には同様で、空間変換やフレーム間予測、量子化、エントロピー符号化を採用している。H.264ではこれらのツールに対して非常に多数の改良が施されており、算術符号化やフィルタなどのツールも追加されている。さらに、画像特徴に応じて多彩なモードを適応的に使い分けることで、従来方式をはるかにしのぐ圧縮効率を達成している。
従来規格のMPEG-1、MPEG-2やH.261では16×16画素、H.263、MPEG-4では8×8画素のブロック（マクロブロック）を単位として、原画像ないしフレーム間予測の予測誤差画像の離散コサイン変換 (DCT) 係数を求め、その係数を量子化している。このとき、コサイン関数を用いるため、実数精度の演算が必要となる。これに対しH.264では、16ビット整数精度で演算が可能な整数変換を採用している。この整数変換は、加減算とビットシフトのみによって演算可能となるように設計されているため、ソフトウェア、ハードウェアいずれの場合でも実装が非常に容易となる。
演算がすべて整数精度で行われることで、実数演算の実装差による「デコーダごとの演算結果の差分」を生じさせることなくエンコードすることが可能となった。これは、エンコード時の局部復号器の結果とすべてのデコーダでの出力結果が全く同一になることを意味している。エンコード時の局部復号器の結果とデコーダの出力結果が異なる場合、エンコーダが作成する再構成画像とデコーダが作成する再構成画像が異なることとなるため、フレームが経過するごとに画像にノイズが蓄積してしまう。これを回避するため従来技術ではそのDCT演算誤差の帳消しのために定期的にイントラマクロブロックを挿入する必要があった。H.264では整数変換を用いており誤差の問題が生じないため、定期的にイントラマクロブロックを挿入する必要がない。
デコーダの実装差による出力結果の違いが生じないことは、デコーダの規格適合性を検証する上でも有利となる。H.264の関連規格であるH.264.1はH.264規格適合性の検証手法を定めるもので、H.264で符号化済の試験用ビットストリームとそのデコード結果の組が多数付属している。開発中のデコーダに試験用ビットストリームを入力し、その出力結果とH.264.1付属のデコード結果が厳密に一致しているかどうかを確かめることで、規格適合性の判断を行うことができる。
当初、H.264で使用可能な整数変換のブロックサイズは4×4画素のみだった。このサイズでは、低解像度の動画の圧縮では比較的好適な画質を示すが、HDTVなどのような高解像度の動画で画質の再現性に弱いという問題点があった。そのため、後に導入されたプロファイル群では、これを克服するために8×8サイズの整数変換が導入されている。これらのプロファイルでは、フレーム内で4×4変換と8×8変換を適応的に切り替えて使用することができる。
従来技術では、フレーム間予測で参照フレームとして指定できるフレームは、Pフレームについては直前のI, Pフレーム、Bフレームについては直前および直後のI, Pフレームに固定されている。
H.264では、複数の参照フレームを持つことによって、例えばシーンチェンジや移動物体を考慮してより前のフレームを参照フレームとして指定することが可能となっている。また、Bフレームについては未来方向のフレームを使わずに過去の2フレームを参照フレームとして指定したり、別のBフレームを参照フレームとして指定することが可能となっている。
複数参照フレームの導入に伴いIフレームより前のフレームも参照可能となっている。この場合、Iフレームから再生を開始しようとしても、後続のフレームが、再生を開始しようとするIフレームより前のフレームの情報を必要とすることがある。このため、H.264ではIフレームから再生を開始することができるとは限らない。この問題を解決するため、参照フレームが格納されているバッファのクリアを行うことでそのフレームから再生が可能であることを保証する、IDR (Instantaneous Decoder Refresh) フレームが導入されている。すなわち、P, BフレームはIDRフレームをまたいで参照フレームを指定することができないように定められている。
従来技術では、動き補償の単位は16×16画素のマクロブロックが基本であり、H.263およびMPEG-4においては8×8画素ブロック単位の動き補償も利用できた。
H.264ではさらに単位ブロックサイズを追加し、16×16, 16×8, 8×16, 8×8の4種類から選択可能となっている。さらに、8×8画素ブロックについては、8×8, 8×4, 4×8, 4×4の4種類のサブブロック分割も指定できる。
このように多数のブロックサイズを利用することで、形状や動きに適したブロックから予測が可能である。これは、原理的には符号化効率が上がることとなる。ただし、サブブロックを指定することは余分なヘッダが付加されることになり、これがオーバーヘッドとなって符号化効率に影響を与える可能性もある。シーンに適した動き補償ブロックサイズを選択することが、エンコーダには求められる。
H.264では、従来方式では画質向上が困難だったフェードやディゾルブなどの特殊効果が用いられている動画の画質向上のため、参照フレームの予測誤差に重み付け係数を掛けてデコードする、重み付け予測 (Weighted Prediction) が採用されている。フェードやディゾルブは、前フレームと現フレームで一定のオフセットがかかったような画像であるため、そのことで予測差分に大きな値が生じることとなり、MPEG-4などでは画質劣化の原因として問題となっていた。
動き補償の精度としては、MPEG-4 ASPで導入された1/4画素精度（クォーターペル精度）動き補償を使用している。ゆっくり動くパンなどで特に効果的である。1/2画素精度動き補償では6tapフィルターを用いて高周波まで再現を行っており、MPEG-4で使用された線形補間よりも再現性が良くなっている。1/4画素の生成は、再現性の高い1/2画素を用いてその線形補間で作成を行う。
H.264では、フレーム間予測を用いないマクロブロックに対して、上や左などに隣接するマクロブロックの隣接画素から補間によって予測画像を生成し、その予測画像との差分を符号化する、イントラ予測 (Intra prediction) が採用されている。予測画像の生成単位となるブロックサイズは、輝度 (Y) 成分については4×4および16×16画素の2種類であり、色差 (Cb, Cr) 成分の8×8画素については8×8画素単位の1種類である。また、予測画像生成における補間パターンは、輝度成分の4×4単位の場合は9種類、輝度成分の16×16単位および色差成分の場合は4種類が利用できる。
さらに、ハイプロファイル以上のプロファイル（後述）では、8×8画素単位のイントラ予測も利用可能である。補間パターンは4×4の場合と同様の9種類が利用できる。なお、8×8、4×4の場合は、整数変換も同じ行列サイズに固定される。
MPEG-4で導入されているAC/DC予測では、予測する係数がDCT係数の行列のうちの最上列ないし最左行の係数に限られているため、縦方向ないし横方向の画素変化に対してしか予測効率を高めることができない。これに対して、H.264のイントラ予測ではDCT係数ではなく画素レベルでの予測を行い、かつ縦・横方向以外にも斜め方向の画素予測パターンも利用できるため、予測効率が大幅に向上している。
H.264では、ハフマン符号をベースとした可変長符号化 (VLC; Variable Length Coding) と、算術符号化のいずれかを選択できる。
前者はBaseline Profileで採用され、従来の3次元VLCに近いCAVLC (Context-based Adaptive VLC) と、指数ゴロム (Exponential-Golomb) 符号を用いることによって変換テーブルを用いずに符号化するUVLC (Universal VLC) が用いられる。CAVLCでは隣接MBのDCT係数の状態に依存して現在のMBの符号化に使用する符号化テーブルを切り替える。このように切り替えを行うことで、現在の画像のテクスチャに応じた符号化テーブルが使用でき、より短い符号への圧縮が期待できる。
後者はCABAC (Context-based Adaptive Binary Arithmetic Coding) と呼ばれ、Main Profileで採用されている。
H.264ではこのように複数の符号化方式が用いられている。これは、処理量は少ないが効果もそこそこのCAVLCと、処理量は大きいが効果も高いCABACではその用途が異なるため、そのことによって「符号化」という同じ目的を持ったツールが複数存在することとなった。
H.264では、かつてH.261で採用されたループ内フィルタ (In-loop Filter) と似たように、ループ内にデブロッキングフィルタ (Deblocking Filter) が設置されている。このフィルタはH.261のようなブロック全体の平滑化フィルタではなく、整数変換のブロック境界のみを平滑化してブロックノイズの発生を抑制するものである。H.261のループ内フィルタは、MPEG-2以降で採用された半画素精度動き補償が数学上同等の役割を果たすため、その意味を失った。
デブロッキングフィルタは圧縮率向上のためには効果的であるが処理量が大きいために、そのON/OFFがヘッダによって指定可能とされている。したがって、処理量に懸念がある場合にはデブロッキングフィルタを使用しないといった選択肢も可能である。
例えば番組のチャンネルを切り替えたり、再生の途中でプレビューを見ながら早送りしたりする場合のように、ある動画ストリームから途中で別のストリームに切り替えて再生する場合、次のストリームの再生はフレーム間予測を用いないIフレームを受信するまでできなくなる。そこでH.264では、切替用の中間フレームとして、SI, SP（SはSwitchingの意）フレームが採用されている。特にSPフレームの場合は、切替前の動画のフレームを参照画像として切替後の動画がデコードできるように符号化される。
H.264のビット列の規則（シンタックス）は、圧縮符号化された画像データをビット列に変換するための規則を定めたVCL (Video Coding Layer) と、VCLやヘッダ情報などのデータを分割および識別するためのNAL (Network Abstraction Layer) の2層構造を持つ。
従来技術では、シンタックスに従って1つの動画を圧縮符号化した場合、1つのビット列（エレメンタリストリーム）となる。これに対し、H.264では複数の種類のNALユニットに分割して符号化される。なお、従来のエレメンタリストリームと同様に1つのビット列として圧縮データを扱うことができるように、バイトストリームフォーマットがAnnex Bで規定されている。
NAL構造によって、MP4などのファイルフォーマットに格納したり、パケットに分割して伝送したりするなど、圧縮データをさまざまな用途に柔軟に適用できるようになっている。
複数の視点（マルチビュー）で撮影された映像を、それぞれのビューを独立して扱うよりも効率的に圧縮することができるマルチビュー符号化 (multi view coding: MVC) が、H.264のバージョン10で追加で規格化されている。MVCではマルチビュー映像を、1個のベースビュー (base view) と、1個以上の非ベースビュー (non-base view) として符号化する。ベースビューは既存のプロファイル（現在ではハイプロファイルのベースビューのみ定義）のストリームとして符号化され、非ベースビューはMVCで新たに拡張されたプロファイルとシンタックスを用いて、他のビューや自分自身のビューに含まれるフレームを参照）ビュー間予測: inter-view prediction）して符号化される。
ビュー間予測を用いることで、ビュー間の相関が利用可能になるほか、非ベースビューでは符号量の大きいIフレームを使用しない符号化が可能となるため、より効率的に圧縮できる。通常のH.264ストリームでは、多くのアプリケーションで必要となるランダムアクセス機能（放送チャンネル切替えやチャプタージャンプのようにストリームの途中から再生する機能）のために、適切な時間間隔でIフレームを挿入しておく必要があった。放送の場合は通常0.5秒程度である。
MVCでもベースビューではそれが当てはまるが、非ベースビューのフレームについては、ベースビューのみを参照するP/Bフレームだけで構成すれば、ベースビューがランダムアクセス可能である限り、その非ベースビューもランダムアクセス可能である。なお、そのように符号化された非ベースビューのみを参照する形で、別の非ベースビューを符号化してもやはりランダムアクセスは可能である。
MVCに対応しない従来のデコーダでもベースビューのプロファイルとレベルを満足すれば、ベースビューのみの再生は可能であり、後方互換性が維持される。非ベースビューについても、使用されている圧縮のツール（アルゴリズム）についてはビュー間予測が可能という点を除き従来のI/P/Bピクチャと同じものを使用するため、デコーダをMVC対応とするのに必要な機能拡張は少ない。ただし、複数のビューをデコードするために、必要な処理速度は単一ビューに比べ増大する。
MVCを使用した場合の圧縮の効率は、2視点のステレオ映像の場合、1視点に比べ50%程度のデータ量の増加で圧縮可能とされている。なお、50%程度という数字はBlu-ray Disc Associationが2009年12月17日に発表したものである。
MPEG-2などと同様、目的用途別に定義された機能の集合を表すプロファイルと、処理の負荷や使用メモリ量を表すレベルが定義がされる。これらは画面解像度やフレームレートに影響する。
H.264に準拠する機器またはビットストリームそのものは、このプロファイルとレベルによって、機器の性能やビットストリームをデコードするのに必要な性能を表示することが多い。
H.264規格では当初ベースラインプロファイル、メインプロファイル、拡張プロファイルのみだった。その後、規格の拡張に伴い種類が増加している。以下では主なものを挙げる。レベル1からレベル5.1まで、16段階が定義されている。それぞれのレベルにおいて、処理の負荷や使用メモリ量等を表すパラメータの上限が定められ、画面解像度やフレームレートの上限を決定している。各パラメータの詳細はを参照のこと。
H.264は下記の放送・規格で採用されている。なお、日本の地上デジタルテレビ放送 (ISDB-T) では、MPEG-2が採用されているが、H.264はISDB-T方式を改良した、ブラジルのSBTVD方式の他、DVB-T方式の一部で採用されている。
また、下記の規格にも映像コーデックのひとつとして採用された。現在、ほとんどの動画共有サービスは、Flash Video (flv) とH.264 (mp4) を使用している。その他、海外スポーツイベントの生中継等でも使用。
H.264には多数の特許権が含まれており、本規格を採用したハードウェア製品やソフトウェア製品を製造する企業は、特許使用料であるパテント料の支払いが求められる。これらのライセンスに関する管理は、パテントプールであるMPEG-LAコンソーシアムが特許権者からの委託を受けて業務を代行している。
"H.264"を採用した製品を購入した消費者は個別に使用料を請求されることはないが、製品価格にそれらのコストが含まれることになる。
2013年10月30日、米Cisco Systemsより、同社によるH.264の実装をオープンソース化、無償でダウンロードできるようにするとの発表。
このオープンソースを利用するにあたりMPEG-LAコンソーシアムへのライセンス料はCiscoが負担する。
BSDライセンスにより公開中。
MPEG-2の2倍以上の圧縮効率を持つとされる動画圧縮規格には、H.264の他にも米マイクロソフト社が開発したVC-1 (Windows Media Video 9) がある。H.264とVC-1は同一ビットレートで同等の画質性能であるという意見がある。PCのウェブブラウザではAdobe Flashを通じて広く利用されている。スマートフォンなどでは動画フォーマットの選択制限が厳しいこともあり、デファクトスタンダードとなっている。
ウェブ表示の次世代規格であるHTML5にはvideo要素で動画再生を行う機能が盛り込まれており、これに使用する動画フォーマットについて、ウェブブラウザベンダーのアップルとマイクロソフトはH.264を推進しているが、Mozilla Foundationとオペラ・ソフトウェア、Googleはロイヤリティが発生する点などを問題視し、積極的な利用に難色を示していた。2016年4月現在では、Safari、Internet Explorer、Mozilla FirefoxはH.264をサポートしているが、Google Chrome、Operaではサポートしていない。
Mozilla FoundationはかつてH.264をサポートしていなかったため、反発した一部の有志が、Mozilla FirefoxにH.264サポートを追加したウェブブラウザを提供することを目的としたプロジェクトを立ち上げた。これはH.264に関する特許が成立していない国のユーザに向けたもので、特許が成立している国のユーザは事実上使うことはできない。2012年、Mozilla FoundationはH.264のサポートを表明した。
マイクロソフトはMozilla FirefoxでH.264を再生できるようにするアドオンを公開している。これは動的にvideo要素をobject要素に書き替えるという力業で実現しており、video要素固有のAPIが利用できなくなるという仕組み上の欠点を抱えている。