「H.264」の版間の差分

削除された内容追加された内容

インライン

2021年5月20日 (木) 11:08時点における版

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などでは画質劣化の原因として問題となっていた。

1/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がヘッダによって指定可能とされている。したがって、処理量に懸念がある場合にはデブロッキングフィルタを使用しないといった選択肢も可能である。

SI, SPフレーム

例えば番組のチャンネルを切り替えたり、再生の途中でプレビューを見ながら早送りしたりする場合のように、ある動画ストリームから途中で別のストリームに切り替えて再生する場合、次のストリームの再生はフレーム間予測を用いないIフレームを受信するまでできなくなる。そこでH.264では、切替用の中間フレームとして、SI, SP（SはSwitchingの意）フレームが採用されている。特にSPフレームの場合は、切替前の動画のフレームを参照画像として切替後の動画がデコードできるように符号化される。

NAL構造

H.264のビット列の規則（シンタックス）は、圧縮符号化された画像データをビット列に変換するための規則を定めたVCL (Video Coding Layer) と、VCLやヘッダ情報などのデータを分割および識別するためのNAL (Network Abstraction Layer) の2層構造を持つ。

従来技術では、シンタックスに従って1つの動画を圧縮符号化した場合、1つのビット列（エレメンタリストリーム）となる。これに対し、H.264では複数の種類のNALユニットに分割して符号化される。なお、従来のエレメンタリストリームと同様に1つのビット列として圧縮データを扱うことができるように、バイトストリームフォーマットがAnnex Bで規定されている。

NAL構造によって、MP4などのファイルフォーマットに格納したり、RTP パケットに分割して伝送したりするなど、圧縮データをさまざまな用途に柔軟に適用できるようになっている。

マルチビュー符号化

複数の視点（マルチビュー）で撮影された映像を、それぞれのビューを独立して扱うよりも効率的に圧縮することができるマルチビュー符号化 (MVC: Multiview Video Coding) が、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規格では当初ベースラインプロファイル、メインプロファイル、拡張プロファイルのみだった。その後、規格の拡張に伴い種類が増加している。以下では主なものを挙げる。

制約付きベースラインプロファイル(Constrained Baseline Profile)

ローコストアプリケーションのためのプロファイル。ビデオ会議やモバイルアプリ等で使用される。

ベースラインプロファイル(Baseline Profile)

I, Pフレームのみ、エントロピー符号化はCAVLC+UVLCのみ。

メインプロファイル(Main Profile)

ベースラインプロファイルにBフレーム、CABAC、重み付け予測などを追加。

拡張プロファイル(Extended Profile)

ベースラインプロファイルにSI, SPフレームなどを追加。

ハイプロファイル(High Profile)

メインプロファイルに8×8画素整数変換、量子化マトリックス等を加えたもの。また、YCbCr 4:0:0色空間（グレースケール）にも対応している。

ハイ 10 プロファイル(High 10 Profile)

ハイプロファイルに10ビット画像フォーマットへの対応を追加したもの。

ハイ 4:2:2 プロファイル(High 4:2:2 Profile)

ハイ10プロファイルにYCbCr 4:2:2色空間への対応を追加したもの。

ハイ 4:4:4 プロファイル(High 4:4:4 Predictive Profile)

ハイ4:2:2プロファイルにYCbCr 4:4:4色空間や12ビット画像フォーマット、YCbCr以外への色空間への変換、可逆圧縮など多数の機能を追加したもの。

マルチビューハイプロファイル(Multiview High Profile)

MVC拡張規格の策定に伴い定義されたプロファイル。ベースビューはハイプロファイルと互換のある符号化を行い、非ベースビューはマルチビュー拡張で定義されたシンタックスで符号化する。最大1024個のビューを符号化できるが、インターレース符号化をサポートしない。

ステレオハイプロファイル(Stereo High Profile)

ステレオ（2視点）映像を想定しており、MVCにおいて、ビューの数を2個以下に制限し、インターレース符号化をサポートするMVC拡張用プロファイル。Blu-ray Discの3D拡張版に採用されている。

プロファイルごとの機能一覧表
Feature	CBP	BP	XP	MP	HiP	Hi10P	Hi422P	Hi444PP
I and P スライス	○	○	○	○	○	○	○	○
YCbCr色空間	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
色深度 (bits)	8	8	8	8	8	8 〜 10	8 〜 10	8 〜 14
Flexible macroblock ordering (FMO)	×	○	○	×	×	×	×	×
任意順序スライス (ASO)	×	○	○	×	×	×	×	×
冗長スライス (RS)	×	○	○	×	×	×	×	×
データ分割	×	×	○	×	×	×	×	×
SI and SP slices	×	×	○	×	×	×	×	×
B スライス	×	×	○	○	○	○	○	○
インターレースコード (PicAFF, MBAFF)	×	×	○	○	○	○	○	○
複数フレーム参照	○	○	○	○	○	○	○	○
In-loop deblocking filter	○	○	○	○	○	○	○	○
CAVLC 符号化	○	○	○	○	○	○	○	○
CABAC 符号化	×	×	×	○	○	○	○	○
8×8 vs. 4×4 適応変換	×	×	×	×	○	○	○	○
Quantization scaling matrices	×	×	×	×	○	○	○	○
Separate C_b and C_r QP control	×	×	×	×	○	○	○	○
グレースケール (4:0:0)	×	×	×	×	○	○	○	○
Separate color plane coding	×	×	×	×	×	×	×	○
予測的可逆エンコード	×	×	×	×	×	×	×	○

レベル

レベル1からレベル5.1まで、16段階が定義されている。それぞれのレベルにおいて、処理の負荷や使用メモリ量等を表すパラメータの上限が定められ、画面解像度やフレームレートの上限を決定している。各パラメータの詳細は英語版を参照のこと。

Levels with maximum property values
Level	最大マクロブロック		最大動画ビットレート (VCL)				解像度例@ フレームレート（ストアされる最大フレーム数）
Level	秒あたり	フレームあたり	BP, XP, MP (kbit/s)	HiP (kbit/s)	Hi10P (kbit/s)	Hi422P, Hi444PP (kbit/s)	解像度例@ フレームレート（ストアされる最大フレーム数）
1	1,485	99	64	80	192	256	128×96@30.9 (8) 176×144@15.0 (4)
1b	1,485	99	128	160	384	512	128×96@30.9 (8) 176×144@15.0 (4)
1.1	3,000	396	192	240	576	768	176×144@30.3 (9) 320×240@10.0 (3) 352×288@7.5 (2)
1.2	6,000	396	384	480	1,152	1,536	320×240@20.0 (7) 352×288@15.2 (6)
1.3	11,880	396	768	960	2,304	3,072	320×240@36.0 (7) 352×288@30.0 (6)
2	11,880	396	2,000	2,500	6,000	8,000	320×240@36.0 (7) 352×288@30.0 (6)
2.1	19,800	792	4,000	5,000	12,000	16,000	352×480@30.0 (7) 352×576@25.0 (6)
2.2	20,250	1,620	4,000	5,000	12,000	16,000	352×480@30.7 (10) 352×576@25.6 (7) 720×480@15.0 (6) 720×576@12.5 (5)
3	40,500	1,620	10,000	12,500	30,000	40,000	352×480@61.4 (12) 352×576@51.1 (10) 720×480@30.0 (6) 720×576@25.0 (5)
3.1	108,000	3,600	14,000	17,500	42,000	56,000	720×480@80.0 (13) 720×576@66.7 (11) 1280×720@30.0 (5)
3.2	216,000	5,120	20,000	25,000	60,000	80,000	1,280×720@60.0 (5) 1,280×1,024@42.2 (4)
4	245,760	8,192	20,000	25,000	60,000	80,000	1,280×720@68.3 (9) 1,920×1,080@30.1 (4) 2,048×1,024@30.0 (4)
4.1	245,760	8,192	50,000	62,500	150,000	200,000	1,280×720@68.3 (9) 1,920×1,080@30.1 (4) 2,048×1,024@30.0 (4)
4.2	522,240	8,704	50,000	62,500	150,000	200,000	1,920×1,080@64.0 (4) 2,048×1,080@60.0 (4)
5	589,824	22,080	135,000	168,750	405,000	540,000	1,920×1,080@72.3 (13) 2,048×1,024@72.0 (13) 2,048×1,080@67.8 (12) 2,560×1,920@30.7 (5) 3,680×1,536@26.7 (5)
5.1	983,040	36,864	240,000	300,000	720,000	960,000	1,920×1,080@120.5 (16) 4,096×2,048@30.0 (5) 4,096×2,304@26.7 (5)

利用例

H.264は下記の放送・規格で採用されている。なお、日本の地上デジタルテレビ放送 (ISDB-T) では、MPEG-2が採用されているが、H.264はISDB-T方式を改良した、ブラジルのSBTVD方式の他、DVB-T方式の一部で採用されている。

デジタル放送方式

DVB-T
DVB-S2
- スカパー!プレミアムサービス
ISDB
- SBTVD (ISDB-TB)
- ワンセグ
- NOTTV（2016年6月終了）
DMB
- モバHO!（2009年3月終了）

マルチメディア規格

QuickTime 7 - QuickTime 7 PlayerではH.264の再生、QuickTime 7 ProではH.264への変換が出来る
Adobe Flash Player 9 - 2007年8月21日、H.264対応版発表
Microsoft Silverlight - 2009年7月にリリースされたSilverlight 3でH.264に対応
DivX - バージョン7のDivX Plus HDでH.264を採用
Nero Digital
メモリースティックビデオファイルフォーマット
ユニバーサル・メディア・ディスク (UMD)
AVCHD
AVCREC
HD Rec

また、下記の規格にも映像コーデックのひとつとして採用された。

動画コンテンツ

動画共有サービス

現在、ほとんどの動画共有サービスは、Flash Video (flv) とH.264 (mp4) を使用している。

ニコニコ動画 - 2008年7月5日より600kbpsまでのH.264動画を一般会員も投稿可能、有料会員はビットレート無制限で投稿可という仕様だったが、2016年12月08日から一般会員もビットレート無制限になった。
Dailymotion - フランスの動画共有サイト。ヨーロッパの動画共有サービスでは最初に対応したという。
eyeVio - H.264によるハイビジョン動画配信・eyeVio HD PROを2008年7月より開始した。
PANDORA.TV - 韓国の動画共有サイト。
Veoh - アメリカの動画共有サイト。H.264動画を無制限容量で投稿可能。
Youku - 中国の動画共有サイト。
YouTube - 以前はビデオコーデックがH.263（音声MP3）だったが、2011年ごろからはH.264（音声AAC）のデータ形式が標準となっていた。2018年現在、VP9（音声Opus）への再エンコードが進んでおり、4KはVP9でしか視聴できない。
zoome - 3,000 kbpsまで（音声込みの上限値）のH.264動画を完全無料（2010年 8月1日に有料化）で投稿可能。2007年 12月20日より。日本の動画投稿サイトで最初に対応した。2011年 8月31日をもって終了。

通信

JNN次世代HD SNG 中継車 - HD対応のテレビ中継車。DVB-S2方式を使用^[1]。2008年12月よりJNN系列局で順次導入。
NHKお天気カメラ・情報カメラ - IP回線を使いNHK放送センターとNHK大阪放送局に伝送^[2]。

その他、海外スポーツイベントの生中継等でも使用。

ライセンス

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は同一ビットレートで同等の画質性能であるという意見がある。

VC-1: 2003年、マイクロソフト社は"WMV9"の基本アルゴリズムにインタレース映像への対応を加えた仕様を"VC-9"と命名して、米国映画テレビ技術者協会 (SMPTE) に提出した、これは後に名称が"VC-1"に改められた。VC-1はH.264と共にHD DVDとBlu-ray Discでの動画圧縮規格として採用された。"H.264"は非常に多数の複雑な符号化ツールで構成されており、VC-1に比べてエンコーダもデコーダも処理負荷が増す傾向があるが、H.264はITU-TおよびISO/IECといった国際標準化団体の規格であるため、世界中の多くの企業が支持を表明し、製品に採用されている。また、デジタルTVやパソコン等に用いられる画像処理半導体の処理能力向上に伴って、負荷の重さは以前ほど問題にならなくなってきている。

ウェブブラウザ

PCのウェブブラウザではAdobe Flashを通じて広く利用されている。スマートフォンなどでは動画フォーマットの選択制限が厳しいこともあり、デファクトスタンダードとなっている。

ウェブ表示の次世代規格であるHTML5にはvideo要素で動画再生を行う機能が盛り込まれており、これに使用する動画フォーマットについて、ウェブブラウザベンダーのAppleとマイクロソフトは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サポートを追加したウェブブラウザを提供することを目的としたプロジェクトを立ち上げた^[3]。これはH.264に関する特許が成立していない国のユーザに向けたもので、特許が成立している国のユーザは事実上使うことはできない。2012年、Mozilla FoundationはH.264のサポートを表明した^[4]。

マイクロソフトはMozilla FirefoxでH.264を再生できるようにするアドオンを公開している^[5]。これは動的にvideo要素をobject要素に書き替えるという力業で実現しており、video要素固有のAPIが利用できなくなるという仕組み上の欠点を抱えている。

脚注

[脚注の使い方]

^ 関昭一・井下雅美「「JNN次世代HD-SNG中継車」標準仕様車について」、『放送技術』第67巻（2014年5月号）、兼六館出版、2014年5月、 ISSN 0287-8658
^ 平樹・田嶋亨「ロボットカメラモニタリングシステムの更新」、『放送技術』第62巻（2009年3月号）、兼六館出版、2009年3月、 ISSN 0287-8658
^ Wild Fox Project
^ Mozilla が H.264 をサポートへ、webM 一本化を断念 Engadget 2012年03月20日
^ HTML5 Extension for Windows Media Player Firefox Plug-in Interoperability Bridges and Labs Center

参考図書

小野定康, 浅井光太郎, 村上篤道『ユビキタス技術動画像の高能率符号化―MPEG-4とH.264』オーム社、2005年。ISBN 978-4274200601。
角野眞也『改訂三版 H.264/AVC教科書』インプレスR&D、2008年。ISBN 978-4844326649。
Iain E. Richardson (2010). The H.264 Advanced Video Compression Standard (2nd ed.). Wiley. ISBN 978-0470516928

[2] 平樹・田嶋亨「ロボットカメラモニタリングシステムの更新」、『放送技術』第62巻（2009年3月号）、兼六館出版、2009年3月、 ISSN 0287-8658

[3] Wild Fox Project

[4] Mozilla が H.264 をサポートへ、webM 一本化を断念 Engadget 2012年03月20日

[5] HTML5 Extension for Windows Media Player Firefox Plug-in Interoperability Bridges and Labs Center

[1]

[2]

[3]

[4]

[5]

@@ 382行目: / 382行目: @@
 PCの[[ウェブブラウザ]]では[[Adobe Flash]]を通じて広く利用されている。[[スマートフォン]]などでは動画フォーマットの選択制限が厳しいこともあり、[[デファクトスタンダード]]となっている。
-ウェブ表示の次世代規格である[[HTML5]]にはvideo要素で動画再生を行う機能が盛り込まれており、これに使用する動画フォーマットについて、ウェブブラウザ[[ベンダー]]の[[アップル (企業)|アップル]]と[[マイクロソフト]]はH.264を推進しているが、[[Mozilla Foundation]]と[[オペラ・ソフトウェア]]、[[Google]]は[[ロイヤリティ]]が発生する点などを問題視し、積極的な利用に難色を示していた。2016年4月現在では、[[Safari]]、[[Internet Explorer]]、[[Mozilla Firefox]]はH.264をサポートしているが、[[Google Chrome]]、[[Opera]]ではサポートしていない。
+ウェブ表示の次世代規格である[[HTML5]]にはvideo要素で動画再生を行う機能が盛り込まれており、これに使用する動画フォーマットについて、ウェブブラウザ[[ベンダー]]の[[Apple]]と[[マイクロソフト]]は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サポートを追加したウェブブラウザを提供することを目的としたプロジェクトを立ち上げた<ref>[http://wildfox.sourceforge.net/ Wild Fox Project]</ref>。これはH.264に関する特許が成立していない国のユーザに向けたもので、特許が成立している国のユーザは事実上使うことはできない。2012年、Mozilla FoundationはH.264のサポートを表明した<ref>[http://japanese.engadget.com/2012/03/20/mozilla-h-264-webm/ Mozilla が H.264 をサポートへ、webM 一本化を断念] [[Engadget]] 2012年03月20日</ref>。