Presented at the SPIE
Conference on Applications of
Digital Image
Processing XXVII
Special Session on Advances in the New Emerging Standard: H.264/AVC,
August, 2004
The
H.264/AVC Advanced Video Coding Standard:
Overview and Introduction to the Fidelity Range
Extensions
摘要
H.264/MPEG-4 AVCは最新の国際映像圧縮規格。開発はITU-TのVCEGとISO/IEC のMPEGの共同作業で行われた。H.264/AVCは最先端の符号化ツールを用いて幅広いアプリケーション（ビデオ電話/会議、TV、ストレージ （DVD、ハードディスクベース、わけてもハイデフDVD）、ストリーミング映像、デジタル・ビデオ・オーサリング、デジタルシネマ、などなど）に高度な 圧縮効率をもたらすものだ。
このほど、この規格の拡張作業が完了した。この拡張はFRExt（Fidelity Range Extensions、忠実度の拡張）と呼ばれるもので、 2003/春に定義完了したAVCのオリジナル規格に比べて様々な点で優れた能力を持っている。
この文書では、新しいFRExt規格のハイライトを含めたAVC規格の概要を述べ、さらにMPEG-2およびMPEG-4 part2との若干の比較を行う。
Keywords: Advanced Video Coding (AVC), Digital Video Compression, H.263, H.264, JVT, MPEG, MPEG-2, MPEG-4, MPEG-4 part 10, VCEG.
もくじ
90年代初頭のこの分野の揺籃期より、国際ビデオ符号化規格～ 時系列順に並べるとH.261[1], MPEG-1 [2], MPEG-2 / H.262 [3], H.263 [4], およびMPEG-4 (Part 2) [5] ～は、デジタル映像圧縮の商業的成功の影の立役者だった。これらの規格の意義は、様々な会社の製品間での相互互換性を助けるとともに、特定用途向けアプリケーションや製品開発に於いて、コストパフォーマンスと性能のバランスの良い技術を選択できるだけの「多様性」を確保した事にある。その結果、様々な分野で、妥当なコストで先端技術が活用されるようになった。これらの規格はコンテンツ・クリエイタに再生互換性を保証し、同じコンテンツを様々な会社の様々な製品むけにコピーしなくて済むようになった。その結果、多くの人が技術を享受出来るだけの劇的なコスト削減と規模の利益追求が可能になった。これらの規格は会社の壁を超えた専門家の間のオープンな共同作業や、技術との需要のバランスの録れたイノベーションを進めるよう助長した。
ITU-T H.264 / MPEG-4(Part10) Advanced VideoCoding（一般にはH.264/AVC）[6]は、これら国際映像符号化規格の最新版だ。現時点では最もパワフルで、最新技術を結集したものだ。開発に当たったのは、JVT。これはITU-TのVCEGとISO/IEC のMPEGの専門家で構成された。
過去の規格同様、H.264/AVCが提供するのは、VLSI（CPU, DSP, ASIC, FPGAなど）技術の状況を考慮しつつ、符号化効率・実装上の複雑さ・コストの「現時点で望み得る最善のバランス」だ。具体的な目標は「妥協できるコストで、少なくともMPEG-2の2倍の符号化効率を達成する事」だった。
2004年7月、この規格に改正が施された。名称はFidelity Range Extensions（FRExt Amendment1）。これは符号化効率をさらに向上するもので、主要なアプリケーションでの符号化効率は、潜在的にMPEG-2の3倍に達し得る。
この文書ではまず最初のH.264/AVCのアウトラインを紹介し、その後で、既に産業界から大きな注目を集めている新しい FRExt拡張の概要を紹介する。
H.264/AVCの開発は4年を要した。この規格のルーツはITU-TのVCEGが始めたH.26Lプロジェクトにある。H.26Lは1998前半に CfP(Call for Proposal、提案書募集声明。技術提案の募集の段階)に達し、1998/8月に規格化に向けた最初のドラフト・デザインが作られた。2001年、ISO/IECのMPEGがMPEG-4Part2の策定を終えた段階で、彼らも将来に向けて似たようなCfPを出して更に符号化効率の良い技術を募集した。これに対してVCEGはH.26LのCfP をMPEGに送り、次世代規格の共同策定を提案した。MPEG側はその他の団体等からの提案も含めてテストした結果、H.26Lの中から以下のものを支持する結論を出した。
この結果、ITU-TとISO/IECは、迅速な規格策定のために、次世代映像符号化規格をH.26Lベースで共同開発することで合意した。2001/12月に両者の専門家からなるJVTが発足し、2003年までに規格の為の技術開発を完了すべく活動しはじめた。新規格の名称として、ITU-Tは「ITU-TH.264」を考えており、一方 ISO/IECはISO/IEC 14496で定義済みのMPEG-4 規格の一部として「MPEG-4 Part10 Advanced Video Coding(AVC)」を考えていた。結果的として誰も望まなかった事だが、この規格は少なくとも6種類の名前で呼ばれる事になった。H.264, H26L, ISO/SEC 14496-10, JVT, MPEG-4 AVC, MPEG-4Part10。この文書では２組織の間をとって「H.264/AVC」とする。
両組織がカバーするアプリケーションは幅広く、従って規格策定作業で考慮すべきアプリケーションも幅広かった。ビデオ会議システム、エンターテインメント（ケーブル放送、衛星放送、地上波、ケーブルモデム、DSLなど、DVDやハードディスクなどのストレージに、ビデオ・オン・デマンドなど）、ストリーミング、監視用、軍事用、そしてデジタル・シネマ、、、。これらの用途を大雑把に分類するために、プロファイルという機能セット（＊使っても良い技術の詰め合わせ＊）がつくられた。Baseline、Main、Extendedの三種である：
Baseline profile は複雑さを最小限に抑え、幅広いネットワーク環境（そのコンディション下でも使える）での信頼性とフレキシビリティを狙ったもの。Main profileは符号化効率の向上を主軸に置いたもの。Extended profileはBaselineの信頼性を保ちつつ、符号化効率の向上とさらなる信頼性を加え、フレキシブル・ビデオ・ストリーミングなどで有用な "trick use" 向け拡張を加えたものだ。
メモ：
「開発」と言っても、これらの団体はJISのようなもので、実際の「技術」は企業や研究所が持ち寄る。現実には政治力や資金力がモノを言う局面もあるだろう。『H.264/AVC教科書』によると、JVTはこの後、特許料の問題には深入りを避けている。はっきりとは書いてないが、多少の紛糾はあったようだ。実際、MPEG-4part 2 videoが変則的な形で普及した背景には、様々な技術を盛り込みすぎてパテント料の高騰を招いたという背景もあった。
2003/3 月に完成した最初のH.264/AVC規格は "エンターテインメント・クオリティ"に主眼を置いた。すなわち、8bits/sampleと4:2:0 chromaサンプリングベースの映像フォーマットである。時間的な制約から、プロフェッショナル環境下で必要な仕様はほとんどがサポート対象外で、高解像度に適した設計にもなっていない。コンテンツ制作、コンテンツ・ディストリビューション、スタジオ編集やポストプロセッシングといった用途には以下のようなものが必要だ。
こうしたニーズを満たすため、JVTは規格の拡張作業を続けた。作業は2003/3月の最初のドラフト案から2004/7月の最終設計案を経て、編集作業は2004/8～9月に終わると見込まれている。この拡張は当初 "プロフェッショナル" 拡張と呼ばれていたが、最終的には "fidelity range extension（FRExt）" （＊忠実度、正確さの拡張＊）と呼ばれる事になった。その方がこの拡張の本質を表しているからだ。
JVTはこのFRExt改正の過程で、時間的な制約から最初の規格に盛り込めなかった技術提案や、利得が不確実だったもの、想定アプリケーションなどの見直しも行った。特筆に値するものは以下。
FRExtは新たに4つのプロファイルを定義した。これらはひとまとめにしてHigh profileと総称する。
| 名称 | 1サンプルbit数 | 色彩信号形式 | 備考 |
|---|---|---|---|
| High profile (HP) | 8-bitvideo | 4:2:0 | ハイエンドコンシューマ、および高サンプル精度や拡張彩度フォーマットが必要無い高解像度アプリ用。 |
| High10 profile (Hi10P) | 10bit まで | 4:2:0 | |
| High4:2:2 profile (H422P) | 10bitまで | 4:2:2まで | |
| High4:4:4 profile (H444P) | 12bitまで | 4:4:4まで | その他に ・部分的な、効率的なロスレス符号化の使用。 ・RGBビデオの符号化における、color-space変換エラーの無い、残りの整数色彩変換 |
上記のプロファイルは全て Main の全機能を含み、さらに適応ブロックサイズと人間の認識ベースの量子化スケーリングマトリクスをサポートする。
産業界の反応は劇的でFRExtは急速に受け入れられた。High profileが近未来の重要なアプリケーション規格に盛り込まれる事は確実に思える。中でも重要なのは：
その他の環境も程なく後に続くだろう（例えばATSC、Advanced Television SystemsCommittee、米国および多様な衛星/ケーブルTVで採用）。事実、産業界がHigh profileの実装に寄せる関心は急速に Main へのそれにとって変わりつつ有る。なぜならHigh profileでは実装をあまり複雑化することなく、Mainより高い符号化効率が得られるからだ。
基本的な部分では、この規格の符号化構造は既存のメジャーな映像規格、 H.261, MPEG-1, MPEG-2 / H.262, H.263or MPEG-4 part 2、と良く似ている。アーキテクチャとコアブロックをFig1,Fig2に示す。この図から動き補償ベースのDCT変換符号化が基盤になっている事も解る だろう。各ピクチャは一個以上のスライスに分割することで圧縮される。各スライスはマクロブロックからなる。さらにこれは16x16ピクセルの輝度サンプ ルと、それに対応する輝度サンプルからなる。しかしながら（＊これまでとは異なり＊）各 マクロブロックは、動き補償予測の為に、さらにサブ・マクロブロック・パーティションに分割される。予測パーティションのサイズは７種類となる。– 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 そして4x4だ。これまでの規格では、動き補償はマクロブロックを丸ごと使うか、新しめの規格では16x16 か8x8パーティションを使った。従って、パーティションの形にバリエーションが増えたという事は、予測精度の向上をもたらす。次に、残ったデータは 8x8（FRExtでしか使えない）か4x4で空間軸変換される。過去の主要規格ではこの変換ブロックサイズは8x8のみだった。4x4ブロックサイズの 採用で残りの差分信号の精度が向上する事になる。空間軸変換のブロックサイズは常に予測に使われるブロックサイズと同じか、より小さい。ビデオシークエン スのシークエンスからサンプル（*原注：ここでは特にサンプルとピクセルを区別しないが、厳密にはサンプルが正しい。）に至る階層構造は以下のようにな る。
シークエンス（ピクチャ（スライス（マクロブロック（マクロブロック・パーティション（サブ-マクロブロック・パーティション
（ブ
ロック（サンプル））））））
補足として、追加的なストラクチャも存在する。例えばパケッタイゼーション・スキーム、チャンネルコード、などなど。これらは映像データの配信に関わるも ので、オーディオのように他のストリームと連携するものでは無い。ビデオ符号化ツールは基本的にスライス・レイヤー上か、それより下で動作するものなの で、スライス・レイヤー以下に関わるビットをVCL（VideoCoding Layer、ビデオ符号化レイヤ）と呼ぶ。これに対し、スライス・レイヤーよりも上に関わるビットはNAL（NetworkAbstraction Layer、ネットワーク抽象レイヤ）データと呼ぶ。VCLデータと再上層部のNALデータは一緒にして単独のビットストリームとする事もできるし、別個 に送る事もできる。NALは様々な送信方式に対応すべく設計されている（例えば放送、ワイヤレス通信、ストレージメディア）。ここでは、圧縮能力の心臓部 たるVCLのみを取り上げる。エンコーダのブロックダイヤグラムをFig.1に示すが、概念的にはデコーダはこの逆回転だ。基本的にエントロピー・デコー ダとFig.1で灰色の範囲のプロセスから構成されている。
Fig. 1: High-level encoder architecture
Fig. 2: Higher-level encoder block diagram
H.264/AVC規格の初のバージョンは、4:2:0 chromaformat（一般的にはRGB-to-YCbCrカラースペース変換を介して伝達され、彩 度信号は縦横とも2:1にサブサンプリングされている）と、輝 度・彩度は8bitサンプル精度 しかサポートしなかった。FRExt追加議定書はこれに加え、4:2:2 ならびに 4:4:4 chromaformat、8bitよりも高いサンプル精度、オプションとしてアルファブレンドなどのための補助ピクチャを追加した。
マクロブロックはエンコード/デコードが使う基本的なユニットだ。4:2:0 chromaformatでは、各マクロブロックは16x16の輝度サンプルと、それに対応する8x8の彩 度サンプル二つ（＊Cb,Cr＊）か ら成る。4:2:2chroma formatでは、二個の彩度サ ンプルのサイズは8x16、4:4:4 chroma formatでは二個とも16x16となる。
ピクチャ中のスライスは、以下の符号化ツールを使って圧縮される：
もちろん、上記の符号化ツール全てを全てのスライスに使わなければいけないわけではない。適用する符号化ツールの組み合わせにより、スライスには I （Intra、イントラ）、P（Predicted、予測）、B（Bi-predicted、双予測＊ 「双方向」では無い＊）、SP(Switching P) 、SI (Switching I) といったタイプがある。個々のピクチャ内に複数種類のスライスが混在する事もある（＊参考図＊）。 ピクチャは基本的に２種類に別れる、参照ピクチャと非参照ピクチャだ。参照ピクチャはデコードの際に行われるフレーム間予測の過程で後続（ビットストリー ム順＊これは画面表示順とは異なる＊） ピクチャの基準として使われる。非参照ピクチャはこの目的では使用できない。（過去の規格とは異なり、双予測を使ったピクチャもI/Pスライス同様に参照 ピクチャにすることができる事は特筆に値する。）続くセクションでは各スライスタイプに使う符号化ツールについて説明する。
この規格は 映像がプログレッシブ・スキャンでもインターレースド・スキャンでも良い性能を発揮するように巧く設計されている。インターレースド・スキャン映像では、 フレームは２枚のフィールドから成る。各フィールドは1/2フレームぶんの時間差を置いてキャプチャされたものだ。フィールド間には無視できない時間差が あるので、フレーム内の隣接ラインにおける空間的な相関性は、動く物体のある部分では少ないものとなっている（＊ 要するにインタレ縞の事＊）。従って、効率的な符号化の観点か ら、一枚のフレームとして圧縮するか、または２枚のフィールドとして圧縮するかを選択する必要がある。H.264/AVCではこの選択を縦方向に隣接した マクロブロック単位で行うか、まるっとフレーム単位で行うかを選択できる。（＊ インタレ構造フレーム、インタレ構造マクロブロック-ペアで構成されたフレーム、プログレッシブフレーム、が混在できる＊）マ クロブロック-ペア・レベルでの符号化の場合、これをMBAFF（MacroBlock Adaptive FrameField、＊マクロブロック適応型フレームフィールド＊）符号化と呼ぶ。フレー ム・レベルでの符号化の場合は、PicAFF（PictureAdaptive FrameField、＊ ピクチャ適応型フレームフィールド＊） 符号化と言う。MBAFFはMPEG-2規格のマクロブロック単位とは異なる。縦方向に隣接したマクロブロック-ペア単位である事に注意。これにより各マ クロブロックは、各マクロブロックがフレームモードであろうがフィールドモードであろうが。またモードの転換がピクチャレベルであろうがマクロブロック- ペアレベルであろうが、16x16サイズと、全てのマクロブロック・パーティションをキープ出来る。
I-slice（および非I-slice中のイントラ・マクロブロック）において、各ピクセルの値はまず隣接するピクセルの値から空間軸予測にか けられる。空間軸予測の後で、残りの情報（＊residualinformation＊）は4x4 transform または 8x8 transform（FRExtの場合のみ）を使って変換され、最後に量 子化される。
FRExtでは、各変換係数に応じた特定周波数の視認性に従った量子化プロセスの最適化のために、エンコーダ固有の人間の知覚に基づく量子化スケーリングマトリクスを使っても良い。変換（＊に使われる？＊）の量子化された係数はzig-zag または field scanのどちらかの方式でスキャンされ、CAVLC かCABACのどちらかのエントロピー符号化方式で圧縮される。PicAFF オペレーション（＊インターレース方式が使うもの＊）では、各フィールドはフレーム圧縮に似た方式で圧縮される。 MBAFFオペレーション（＊これもインターレース方式が使うもの＊）で は、マクロブロックのペアがフィールド・モードの場合は隣接フィールドを空間軸予測に使い、マクロブロックのペアがフレーム・モードの場合は隣接フレーム を予測に使う。フレーム/フィールドの判断は以下で説明する符号化ツールの適用前に行う。時間軸予測はイントラマクロブロック内部では使われないが、 P/Bマクロブロックタイプでは行われる。主要なマクロブロックタイプのうちではこれが主な違いとなる。従って、このコデックを解説するにあたってはまず I-Sliceの説明を先に行い、その後でPやBとの違いを解説していく。
2.1.1. イントラ空間軸予測ピクセル同士の空間的な相関関係を利用する為に、イントラ空間軸予測には３種の基本タイプが定義されている。
フル-マクロブロック予測では、マクロブロックの全ての輝度または彩度のピクセルの値は、直前にデコードされたマクロブロックの端っこのピクセルの値から 予測される（Fig.3では4x4の領域しか無いが、考え方は同様）。実際にエンコーダが特定のマクロブロックの値をフル-マクロブロック予測する祭に は、4種類の方法が選べる。すなわち、（i） 垂直、 （ii） 水平、 （iii） DC 、（iv） プラナーである。
フル-マクロブロック-空間軸予測はイントラ16x16マクロブロックタイプと呼ばれるマクロブロックの中で輝 度に使う。彩度のイントラ予測は常にフル-マクロブロック予測を利用する。マクロブ ロックに対する彩度情報はサイズもフォーマットも複数あるので、彩度の予測は３種類のブロックサイズが定義されている（4:2:0マクロブロックでは8x8 chroma、4:2:2マクロブロックでは8x16chroma、4:4:4マクロブロックでは16x16 chroma）。彩度の予測タイプは輝度のそれとは独立している。
輝度の4x4イントラ予測はエンコーダが選択的に行う事が出来る（on a macroblock-by-macroblockbasis）。4x4空間軸予測モードでは、4x4ブロック内の輝度サンプル値は隣接する4x4ブロッ クの値から予測される。予測を行う方向は９方向の中からエンコーダが選択する（on a 4x4 block basis）Fig. 3参照（図には無いが、mode 2の番号が振られたDC予測タイプも含む）。
FRExt profilesでは、8x8輝度イントラ予測を使う事もできる。基本的に4x4予測と同じコンセプトを使うが、予測ブロックサイズは8x8であり、予測 精度を上げるためにpredictor（＊予報値？＊）にローパスフィルタ（＊低域通過フィ ルタ＊）を使う。
空間軸予測の後で、データを空間的にdecorrelateするための変換が行われる。この変換ではいくつかこの規格固有の特徴がある。（＊decorrelate は辞書に無いがおそらく削減。この段階では"短く言い換える"もので画質劣化は無いハズ＊）
マクロブロックサイズは16x16のままだが、これは 4x4 か8x8のブロックに分割され、4x4または8x8ブロック変換マトリクスT4x4かT8x8 がevery block of pixelsに適用される。式（＊？＊）は以下の通り：
4x4変換は非常に単純だ。8x8変換（FRExtのみ）はやや複雑だが、それでも一般的な8x8 IDCTに比べれば非常に単純と言える。（＊変換係数の？＊）「T」は、フルサンプルブロックサイズを変換の必要に応じてより小さなブロックに分割する事で、各マクロブロックの輝度(16x16)と彩度(8x8と、FRExtでは8x16または16x16) サンプル、の中の各ブロックに適用される。
さらに、16x16イントラ予測モードが4x4変換と一緒に使われる場合、マクロブロック中の16個の4x4輝度ブロックのDC係数はさらに選択され、下記のH4x4マトリクス（T4x4とH4x4の基本的な類似性に注意）を使った二次ハダマード変換により変換される。全てのマクロブロックタイプの中の輝度サンプルの4x4ブロックDC係数 も、同様に二次ハダマード変換により変換される。4:2:0ビデオでは、これはハダマードマトリクス H2x2（下記）による2x2彩度DC変換を必要とする。4:4:4ビデオでは、彩度DCは同じ4x4ハダマード変換を使う。これは16x16イントラモードで輝度に使うものと同じだ。4:2:2ビデオでは、彩度DC変換は2x4 彩度 DCの二次変換の為に、マトリクス H2x2 と H4x4を使う。
この変換により生成された係数は、マクロブロックごとに変更可能な量子化制御パラメータを使って量子化される。このパラメータは符号化後の映像が 8bit/サンプルをサポートしている場合、52種類の値を取り得る(*1)。もっと大きい映像ビット深度をサポートする場合、FRExtはステップの数を増やす。追加ビット１に対して量子化ステップ６段階（＊FRExt expands the number of steps by 6 for each additional bit of decoded sample accuracy.＊）。
重要なのは、量子化ステップサイズは量子化パラメータの値とリニアには対応していない事だ（全ての過去の規格とは異なる）。量子化ステップサイズは量子化パラメータが６増えると２倍になる（＊ vary in such a way that the quantization step size exactly doubles for every 6 increments of the quantization parameter. ＊）(*2)。
デフォルトの関連性は、輝度と彩度に使われる量子化ステップサイズで決まる。そしてエンコーダはこの関連性を、要求されるカラーコンポーネントの忠実度に見合うように、スライスのレベルで調整できる。FRExt拡張では、エンコーダはCbとCrの忠実度を個別にバランスさせる事ができる。
---------------
(*原注2)
MPEG-4 part 2 と JPEG2000は整数ウェーブレット変換を含む。しかしJPEG2000はフレーム間予測を持たない画像符号化規格で、MPEG-4では整数変換はテクスチャ符号化と呼ばれる特殊な部分でしか使えず（一般的なIフレーム符号化に似ているが、ほとんど実装されていない）、ほぼ全ての映像データで使われる主要な変換は丸め誤差の発生する理想的な8x8IDCTだ。整数変換のコンセプトもH.263 Annex
Wで使われてはいるが実情を追認するパッチに過ぎない。もともとは8x8浮動小数点IDCTだ。
FRExtでは、MPEG-2の大黒柱だった機能を追加した。すなわち、人間の認識に基づいた量子化スケーリングマトリクス（perceptual - based quantization scaling matrices）である。エンコーダは、各トランスフォーム・ブロックサイズごとに、そして、イントラ/インター予測では個別に、カスタマイズされたスケーリング因数を指定出来る。これはデコーダが逆量子化スケーリングに使うものだ。これにより、人間の視覚認識システムの弱点（様々なタイプがある）に従って、量子化の忠実度をチューンできる。
一般的には、この方法でmean-squared error（＊不詳だが恐らく全ての値を一律の基準で評価するという程の意味＊）やPSNRに現れる客観的な忠実度は向上しない。しかし主観的な忠実度は向上する。これはより重要な基準だ。
量子化スケーリングマトリクスのデフォルト値は規格上に定義されている。エンコーダはこれに置き換わる値をコデックに送り込んでシークエンスやピクチャレベルでこの値を変更できる。
マクロブロックが4x4変換モードを使ってフレーム・モードで圧縮されている場合、変換の量子化係数はFig. 4aにあるzig-zag形式でスキャンされる。このスキャン順番は最も大きな変換係数を最初にスキャンする事で、スキャンされた係数の中に0の連続がた くさん出るように考案されたものだ。
マクロブロックが4x4変換モードを使ってフィールド・モードで圧縮されている場合、係数のスキャン順番はFig. 4bのようにフィールドスキャンに適したものに変更される。これは、フィールド素材ではデータ中の相関性は縦方向のほうが高いためだ。
その他のブロックサイズでも（輝度8x8、4:2:0 彩度 DCの2x2、 4:2:2彩度DCの2x4）、基本的に同じコンセプトを用いる。スキャン順番は各ブロックサイズ単位で変更。
----
メモ
・画面内のスキャンは左上隅が起点。
・『スキャンされた係数の中に0の連続がた
くさん出るように』
例えば各ピクセルの輝度値を「255, 254, 243,,,,
」と真面目に書き込む代わりに、隣接ピクセルとの差分を符号化するだけでそれなりの圧縮になる。隣のピクセルは
ほとんど同じ値の事が多いので、実際の信号は「0（起点）, 0, +1（地味に明るい）, -1（起点と同じ）、、、といった感じになる。
エントロピー符号化とはロスレス符号化手法に関わる（＊一種数学的な＊）用 語で、データの構成要素を代替符丁と、あらかじめ定義された予測、変換、量子化、などと組み合わせて置き換えるもの。データサイズ削減効果が非常に大 きい（エントロピー符号化それ自体のデータ節約効果はそれなりでしか無い）。
本規格上のエントロピー符号化方式は二つ。VLC（variable length coding、可変長符号化）と BAC（binary arithmetic coding、２進数算術符号化）だ。
H.264/AVCでは二つともCA（context adaptive、文脈適応）方式で使うので、それぞれの用語は CAVLC と CABAC となる。これでスライス・レイヤー以下の Syntax element（＊ 訳語不詳＊）を臨機応変に符号化できる。過去の規格同様、マクロブロックは符号記述とデコード・プロセスの基本ユ ニットだ。
Syntax elementsには以下の要素が含まれる。：
最後の２タイプのデータが符号化データの大半を占める。一方非常に低いビットレートでは、a.～g.の分量が最大になり得る。高ビットレートで は、h. が大半だ。そして文脈適応（CA）が優先的に使われるのは、変換係数の符号化（＊h.）だ。（実際、CAVLCでは、文脈適応は変換係数にしか使われな い）。
