【リンク】http://www.nikon-sys.co.jp/products/index_1_1.htm

---

　Win 用H.264 解析ツール。リンク先から製品パンフレット(pdf)が落とせる。本やwebなどで読むより一目瞭然に解る図が満載。



　IPBはフレームではなくて「スライス」。1枚のピクチャ（フレームの中に）Iスライス、Pスライス、Bスライスが混在している。




　これを見ると4x4や8x8は文字通り16x16に対するサブマクロブロックに過ぎないようだ。実際、cropやscaleで縦横を8や4の倍数にする と[x264]がなにやら困っ たようなメッセージを出して来る。一番右下、田の字型に分割されてるのが8x8だと思う。



　モーションベクトルはそのサブマクロブロック単位で算出される。通常のマクロブロック（16x16）は矢印1本なのに対し、一番右下、田の字型に分割さ れたマクロブロック（8x8）からは矢印が4本でている。
　絵を見るとカメラパン以外に動きなどなさそうに思えるが、短いのとなが～いベクトルがあるのは、恐らく直前直後よりも遠いスライスと参照関係にあるのか な？。




　Y（輝度）のPSNRは35程度なのに対し、U,V（彩度）は43程度と高い。手許ではもう少し差が小さいが、傾向は同じだ。

　以下はDoom9 のMPEG-4 情報（AVC/H.264含む）の試訳。
　MacOSXを使う上で即効あるものではありません。Win向け。
　経験の範囲で補足は入れますが、ど素人ゆえ以下略。
　尚、本文に関する著作権は全て投稿者であるdoom9のbond氏に帰属します。、、たぶん。

==試訳ここから==

MPEG-4 AVC/H.264情報

MPEG-4とは?

MPEG-4（ISO 14496） はMPEG(Moving Picture Experts Group）が定めたオープン規格。
ここでMPEGとは、ISO(International Organization for Standardization）の下部組織で、有名なMPEG-1（利用例:MP3, VCD）やMPEG-2（利用例:DVD, SVCD） 規格などのオーディオ/ビデオ圧縮規格や、他にもいろいろな規格を決めています。

MPEG-4 規格は、本質的になんらかの製品規格ではありません（例えば、DVD規格はDVDフォーラムがMPEG-2をベースに定めたものです）。
幅広い下位規格をカバーしており、製品開発者が自社製品に見合った規格を選択できるようになっています。

数あるMPEG-4 の下位規格のうち、ここDoom9で重要なものを以下に挙げます:
- ISO 14496-1（システム）, アニメーション / インタラクティビティ（DVD メニューなど）
- ISO 14496-2（ビデオ）, この中の ASP（Advanced Simple Profile）には XviD, DivX5, 3ivx...などが対応。
- ISO 14496-3（オーディオ）, AAC（Advanced Audio Coding）
- ISO 14496-10（ビデオ）, AVC（Advanced Video Coding） 別名H.264。
- ISO 14496-14（コンテナ）, MP4コンテナフォーマット（拡張子.mp4）。
- ISO 14496-17（字幕）, MPEG-4 時間情報付きテキストフォーマット

以下の文章ではMPEG-4 ASPとAVC/H.264に焦点を当てて、上記のパートについて解説していきます。

Micro$oft Windows Mediaなどのクローズドな規格と比べて、オープン規格にはどんなメリットがあるのでしょうか？

利点は誰でも規格に沿った製品を開発できる事です。
このため、既にMPEG-4規格互換製品が多数出ています。もちろん再生互換性があります。
次に、オープン規格は競争をもたらします。競争の有るところ価格は下がり、品質が向上し、より需要に見合った製品が登場します。

しかし私にとって最も大切な事は：
オープン規格はオープンソースによる開発を容認しているということです。例えば、XviD 。知ってるよね？

__________________
弱者と強者の間では自由は圧迫の源であり、それを解放するのは法である（ジャンジャック・ルソー）
私は自分が何も知らない事を知っている（ソクラテス）

最終更新日：2005/10/22, bond

==試訳ここまで==

補足：
　本文中に「既にMPEG-4規格互換製品が多数出ています。もちろん再生互換性があります。」とあるが、現実にはもちろんそうではありません。
　ここで言う再生互換性とは、映像部分に限った話であり、しかも、最新のビデオコデックがある場合に限ります。

　QuickTime Player 6のMPEG-4コデックはMPEG-4 ASP（Bフレーム付きなど）を受け入れませんでしたし、QuickTime Player 7のApple-H.264はAVC/H.264 High Profileを再生できません。
　AppleはそもそもBフレームとモーションベクトル算出に技術的な問題を抱えているようです。いずれも近代的な動画コデックの基礎とも言える部分で す。

　Windows Media Player（もちろんWin版）はそもそも拡張子.mp4を受け入れないので、QuickTime Player（Win版のデキはかなりアレと聞きます）か、Media Player Classic（環境構築が面倒と聞きます）と言う事になります。

　オープンソースの動画再生ソフトVLCは、 Win/Mac/Linuxの主要プラットフォームで同等の性能を持っています。

改訂版 H.264/AVC 教科書

　とりあえず、とても高い。TVキャプチャをエンコードしたいだけの身に実用性はほとんど無い。基礎理論の話だけなので、どうも実際にコデックの開発に当たっている人たちにとっても実用性が薄いらしい。

　正直歯が立ちません（泣）。
　んが、頑張って読む価値はあると思う。
　冒頭にH.264/AVCは過去の圧縮理論が折り紙のように積み重なってできたものなので、一見とても複雑に見えるがいっこいっこの理屈を理解してゆけば恐れる事はない、みたいな事が書いてあった。
　ここから、H.264/AVCには特に革新的な要素はなく、些細なオプションを山のように積み上げて高圧縮を得るもの、と理解した。

　従って、基礎的な理屈を把握すれば、どのオプションがどんな効果がありそうか、鼻が効くようになる。と思う。

　執筆陣は実際にH.264/AVC規格策定に関わった人々であるらしく、また内容は基礎理論の説明に徹している。教科書と言うだけあってインターレースやyuvカラーフォーマットのしくみや、動画圧縮技術の歴史まで一通り網羅している。ここからApple-H.264やx264に足りない部分を推測する事も、設定などで煮詰まった時に辞書として使う事もできる。

　PHL （パナソニック・ハリウッド・ラボラトリ）こそはAVC High Profileの教祖、始祖鳥、ご本尊と認識している。

1. 04年07月/本田雅一氏/ITmedia：H.264/AVC改良版で動き出すか？ 次世代光ディスク情勢
2. 06年01月/本田雅一氏/ITmedia：H.264の画質向上がもたらすもの--PHL
3. 06年07月/本田雅一氏/ITmedia：BDソフトの本命、最新PHLエンコード画質の衝撃

　要するに 本田雅一氏の記事を盲信してるだけなのだが、かいつまんで言うと、HDでのMainのショボさに納得いかなかったPHLの人たちが、次世代DVDで MPEG-2を推す会社に掛け合って一年の時間を貰い、開発したのがH.264/AVC High Profileナノデアッタ。みたいな。特に三つ目は、ええとコレホントに本田さんの記事だよねってくらい画質に興奮しておられた。
　で、

06年09月：次世代光ディスクの画質を上げるPHLエンコーダーとは？ ：本田雅一氏，ITmedia

---

　 高橋氏は「ひとつはパラメータの選び方、もうひとつ は量子化マトリックスの作り方や映像全体に対するビット配分で すね。特にビット配分に関しては、 DVD時代に高画質圧縮を行うための研究開発を相当やり、実際に映画会社と一緒に高画質化を行ってきましたから、そこでの経験があります」と話す。

　High Profile番長御総謹製のエンコーダを、素材ごとに設定をチューンするようなプロが、駆使する世界。
　地上波アナログのTVキャプチャ、ど素人が使うx264、しかもMac。全然世界が違うが、なんかの参考にはなるだろう。

量子化マトリックスの作り方

あらかじめ素材映像の輝度分布や彩度分布、登場頻度などを知っておく必要があるだろう。無理ッス！

映像全体に対するビット配分

場面毎に要求ビットレートの差が激しそうなら配分傾斜をキツく、逆なら緩くするという事だと思う。無理ッス！

一応、x264cliは --rceqというオプションでレートコントロールの式らしきものを弄れる。

MEncoderではratetol, vbv_maxrate, vbv_bufsize, vbv_init, といったあたりだろうか。

パラメータの選び方

以下。

　高橋氏のいう“パラメータの選び方”は、H.264世代になって大きく画質に影響する ようになった部分だろう。MPEG系の圧縮ではフレーム間の 近似する映像パターンを見つけてコピーする動き予測という手法が用いられるが、H.264では予測のパターンが大幅に増加している。また同一フレーム内で の動き予測という新しい要素も加わった。

　さらに動き予測のマクロブロックに柔軟性が増し（4x4、8x8、4x8などさまざまな形状を選べ る）、 エンコーダー側で判別しなければならない 動き予測のバリエーションが想像を絶するほどに増えているのだ（これがH.264の圧縮負荷が高い原因になっている）。

• 「同一フレーム内で の動き予測」は、direct_pred=<0-3>に相当す ると思しき効果がある。尤も常用は3(Auto)。
• 「4×4、8×8、4×8などさま ざまな形状を選べる」 はモロに、(no)i4x4, (no)i8x8, (no)b8x8mv, (no)8x8mv, (no)4x4mv, (no)8x8dct、 だ。常用はSDのくせに全部on。High Profileだ。

さて、PHLの開発プロセスの話。

　“最適なパラメータを選ぶ”エンコーダーを開発すればい いと文字で書くのは簡単だが、 実際のプログラミングは相当に難しいだろう。しかし、だから こそ他エンコーダーに先んじて高画質化を果たせたと高橋氏は話す。

　「われわれは研究開発の部隊で、本来はオーサリング事業を行う部署ではありません。しかし、現在はBD事業を立ち上げるために オーサリングや出荷 するディスクの画質面での品質評価を支援しています。おそらくこうした組織は、世界中どこを探してもないでしょう。品質評価をコーデックを開発と圧縮作業 の監修を行った人間が直接行うのですから」

　「たとえば過去にはこんなことがありました。DVDの圧縮作業で、どうしても歪みが目立つところがあり、パラメータ変更では取り 切れない。そこに 柏木が来て“あぁ、これはエンコーダーのバグだなぁ”と話し、エンコーダーのソースコードを修正してしまいまし た。品質評価で納得がいかない時、それをエ ンコーダーのレベルにまで振り返って修正することで進化させる。このプロセスがPHLエンコーダーの画質を高めたのだと思います」

　つまり、エンコーダーのバグなのか、それとも圧縮規格そのもののクセや限界なのか、それともビットレートが不足しているのか、逆 にビットが余って 無駄になっていないか。その切り分けが正確に行えることこそが、PHLエンコーダーのアドバンテージというわけだ。

　この開発プロセスはx264でも存在する。素材はほとんどDVDだし機材はご家庭のパソコンだし、バラツキも大きいが、アタマ数は充分だ。その領域に 限っては、“最適なパラメータを選ぶ”エンコーダーに 最も近いと言える。
　また、ビットが余って 無駄になっていないかというスタンスは、MEncoderドキュメントのホネの一つでもある。

　駄菓子菓子、これはx264では有り得ない。

　筆者自身、PHLでの品質評価のプロセスを知って驚く、、、というよりも、呆れたことがある。

　縦12フィートの巨大スクリーンで評価を行っているというのは、以前に紹介したことがあるが、最近 はそれでも歪みやノイズを探すこと が困難にな り、コントラストを強調し、歪みやノイズをディスプレイ側で浮き立たせてチェックを行い、そのノイズを消すように配慮しながら圧縮作業を行っている。

　明らかにオーバークオリティといえる品質評価は、PHLが事業体ではなく研究開発を目的にした組織だからこそだが、その結果とし ての 映像は素晴らしいの一言に尽きる。

　気違いです。気違いが居ます！12ftは約3.7m。自分の部屋の天高は2.3mだった（測るなよ）。16:9なら横は6.5m程になる、、、いや測っ てませんよ？^^;

　エンコーダーは使いこなしと品質評価のプロセスが肝要で、エンコー ダーが同じならば同じ品質になるわけではないが、PHLエンコーダーが広がり、これこそが次世代といえる画質のソフトが登場することに期待したい。

　期待したい。期待したい。期待したい（エコー）。

原文：Introduction paper to H.264/MPEG-4 AVC including the Fidelity Range Extension. （PDF）
※スウェーデン、 Luleå University of Technology、Dr. Peter Parne氏の 講義ガイダンスの模様。）

2.1.5. エントロピー符号化

　エントロピー符号化とはロスレス符号化手法に関わる（＊一種数学的な＊）用 語で、データの構成要素を代替符丁と、あらかじめ定義された予測、変換、量子化、などと組み合わせて置き換えるもので、データサイズ削減に非常に効果が大 きい（エントロピー符号化それ自体のデータ節約効果はそれなりでしか無い）。
　規格上のエントロピー符号化方式は二つ。VLC（variable length coding、可変長符号化）と BAC（binary arithmetic coding、２進数算術符号化）
　H.264/AVCでは、この二つともCA（context adaptive、文脈適応）方式で使うので、それぞれの用語はCAVLC と CABACだ。これでスライス・レイヤー以下の Syntax element（＊ 訳語不詳、記述要素？＊）を臨機応変に符号化できる。過去の規格同様、マクロブロックは符号記述とデコード・プロセスの基本ユ ニットだ。
　Syntax elementsには以下の要素が含まれる。：

1. シークエンス、ピクチャ、スライス・ヘッダ用の高次レイヤー syntax element。これらはシンプルな固定長符号か、シンプルなUVLC（universal VLC、汎用VLC）符号化テーブルで符号化される。；
2. スライス・ペイロード・データ。例えばスライスの長さやマクロブロック・スキッピング・インジケータなど（CAVLC& nbsp; やCABACなどのエントロピー符号化が使われるレイヤー以下にある）;
3. マクロブロック・タイプ（mb_type）；
4. マクロブロックのCBP（coded block pattern）。これは、4x4または8x8変換ブロックのどれが non-zero 係数を持っているかのフラグ（従って符号化の必要が無いサブマクロブロックを効率的に区別することができる）；
5. マクロブロック量子化パラメータ。直前マクロブロックのデルタとして符号化される（＊デルタ？＊coded as a delta from the previous macroblock＊）;
6. 参照フレームインデックス；
7. モーション・ベクトル（MVs）。隣接データから形成されたMVの予測から、デルタとして送られる（＊sent as a delta from a prediction of the MV formed from neighboring data＊）; 
8. 量子化された変換係数（8x8・4x4変換から、または、ローレベル4x4変換のDC係数に適用された二次ハダマード変換から）（＊from 8x8 or 4x4 transformations, or from secondary Hadamard transformations applied to DC coefficients of lower-level 4x4 transformations＊）。

　最後の２タイプのデータが符号化データの大半を占める。一方非常に低いビットレートでは、a.-g.の分量が最大になり得る。高ビットレートでは、h. が大半だ。そして文脈適応が優先的に使われるのは、変換係数の符号化だ。（実際、CAVLCでは、文脈適応は変換係数にしか使われない）。

----
メモ
　CAVLCやCABACは符号化の様々な工程で用いられる一種数学的な理屈。とでも思えばいいのかな。

2.1.4. スキャニング

　マクロブロックが4x4変換モードを使ってフレーム・モードで圧縮されている場合、変換の量子化係数はFig. 4aにあるzig-zag形式でスキャンされる。このスキャン順番は最も大きな変換係数を最初にスキャンする事で、スキャンされた係数の中に0の連続がた くさん出るように考案されたものだ。

 
　

　マクロブロックが4x4変換モードを使ってフィールド・モードで圧縮されている場合、係数のスキャン順番はFig. 4bのようにフィールドスキャンに効果的なものに変更される。これは素材データ中の相関性が縦方向に高い事に応じたものだ。
　その他のブロックサイズでも（輝度8x8、4:2:0 彩度 DCの2x2、 4:2:2彩度DCの2x4）、基本的に同じコンセプトを用いる。スキャン順番は各ブロックサイズ単位で変更。

----
メモ
　画面内のスキャンは左上隅が起点。例えば各ピクセルの輝度値の代わりに、隣接ピクセルとの差分を符号化するだけでそれなりの圧縮になる。隣のピクセルは ほとんど同じ値の事が多いので、実際の信号は0（起点）、0、0、0、+1（地味に明るい）、-1（起点と同じ）、、、といった感じになる。

原文：Introduction paper to H.264/MPEG-4 AVC including the Fidelity Range Extension. （PDF）
※スウェーデン、 Luleå University of Technology、Dr. Peter Parne氏の 講義ガイダンスの模様。）

2.1.3. 人間の認識に基づいた量子化スケーリ ングマトリクス

　FRExtでは、MPEG-2の大黒柱だった機能を追加した。すなわち、人間の認識に基づいた量子化スケーリングマトリクス（perceptual- based quantization scaling matrices）である。エンコーダは、各トランスフォーム・ブロックサイズごとに、そして、イントラ/インター予測では個別に、カスタマイズされたス ケーリング因数を指定出来る。これはデコーダが逆量子化スケーリングに使うものだ。これにより、人間の視覚認識システムの欠陥（様々なタイプがある）に 従って、量子化の忠実度をチューンできる。
　一般的には、この方法でmean-squared error（＊恐らく全て の値を等価に測定する方式という程の意味＊）やPSNRに現れる客観的な忠実度は向上しない。しかし主観的な忠実度は向上す る。これはより重要な基準だ。
　量子化スケーリングマトリクスのデフォルト値は規格上に定義されている。エンコーダはこれに置き換わる値をコデックに送り込んでシークエンスやピクチャ レベルでこの値を変更できる。
　

----

■メモ

・太陽の中の黒点は見えにくい。　ー＞　高輝度の中の細かいディテイルは省略しても画質劣化がバレにくい。
・闇夜のカラスは見えにくい。　ー＞　低輝度の中の細かいディテイルは省略しても画質劣化がバレにくい。
　従って、レート 制限がある場合、バットマンのよう に暗闇の多い素材では低輝度成分を細かく区分したカスタム量子化マトリクスを用意すると、画質が良いと感じる事ができる＝ビットをより有効に使える。 CPU的には「いわれた通りやりますけどぉ～、素材への忠実度は下がりますけどぉ～」てな感じだろう。
　シークエンスはムービー全体。ピクチャはコマ単位。くらいに思ってもよさそう。
　MEncoder -x264encoptsでは、cqm、cqm4iy、cqm4ic、cqm4py、cqm4pc、cqm8iy、cqm8py。
　cqmで出来合いのカスタムマトリクスを使う以外はちょっと手が出しにくい。妄想的には1stパスで輝度や彩度の統計を取り、そこからカスタム量子化マ トリクスを自動生成する仕組みがあっても良さげでは ある。GIFの「カラーインデックス」みたいなわけにはいきませんかそうですか。

原文：Introduction paper to H.264/MPEG-4 AVC including the Fidelity Range Extension. （PDF）
※スウェーデン、 Luleå University of Technology、Dr. Peter Parne氏の 講義ガイダンスの模様。）

2.1.2. 変換と量子化（Transform and Quantization）

　空間軸予測の後で、データを空間的にdecorrelateす るための変換が行われる。この変換ではいくつかこの規格固有の特徴がある。（＊decorrelate は辞書に無いがおそらく削減。この段階では"短く言い換える"もので画質劣化は無いハズ＊）

• H.264/AVCは、基本的に主要な空間軸変換に整数逆変換ベースを使う最初のビデオ規格だ。理想的な三角関数を使った逆変換 方程 式の定義は、実装ごとに許容誤差が異なる(*原注2)。一般的にエンコードに使われるその先の変換も整数変換だ。整数を使うメリットは、正確な整数逆変換 を使うとMPEG-2やMPEG-4 part 2とは事なりエンコーダとデコーダの間でミスマッチが出ないと言う事だ。
• 実質的にこの変換は8-bit ビデオデータ入力の為に定義されたもので16-bit arithmeticだけで簡単に実装できた。それ以前の規格は変換の為に32-bit以上の精度を必要とした。
• この変換（少なくとも4x4ブロックサイズはFRExt抜きでも使える）のデザインはシンプルさを旨としていたので、わずかな調 整とビットシフトだけで実装できるものだ。
• 8x8に加え、4x4変換のサポート。この結果、隣接ブロックとの不一致は低粒度となり、目立ちにくくなる。機能の分離は空間位 置精度の向上をもたらす（いわゆる"リンギング"の減少）。ある種のハードウェア実装では、小さなブロックサイズは特に便利だ。

　マクロブロックサイズは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だ。

(*1)
　qp_constantの範囲は0-51、qp_min、qp_maxの範囲は1-51。なお、x264の量子化はフレーム単位。マ クロブロック単位では無い。
(*2)
　"H.264の quantizationパラメータ (QP)は対数尺を用いる。 換算すると概ねH264QP = 12 + 6*log2(MPEGQP)。例えば、MPEGのQP=2 は概ね H.264 の QP=18。"
　man mencoder、qp_constantの記載より。

原文：Introduction paper to H.264/MPEG-4 AVC includingthe Fidelity RangeExtension. （PDF）
※スウェーデン、 Luleå University of Technology、Dr. Peter Parne氏の講義ガイダンスの模様。）

2.1. I-スライス

　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. イントラ空間軸予測

ピクセル同士の空間的な相関関係を利用する為に、イントラ空間軸予測には３種の基本タイプが定義されている。

• フル-マクロブロック予測。これは16x16輝度、また、それに対応する彩度ブロックサイズ用。
• 8x8 輝度予測 (FRExt-only)
• 4x4 輝度予測

　フル-マクロブロック予測では、マクロブロックの全ての輝度または彩度のピクセルの値は、直前にデコードされたマクロブロックの端っこのピクセルの値から予測される（Fig.3では4x4の領域しか無いが、考え方は同様）。実際にエンコーダが特定のマクロブロックの値をフル-マクロブロック予測する祭には、4種類の方法が選べる。すなわち、(i) 垂直、 (ii) 水平、 (iii) DC 、(iv) プラナーである。

• (i) 垂直予測と(ii)水平予測では、マクロブロックのピクセル値はマクロブロックの真上かすぐ左のピクセルの値から予測される（Fig3の0か1）。
• (iii)のDC予測（Fig3には無い）では、隣接ピクセルの輝度値を平均化した値をpredictor（＊予報値？＊）に使う。
• (iv) プラナー予測（Fig3には無い）では、three-parameter curve-fittingequation（＊なんかの式？＊）を使って輝度ブロックを予測する。この予測は水平方向の傾斜（＊値？＊）であり、垂直方向は隣接ピクセルにおおよそ見合ったものになる。

　フル-マクロブロック-空間軸予測はイントラ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予測タイプも含む）。

　FRExtprofilesでは、8x8輝度イントラ予測を使う事もできる。基本的に4x4予測と同じコンセプトを使うが、予測ブロックサイズは8x8であり、予測精度を上げるためにpredictor（＊予報値？＊）にローパスフィルタ（＊低域通過フィルタ＊）を使う。


 

原文：Introduction paper to H.264/MPEG-4 AVC includingthe Fidelity RangeExtension. （PDF）
※スウェーデン、 Luleå University of Technology、Dr. Peter Parne氏の講義ガイダンスの模様。）

2. 符号化ツール

　基本的な部分では、この規格の符号化構造は既存のメジャーな映像規格、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ブロックサイズの採用で残りの差分信号の精度が向上する事になる。空間軸変換のブロックサイズは常に予測に使われるブロックサイズと同じか、より小さい。ビデオシークエンスのシークエンスからサンプル（*原注：ここでは特にサンプルとピクセルを区別しないが、厳密にはサンプルが正しい。）に至る階層構造は以下のようになる。

　シークエンス（ピクチャ（スライス（マクロブロック（マクロブロック・パーティション（サブ-マクロブロック・パーティション（ブロック（サンプル））））））

　＊参考--ニコンシステム(株)H.264 解析ツールNH264H1

　補足として、追加的なストラクチャも存在する。例えばパケッタイゼーション・スキーム、チャンネルコード、などなど。これらは映像データの配信に関わるもので、オーディオのように他のストリームと連携するものでは無い。ビデオ符号化ツールは基本的にスライス・レイヤー上か、それより下で動作するものなので、スライス・レイヤー以下に関わるビットをVCL（VideoCoding Layer、ビデオ符号化レイヤ）と呼ぶ。これに対し、スライス・レイヤーよりも上に関わるビットはNAL（NetworkAbstraction Layer、ネットワーク抽象レイヤ）データと呼ぶ。VCLデータと再上層部のNALデータは一緒にして単独のビットストリームとする事もできるし、別個に送る事もできる。NALは様々な送信方式に対応すべく設計されている（例えば放送、ワイヤレス通信、ストレージメディア）。ここでは、圧縮能力の心臓部たるVCLのみを取り上げる。エンコーダのブロックダイヤグラムをFig.1に示すが、概念的にはデコーダはこの逆回転だ。基本的にエントロピー・デコーダとFig.1で灰色の範囲のプロセスから構成されている。


Fig. 1: High-level encoder architecture

　＊基本的に量子化（Quantization）以外は「短く言い換える」もの。


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となる。

ピクチャ中のスライスは、以下の符号化ツールを使って圧縮される：

• "イントラ"空間軸（ブロック・ベースの）予測
• フル-マクロブロックの輝度/彩度予測、予測は4モード（方向）。
• 8x8（FRExtのみ）または4x4輝度予測、予測は9モード（方向）。
• "インター"時間軸予測、ブロック・ベースの動き予測と動き補償。
• Multiple reference pictures --（＊マルチプル・レファレンス、複数参照、複合参照、不等距離参照＊）
• Bの参照フレーム化
• Arbitrary referencing order-- （＊自由な参照順番＊）
• 動き補償における可変ブロックサイズ
• ブロックサイズは7種: 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, 4x4
• 1/4-sample luma interpolation (1/4 or 1/8th-sample chromainterpolation) --1/4-サンプル輝度補間（1/4または1/8サンプル彩度補間）
• Weighted prediction --（＊適応重み補間予測＊）
• インターレース・スキャン映像のための、フレームまたはフィールドベース動き補償
• インターレースド・符号化機能
• Frame-field adaptation-- （＊フレーム-フィールド適応＊）
• Picture Adaptive Frame Field (PicAFF) --（＊ピクチャ適応型フレームフィールド＊）
• MacroBlock Adaptive Frame Field (MBAFF) --（＊マクロブロック適応型フレームフィールド＊）
• フィールドスキャン
• ロスレス描写能力 -- Lossless representation capability
• Intra PCM raw sample-value macroblocks -- （＊イントラPCMrawサンプル値マクロブロック＊）
• Entropy-coded transform-bypass lossless macroblocks(FRExt-only) --（＊エントロピー符号化された変換バイパス型ロスレスマクロブロック＊）
• 8x8（FRExt-only）または4x4の整数逆変換（概念的には有名なDCTに類似）
• 効率的なRGB符号化を変換ロスや肥大化抜きで実現するための、残りのカラー・トランスフォーム（FRExt-only）-- （＊Residual color transform、残余の？なにか定型的な訳が？＊）
• スカラー量子化 --（＊段階的な量子化、H.264の量子化スケールは対数目盛り＊）
• 人間の視覚認識を考慮した重み付けを施した量子化スケーリングマトリクスを、エンコーダで指定できる（FRExt-only）-- （＊カスタム量子化マトリクス＊）
• 量子化コントロール・パラメータの機能として、量子化ステップのサイズを対数的に（＊Logarithmic＊）コントロールできる。
• デブロッキング・フィルタ -- （動き補償ループの中で）
• Coefficient scanning --（＊協調的スキャニング？フィールド構造データでも必要の無い部分はフレーム用のZig-Zagスキャンで済ませられる？＊）
• Zig-Zag（フレーム）
• フィールド
• ロスレス・エントロピー・符号化
• 拡張ゴロム符号を用いた汎用可変符号化（UVLC）-- （＊Universal Variable LengthCoding (UVLC) using Exp-Golomb codes＊）
• 文脈適応型可変符号化（CAVLC） --（＊Context Adaptive VLC＊）
• 文脈適応型２進数算術符号化（CABAC）--（＊Context-based Adaptive Binary Arithmetic Coding＊）
• エラー耐性ツール
• フレキシブルなマクロブロックの順番 --（＊Flexible Macroblock Ordering(FMO)＊）
• 任意なスライス順番 --（＊Arbitrary Slice Order (ASO)＊）
• 冗長なスライス --（＊Redundant Slices＊）
• ストリーミングなどのためのSP と SI 同期化ピクチャ
• 多様なカラースペースのサポート（様々なYCbCr、YCgCo、RGB、など– FRExtでは特に）
• 4:2:0、4:2:2（FRExt-only）、4:4:4（FRExt-only）カラー信号
• アルファブレンディングのための補助ピクチャ（FRExt-only）

　もちろん、上記の符号化ツール全てを全てのスライスに使わなければいけないわけではない。適用する符号化ツールの組み合わせにより、スライスには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サイズと、全てのマクロブロック・パーティションをキープ出来る。

原文：Introduction paper to H.264/MPEG-4 AVC includingthe Fidelity RangeExtension. （PDF）
※スウェーデン、 Luleå University of Technology、Dr. Peter Parne氏の講義ガイダンスの模様。）

1.イントロダクション

　90年代初頭、この分野の揺籃期より、国際ビデオ符号化規格– 時系列順に並べるとH.261[1], MPEG-1 [2], MPEG-2 / H.262 [3], H.263 [4], and 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拡張の概要を紹介する。
　両組織がカバーするアプリケーションは幅広く、従って規格策定作業で考慮すべきアプリケーションも幅広かった。ビデオ会議システム、エンターテインメント（ケーブル放送、衛星放送、地上波、ケーブルモデム、DSLなど、DVDやハードディスクなどのストレージに、ビデオ・オン・デマンドなど）、ストリーミング、監視用、軍事用、そしてデジタル・シネマ、、、。これらの用途を大雑把に分類するために、プロファイルという機能セット（＊使っても良い技術の詰め合わせ＊）がつくられた。Baseline、Main、Extendedの三種である：
　Baselineprofileは複雑さを最小限に抑え、幅広いネットワーク環境（そのコンディション下でも使える）での信頼性とフレキシビリティを狙ったもの。Main profileは符号化効率の向上を主軸に置いたもの。 ExtendedprofileはBaselineの信頼性を保ちつつ、符号化効率の向上とさらなる信頼性を加え、フレキシブル・ビデオ・ストリーミングなどで有用な"trick use"向け拡張を加えたものだ。

メモ：

　「開発」と言っても、これらの団体はJISのようなもので、実際の「技術」は企業や研究所が持ち寄る。現実には政治力や資金力がモノを言う局面もあるだろう。自社特許が「国際標準規格」に採用されればメリットは大きい。てゆうか日米欧韓それぞれの知財戦略が全開バリバリで絡む。おいらが中・印・露・ブラジルあたりの政府の人だったら普及はジャマしたいと思うだろう。『H.264/AVC教科書』によると、JVTはこの後、特許料の問題には深入りを避けている。はっきりとは書いてないが、多少の紛糾はあったようだ。実際、MPEG-4part 2 videoが変則的な形で普及した背景には、様々な技術を盛り込みすぎてパテント料の高騰を招いたという背景もあった。

1.2. FRExt追加議定書

　2003/3月に完成した最初のH.264/AVC規格は "エンターテインメント・クオリティ"に主眼を置いた。すなわち、8bits/sampleと4:2:0 chromaサンプリングベースの映像フォーマットである。時間的な制約から、プロフェッショナル環境下で必要な仕様はほとんどがサポート対象外で、高解像度に適した設計にもなっていない。コンテンツ制作、コンテンツ・ディストリビューション、スタジオ編集やポストプロセッシングといった用途には以下のようなものが必要だ。

• 素材映像を1サンプルあたり8bit以上の精度で再現すること。
• 一般的なコンシューマ・アプリケーションよりも広い色彩表現の幅（たとえば、4:2:0 chromaサンプリングではなく、4:2:2や4:4:4 chromaサンプリング）。
• アルファ・ブレンディングなどの素材編集機能（複数の映像場面のブレンド。たとえば天気予報でキャスターの上に地図や気象レーダーの映像をスーパーインポーズするなど）
• すごい高ビットレート
• すごい高解像度
• すごい忠実度の実現 -- 部分的に映像をロスレスに再現する事も含む。 
• カラースペース変換の丸め誤差回避。
• RGBカラー表現の採用（＊YUV4:2:0とかじゃなくて＊）。

　こうしたニーズを満たすため、JVTは規格の拡張作業を続けた。作業は2003/3月の最初のドラフト案から2004/7月の最終設計案を経て、編集作業は2004/8～9月に終わると見込まれている。この拡張は当初 "プロフェッショナル" 拡張と呼ばれていたが、最終的には "fidelity rangeextension（FRExt）" （＊忠実度、正確さの拡張＊）と呼ばれる事になった。その方がこの拡張の本質を表しているからだ。
　JVTはこのFRExt改正の過程で、時間的な制約から最初の規格に盛り込めなかった技術提案や、利得が不確実だったもの、想定アプリケーションなどの見直しも行った。特筆に値するものは以下。

• Supporting an adaptive block-size for the residual spatialfrequency transform
  　・残りの空間軸周波数変換のための適応ブロックサイズ。（＊PHLが提案した8x8と思われる。i8x8, 8x8dct＊）
• Supporting encoder-specified perceptual-based quantizationscaling matrices, and
  　・エンコーダが指定できる、人間の知覚に基づいた量子化スケーリングマトリクス。（＊カスタム量子化マトリクス。cqm＊）
• Supporting efficient lossless representation of specificregions in video content.
  　・映像内の特定箇所をロスレスに、効率的に表現する。（＊下手に圧縮すると肥大化する部分、というのがあるらしい。MEncoderの対応不詳。＊）

　FRExtは新たに4つのプロファイルを定義した。これらはひとまとめにしてHigh profileと総称する。

名称	1サンプルbit数	色彩信号形式	備考
Highprofile (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は急速に受け入れられた。Highprofileが近未来の重要なアプリケーション規格に盛り込まれる事は確実に思える。中でも重要なのは：

• HD-DVD 規格（DVD Forum ）
• BD-ROM Video 規格（Blu-ray Disc Association）
• DVB (digital video broadcast) 規格（欧州のTV放送 ）

　その他の環境も程なく後に続くだろう（例えばATSC、Advanced Television SystemsCommittee、米国および多様な衛星/ケーブルTVで採用）。事実、産業界がHighprofileの実装に寄せる関心は急速にMainへのそれにとって変わりつつ有る。なぜならHighprofileでは実装をあまり複雑化することなく、Mainより高い符号化効率が得られるからだ。

原文：Introduction paper to H.264/MPEG-4 AVC including the Fidelity Range Extension. （PDF）
※スウェーデン、 Luleå University of Technology、Dr. Peter Parne氏の 講義ガイダンスの模様。）

H.264/AVC規格：概要と忠実度拡張（FRExt）のイントロダクション

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

ABSTRACT～摘要
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.

もくじ

• 1. イントロダクション
• 1.1. H.264/AVCの歴史
• 1.2. FRExt追加議定書
• 2. 符号化ツール
• 2.1. I - スライス
• 2.1.1. イントラ空間軸予測
• 2.1.2. 変換と量子化
• 2.1.3. 人 間の認識に基づいた量子化スケーリングマトリクス
• 2.1.4. スキャニング
• 2.1.5. エントロピー符号化
• 2.1.5.1. VLC, UVLC and CAVLC coding
• 2.1.5.2. CABAC
• 2.1.6. Lossless macroblock modes
• 2.2. P-slices
• 2.3. B-Slices
• 2.4. SP and SI Slices
• 2.5. Deblocking Filter
• 2.6. Error Resilience Tools
• 2.7. Color Space and Residual Color Transform Support
• 3. SUPPLEMENTAL INFORMATION
• 4. PROFILES AND LEVELS
• 4.1. The Baseline, Main, and Extended Profiles in the First Version
• 4.2. The New High Profiles Defined in the FRExt Amendment
• 4.3. Levels
• 5. SIMULATION RESULTS
• 5.1. Performance of the First Version of the H.264/AVC
• 5.2. Performance of FRExt High Profile
• 6. CONCLUSIONS

"COMPRESSION PROJECT"

以下、英語版。

1. "COMPRESSION PROJECT"
1. プロジェクトのねらい。
   　"データ圧縮のすべて"。全ての人々にとって、最大限の完全さ、最大限の無駄のなさ、最大限に有用なデータ圧縮、の創造と供給。
2. Video filtering and compression by MSU Video Group
1. 映像圧縮関連もくじ
3. Second Annual MSU MPEG-4 AVC/H.264 Video Codec Comparison
1. 2005年コデック比較テスト。
   
4. x264 Codec Improvement
1. ABR（2パス）におけるx264の改善。ソース配布有り。

で、その"COMPRESSION PROJECT" とはナニモノか？

　随所にMSUという文字がある。Moscow State Universityの事のようだ。モスクワ州立大学（？）

wikipedia：モスクワ大学-- 太字オレ

---

モスクワ大学（モスクワだいがく、Московский государственный университет имени М.В. Ломоносова, M.V. Lomonosov Moscow State University）は、ロシア・モスクワにある大学。ロシアでは通常МГУ（エム・ゲー・ウー）と呼ばれ、M.V.ロ モノーソフ記念モスクワ国立総合大学の略称である。

　ロシア国内では最高学府とされ、世界的にもよく知られた総合大学の1つである。

　ようするに東大だべ。

　「モスクワ州立大学」でぐぐると、東欧にはスゲェプログラマが沢山いるんだけど、IT産業がアレでいい仕事があまり無いのですよと いう話が出て来た。2005の国際大学対抗プ ログラミング・コンテストでも「モスクワ州立大学」になってるね。ちなみにこのコンテストの主催者ACMってのは Association for Computing Machinery、アメリカの計算機学会。コンピュータ全般における権威のラスボスだ。
　ゲーマー的に旧共産圏といえば、テトリスの昔からアレ目なハードで工夫の限りを尽くす人々。北朝鮮の囲碁ソフトとかもなんかスゲェらしい。

Second Annual MSU MPEG-4 AVC/H.264 Video Codec Comparisonについて

　2005年コデック比較テスト。参加コデックは以下。

DivX 6.0 (Not H.264 video codec, tested as reference codec)

ArcSoft H.264

Ateme H.264

ATI H.264

Elecard H.264

Fraunhofer IIS H.264

VSS H.264

x264

　結論は以下（試訳）。2005末時点のテストである事に注意。

http://www.compression.ru/video/codec_comparison/mpeg-4_avc_h264_2005/part4.htm

---

• 前年の比較テストと比べると、H.264 規格コデックの水準は極めて向上した。１年前にはMPEG4-ASP 規格のベストコデックはH.264規格のベストコデックに匹敵したが、今やその状況は大きく変わった。DivXコデックには少なからぬ向上が見られるにも 関わらず、新規格コデックの大半に引けを取る。
• 新規格コデックのうち明白に水準を抜いたものを選ぶ事は困難だが、x264 と Ateme が全般的にベストの結果を出した。
• 速度面では明白にATIが抜きん出た。またそれ以外の面が必ずしも悪いわけでもない。

　詳細は、比較項目は多岐に渡り、図表だらけで科学的で分析も細かくて手が出ない。Doom9コデックコンテストがマニアの集合知（CGM）の極点なら、 ここがネットで見れる範囲では、アカデミズム側の極点だろう。
　2006年、第３回の募集は８月に締め切り済み。

・ http://forum.doom9.org/showthread.php?t=95939
現存するMPEG-4 AVC/H.264 コデックの一覧

プロファイル

　H.264/AVC には多数の符号化ツールがあるが、全てのアプリケーションで全てのツールが必要とされている訳ではない。例えば、洗練されたエラー耐性ツールはデータロス や破壊が非常に少ないネットワークでは重要ではない。全てのアプリケーションに全ツールのサポートを強制した場合、無駄に複雑なアプリケー ションが出て来てしまうだろう。このため、符号化ツールのサブセットが定義された。これをプロファイルと呼ぶ。 デコーダでサポートするサブセット（プロファイル）はどれか一つだけでも自由だし、複数や全てサポートしても自由だ。H.264/AVC最初の規 格では、以下の三つのプロファイルが定義され、最新版でもそのまま残っている。：

• Baseline (BP)
• Extended (XP)
• Main (MP)

　Baseline profile（BP）がサポートするのは I およびPスライス、一部の高度なエラー耐性ツール（FMO, ASO, RS）、そしてCAVLC。B、SP、SIスライス、インターレース符号化ツール、CABAC エントロピー符号化はサポートしない。Extended profile（XP） はBaselineのスーパーセットで、上記にB、SP、SIスライス、インターレース符号化ツール、そして、データパーティショニング（DP）によるエ ラー耐性の向上を加えたもの。CABACはサポート外。Main profile（MP） がサポートするのは I、P、Bスライス、、インターレース符号化ツール、CAVLCとCABAC。高度なエラー耐性ツール（FMO, ASO, RS, DP）やSP、SIスライスはサポート外。

　 本稿執筆時点（＊2004/08月＊）では、 Baseline Profile はビデオ会議のプライマリ・チョイスのようだ。Main profileは、エンターテインメント品質のコンシューマー・アプリケーションで大きな関心を集めてきたが、勢いはFRExtの新しいHigh profileの登場により弱まりつつある。
　プロファイルは、想定する主な用途に対応して7種類あり、各々において使用するツール と処理範囲等を定めている。レべルは、取り扱う映像の画素数に対応して16種類が定められている。

FRExt 改正により、以下4のprofileが追加定義された:

• High (HP)
• High 10 (Hi10P)
• High 4:2:2 (Hi422P)
• High 4:4:4 (Hi444P)

　 これら４つのプロファイルは、Main profileのデザインの上に構築され、共通するのは以下の４点；

• 適応的マクロブロック・レベルスイッチング。8x8と4x4変換ブロックサイズの自動選択が可能になった。
• （＊Adaptive macroblock-level switching between 8x8 and 4x4 transform block size＊）
• エンコーダが固有の人間の視覚認識 ベースの量子化スケーリングマトリクス（カスタム量子化マトリクス）を使える。
• （＊Encoder-specified perceptual-based quantization scaling matrices＊）
• エ ンコーダは独自に各彩度コンポーネント（＊CbとCr＊）に独立した量子化パラメータを使える。
• （＊Encoder -specified separate control of the quantization parameter for each chroma component＊）

　 一般的な4:2:0 videoに加え、これらのプロファイルは全て、白黒符号化されたビデオシークエンスもサポートする。新プロファイル間の違いは主にサポートする色深度と 色差信号(＊chroma＊) フォーマットだ。ただし、High 4:4:4 はさらに、residual（＊ 残りの＊） color transform と predictive（＊予測＊） lossless coding の機能を持つ。これは他のプロファイルには存在しない。詳細は以下。

プロファ イル

Coding Tools	Baseline	Extended	Main	High	High 10	High 4:2:2	High 4:4:4
概要	双方向予測やインタレース映像への処理等を省いた基本的ツールで構 成。 伝送エラー耐性用ツールを含む。	Baselineを包含すると共に、よ り高画 質・高度化のためのツールを追加。	標 準的ツール群で構成される代表的なプロファイル。 FMO,ASO,RS(注7)を除くBaseline プロ ファ イルを包含。	Mainを包含する と共に、HDTV映像等の高画質化用拡張(FRExt)ツール群を追加。	Highに10ビットサンプリング映像対応を追加。	High 10に4:2:2クロマフォーマット対応を追 加。	High 4:2:2に12ビットサンプリング映像および4:4:4クロマフォ ーマット対応を追加。
主 要用途	モバイル放送、ネット 配信など	高 度な配信など	放送、蓄積メディア、 配信など	高 画質放送、蓄積メディア、スタジオ(編集・蓄積)など	素材配信、スタジオ(編集・蓄 積)など	素材配信、スタジオ(編集・蓄積)など	素材配信、ス タジオ(編集・蓄積)など
スライス
I 、Pスライス	◯	◯	◯	◯	◯	◯	◯
B スライス		◯	◯	◯	◯	◯	◯
イ ンターレース符号化 (PicAFF, MBAFF)		◯	◯	◯	◯	◯	◯
エントロピー符号化
CAVLC	◯	◯	◯	◯	◯	◯	◯
CABAC			◯	◯	◯	◯	◯
整数変換（DCT？）
8x8 または 4x4 の適応変換				◯	◯	◯	◯
量子化制御
カ スタム量子化マトリクス				◯	◯	◯	◯
CbとCrの個別 QPコントロール				◯	◯	◯	◯
重 み付け予測	-	◯	◯	◯	◯	◯	◯
色関係
モノ クロ映像フォーマット				◯	◯	◯	◯
9 および10 Bit サンプル深度					◯	◯	◯
11 および12 Bit サンプル深度							◯
8 Bit サンプル深度	◯	◯	◯	◯	◯	◯	◯
4: 2:0クロマフォーマット	◯	◯	◯	◯	◯	◯	◯
4: 2:2クロマフォーマット							◯
4:4:4クロマフォーマット							◯
エラー耐性
高度 なエラー耐性 (FMO, ASO, RS)	◯	◯		◯	◯	◯	◯
よ り高度なエラー耐性 (DP)		◯		◯	◯	◯	◯
SP、 SIスライス		◯		◯	◯	◯	◯
その他（不詳）
Residual Color Transform							◯
Predictive Lossless Coding							◯

　高位のプロファイルは下位プロファイルの機能を包含する。規格上も高位プロファイルに対応するものは 下位プロファイルのビットストリームは全てデコード可能でなければならないとしている。

　High profileが短期間に極めて大きな関心を集めている理由は、実装上の複雑さがMain profileに比べて非常に小さく（ほとんど無い）、その一方で圧縮能力は主観的にも客観的に も向上（特にカスタム量子化マトリクスと適応的マクロブロック・レベルスイッチングによる）し、エンコーダ制御の自由度も増すためだ（CbとCrに独立し た量子化パラメータを使える事による）。

---

【元ネタ１】
【元 ネタ２】

レべル

 　 H.264/AVCでは16種類のレベルが定められている。 　
　取り扱う映像の画素数とフレームレートに対応しているが、これはそ れらが実際の製品開発で重要なCPUパワーとメモリサイズの制約への影響が最も大きい為だ。また、最大 参照フレーム数と、最大ビットレートもレベルにより制限がある。
　"1b"のようなレベルはFRExt改正で追加されたもので、主に3Gワイヤレス環境の要請に応えるためのもの。
　FRExt profileはより忠実度の高いアプリケーションの為の定義なので、ビットレートの許容範囲も表１のように拡大した。この係数は表２の７番目の列（非 FRExtでの最大圧縮ビットレート (VCL用)）で使われるものだ。
 
　Note： 規格上、Levelが規定する最大フレームサイズとは、pixel/frameの合計数だけだ。水平・垂直それぞれの最大サイズは、Sqrt （maximum frame size * 8）以下でなければならない事を除けば規格には無い。（＊8の倍数でも良い？＊）
　も し、ある特定 のレベルで、ピクチャ・サイズが表のサイズより小さければ、それに応じて動き予測と動き補償にもっと大きな数のマルチプル・レファレンスピクチャ（＊複数 参 照＊）が使える（最大16）。同様に、それぞれのレベルで最大フレームレートを指定する代わりに最大サンプル（ピクセル）レートが、マクロブロック /secという用語で規定されている。従って、もしピクチャ・サイズが表２の一般的なサイズより小さい場合、フレームレートは表２にある値よりも大きくと り得る。最大は172fps。各レベル・解像度ごとに対応可能な最大fpsは表３を参照。

表 １：Compressed Bit Rate Multipliers for FRExt Profiles (表２の第７列参照)

FRExt Profile	Bit Rate Multiplier
High	1.25
High 10	3
High 4:2:2	4
High 4:4:4	4

表 ２ H.264/AVCのレベル

レ ベル	最大 フレーム サイズ (MBs)	最 大 MB処理 レート (MB/s)	最大映像 ビッ ト レート (kbps)	一般的な ピクチャ サ イズ	一般的なfps	非FRExt での最大 圧 縮ビット レート  (VCL用)	一 般的な ピクチャ サイズで の最大参 照フレーム数	符 号化 ピクチャ	想 定プロファイル （下記に限定されない）				備考
1	99	1485	64	QCIF	15	64 kbps	4	フレームMBのみ	BP	EP
1b	99	1485	128	QCIF	15	128 kbps	4
1.1	396	3000	192	CIF or QCIF	7.5 (CIF) / 30 (QCIF)	192 kbps	2 (CIF) / 9 (QCIF)
1.2	396	6000	384	CIF	15	384 kbps	6
1.3	396	11880	768	CIF	30	768 kbps	6
2	396	11880	2000	CIF	30	2 Mbps	6
2.1	792	19800	4000	HHR (480i or 576i)	30 / 25	4 Mbps	6	フレームまたはフィールド			MP
2.2	1620	20250	4000	SD	15	4 Mbps	5
3	1620	40500	10000	SD	30 / 25	10 Mbps	5					HP～
3.1	3600	108000	14000	1280x720p	30	14 Mbps	5
3.2	5120	216000	20000	1280x720p	60	20 Mbps	4
4	8192	245760	20000	HD Formats (720p or1080i)	60p / 30i	20 Mbps	4
4.1	8192	245760	50000	HD Formats (720p or1080i)	60p / 30i	50 Mbps	4
4.2	8704	522240	50000	1920x1080p	60p	50 Mbps	4	フレームMBのみ
5	22080	589824	135000	2kx1k	72	135 Mbps	5
5.1	36864	983040	240000	2kx1k or 4kx2k	120 / 30	240 Mbps	5						x264 デフォルト

表 ３：各映像サイズに対応可能なレべルと最大フレームレート(fps)

映像フォーマット	輝度の WxH	最 大 フレーム サイズ （MBs）	1.0	1b	1.1	1.2	1.3	2	2.1	2.2	3	3.1	3.2	4	4.1	4.2	5	5.1
SQCIF	128×96	48	30.9	30.9	62.5	125.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0
QCIF	176×144	99	15.0	15.0	30.3	60.6	120.0	120.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0
QVGA	320×240	300			10.0	20	39.6	39.6	66.0	67.5	135.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0
525 SIF	352×240	330			9.1	18.2	36.0	36.0	60.0	61.4	122.7	172.0	172.0	172.0	172.0	172.0	172.0	172.0
CIF	352×288	396			7.6	15.2	30.0	30.0	50.0	51.1	102.3	172.0	172.0	172.0	172.0	172.0	172.0	172.0
525 HHR	352×480	660							30.0	30.7	61.4	163.6	172.0	172.0	172.0	172.0	172.0	172.0
625 HHR	352×576	792							25.0	25.6	51.1	136.4	172.0	172.0	172.0	172.0	172.0	172.0
VGA	640×480	1200								16.9	33.8	90.0	172.0	172.0	172.0	172.0	172.0	172.0
525 4SIF	704×480	1320								15.3	30.7	81.8	163.6	172.0	172.0	172.0	172.0	172.0
525 SD	720×480	1350								15.0	30.0	80.0	160.0	172.0	172.0	172.0	172.0	172.0
4CIF	704×576	1584								12.8	25.6	68.2	136.4	155.2	155.2	172.0	172.0	172.0
625 SD	720×576	1620								12.5	25.0	66.7	133.3	151.7	151.7	172.0	172.0	172.0
SVGA	800×600	1900										56.8	113.7	129.3	129.3	172.0	172.0	172.0
XGA	1024×768	3072										35.2	70.3	80.0	80.0	170.0	172.0	172.0
720p HD	1280×720	3600										30.0	60.0	68.3	68.3	145.1	163.8	172.0
4VGA	1280×960	4800											45.0	51.2	51.2	108.8	122.9	172.0
SXGA	1280×1024	5120											42.2	48.0	48.0	102.0	115.2	172.0
525 16SIF	1408×960	5280												46.5	46.5	98.9	111.7	172.0
16CIF	1408×1152	6336												38.8	38.8	82.4	93.1	155.2
4SVGA	1600×1200	7500												32.8	32.8	69.6	78.6	131.1
1080 HD	1920×1088	8160												30.1	30.1	64.0	72.3	120.5
2Kx1K	2048×1024	8190												30.0	30.0	63.8	72.0	120.0
2Kx1080	2048×1080	8704														60.0	67.8	112.9
4XGA	2048×1536	12288															48.0	80.0
16VGA	2560×1920	19200															30.7	51.2
3616x1536 (2.35:1)	3616×1536	21696															27.2	45.3
3672x1536 (2.39:1)	3680×1536	22080															26.7	44.5
4Kx2K	4096×2048	32768																30.0
4096x2304 (16:9)	4096×2304	36804																26.7

---

【元ネタ１】
【元 ネタ２】

1. 『H.264/AVCは縦横とも16画素の倍数でないと符号化できない』

改訂版H.264/AVC教科書、p183
※太字オレ

---

例 えばHDTVの場合、走査線の数は1080本です。これに対してH.264/AVCでは垂直、水平方向とも16画素の倍数で ないと符号化できません （1080本は16の倍数ではない）。例えば、1088本（16の倍数）を符号化した場合、8ラインを捨てて表示する必要がありますが、この場合、クロッ ピング処理によって、ビットストリーム中でどの上下8ラインを捨てるのかを明示的に指定する事ができます。

　※この「明示的な指定」は、x264cli、VUI設定の--overscanで行う（参考1, 2）。

2. 8x8や4x4は16x16マクロブロックのサブ区分と思われる

Introduction paper to H.264/MPEG-4 AVC includingthe Fidelity RangeExtension. （PDF）
2. 符号化ツール（試訳）

---

各ピクチャは一個以上のスライスに分割することで圧縮される。各スライスはマクロブロックからなる。さらにこれは16x16ピク セルの輝度サンプ ルと、それに対応する輝度サンプルからなる。しかしながら（＊これまでとは異なり＊）各 マクロブロックは、動き補償予測の為に、さらにサブ・マクロブロック・パーティションに分割される。予測パーティションのサイズは７種類となる。 – 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 そして4x4だ。これまでの規格では、動き補償はマクロブロックを丸ごと使うか、新しめの規格では16x16 か8x8パーティションを使った。従って、パーティションの形にバリエーションが増えたという事は、予測精度の向上をもたらす。次に、残ったデータは 8x8（FRExtでしか使えない）か4x4で空間軸変換される。過去の主要規格ではこの変換ブロックサイズは8x8のみだった。4x4ブロックサイズの 採用で残りの差分信号の精度が向上する事になる。空間軸変換のブロックサイズは常に予測に使われるブロックサイズと同じか、より小さい。ビデオシークエン スのシークエンスからサンプル（*原注：ここでは特にサンプルとピクセルを区別しないが、厳密にはサンプルが正しい。）に至る階層構造は以下のようにな る。

シークエンス（ピクチャ（スライス（マク ロブロック（マクロブロック・パーティション（サブ-マクロブロック・パーティション（ブロック（サンプル））））））

ニコンシステム(株)H.264 解析ツールNH264H1のpdf
http://www.nikon-sys.co.jp/products/index_1_1.htm

---

　※これらから、4x4や8x8は16x16に対するサブ区分と思われる。一番右下、田の字型に分割されてるのが8x8だと思う。

3. cropやscaleで縦横を8や4の倍数にするとMEncoderはエラーメッセージを出す。
　ただしエンコードは進行する。

4. Xvidやlibavcodec mpeg-4では、縦横16倍数は鉄のオキテ

MEncoder Document/ DVD映像を高画質なMPEG-4 ("DivX")にする方法/効果的にエンコードするための制限事項（試訳）

---

最 高画質を追求する場合、MPEG系圧縮の特徴からくるいくつかの制限事項を守る必要があります。MPEGは映像をマクロブロックと呼ばれる16x16の正 方形に分割します。各マクロブロックは、輝度（強度）情報を表す4個の8x8ブロックと、2個のハーフ・レゾリューション8x8ブロック（red- cyan 軸とblue-yellow軸）で構成されます。手許の動画の横幅と高さが16の倍数でない場合でも、エンコーダは映像全体をカバーできるだけの 16x16マクロブロックを使うので、余聞な無駄が出ます。
ですので、目標ファイルサイズの範囲で最高画質を求める場合は、16の倍数以外の縦横は使わないようにしよう。

　※Xvidやlibavcodec mpeg-4では、入力映像の縦横が16の倍数でなかった場合、勝手に16の倍数まで映像領域が「あるものとして」エンコードする。
　　自分はこれを訳す過程で、16倍数はMPEG-1/2/4 に跨がる鉄のオキテと認識した。AVC | H.264においても三つ子の魂で。テストはしていない。

5. 少なくともx264では、画質への影響は軽微らしい。

2ch/DTV/x264 rev7（2006年11月下旬～12月上旬）

---

1. やっぱり16の倍数じゃないとダメっぽいとあったのですが、みなさんは16:9の映像の場合どのような解像度にしています か?
2. 704x480(DVD左右クロップ) --sar 40:33
3. 自動的に無効領域が追加されて16の倍数になるから問題なし
4. 俺も気にしてないな。画質は全然落ちないし
5. 俺は気にしてる。16の整数倍にしないとなんとなく暗部とか薄いグラデーションとかでブロック ノイズ増える気がする。ただの気のせいかもしれないけど。
6. 画質に関しては関係ないと思うけど、16の倍数だと動画の圧縮率や精度が向上するのは確かだと 思うよ

　※画質的な問題を感じている人はほとんど無いようだ。
　※ただし、上記1.2.3.補足的に4.までは16倍数制限の存在を明示、または示唆している。
　　2ch/Doom9ともに、アニメ派が中心な事も一応さっぴいて考えるべきかと思う。手許でもアニメのほうが多いっつうのはともかく。

6. さしあたっての結論
　H.264/AVCは、縦横が16の倍数でなかった場合でも、バリエーションが増えたマクロブロック・パーティション（x4 .. x8 .. x16）を駆使して、画質への影響をある程度封じ込める事ができると思われる。
　実用上の画質劣化は、少なくともx264では、無視できる範囲と思われるが、程度は素材に依り異なるだろう。

---

余談
　アニメの情報量は非常に少ない。基本だけど。
　人間の脳が受ける「印象」のハナシではなく、必要bit量とでも言うか、ともかくCPUから見てのハナシ。
　アニメの場合、なにがどうだろうと、単色のっぺりの「アニメ塗り」が映像に占める割合が多い（実写に比べてディテイルが圧倒的に少ない）。
　背景やテクスチャの精細さが際立って見える作品も多いが、その印象は前景のキャラが「アニメ塗り」だからだ。
　キャラクタの顔に皺や毛穴やニキビは無いし（この点、役者がドーラン塗りまくってる初期のカラー映画は結構圧縮しやすい）。
　着物の質感というのもまず無い（例外）。

1. MPEG-4Part 2 のプロファイル
2. Advanced SimpleProfile (ASP)
   1. Bフレーム/B-VOPS/双方向予測（符号化）
   2. 1/4ピクセル精度の動きサーチ (QPEL):
   3. グローバル動き補償 (GMC):
   4. MPEG量子化マトリクス / カスタム 量子化マトリクス:
   5. 適応的量子化:
3. 入手可能なMPEG-4 ASP コデック
   1. XviD
   2. DivX5
   3. ffmpeg
   4. 3ivx
   5. Nero Digital
4. ハードウェアにおけるMPEG-4 ASP -DivX/NeroDigital Certification / Private MPEG-4 Profiles
5. その他の情報

ISO 14496-2 (Video) - Advanced Simple Profile (ASP)

　MPEG-4規格は幅広い動画符号化ツールを規格化しています。現在、最も広く使われているものはISO14496-2で定義されています。この規格がしばしばMPEG-4 "Part2"と呼ばれるのはこのためですが、ここでは次に説明する理由でMPEG-4 ASPと呼ぶ事にします。

MPEG-4Part 2 のプロファイル

　前述の通り、MPEG-4規格は幅広いアプリケーションで使われる事を狙っています。もちろん、目的によって必要な符号化ツールは異なります（非常に低いビットレートでストリーミングをする場合と、中～高ビットレートでDVDのバックアップを作る時とでは、別の符号化ツールを使うことでしょう）。
　さまざまなニーズをカバーするために、MPEG-4規格は大量のプロファイルとレベルを定めています。それぞれのプロファイル/レベルは相互運用性や適合性の目安となるものです。ある特定のプロファイル/レベルに従っていれば、全ての製品が、たとえ他の会社の製品であっても、協調できるようにするためのものです。
　これらのプロファイル/レベルは使っても良い符号化ツールだけでなく、使っても良いビットレートの範囲、映像の解像度、フレームレートなども定めています。
　MPEG-4プロファイルの概要はここを見て下さい。

Advanced SimpleProfile (ASP)

　DVDバックアップが目的なら、Advanced Simple Profile @ Level5 (ASP@L5) が最適でしょう。
　ASP@L5の最大解像度は720x576、最大フレームレートは30fpsで、B-Frames (B-VOPS)、QuarterPixelMotion Estimation (QPEL)、Global Motion Compensation(GMC、グローバル動き補償)、MPEG/CustomQuantizationなどの先進的な符号化ツールを使っても良い事になっています。一方、SimpleProfile(SP)では、最大解像度は352x288、最大フレームレートは15fpsに過ぎません。


　Advanced Simple Profileの符号化ツールで最も大事なものは以下の通り（SimpleProfileでは使えないもの）：

入手可能なMPEG-4 ASP コデック

　現在入手可能なASPコデックは、 XviD( binary), DivX5, DivX4/OpenDivX, ffmpeg/ ffvfw/ffdshow, 3ivx, NeroDigital, Skal, Quicktime, mpegable, Envivio, Sorenson 、などなどなど...
　Doom9の画質比較はここにあります: 1 2
　（DivX3.11 別名 MS MPEG-4、RV9、VP6、WMV9はMPEG-4規格には適合していない事に注意して下さい！）

ハードウェアにおけるMPEG-4 ASP -DivX/NeroDigital Certification / Private MPEG-4 Profiles

　第一世代のハードウェア・デコーダ・チップの中にはASPの重要な符号化ツール（QPELやGMCなど）を扱えないものがありました。現在のチップはより強力で、例えばQPELやワープポイント１個のGMCが扱えるようになっています（これまでのところワープポイント３個のサポートはありません）。
　古いチップを使ったプレイヤでもサポートできるように、DivXNetworks とNeroはプライベートMPEG-4プロファイルとでも言うべきものを作っています。それぞれ、DXNHome Theater Profile (DXN HTP) 、ND Standard Profile (ND StP)と言う名前です。
　DXNHTP や ND StP（他にも数種類のプロファイルがあります）を扱えるプレイヤはどこの製品であれ、DivXNetworks とNeroから認証を受ける事が出来ます。
　例えば、HTP/StPに適合するようにエンコードする場合、QPELまたはGMC、それから最大１枚のBフレームが使えます。ですから、HTP/StPは基本的に画質と古いデコーダチップとの互換性の取引です。
もちろん、これらのプライベート認証はDivXNetworks と Neroのブランドネーム向上にも役に立ちます。

　しかしながら、我々がプレイヤに望むものを正確に表現する言葉は、MPEG-4ASP@L5です。もしもあなたのプレイヤがこれに対応しているならば、どのエンコーダを使おうとも、MPEG-4ASPに従って作ったファイルを問題無く再生できます。

その他の情報

MPEG-4Videoに関する詳細は MPEGIndustry Forumへ、ここには入手可能な Resourcesと Tutorials/Papersの概要がある。
14496-2改正1の規格は ここ。
Moving Picture Experts Group (MPEG)も重要だ。ここには MPEG-4 Videoの FAQ や、 MPEG-4 Standardの概観がある（MPEG-4Videoにかんする情報も沢山ある）。
それから googleで"MPEG-4"を検索すれば、大量の有益なサイトが見つかるだろう。
__________________
弱者と強者の間にあっては、自由は抑圧の源であり、それを解放するものが法である（ジャン・ジャック・ルソー）
私が自分が何も知ってはいない事を知っている（ソクラテス）

Lastedited by bond : 2005/06/19

• 1）MP4とはなんですか？「コンテナフォーマット」って聞いたけど、ソレ何？
• 2）MP4の拡張子にはどんなものがあるの？
• 3）MP4規格に適合したファイルを作るにはどうすれば？
• 4）MPEG-4 規格外のストリームをMP4に入れられる？
• 5）AVIからMPEG-4映像をMP4にmuxするとき、どんな事に注意すれば？
• 6）MP4にmuxし直すと再エンコードになりますか？
• 7）字幕をMP4にmuxするには？
• 8）MP4ファイルの中にチャプターを作るには？
• 9）MP4ファイルにタグを付けるには？
• 10）様々なトラックに関する情報をMP4ファイルの中に保存するには？
• 11）MP4ファイルのオーサリング（例えばDVDメニューのような）をするに は？サンプルとかありますか？
• 12）MP4で "アナモルフィック・リサイズ" をやる方法は？
• 13）MP4に可変フレームレート（VFR）コンテントを入れられる？
• 14） MP4ファイルの再生はどうやったらいいですか？
• 15）MP4の（ライブ）ストリーミングを見たり、流したりするには？
• 16）MP4のビットレート計算機はありますか？どうしてAVIから作成した MP4ファイルは元のAVIより小さくなるの？
• 17）MP4はCRC、EDC、ECCをサポートしていますか？
• 18）MP4ファイルを作るのに使われたコデックを判別する事はできますか？
• 19）MP4はMP3の次？
• 20）MP4とMOV/3GPは同じものですか？
• 21）MP4のその他の情報は？

1）MP4 とはなんですか？「コンテナフォーマット」って聞いたけど、ソレ何？

　様々な マルチメディアストリーム（大半はオーディオとビデオ）を一つのファイルに入れる為のコンテナフォーマットです。
マルチメディアコン テナは例えば、有名なAVI (.avi)、MPEG (.mpg, .mpeg)、Matroska (.mkv, .mka)、OGM (.ogm)、Quicktime (.mov) 、Realmedia (.rm, .rmvb)などがあります。

　MP4はMPEG-4 規格 (ISO 14496-14)で決められた公式コンテナフォーマットの汎用拡張子です。
MP4 はストリーミングに対応しており、全てのマルチメディアコンテント（複数音声、複数映像、字幕ストリーム、静止画、可変フレームレート、可変ビットレー ト、可変サンプルレート、などなど）、ならびに、2D や 3Dのアニメーション・グラフィックス、インタラクティビティ、DVD的なメニューなどのより先進的なコンテント（公式には"Rich Media" または "BIFS"）をサポートしています。AVIではほぼ望めないといって良いでしょう。

2）MP4 の拡張子にはどんなものがあるの？

• .mp4：唯一の公式な拡張子。オーディオ、ビデオ、 アドバンスド・コンテント、およびそれらを複合したもの全てに使う。

• .m4v：. mp4 ファイル。appleが video+audio ファイルに使う間違った拡張子(*1)。そのまま .mp4にリネームしても大丈夫。
•  .m4a:  .mp4 ファイル。appleが audioのみのファイルに使う間違った拡張子。そのまま .mp4にリネームしても大丈夫。
•  .m4p：iTunesで売っている DRM 保護付きファイル。apple製の DRM を使う。
•  .m4e：Envivioがストリーミングに使う。.sdp ファイルをリネームしたもの。
•  .m4v, .mp4v, .cmp, .divx, .xvid, .264：通常は raw mpeg-4 ビデオストリーム（MP4コンテナに入っていない状態）（＊QuickTime Player Proでは扱えない＊）
• .aac： raw aac オーディオストリーム/adts （MP4コンテナに入っていない状態）
•  .3gp, .3g2：携帯電話が使う。.mp4 に定義されていないコンテンツも入る （H.263, AMR）Q 20参照。
• .mov： 技術的によく似たコンテナだが、MP4と同じではない。Q20参照。

3）MP4 規格に適合したファイルを作るにはどうすれば？

　簡単な解答：Doom9 の MP4 ガイド、または Nero Recode2 ガイド
　詳細な解答：

1. MP4ファイルに入れるなかみは、MPEG-4 規格上に存在する audio/video フォーマットを使うのが望ましい。
• MP4 ビデオフォーマット：
• MPEG-4 SP/ASP： XviD, DivX5, 3ivx, ffmpeg/ffdshow, NeroDigital ASP... 
• MPEG-4 AVC/H.264： x264, NeroDigital AVC, Apple...
• MPEG-2
• MPEG -1（DivX3/MS Mpeg-4、WM9、RV9、VP6などは異なる）。
• doom9による画質比較は こちら：1 2。
• MP4 オーディオフォーマット：
• Advanced Audio Coding (AAC FAQ): Quicktime/iTunes, Nero, Psytel, FAAC (binary)... 
• （rjamorim による音質比較はこちら：1 2) 
• MP3
• MP2
• MP1
• CELP (speech)
• TwinVQ (very low bitrates)
• SAOL (midi)
• ALS (lossless)
• MP4 subtitle/textフォーマット：
• MPEG-4 Timed Text（Q7参照）
• MP4 pictureフォーマット：
• JPEG, PNG
2. MPEG-4 互換コンテンツを MP4 コンテナにmuxするには以下のツールを使う：
1. GPACの MP4Box。コマンドライン。AVC、packed b-frames、advanced content/BIFS、TTXT、Chaptersをサポート。（Doom9 Guide、同試訳）
2. MPEG4IPの mp4creator。コマンドライン。AVCをmuxできる。AVI と packed b-framesには使わない事！
3. 3ivx mp4 muxer。dshow filter、Grapheditで使える。 packed AVI b-frames をサポートしているが、AVCは非対応（3ivx Guide）。
4. mp4UI。MPEG4IPがベース。AVC、AVI、および (packed) b-framesには使わない事！
5. VideoLAN。AVCをmuxできる。 (packed) b-framesには使わない事！
6. ffmpeg。 バギー。コマンドライン。AVC、AVI、および (packed) b-framesには特に使わない事！
7. IBM の Toolkit for MPEG-4 。Javaベースの XMTBatch and/or AVGen (also a simple version) を含む。
8. dvd2mp4gui。mp4toolを使うGUI。複数音声と字幕スト リームのmuxをサポート（advanced content）。
9. ENSTのmp4tool/mp4edit。BIFSをサポート。mp4edit はコマンドラインであるmp4toolの "light"版 GUI。
3. 以下のような "all-in-one" MP4 エンコードツールもある：
1. Nero Recode2。ASP または AVC と AACの入ったMP4をエンコードできる (Doom9 Guide)。字幕は DVD VobSub（＊MPEG-4規格外＊）。dshow muxer入り。
2. Doom9のMeGUI。ASP (Xvid, libavcodec)、AVC (x264) 、AAC (Besweet - Nero)でのエンコードをサポート（＊tag:MeGUI参照＊）
3. HDX4。ASP とAACをサポート。
4. Dicasの mpegable X4 live。Dicaの codecを使ってMP4を作成できる。
5. Envivioの4Coder 。MPEG-4 AAC、ASP/SP、AVCのエンコード。
4. MP4ファイルのエディットツール (分割や追加など) ：
1. MP4Box。MP4の分割 (AAC, ASP, AVC, TTXT, MPEG-1/2, プライベート・ストリーム) 、分割は時間ベースとサイズベース。他にパーツの抽出や MP4 の結合（＊カテゴリ:MP4box参照＊）。
2. Ulead の VideoStudio 8 。MPEG-4 pluginが必要。
3. Sonyの Vegas 6
4. Quicktime/Pro MP4ファイルの作成（エンコード,mux）とエディット（分割,結合）ができる。MPEG-4 Simple Profile, AAC, AVCをサポート。
   

4） MPEG-4 規格外のストリームをMP4に入れられる？

はい。私は好みませんが。
MPEG-4規格はい かなるストリームも収める方式を定義しています。AVIにプライベートFourCCを付けたストリームを入れるの に似ています。MP4では、"private track ID"を使います。そのようなストリームを再生できるプレイヤは恐らく出てこない事に注意して下さい。ただし、特に設定されていなければ、プレイヤは こうしたストリームを無視するでしょう。

現在MP4に収められるMPEG-4規格外ストリームは以下のとおり：

• Ogg Vorbis と Ogg Theora。要MP4Box。
• Ogg Vorbis。要 patched mp4creator。
• Apple の ロスレス・オーディオ (ALAC/ALE - MPEG-4 ALS非互換)。要iTunes。
• DVD ピクチャ字幕 (Vobsubs)。要 Nero Recode2。

こうしたプライベートストリームが普及し、広く サポートされるかどうかは、未来を待つしかありません。

5）AVIからMPEG-4映像をMP4にmuxするとき、どん な事に注意すれば？

　AVIからMP4にmuxする事には潜在的な問題があります。b-frames/B-VOPs/bi- directional encodingを使っている場合は特に：

1. "delay frames"。原因は古い VFW インターフェイスにあり、今でも使うコデックがある (XviD, DivX5)。b-frameを使う場合、VirtualDub/Mod でこれらのコデックを使う場合のみ、"delay frames"は自動的にドロップされる。
2. "packed bitstream"。原因は古いAVIコンテナ。AVIは本来はb-frameを収める事が出来ない。PBは DivX5 （連続b-frame1がセットの時のみ）が使う。また、新しいXviDビルドはデフォルトで、b-frameを他のフレームと"パック"する（XviD オプションでPB optionのチェックをちゃんと外す事）。AVIとB-frameに関する詳細はこちら（＊試訳＊）。
3. "userdata"。XviD と DivX PBストリームがPBを使っている場合にその存在を示すフラグ。一部のデコーダはこのフラグを（＊映像の一部として？＊）デコード する。
4. "vol"。AVIで全てのキーフレーム に付加されているものだが、MP4ではムービーデータとは別個にしてやる必要がある。
5. "ctts" atom。MP4にb-frameをmuxする際に書き込む必要がある。

　現在、これら全てを正しく扱えるのは 3ivx mp4 muxer と GPACの MP4Box だけだ！
　AVIからの変換にはこの二つ以外使わないように。packed bitstreamがある場合や、あるかどうかよくわからない場合は特に。
　さもないと規格適合性が不完全なMP4ファイルが出来る 可能性が非常に高くなる！

6）MP4にmuxし直すと再エンコードになりますか？

　 いいえ。
　このプロセス自体はロスレスです。単にメディアストリームをコンテナから取り出し、MP4コンテナに入れるだけです。

7）字幕を MP4にmuxするには？

　字幕をmp4に入れる方法は三つあります。：

8）MP4ファイルの中にチャプターを作るには？

　 チャプターを保存するには アドバンスド・コンテントを使います (例えばメニュー作成とか)。しかし Neroは MP4 の "user space" (udta atom) と呼ばれる機能を使います。これはMP4になんでも好きなものを入れられるatomです（例えばiTunesはMP4の udta atom に保存タグとcd/dvd-カバー（"coverart"）を入れています）。
　現在、Nero Recode2でエンコードするとMP4に自動的にチャプターを入れられます。既存のファイルは、MP4Box とRecode2に付属のMP4 directshow muxer filterで可能です（grapheditから使います）。
　再生面では、udtaの中にある 情報を読めないプレイヤは、単にこれを無視します。こうした特別なチャプタを使うには対応したplayer/filterが要ります。(例えば Gabest、Haali、Nero、3ivx)

9）MP4ファイルにタグを付けるには？

　MPEG -4規格には、タグ的な情報を収めるための "meta" atomというものがあります。しかしAppleはiTunesで、"udta" atom の中に utf-8 tagを入れるという、これとは異なったタグの付け方をしています（Q８参照）。
　MP4ファイルにapple 方式のタグ付けをするツールはたくさんあります。mpeg4ipのmp4tags、tg、AtomicParsleyなど。

10）様々な トラックに関する情報をMP4ファイルの中に保存するには？

　MP4コンテナは、各ストリームに付けた名前や、使用言語を保存する ことができます（ストリームがオーディオだろうがビデオだろうがアニメーションだろうが関係ありません）。
　使用言語は、例えば mp4box と quicktimeでセットできます。ストリームに名前をつける機能はNeroが持っており、各ストリーム毎の名前付けはmp4boxでできます。

11） MP4ファイルのオーサリング（例えばDVDメニューのような）をするには？サンプルとかありますか？

　IMOONのおかげで、い まや MP4MenuGUI （＊要.NET、Avisynth2.56＊）と いうツールが入手可能です。これを使って、MP4に簡単にDVDっぽいメニューを作る事が出来ます。このツールはXMT、またはbtと呼ばれるテキスト ベースの言語ファイル（有名なFlash同様、VRMLベース）を生成するので、これをBIFSと呼ばれるバイナリフォー マットにエンコード/コンパイルしてmp4に収めます（フリーのエンコーダとしては、 mp4box, mp4tool または XMTBatch）。

　もしも"自分の手で"MP4オーサリングしたり、MP4MenuGUIが吐いたスクリプトを弄りたければ、GPACのひとたちが書 いた素晴らしいチュートリアルが英語とフランス語で読めます。

　このプ ロセスを楽に済ませるために、私はサンプルスクリプトを書きました、 MP4Menuと 命名しましたが MP4MenuGUIをベースにしたものです。DVDメニューで出来る事はぜんぶ盛り込んでありますから、必要な機能をオンにするだけで済みます
（guide）。

　その他にMP4で出来る事が知りたければビデオ内にmenuを入れた menu sampleを見て欲しい。さらに、MPEG-4 System では2Dや3Dアニメーションも扱える（トイストーリーやファインディング・ニモのようなものを考えて欲しい）、ここに2D animation sample があるが、この中に はビデオストリームが入っていない！。
（＊ どちらも手許のQuickTime Player Pro、VLCでは正常再生できなかった＊）

 advanced contentの入ったMP4を再生するには、それを再生できるプレイヤが要る事を忘れないで。例えばGPAC Osmo4 player。

12）MP4で "アナモルフィック・リサイズ" をやる方法は？

　MPEG-4規格は"マルチタレント"、あらゆるニーズに応える事を狙っていますので、方式が ３つあります：

１）ビデオビットストリームレベルで指定する方式： ２） コンテナレベルで指定する方式：
３）BIFSレベルで指定する方式：

13） MP4に可変フレームレート（VFR）コンテントを入れられる？

　はい。
　タイムコードファイルを使います。これをMP4ファイルにくっつけるか、ASPならn-vopsをドロップさせます。

14） MP4ファイルの再生はどうやったらいいですか？

　MP4の大きなアドバンテージの一つは相互運用性と、オープ ン規格な事（ライセンスフリー！）です。これをサポートする非常にたくさんのツールが、全てのプラットフォームで出ています。Mac、Linux、 PocketPC、そしてもちろん Windows。

15） MP4の（ライブ）ストリーミングを見たり、流したりするには？

MP4のストリーミングについては、Apple と MPEG4IPが無償で良いツールを公開しています。
ストリーミングサーバとしては、Appleの Darwin Streaming Serverが使えま す。ガイドはeverwicked とlinuxjournalにあります。
ライブストリー ミンでは、Linuxのみですが、MPEG4IP の mp4live が使えます。ガイドは everwicked と MPEG4IPにあります。Windowsでは MPEGRecorder が使えます（どうやらmp4liveのポートのようです）。
ViTooKi の toolも試すと良いでしょう（オープンソースのストリーミングサーバ、Player、その他）
Cata からも、オープンソースのMP4ストリーミングサーバが出ています。
MAC では Live Channel を見て下さい。

ストリーミング放送の MP4を再生するには、AppleのQuicktime、RealのRealPlayer 10、MPEG4IPの WMP4Player、Dicasの mpegableおよび EnvivioTV （この二つは dshow playerです）そしてGPACの Osmo4 （最後の二つは streamed advanced content/user interactivitiyもサポートしています（Envivioのインタラクティブ・デモ））。
また、 MediaFrame (demos) と IBM (interactive demos)のjava appletを使うと、プレイヤをインストールしなくてもMP4ストリーミングを再生できます！。

ストリーミングのサンプル： 1 2

16） MP4のビットレート計算機はありますか？どうしてAVIから作成したMP4ファイルは元のAVIより小さくなるの？

17） MP4はCRC、EDC、ECCをサポートしていますか？

18） MP4ファイルを作るのに使われたコデックを判別する事はできますか？

19） MP4はMP3の次？

20） MP4とMOV/3GPは同じものですか？

21）MP4のその他の情報は？

んじゃ、がんばってくれ
bond
______________
弱者と強者の間にあっては、自由は抑圧の源であり、それを解放するものが法である（ジャン・ジャック・ルソー）
私が自分が何も知ってはいない事を知っている（ソクラテス）

Last edited by bond : 2006/09/10

ISO 14496-10 (ビデオ) - Advanced Video Coding (AVC)

1. ISO 14496-10 (ビデオ) - Advanced Video Coding (AVC)
   1. 概 要
   2. AVC/H.264 プロファイル
   3. 符 号化ツール
      1. CAVLC/CABAC:
      2. ループ/デブロックフィルタ
      3. 可変ブロックサイズ/可変マクロブロックパーティション
      4. 複数参照フレーム
      5. 適応重み補間予測
      6. レート歪み最適化（RDO）
   4. AVC/H.264 とその他のポピュラーなビデオ符号化フォーマットの比較
   5. 入 手可能な AVC/H.264 コデック
      1. エンコーダ
      2. デコーダ（比較）
   6. Sample content
   7. AVC/H.264 の問題点
      1. 相 互運用性の問題
      2. 速 度の問題
   8. ハー ドウェアにおけるMPEG-4 AVC/H.264 - HD-DVD/Blu-ray
   9. そ の他の情報

概 要

　MPEG-4規格はAVC/H.264で最新で、技術的にも素晴らしく、state-of-the-artのビデオ符号化フォーマットです。
　AVC/H.264 ビデオ符号化規格は2003年に二つの団体で策定されました。ISOのMPEGとITUのVCEG です。ITUは国連の下部組織で、H.263フォー マット(主にビデオ会議のソフトに使われてい ます)を策定した機関です。
　AVC/H.264 規格そのものの開発はJVTが 開発にあたりました。これにはMPEG とVCEGの専門家が参加しています。
　MPEGサイドから見ればこの規格は MPEG-4 Part 10 (ISO 14496-10)、ITU サイドから見ればH.264 (ITU の文書番号)。 AVC(Advanced Video Coding)という "正式な" タイトルはMPEG側がAACと 並べた時のバランスを考えてつけたものです。

AVC/H.264 プロファイル

　AVC/H.264規格は４種類のプロファイルを定義しています。Baseline、Main、 Extendedお よびHigh Profile。この下にさらにレベル（＊参考）による分類があります。

• Baseline Profile ：I/P-Framesを使っても良い。サポートするのはプログレッシブとCAVLCのみ。
• Extended Profile ：I/P/B/SP/SI-Framesを使っても良い。サポートするのはプログレッシブとCAVLCのみ。
• Main Profile ：I/P/B-Framesを使っても良い。サポートするのはプログレッシブとインターレースド。CAVLCかCABACが使える。
• High Profile (別名 FRExt) ：Main Profileに加えて、8x8イントラ予測、カスタム量子化マトリクス、ロスレスビデオ符号化、yuv formatの拡張 (4:4:4など)

　DVD バックアップには、High Profileを次項の符号化ツール（＊ 要素技術＊）と一緒に使うのが一番向いているようです。
　MPEG-4 ASP （＊試訳）の符号化ツールも読んで下さい。GMC以外はAVCでも使えます。

符 号化ツール

CAVLC/CABAC:

　AVC/H.264では、ビットストリームの記述方式（マクロブロック・タイプ、モーションベクトル+参照インデックス、、、）に、 MPEG-4 ASPより先進的なエントロピー符号化ツールを使います。二種類のエントロピー符号化が 定義されています。

• CAVLC（Context-Adaptive Variable Length Coding、コンテクスト適応型可変長符号化方式）
• CABAC （Context-Adaptive Binary Arithmetic Coding 、コンテクスト適応型２値算術符号化方式）

　CABACは、AVC/H.264デフォル トのCAVLC （別名UVLC）よりも強力な圧縮方式で、ビットレートを約10～15%節約できると言われています（特に高ビットレート時）。CABACもCAVLCも ロスレスで画質低下が一切ありません。し かしエンコードとデコード速度は低下します。

ループ/デブロックフィルタ

　Loop/Deblocking Filter:（他に、インライン フィルタ、インラインデブロック、などとも）

　プレフィルタ（例えばavisynthが行う エンコード前のフィルタリング）や、ポストプロセス/フィルタ （デコーダが最終出力前に行うもの）に対して、ループフィルタはエンコード工程の中で、各フレー ムがエンコードされた後にかけるものです。
　厳密にはエンコードの 後、但し、後続フレームの為の参照フレームとして使われる前 の時点です。これは特に低ビットレート時のブロックノイズ減少に効果があります。しかし、エンコードとデコードは遅くなります。

可変ブロッ クサイズ/可変マクロブロックパーティション

　Variable Block Sizes/Macroblock Partitions:

　MPEG-4 ASPでは、イ ンター4V、またはインター4MVを使うと、16x16～8x8ピクセルの間でブロックサイズを変える事ができました。
　AVC/H.264 では、モーションサーチの精度を決めるマクロブロックの大きさを、4x4ピクセルまで下げる事を提案していま す。これは、8x4のように段階的に下げて行く事もできます。ブロックサイズは映像内容に応じて可変です。
　各マクロブロックにどの 程度のブロックサイズを与えれば最も効果的か、その判断 が賢いものが良いエンコーダと呼ばれるでしょ う。

複数参照フ レーム

　Multiple Reference Frames:

　MPEG-4 ASPでは、参照フレームにできるのは直前のフレームのみでした。
　AVC/H.264のインター・モーション・サーチでは、複数の 候補から参照フレームを選べるようになりました。
　つまり、ビデオコデックはASPのようにシンプルに直前フレームを参照するか、そ れとももっと前のフレームを参照するか自分で 決められると言う事です。 例えば、Pフレームは直前のIフレームよりももっと前のフレームを参照できます。
　このため、新しいタイプのIフレームが必要になり ました。IDRフレームです。これはIフ レームの一種ですが、後続のフレームに自分よりも前を参照する事を禁止します。複数参照フレームを使うとエンコード、デコード速度は低下し、カットも IDR フレーム単位でしかできなくなります。

適 応重み補間予測

　Weighted Prediction:

　Weigthed Predictionを使うと参照フレームに「重要性」を付ける事が出来ます。例えば、直前の映像を（ブライトネス方向に） スケーリングできます。
　 これは特にフェードのある場面、後続の映像が直前の映像によく似ている場合に効果的で す。
　明転で明るさが増す場合は除きます。また、フェードを使った場面転 換のような、クロスフェードには効果がありません。 

レー ト歪み最適化（RDO）

　Rate Distortion Optimisation (RDO):

　RDO を使うと、エンコーダは2種類の選択肢があるような場合に、それがいかなる局面であれ、最も効率の良い符号化方式を選べるようになり ます（例えば インター符号化とイントラ符号化のどちらを選ぶか、モーションサーチ方式の選択、などなど）。
　RDO はAVC/H.264 仕様書の定義にありません。しかし、この新しいアプローチを最初に導入したのはH.264レファレンスソフトウェア(JM)です。他のコデックもRDOを 組み込む事が出来ます。例えば、既にRDOを装備しているXviDのVHQモードのように。

AVC/H.264 とその他のポピュラーなビデオ符号化フォーマットの比較

入 手可能な AVC/H.264 コデック

　現 在入手可能なAVC/H.264の実装は以下の通りです。
　x264、Nero、Apple、Sorenson、Elecard、Moonlight、VSS、mpegable、Envivio、Hdot264 (binary)、DSPR、JM (レファレンスソフト) (binary)、ffmpeg、Philips、FastVDO、Skal、Sony、その他いろいろ。

エ ンコーダ

x264:
NeroDigital AVC:
Sorenson:
Apple:
JM:
Hdot264:
VSS:
Elecard:

公開を停止したもの：

デコーダ（比較）

• ffmpeg： オープンソース（LGPL） ffdshow（VFWやDirectShowデコーダ）、mplayer、VideoLANが 使う。
• サ ポートする機能：Bフレーム、B参照、 CABAC、Loop、Weighted Prediction、High Profile（8x8 dct、8x8イントラ予測、ロスレス
• CoreAVC：
• Apple： QuickTime７内蔵のAVCデコー ダ。.mp4/.movを再生。極めて遅い。
• サ ポートする機能：B-フレーム（１枚のみ）、 CABAC、Loop。
• サポートしない機能：mixed references（複合参照）、 複数Bフレーム、イン ターレース。
• ※手許では素のままでも複数B入りのx264+aac.mp4を再生できた。た だし、b_pyramidやHigh profile非対応なので意味は無い。
• NeroDigital AVC： DierctShowデコーダおよび.mp4パーサ。Recode2に内蔵。
• サ ポートする機能：Main および High Profile
• VSS：VFW デコーダ（5日限定）とDShow Decoder（30日限定）のプレビュー版。
• サ ポートする機能： .avi（fourccはVSSH と H264 ）、CABAC、ループフィルタ、B-Frame。
• Elecard：Elecard's MPEG Player と MainConcept's v2 encoderに内蔵。
• Envivio： EnvivioTVに含まれるAVC DirectShowデコーダ。商品。バ−ジョン2.0以降、.mp4コンテナ中のAVCを扱える（最新versionは2-1- 181）
• Philips： DirectShow AVCデコーダ。フリー。AVC Alliance playerに同梱（raw AVC しか扱えない）。
• FastVDO：High Profile DirectShowデコーダ。時間制限あり（1ファイルにつき５分）。
• 公開を停止したもの：（＊略＊）

Sample content

AVC/H.264 の問題点

相 互運用性の問題

現 時点では、多くの実行環境が異なるコンテナをサポートし ています。

.mp4

MPEG-4 規格 (ISO 14496-15) で定義されたAVCのコンテナ。

現時点でサポートしているのは Apple、Nero、Sorenson、Envivio、Elecard/Moonlight、x264。

.mpg PS/TS

MPEG-2 規格 (ISO 13818-1, AMD3) で定義されたAVCのコンテナ。

現時点でサポートしているのは Mainconcept と Elecard/Moonlight。

 .avi

AVC -in-AVIは誰も規格化していないため、既に相 互運用性の問題がおきています。AVIとVFWの制限（＊試訳＊）、例えば Bフレームや 自由なフレーム符号化順番の扱いなどは、これら二つのフォーマットに対するハッキングを不可欠なものにしており、その結果、AVCの要素技術を全て実装す るのは困難です。これは再生品質悪 化の可能性があり、少なくとも開発の速度を鈍らせ、相互運用性の問題と競争力低 下の原因となっています。

現在AVI は VSS、x264 (mencoder と vfw) でサポートされています（＊x264 の公式なvfwサポートは06/10/05のrev581で停止＊）。

 .264/.h264

コ ンテナに入っていないraw bitstream。JM、x264cli、mencoder、mainconceptなどが出力する。

※.264、.h264はQuickTime7では開け ない。視聴は MPlayer（要fps指定）、MPlayerOSXなどでできる。mp4boxで.mp4コンテナに入れる事ができる。

速 度の問題

　現 在の実装の中には非常に低速なものがあります。
　現在、x264とNeroDigitalの AVCエンコーダは良い速度と画質を実現しているように見えますが、AVCが非常に先進的なビデオ符号化形式である事に変わりはなく、古いCPUでの エンコード・デコードは非常に時間のかかるものになるでしょう。

ハー ドウェアにおけるMPEG-4 AVC/H.264 - HD-DVD/Blu-ray

　DVD フォーラムとBlu-rayディスクアソシエーションが現在一般的なDVD フォーマットの後継を目指して活動しています。これはいわゆる High Definition コンテンツ （現行DVDより大きな映像サイズ）と呼ばれる物で、名称をHD-DVD と BD-ROMと言います。
　HD-DVDでは、 MPEG-4 AVC/H.264は対応必須のビデオコデックです（こ こに書かれている通り）。
　Blu-rayも、MPEG-4 AVC/H.264をビデオコデックに含めました（こ こ（pdf直リン）にあるように）。
　以上の事から、AVC/H.264 は、現在DVDの中で使われているMPEG-2 のように、広くサポートされる次世代ビデオフォーマットになるものと思われます。

そ の他の情報

MPEG-4 AVC/H.264に関するその他の情報。

• フォー マット概要 ：http://www.vcodex.com/h264.html
• サ マリー： http://www.moonlight.co.il/tech_h264.php 、 http://www.dspr.com/www/technology/technology.htm
• 入 手可能な実装のリスト：http://radio.irt.de/docs/codecs.html
• AVC 認証試験の結果：http://www.chiariglione.org/mpeg/working_documents/mpeg-04/avc/avc_vt.zip
• AVC/H.264 仕様書： http://www.dspr.com/www/technology/JVT-G050.pdf  (Draft from the 7-14 March 2003)
• Blu -rayの技術情報： http://www.blu-raydisc.com/Section-13628/Index.html

__________________
弱者と強者の間にあっては、自由は抑圧の源であり、それを解放するものが法である（ジャン・ジャック・ルソー）
私が自分が何も知ってはいない事を知っている（ソクラテス）
最終更新日：07/01/27, bond