【リンク】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に足りない部分を推測する事も、設定などで煮詰まった時に辞書として使う事もできる。

良いインタレ解除やデノイズフィルタが無い。

　自分の感性ではインタレ解除の良否が画質を決めます。QuickTimeに留まる限り、AviSynthやAviUtilとの 差は 詰められません。定評あるJES Deinterlacerは残念ながら手許では安定せず、MPEGStreamclipやDivaのインタレ解除はMEncoderに劣ります。

インフラとしての信頼性。

　10.3.x時代の話ですが、ソフトウェア・アップデートの都度、なにかしらのQuickTimeアプリで問題が起きました。 毎週素材が溜まるTVキャプチャでは「年間トータル・ダウン・タイム」と 言う単語すら意識しました。アップデートは慎重にすべきなのは基本としても、頼りにしていたアプリやQuickTimeコンポーネントがひっかかればそこ で"待ち"が出ます。作者さんの対応が間に合わなければワークフローのリストラ。それが固まると次のアップデート。これには付いて行けませんでした。

　なお、MPEG-2素材固有の問題として、有償のMPEG-2再生コンポーネント+QuickTime Playerは4GB以上のMPEG-2ファイルを最後まで再生できません。このバグは2003年秋には発見されていますが、2006年秋現在もそのままです。無 償で回避するにはMPEGStreamclip。

　自分は2004/12月頃にターミナルでMEncoderを使う事を覚えましたが、以降、こうした問題はほぼ根絶できていま す。Jaguar to TigerのOSバージョンアップ（2005/05月、QuickTime 7）の際にはQuickTimeアプリに軒並み影響が出ましたが（*1）、手許での面倒は皆無でした。2006/秋現在、QuickTimeインフラで 使っているのは録画を除けばMPEGStreamclipでのCMカットのみ。視聴もVLCです。

（*1）唯一無傷だったのは"なんぴとたりともオレの 前には行かせねぇ"3ivx+Divaだったと思います。オープンソース系でもffmpegXが同年9月頃までインストールできない状態でしたが、これは AppleがBSDサービスに関わる ディレクトリの書き込み権限を変更したため。セキュリティ上、Appleが正しいでしょう。D-Vision 3は無傷で動きました。

Appleコンピュータの独占志向。

　かつてMPEG-4のデコード権を巡ってApple MPEG-4, "神速の"3ivx, Divxの「乗っ取り合戦」がありました。QuickTimeにはユーザーが適用コデックの優先順位を指定する仕組みがありません。むしろ、そういう面倒 は全部ま かせろ！な会社です。もちろんそれは非常に便利なのですが、もっと良いコデックが出て来た場合に困る事になります。今後、FFdshowの QuickTimeコンポーネントや、3ivx社のAVCコデックが出たと しても、数ヶ月単位で /System/Library/QuickTime/QuickTimeMPEG4.componentや /System/Library/QuickTime/QuickTimeH264.component/が乗っ取り返す事が想定されます。今度は iTMSの看板とDRMが絡みますから、少なくともデコードに限っては、コデック選択の自由は様々な制限を受けるでしょう。

　なお、拡張子.m4vはISO/IEC国際標準規格には存在しません。し かし、Win/linux界では .mp4v, .cmp, .divx, .xvid, .264と並ぶraw mpeg-4 video streamの拡張子として定着し、尊重されてきたものです。その中にfps指定値や音声が入っている事は、Apple以外の.mp4作成ツールにとっては当然、想定の範囲外です。コ マンドラインでは指定された拡張子を頼りに出力フォーマットを決める方式もありますから、そうしたものは正当な理 由無く改変を余儀なくされた事になります。

　Appleが様々な国際標準規格をいち早く取り入れ、その普及に努めて来た功績 は少なくありませんが、他プラットフォームにおける貴重な努力を毀損するまでの資格はありません。Appleコンピュータは、自 社独自の拡張子の決定に当たってしかるべき敬意を払うべきだったと思います。

　iPod に関心がない事、iTMSで買い物をしない事から普段は気に留めていませんが、Appleのやる事＝国際標準規格と誤解した無遠慮なiPod厨の言動を オープンソースコミュニティが迷惑に思っている事は言うまでもありません。

　もちろん、オープンソースにもバグや問題は存在します。しかし、元々オープンソースのフリーウェアは「末 路哀れは覚悟の前」で す。
　その上で、需要有るところ必ずパッチの書き手が現れます。解決できずに投げ出す場合も「コレ コレの事情で今は無理！」と明示されるのはそう悪くは無いです。それを見た誰かが手を出す事を期待できますし、それが納得出来なければQuickTime インフラに戻っても良いわけです（まぁlinux界の人は背水の陣なわけですが）。

　実感としては、QuickTimeインフラ下でエンコードするよりも安定しており、進化も早いと感じます。


　今後、インフラとしてのQuickTimeが充実していく見込みは薄いと思っています。Appleの利益にならないから。

　既に動画インフラとしてのQuickTimeの普及は見込めません。Appleとしては、アプリケーションの登場を促すためにドキュメントやAPIを整 備したり、"爆速無双"3ivxを買収するよりは、iTMS/iTunes/iPod専用の流通インフラと して使うほう がお金になります。ですからQuickTimeテクノロジーは「閉じた」「そう簡単には弄れない」「Appleの想定する使い方から出ないぶんには便利 な」形で活かして行くのが得策です。

　「iTMSで買ったものは、大画面iMac、iPod、TVに繋いだMac mini、お好きなところでご覧になれます。」

　そこに「動画エンコード/デコード/フォーマットの自由」があっては消費者が混乱する、と考えている事でしょう。
　"iアプリ"では書き出せるのにプロキーが有償なのは一見不整合に見 えますが、"iアプリ"で書き出せるのは「Appleが想定する使い方」を外れないものに限られます(*2)。
　スティーブ・ジョブ ス氏の率いる組織に戦略の不徹底はありません。
　Mac OSXに「動画エンコード/デコード/フォーマットの自由」があってはイケナイ。という考えと見ています。

　QuickTimeの改善はAppleにしかできませんしし、プログラミング情報をどの程度公開するかもしないかも、「ソフトウェア・アップデート」を い つ、どのように行うかもAppleが自由に決める事です。それら全てが人々をiTMSでの購入に向かわせる材料となります。

　もちろん今はまだそこまで閉じたものではありません。しかし、だから将来もそうだという事もないでしょう。intel移行とOS9破棄を事前に予想して いた人は多くは無いはずです。
　QuickTimeには優れた点が沢山ありますが、その上にエンコード・ワークフローを築いたり、そこで経験値を積み上げるのはリスキーだと思います。

　Mac OSXにはもう一つの動画インフラがあるべきです。

　どっちが良いとか正しいとかではなく、両方あるべき。んでもって刺激すべき。それでこそQuickTime Player Proの改善も望めるというものです。

(*2)　「Macはこのソフトを、こうやって使えば、こうゆう事ができます。するとほぉら、こんな素敵なライフスタイル。いい でしょ？奥さん」。

仮に、ユーザー・エクスペリエンス・ドリブン・ビジネスと名付ける。

価値の源泉・コアコンピタンスは「ジョブス氏のプレゼン」そのもの。あとは、店の雰囲気、持ち帰る時の誇らしさ、箱をあけた時の 高揚感、使ったときの楽しさ、単にデザインだけでなく製品そのものも、 『演出の一環』。その一連の体験が真の商品。というのはどうか。

ところで。文具は手っ取り早く無印良品で揃えるオイラですが、消しゴムだけはコクヨです。カドケシが好きで。

　Apple-H.264は画質は悪く有りません。むしろ非常に良いのですが、速度が大問題です。QuickTimeインフラには良いインタレ解除やデノ イズフィルタが見当たらない事も含め、TVキャプチャを全部エンコードするという目的に は向かないと考えています。

マルチパスの速度が遅すぎる。

　日々素材が溜まってゆくTVキャプチャではエンコードが追いつきません。マルチパスのパス数はフロントエンド （QuickTime Player ProやMPEGstreamclipなど）の作者さんがAPIで規定するようですが、多くは5パス程度のようです。raw2qt264で はパス数指定がで きるので 2パスで試したところ、x264では有り得ないブロックノ イズが出ました。恐らく、モーションベクトルの算出アルゴリズムが弱く、マルチパスはそれをカバーするためと考えています。

High Profileをサポートしていない。

　Apple-H.264で手が届くのはMain Profileまでで、これは次世代DVDのコデック選定でVC-1どころかMPEG-2にも劣るとされたものです。ただしSDでの画質は良いとされてい ますから、地アナTVキャプで無理に手を出す必要は無いのですが、High profileでなければ8x8マクロブロックサイズが使えません。これはASPでは使えるものなので、Apple-H.264は基本的な土台がXvid 等に劣る事になります。他にもMainは規格策定を急いだのか符号化ツールの積み残しが目立ちます。

　Doom9でも、Bond氏はDVDバックアップにおける推奨としてHigh profileを支持しており、また再生面でもDoom9コデックコンテスト2005では「Main Profileサポートというには不可解な制限が多すぎる。コデックに文句を言う前にQuickTime Player以外の再生ソフトを使いなさい」としています。

　Apple-H.264 + QuickTime Player Pro固有の問題として、.mov書き出し時でなければBフレームが使えない事があります（フレーム並べ替え）。後からソレを.mp4に収める事はできる の で、この仕様は不可解に思えます。

設定で遊べない

　Apple-H.264のUIではややこしいところは奇麗に隠蔽されています。最小/最大量子化値もインラインデブロックもマ ルチ プルレファレンス（不等距離参照）もありません。これらは決めウチであり人に優しい点がAppleの美点なのですが、逆に速度が不満でも調整余地がほとん どありません。

　ただし、肝心の画質は非常に良いです。
　この点はDoom9のbond氏も明言していますし、手許でもビットレートを下げ過ぎない限りまず破綻しません。一例を挙げるとx264で問題となった 「闇 階調でフレーム 毎にぱたぱた動くブロックノイズ」はまず出ません。x264でMainに留まる限りこの画質は難かしいでしょう。マルチパスについてもx264は50パス ほどやって10パス単位で画質が向上して行くものだそうです。やや古いですがNTT関連の研究所でも数十パスで1080pを1.8Mbpsにできるとい うニュースもありますから、Mainでの画質はApple-H.264のチューニングが有利と言えます。細かい設定であまり悩まずに済む点とあわせるとス ゲェと思います。
　とにもかくにも問題は速度なのですが、実は各パスは速いです。爆速と言って良いです。ス レッドを見て も7～8分割してますし、未来の10コアCPUでも現在の1コアでもほとんどCPUを遊ばせずにぶん回す事でしょう。基本的にエンコードはデコードの逆回 転なの で、これはデコード速度も半端じゃないと言う事です。
　実際、G4 Cube（450Mhz）で、MPlayerがYOUR PC IS TOO SLOW!!っつって止まってしまうようなものでも、激しくコマ落ちしながらもなんとか再生してくれます。CPUパワーがどうだろうがまず同期を死守する QuickTimeアーキテクチャの面目躍如です。

　要するに、目指したのは「G4でもまずまずH.264を楽しめるデコーダ」と思われます。

　と考えると、.mov書き出し時でなければBフレームが使えないQuickTime Player Proや、異様に遅いマルチパスといった「仕様」に整合性が見えてきます。映画を売るにはカジュアルなエンコードはジャマですし、G4でもそこそこ楽し める必要が あります。スティーブ・ジョブス氏が率いる組織に不整合はありません。ねばーありません。


　QuickTimeがサポートするもの = 国際標準規格では無いです。
　実態は『QuickTimeがサポートするもの ＜  国際標準規格』であり、Appleがサポートしない部分には他社の特許が絡みます。一社で全てを提供できる存在は無いでしょう。

　大事なのはデファクトです。
　win/linuxでデファクトのx264か、iTMS/iTunesのApple-H.264か。
　
　サイレントマジョリティはiPod/iTunes/QuickTime Playerを支持すると思います。なにしろ楽で、安心です。
　Net上では一見、x264が優勢に見えるといっても、それは自分も含め てノイジー・マイノリティに過ぎないと思いますです。
　x264でもMainで作ればQuickTime Player で再生できるものは作れますが、画質的に有利とは言えません。それならiTMSで買うと言う人も多い筈です。

　SD以上の解像度ではx264が有望だと思います。8x8ブロックサイズやカスタム量子化マトリクスなど、Mainで積み残された符号化ツールを使って もApple-H.264よりは速いですし（G5で、です。x86ではさらに差が出る筈です）、概ね画質でも引けを取り ません。この速度差は主流の解像度がもっと大きくなった時に効いて来る筈です。x264の歴史はApple-H.264よりも長く、画質に関わる符号化 ツールはほぼ網羅されており、設定ノウハウの蓄積も充分で、コンテンツをHDにぎっしり溜め込んでいる人にとってはQuickTime Playerは選択肢から外れつつあります。しかし、ここ数年のうちにAppleがx264+aac.mp4（High profile）の再生をサポートする見込みは無さそうです。

　どっちをとるにせよ、博打です。末路哀れは覚悟の前で ひとつ。

　心情的には、iPod/iTMSのシェアを楯に規格名をそのまま自社コデック名に冠し、それがあたかも「国際標準規格」そのものであるかのごとく振る舞 うAppleには好感を持ちにくいですけどね。マカーとして。

原文：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.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

Iフレーム：デカイ・キレイ・画質の素

　Iフレームとは普通の一枚絵の事。PやBフレームはIフレームとの差分なの で、Iは全ての空 間軸画質（一時停止したときの奇麗さ）の土台になる。あるフレームを別フレームとの差分で済ませる事を時間軸圧縮と言うのだけれど、要するにアニメの口 パクだ。
　差分で済ませるとは、元になるフレームが無ければちゃんとした絵にならないと言う事だ。こうしたフレーム間の依存関係を「参照、reference」と 呼 び、Iフレームと、それに依存 するフレームの軍団をGOP（Group of Pictures）と呼ぶ。
　下図は最も単純な時間軸圧縮の例。ここでは各Pは直前フレームのみを参照してると思って欲しい。
　時間軸圧縮を使った動画は、だいたいこのGOPの連続でできている。
　Iフレームの特徴は、ますP/Bに比べるとデータサイズが大きい事。これは もう圧倒的だから、Iは場面転換の先頭にあるのがいちばん効率がいい。次 に、シーク（早送り・巻き戻し・スキップ・頭 出しなどの総称）は基本的にIフ レームが基準となる。上図のPフレームだけ頭出ししてもまともな絵にはならないよね。最後は少しややこしいのだけど、依存関係にあるフレームの処理（エン コード・デ コード） が完了するまで、参照元のフレームはデコーダ・バッファ・メモリに置いて おく必要がある。
　ようするに、Iはデカイ・キレイ・画質の素。 

IDRフレーム：Iとシークとマルチレフ

　H.264/AVC規格で新しく追加されたフレーム。Iフレームとしても 機 能する。おそらくはIフレームに特定のフラグを付けたもの。
　特定のフラグとは次のようなものだ。
　H.264は時間軸圧縮にMultiple reference pictures（＊マルチプル・レファレン ス、複数参照、自分的には不等距離参照＊）を使う。例えば、旧規格のPフレームは直前のフレームしか参照できなかったが、 H.264ではもっと前のフレームを参照できる。具体的な効果は、通過する車が建物の向こうに一旦隠れて反対側に出る、といった場面に現れ る。こういう場面で車の前半分くらいを自分より前のフレームからの"引用"で済ませる事を動き補償と言うのだけれど、当然、直前よりはもっと前から パクって きた方が効率が良い。
　しかしいくら効率が良いと言っても無限に参照関係を作るとキリがないし（映画のエンドロールが冒頭のフレームを参照するとなると、映画一本まるまる バッファに置いておく必要 がある）、間違って全然関係無いシーンを参照してしまうと画質が悪い上に"差分"のデータ量も膨大になる。
　従って、マルチプル・レファレンスにはなん らかの参照関係の区切り、ストッパー 役 が必要になる。シーンチェンジ検出機構をこの参照関係の区切り役に使うのがkeyint関連。常識的な立場（デコーダに積める程度のバッファ）から 参 照関係に区切りを付けるのがframeref（-r,--ref）だ。
　なお、規格上の参照関係は前後を問わないがx264ではPは前、Bは前後各１を使うようだ。

---

■参考記事

1. GOP 関連をおろそかにしたx264はXvidにも劣る
2. Frame -type_01_GOP関連

プロファイル

　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. 映画界の呼称
2. DARとPARとSAR
3. 一般的な SAR:
4. なぜx264にDARが無いのか。
5. AVIとQuickTimeとMPEG規格

映 画界の呼称

スクリーン・サイズの種類と縦横比（アスペクト比）：りおなのVIVA!WIDESCREENよ り作成。

名 称	縦x横	備考
スタンダード	1×1.37	35mm写真フィルムとほぼ同じ。TVもこれに倣った。
不詳	1×1.2	ほぼ正方形。トーキーの音声をフィルム上に収録するため、ちょっ と映像を削った。不評で消えた。
ヨーロッパ・ビスタ	1×1.66	フランス映画に多い。
アメリカン・ビスタ	1×1.85	シネマスコープを除くほとんどのアメリカ映画。日本、イギリス、 イタリア映画にも多い。
マスキングビスタ	1×1.66～1×1.85	35mm（スタンダード・サイズ）フィルムでの撮影または上映時に上下にマスクをかける。 純 正のビスタビジョンと区別するため“ビスタ サイズ”と言う。 1960年代のフィルムの品質向上で実用化。 1980年代のビデオ普及に より、撮影はスタンダード、上映はマスキングビスタが主流となる。
シネマスコープ	1×2.35	基準は1×2.35だが、通常は 1×2以上のアスペクト比を「スコープ・サイズ」と呼ぶ。 撮影は専用のアナモルフィック・レンズか、スーパー 35方式（マスキングビスタ的なもの）を使う。

　4: 3なら1.33だし、16:9は1.78だ。勘定が合わない。「なんですかこれわ？」という数字だらけ。恐るべし映画百年の歴史。
　 これら多彩な縦横比をどうやってデジタルの世界に持って来るか。

　DVD（と言うかMPEG-2のMain Profile @ Main Level）の720x480はアスペクト比1.5。表の中のどれにも合わない。
　なぜこれを採用し たかは知らないが、720x480の画素数は僅か34万5,600画素。恐らくは、規格制定当時、ご家庭で買える範囲のお値 段で再生機を作るには35万画素を30fpsで動かす程度が限界と予想された、という事だろう。画素数とfpsがCPUパ ワーとバッファメモリ搭載量に直結するからだ（MPEG規格は半導体の価格動向予測も考慮して決める）。
　 だから、まず画素数とfps。次に、どのアスペクト比の映画でも、720x480を有効に使いきる、仕組み。
　 例えばデータ上の解像度（サンプル数）は720x480 で固定しておいて、表示上のアスペクトは別に指定してやる。など。これならどのアスペクト比の映画でも、720x480を無駄なく使いきれる。画質最優先 ならどのアスペクトに対しても個別に最適な縦横のピクセル数を決めるべきだが、家庭用DVDプレイヤでそこまでカヴァーするのは無謀だったという事だろう。

DAR とPARとSAR

名 称	種別	対応規格	根拠
DAR Display Aspect Ratio ディスプレイ・アスペクト・レシオ	画面表示のアスペクト比。	MPEG-1/2/4	MEncoder 　- mpegoptsのvaspect=<1 | 4/3 | 16/9 | 221/100> 　-xvidencopts のaspect=<x/y | f (float value)>
PAR Pixel Aspect Ratio ピクセル・アスペクト・レシオ	ピクセルのアスペクト比。	MPEG-4 ASP?	MEncoder 　-xvidencoptsのpar=<mode> 　DAR = PAR * (width/height)。
SAR Sample Aspect Ratio サンプル・アスペクト・レシオ	ピクセルのアスペクト比。	MPEG-4 AVC	x264cli 　Input/Output:の --sar ※ 規格上はVideo Usability Info (Annex E):だが、 ここではcore:54 svn-611M --longhelpに従った。 MEncoder -x264encoptsには見当たらない。

　 アスペクト比はスクリーン（画面全体）で指定するものと、ピクセル単位で指定するものの２種類がある。PARとSARは、規格上の呼び方が違うだけで同じ ものだろう。手許では実際に-xvidencoptsのpar=<mode>を 使った事は無いが、modeには ntsc169 や pal43 などのプリセットを入れる。ここに ext と入れると、par_width=<1-255> や par_height=<1-255> で独自の縦横比を指定する事ができるようだ。恐らく は、これがSAR。

一般的な SAR:

x264cli のSARは「8:9」のような書式で指定するようだ。-xvidencoptsの書式で書くと、par_width:par_height に相当するだろう。
DAR= (par_width / par_height) * (width/height)

Encoding H.264 using the x264 Command Line Interface（Zero 1氏）の一般的な SAR表から作成。

素 材解像度	DAR		SAR（PAR_W : PAR_H）
	一 般名 （縦横比など）	少数表記 （高さを1とした時の横幅）	PAR_W	PAR_H
720x480 (NTSC)	4:3	1.33	8	9
	16:9	1.77(*1)	32	27
	アメリカン・ビスタ(*2)	1.85	100	81
	シネスコ	2.35	69	44
704x480 (NTSC Crop)	4:3	1.33	10	11
	16:9	1.77(*1)	40	33
	アメリカン・ビスタ(*2)	1.85	125	99
	シネスコ	2.35	85	53
720x576 (PAL)	4:3	1.33	16	15
	16:9	1.77(*1)	64	45
	アメリカン・ビスタ(*2)	1.85	40	27
	シネスコ	2.35	32	17
704x576 (PAL Crop)	4:3	1.33	12	11
	16:9	1.77(*1)	16	11
	アメリカン・ビスタ(*2)	1.85	50	33
	シネスコ	2.35	102	53

　なお、『改訂版 H.264/AVC 教科書』 を見ると、VUI（ビデオ表示パラメータ、309ページ）の項に、aspect_ratio_idc、sar_width、sar_height、という ものがあった。aspect_ratio_idcはプリセット。0は定義無し、1は1:1、2は12:11、、、という具合。13まである。14～254 はreserved（将来の拡張用）。ここが255だったら、
sar_width、sar_heightの値からSARを計算する。 とある。
　上の表の「一般的なSAR」は16通りある事から、x264cliの--sarオプションは、sar_width、 sar_heightを入力するものと思われる。

なぜx264にDARが無いの か。

DARがありゃ便利なのにと思うのだが、どうもH.264/AVC規格にも無いらしい。例え ば、H.264/AVC規格概要：レベルにある以下の記述。

規 格上、Levelが規定する最大フレームサイズとは、pixel/frameの合計数だけだ。水平・垂直それぞれの最大サイズは、Sqrt （maximum frame size * 8）以下でなければならない事を除けば規格には無い。

　 もしもAVCのレベルにフレームの縦横は720x480といった規定が無く、制限は1フレームあたりのピクセル数だけで、かつ、ピクセルに縦横比情報を持 たせる事ができるのなら、ヨーロッパ・ビスタだろうがアメリカン・ビスタだろうがマスキングビスタだろうがシネスコだろうがそれ以外の変形素材だろうが、 オリジナルのフィルムから起こす場合に限っては、もうちょっとだけ、素材に忠実な解像度で作る事ができそうだ。それなら、MPEG-4 ASPの"PAR"の名称を変える必要性が納得できる。
　あと、4kシネマ（4,096×2,160ドット）とか2kシネマ（2,048×1,080ドット）とかも睨んでるのかもしれないなと思った。

AVIと QuickTimeとMPEG規格

MEncoderはAVIヘッダにアスペクトを書き込む事 ができる。しかしそれをちゃんと解釈できるのはMPlayerくらいらしい。オプションにある通り、rawvideo.xvidにDARやPARを埋め込 む事もできる。しかしこれも、AVIコンテナではちゃんと解釈できるのはMPlayerくらいらしい。DARやPARは.MP4コンテナが安全だろう。

　 一方、QuickTimeはコンテナにはアスペクトヘッダを埋め込め、正しい解釈もできる筈だが、インフラ全般に渡って映像データと付加情報は分離すべ し、という一貫した思想がある（オブ ジェクト指向）。これはかなり徹底したもので「アスペクト情報を持った映像ストリーム」に対応困難らしい。結果的に.MP4であっても、SAR指定の入っ たH.264サ ポートをQuickTimeコンポーネントとして実装するのは難しいようだ（考察：SARとQT（My cometG3））。
　Appleが国際標準規格の推進をアピールするのは自由だが、Apple - h.264 だけが H.264/AVCであるかのような印象操作は 不愉快だ。

　MPEG （Motion Pictures Expert Group）規格はその名の通り、動画に関する規格だ。.MP4はAppleの.movベース（Appleが唯一MPEGに提供しているパテント）とはい え、発想は異なる。上位団体はISO（International Organization for Standardization、国際標準化機構）と仰々しいがなんのことは無い。JISだJIS。「2Bの鉛筆」とか「単 ３の乾電池」とか「M３のボルト」などと本質的な違いは無い。ISO-MPEGの仕事は「産 業界における汎用的な実用性を持った規格を定める事」だ。ひらたく言えば妥協がお仕事。できるだけ高いレベルで。

　 手許ではSARを使わずにスケーリングしてしまうが、過去に720x480のMPEG-2PS（TVキャプチャ）の黒帯を、16:9にするべくcropし て、スケーリングを間違えて640x480でエンコードした事がある（ソルティレイ#01 オーロラの降る街）。

-vf pullup,softskip,crop=702:352:8:64,scale=640:480,hqdn3d=2:1:4,pp=l5,harddup

記録が残っていないがSARもPARも滅茶苦茶なハズだ。

QT Player + avcdecoder 0.5.1	VLC 0.8.6	MPlayer OSX 1.0 pre 8

　これを正しいアスペクトで表示できる方が狂っているのだが、なぜかこうなった。
　QT Playerは素直に640x480。VLCとMPlayer OSX 1.0は、縦480を軸に、横幅を852に拡大している。当時（2005/10月）はMain profileで作っていたので、素のQT7（Apple-H.264）でもこうだった。偶然に正しいSARにでもなったのだろうか。

　 ところでこのファイルは「こんなこともあろうかと」取って置いたというわけでは無く、何気なくme=ext、me_range=64を試して122時間 34分49秒かかった後に、やり直す気力が残ってなかっただけです^^;。

---

余談：
　なにげなくISOのスペルを 辞書でひいたらこういうものがあった。
冗談かと思ったら、本物でした。ISOで規格書も売っている。紅茶好きの間では有名な話らしく「ISO 3103:1980」で検索するとちょっと大変な事になっている。イギリス人め！安倍政権はISO国際標準すし規格の策定に全力を注ぐべきだ。

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