【リンク】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程度と高い。手許ではもう少し差が小さいが、傾向は同じだ。

改訂版 H.264/AVC 教科書

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

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

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

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

　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には好感を持ちにくいですけどね。マカーとして。

　2006年の秋口に終わったアニメの中ではゼーガペインの評判がよさそう。自分も結構好き。
　アニメは一応こんだけ録画してる（た）。

1. NHK
2. エア・ギア
3. ガイキング
4. ケロロ軍曹
5. シムーン
6. ゼーガペイン
7. ドットハックルーツ
8. まんが日本昔ばなし
9. 無敵看板娘
10. 僕らがいた
11. コヨーテ・ラグタイムショー

　2ndモニタで一応再生はするんだけど、目線はだいたい他にある。横目であー奇麗だなとか、可愛いなとか、うお、このカットそう繋ぎますかとか、断片的な印象ばかりでお話はまるで把握してない。そんな見方で印象に残るゼーガペインも面白そうなのだが、ここでは『無敵看板娘』の事を。実はこれだけは毎回ちゃんと"見た"。

　ギャグアニメなんで、たぶんネタバレもへったくれもありゃしないと思います。

■エンコードログ：2006/07/20-09/24, 2pass, 640x480, 1024kbps

タイトル	I枚数	I比率	Avg QP (P)
VGAアニメ平均値 （無敵看板娘を除く33件）	401	0.92%	20.10
『無敵看板娘』平均 （02-12話）	439	0.98%	22.16

　※1）QPの下限＝２で揃ってもその数字と言う事。つまり、Xvidでは過剰ビットレートでの2passは実質的に固定QPと変わらず時間の無駄。他にサイズの不揃いが厭でビットレートを落とした。H.264/AVCの下限=0=（量子化プロセスを切るという意味での）ロスレスで、QP値の変動ももっと小刻み。x264ではこのロスレスも可。
　※2）他にディズニーの『シリーシンフォニー』、『ファンタジア』『白雪姫』など。

■アニメそのものの感想

　06/10/01、x264に大きな動きがあった。目玉はインタレ保持関連（Sylphideさんに教えて頂きました）。

■手許の状況

• MEncoder dev-SVN-r20016-4.0.1
• x264 core:52 svn-575M

■https://trac.videolan.org/x264/timelineから

　10/01/06:

■有用な符号化ツールの実装完了が近い。

　インタレ保持はこの中では最後の大物だ。残りは通信エラー耐性、チャンネル切り替え用フレーム（SI/SP）、アルファブレンド、カラースペース拡張、、、必要とするのはモノホンの製商品開発者や研究室レベルだろう。x264もカラースペース拡張くらいは手を出すかもしれないが、yuv4:2:2やyuv4:4:4対応は大掛かりな作業になると思われ、実用上それが必要な素材もまだ少ない。

　すこし、特許/著作権保有サイドにも目を向けるべきかも知れない。具体的な製商品の普及前に同クラスのコデックが普及している構図は初だ（DVDがでた時に自宅でMPEG-2エンコ経験X年なんて人は居なかった）。x264開発サイドも過去の経験から学んでるだろうが、それは知的財産権ホルダーも同じだ。EUだけでなく、H.264/AVCに関してはむしろ日本。なにも無いとは思わない。

　なお、最近追加されたっぽいオプションはいくつかあるが、rev575の段階ではインタレ保持関係が見当たらない。manMEncoderとx264 --longhelpとChangeset xxx fortrunkで記述内容にも不整合がある。ように読める。この中ではman MEncoderが一番遅く、そして最も詳しい。
　っと、ここまで書いて出かけて、帰って来たらrev577だって。なぁに新学期って忙しくないのですくわ？

　いずれにせよ、最近追加されたっぽいオプションはちと濃ゆいっす。
　各文書が整合した段階で『改訂版 H.264/AVC 教科書』と付き合わせてみるほうが良いと思う。ちなみにこの本は便利ですますとはぶです。てゆうか書いたの規格策定に参加した張本人くさいです。大きな本屋の工学書の棚にあります。高いです。でも買いましょう（AAとかココないから）。みっちり読んで、そしておいらに教えて下さいw。

　なおLunatilia@Wiki Motion Picture Newsでは、日本語でx264更新情報が掲載されていまする。win向けTips付き。例えば：

※Jarod(x264.nl)では、Rev.573以降でvfwおよびインストーラは外されました。
事実上x264.exeに移行することになります。

　MEncoderはたぶんvfw相当なので、ちょっと気になります。
　Win界でvfwが生きている限りは、MEncoder経由でもある程度"事実上の再生互換性"が確保できると踏んでいたので。
　※06/10月現在、手許で作ったものは画質でAviSynth経由に劣り、規格互換性でvfw/virtualdub(mod)経由に劣る。ハズです。詳しくはこちらを。
　　WinではAviSynth+x264.exeがベストなように見えます（参考）。

【魔除け】：自分はC読み書きできませんwin持ってません文系のPPCマカーです。win固有の部分～vfw, AviUtil,AviSynth～や規格の内容は推測です。
【引用元】：2ch/DTV板/x264 rev6

1. ■インタレ保持着手の反応
2. ■ vfwについて
3. ■インタレ保持の必要性
4. ■ AviSynth vs. AviUtil

■インタレ保持着手の反応

900 名前: 名無しさん＠編集中  Mail: sage 投稿日:2006/10/01(日) 19:04:34 ID:pMv6VZRm
遂にきたか、長かった… 今後更新履歴みるのが楽しみに。

904 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/01(日) 21:14:10 ID:0g7yKvdU
r570 | pengvado | 2006-10-01 04:41:22 +0200 (Sun, 01 Oct 2006) | 2 lines
support interlace. uses MBAFF syntax, but is not adaptive yet.

905 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/01(日) 21:18:33 ID:E2aegN8f
サポートしたけど適合してないってどういう意味？

907 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/01(日) 21:42:35 ID:a7SYXf6g
MBAFF - MB Adaptive Field Frame
適応的に、フィールドとフレームを切り替える
まだどっちか固定になってるんでしょ。
フィールド固定なら一応インタレース対応だけど
フレーム固定なら今までと変わらないね。

913 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/01(日) 22:40:38 ID:gf101Dq5
Picture Adaptive Frame FieldとMacroBlock Adaptive Frame Fieldとの
違いがいまいちわからない
pure interlaceとは違うんだよな

　Introduction paper to H.264/MPEG-4 AVC includingthe FidelityRangeExtension. （PDF）からインタレ絡みの符号化ツールを拾うと：

• インターレースド・符号化機能
• Frame-field adaptation--（＊フレーム-フィールド適応＊）
• Picture Adaptive Frame Field (PicAFF) --（＊ピクチャ適応型フレームフィールド＊）
• MacroBlock Adaptive Frame Field (MBAFF) --（＊マクロブロック適応型フレームフィールド＊）
• フィールドスキャン

　ちゃんと読んでないけど、"フィールドスキャン"が完全インタレ保持で、後はフレーム構造とフィールド構造の混在なんじゃないかと思う。なんとなく。
　インタレ縞の無いとこはフレーム構造にしちゃっていいじゃんよ、というのは理にかなっている。と、思う。
　PicAFFは時間軸混在、フィールド構造とフレーム構造を必要に応じて使い分ける。コマ単位で。
　MBAFFは空間軸混在、フィールド構造とフレーム構造を必要に応じて使い分ける。マクロブロック単位で。
　でも"not adaptiveyet."だから、フィールド構造のマクロブロックで埋め尽くす。の、かな？
　あとMBAFF使うときは16x16マクロブロックを縦に２個繋げたものがナニカの単位になるとか、どっかにあった希ガス。
　いずれにせよx264はまだ一部に着手した段階。昨日の今日でデコーダの対応もまだだろう。

　※PDFの試訳はタグ：H.264/AVC規格概要でちまちまやってます。変なとこあったらコメント頂けると有り難いです。

■vfwについて

　vfwユーザーは結構沢山らしい。そりゃそうだよなぁ。

909名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/01(日) 21:54:33 ID:ZHoH6M/H
45%の人が使ってるのに切捨てとは

910 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/01(日) 22:24:31 ID:TLCSnsgz
これでCLI覚える為の踏ん切りがつきました、アリガトウ

912 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/01(日) 22:37:20 ID:uchwyHZ8
なんで切り捨てになるんだ？
もしそうなら急いでsynthを覚えなければorz

914 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/01(日) 22:41:00 ID:uchwyHZ8
nlで落としたんだがインストーラーじゃないよな・・・
cliでパス指定しろってことかぁぁぁぁ
vfwｵﾜﾀorz
誰か優しい人がいたら混合フレームレートを処理する方法が書いてあるサイトをorz

986 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/03(火) 06:59:02 ID:hx+Lfe7D
綺麗でも他のオプション使えないからVFW使わないんだよ
テスト目的なものだろこれ？

1. vfwで使えないオプションてなんだろう。"1 frame in 1 frame out"ならframerefとか b_pyramidとか考えにくいんだけどみんな使ってるっぽいし、、、あ、使えてねぇや、--refは動き補償に効く。アニメの方が効くが実写でも場面次第では。--b-pyramidはQT7互換性を維持するなら使えないがBの画質劣化を抑えて、かつ縮む（b=3まで効果アリ）参考。H.264/AVCはちまちましたオプションを積み重ねて効果を出すもんなのでどれがキモとは言い難いが、refとB絡みはちょっとデカイ。
2. 一時期x264の「リリース」はMEncoderに内蔵の形で出るという話があったが、B使うと.mp4吐き出しできないなどの問題が噴出して消えたっぽい。MEncoderは元来avi作成機なのでvfw相当の制限があるのだと思っていたが、ほんの少し違うのかもしんない。

■インタレ保持の必要性

937 名前: 名無しさん＠編集中  Mail: sage 投稿日:2006/10/02(月) 04:22:29 ID:L6I6l2OJ
解除の誤爆だの連結ミスだのに
気を回さなくていいからずっとインタレだな。本数が多くなるとやっぱ楽チンがいいわ

944 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/02(月) 11:06:35 ID:IoDx2zKL
>>942
少なくとも自分は今までインタレ保持について必要性は感じなかったが。
実装については嬉しく思うが、今後も使うことはないと思うぞ？

945 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/02(月) 11:12:12 ID:XG6nlH+n
全編周期一定の綺麗なテレシネもの以外は、自分はアニメでも
インタレ保持だな、昔はvfrとか好きでやってたけど、今はつらくなった

949 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/02(月) 12:13:58 ID:Le3HhJdF
>>947
おれも、おれも。
PVとか60のはやっぱインタレが良いよな。
あと大河ドラマがインタレつかえるのがマジうれしい。

• 確かにインタレ保持できた方がラクではあるが、自分はしないと思う。bitが勿体ないし、MacでCoreVideo（APIの名前）経由でグラボにHWインタレ解除させる手はたぶん出てこない。
• つうか、久しぶりにDTV板みたけど、H.264/AVC絡みって激しく寂れてますな。他スレでインタレ保持を理由に（特に実写）Xvid等って声が根強いみたい。あと圧縮/再生負荷。セレロンやセンプロンも多いもんなぁ。逆に言えばx264自体の設定ノウハウは固まってるって事か。

■AviSynth vs. AviUtil

936 名前: 名無しさん＠編集中  Mail: sage 投稿日:2006/10/02(月) 03:25:14 ID:flQzRs/J
インタレとか不要だし。
AviUtlなら混在だろうが何だろうがばっちり完璧に解除できるし。

985 名前: 名無しさん＠編集中  Mail: sage 投稿日: 2006/10/03(火) 05:06:19 ID:R1av9My0
VFWの方が絶対綺麗なのに…メクラばっかりでこまる

1. いまだにAviSynthよりAviUtilの方が画質で勝ると言う事らしい。もしかしてそれがフィールドシフトってヤツだろうか？

原文：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より高い符号化効率が得られるからだ。

Lunatilia-2006/10/16：x264は厳密にはCodecではなくライブラリ

---

Windows環境では ffdshow + Media Player Classic 6.4.x.x との連携が一番使いやすいとは思いますが、これは個人的主観になりますので何ともいえません。
他のOSでのデコード環境はageha氏 のところを参照してください。

　あ、はい。手許（Mac OSX）ではVLCっ す。視聴はこれ一本。あとは要らん。


　Macではダウンロードして解凍するだけ。なんの設定も要らない。簡単。全然簡単。QuickTimeとは完全に別モノだからソフトウェア・アップデー トも問題無い。一切無い。VLCプロジェクトはPowerMacG5やx86Macも自前で持ってるんでそのへんも安心。なにかと安心。MEncoder やx264の進化に追いつかなくなったらNightlyへGoっす。
　QuickTime Playerが受け付けないH.264/AVC High profileだろうがどんと来いっす。次のVLC 0.8.6.でlibavcodec経由でWMV 3 / WMV-9 / VC-1も対応するとか。--> full features list

　オープンソースなんでOS問わずいろいろ動くらしいです。 --> VLC screenshots
　win/linuxではskin変更ができるらしいです。 --> Download skins







ところで。

Changeset 588

---

Timestamp: 10/10/06 07:05:55
Author: pengvado
Message: no more decoder. it never worked anyway, and the presence of defunct code was confusing people.
//
デコーダはもう無い。いずれにしてもまともに動作した事など無かったし、死んだコードを残しておいても混乱の元なので。

　デコード機能あったんかい！

メガドラ兄さん

　北米でシェア51%を取ったという脅威のゲーム機。相手がスーファミだったので、だから脅威。ついでにガキの間で看板キャラ"ソニック"の認知度がミッ キーマウスを抜いたとも聞く。その後メガＣＤ、スーパー３２Ｘと次々に拡張機器を発売し、最終的にこうなった。

　※ちなみにボクは持ってません。

VfW/AVI

　1992年11月、Win3.1用拡張パックとして発売。サポートフォーマットはAVI。商品名「Video for Windows」。

槻ノ木 隆のBBっとWORDS-その86「AVIの生い立ちとそのコーデック」（2006/07/10）

---

　それにも関わらずAVIフォーマットはいまだに現役であり続けています。その理由の大きな部分は、逆説的ですがコーデッ クを選ば ないことでしょう。例え ば、DivX NetworksのDivXを使ってエンコードする場合、フォーマットは（MP4やOGM/MVKなども対応していますが）AVIにするのが一般的でしょ う。また、DVフォーマットの場合も、Windows環境ではやはりAVIにするのが一般的です。最近利用が始まった H.264でも、やはりAVIを使う ことが多いようです。

　新しいコーデックを作っても、それをサポートするためのファイルフォーマットがなければ利用するのは難しく、新しいフォーマットを作るとなる と、それを再生するためのプレイヤーや、生成するためのエンコーダも用意しなければなりません。ところがAVIフォーマット を使うと、コーデックさえ提供 すれば、プレーヤーやエンコーダはすでにあるものを使うことができるので、非常に手軽だからです。そして、新しいコーデッ クが最新技術（DivXもそうで すし、H.264もそうですが）を提供してくれれば、AVIフォーマットは十分魅力的です。そういうわけで、 MicrosoftはWMVを前面に押し出し ているものの、AVIは引き続き使われ続けるでしょう。

　以下要約+アルファ：
　AVI最大の特徴はコデック定義がない事。何でもあり・FourCCでコデックは呼び出すけどあとヨロシク！なゆるゆる フォーマット。
　初期のVfWは音声・映像と も非圧縮で、Audio Video Interleavingの名の通り、30fpsの動画なら1/30秒ごとに交互に配置された静止画1枚と、1/30秒ぶんの音声を頭から再生していくの み。圧縮 コデックを使うな らその前にデコードを済ませる必要があるのは当然だが、間に合わなかった際のフェイルセーフ（同期の仕組み）が無い。いったん映像と音声がずれ始めたらズ レっぱ。副音声？字幕？んなもなぁ、想定の範囲外。

　「時間軸管理のアーキテクチャ」として誕生したQuickTimeと は対極の極み。たぶんコンテンツ・クリエイタから見てもできないことだらけじゃん！ってとこだと思う。
　だが、プログラマーにとってのとっつきやすさ、アプリの作り易さは圧倒的にVfW/AVIだ。
　null-frameを使った120fps-Variable Frame Rate、Packed B Frame（複数フレームのパッケージ化）やdelay Frame（偽フレーム挿入）を駆使したデコーダバッファ欺瞞、まてまてまてまて、そもそもMPEG-2をVfW/AVIで扱えるわけが無い、、、 D2Vって偽装ヘッダファイルか！

　なるほど 、そいつぁなかなか捨てがたいだろうなぁ。というか「事実上のオープンソース動画インフラ」と言いたい。

■"最近利用が始まった H.264でも、やはりAVIを使うことが多いようです"。について。
　しかし、妖精現実さんとこにAVC-in-AVIはトラブルの種って出てから随分たつ。
　知識の上でもVfWのデコーダ・バッファには「1フレーム in 1フレーム アウト」制限がかかる以上、framerefもmixed_refもb_pyramidもAVIに突っ込んだら再生に問題がありそうだ。ASP-in- AVIのようなシンプルなデコーダバッファ欺瞞では効かない。（参考１、参考２）
　MEncoder のman、ドキュメント、あとこの本を読んだ範囲では、H.264/AVC は過去技術の集大成で、革新的な要素は無い。ゴミのような符号化ツールを山のように積み上げ て効率をたたき出す、労働集約型人海戦術だ。なんつうの？吉野屋の店員が飯盛りで0.3秒削り、出店本部が調理場からの歩 数を平均化してカウンターを設計し、みたいな。
　だから手許ではAVC-in-AVIは中間生成物含めて一切作らない。使えないオプションがあるってのが面白く無いから。Xvidは絶対AVIだけど。

　よってたかって拡張してきた代償として、エンコのワークフローは複雑化する。Lunatiliaさんとこの例。

MPEG2デコード	ビデオフィルタ	エンコード	.mp4化
DGMPEGDec(D2V)	AviSynth	x264cli(rawvideo.264)	mp4box(.mp4)

　画質うんぬんはひとまず置く。簡便さから言えばトッツキが良いとは言い難い。

ffmpegとMEncoder

　言っちゃ悪いがLinuxというのは、winのインスパイヤだ。ヒマなおっさんと学生さんがよってたかって積み上げるも ので、言っちゃ悪いが烏合の衆だ。なにが言いたいかと言うと、誰も見た事もねーような革新的で天才的なアプリケーションが生まれてこない。それができると どうなるの？ってのがズバリわかるものでないと人が集まらない。コンセプトが伝 播・共有しにくいから。深い部分とNet関係は別かしれないが、PhotoshopとGimp、MS OfficeとOoo、iTunesとSongbird、Win98とKDE、ど素人の目に映る範囲ではどれも先行モデルがある。

　推測ではあるが、ffmpegもMEncoderもVfW/AVIを先行モデルとしている。

　それに起因すると思しき事例として、MEncoder.cにはそもそ もPTS/DTSという概念が無い。Bフレームを使いたければrawvideo.264で一端吐くしか無い。
　ffmpeg.cはまだ良いようだが、最近のMyComet G3さんによると、やや難しい部分があるようだ。

　手許の例。

MPEG2デコード	ビデオフィルタ	エンコード	.mp4化
MEncoder	MEncoder	MEncoder(rawvideo.264)	mp4box(.mp4)

　MPEG2デコードとビデオフィルタの性能や画質や規格適合性うんぬんは置く。内部的にはWin上でやってることとそんなに 違わない筈だ。

まとめ

　もちろん、理想はQuickTimeインフラ上で全てを済ませる事だが、Appleはその道を阻む。固く阻む。彼らはここを目指しているからだ。
　VfW/AVIアーキテクチャに手を入れる事はMicrosoftにしかできない。その旨味が無いからこそのWMTでもある。
　VfW/AVIを先行モデルとするffmpeg.cやMEncoder.cは、手が入る、可能性がある。何年も先だろうけど。
　ほとんどx264cli版しか使われていないにも関わらず、MeGUI（MEncoder Graphic User Interface）が名前を変えないのはそのへんの期待込み。だといいなぁ。

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

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関連

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から見てのハナシ。
　アニメの場合、なにがどうだろうと、単色のっぺりの「アニメ塗り」が映像に占める割合が多い（実写に比べてディテイルが圧倒的に少ない）。
　背景やテクスチャの精細さが際立って見える作品も多いが、その印象は前景のキャラが「アニメ塗り」だからだ。
　キャラクタの顔に皺や毛穴やニキビは無いし（この点、役者がドーラン塗りまくってる初期のカラー映画は結構圧縮しやすい）。
　着物の質感というのもまず無い（例外）。

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

　コメント欄にて「D」 さんにXbox 360「春のシステムアップデート」(2007)の内容を教えて頂きました。丁度この表どーしよーと思ってたんでラッキー（有り 難うございます）。

※Web上の情報を拾って来ただけです。未検証。

			Xbox 360	PS3	Apple TV
税込価格			39,795円(20GB)	49,980 円(20GB)	36,800円(40GB)
CPU			PowerPC カスタム 3.2GHz 3コア	Cell 3.2GHz, 1PPE+8SPE	Pentium M-based "Crofton" 1 GHz
GPU			ATI カスタム 500MHz	RSX 550MHz	NVidia GeForce Go 7300 / G72
H.264/AVC	Profile	High	◎	◎(で きる筈*2)	×
		Main	◎	◎	◎ （CABAC不可）
		Baseline	◎	◎	◎
	最大bitrate		15Mbps(*1)	不 詳(*2)	5Mbps
	最大解像度		1080p	1080p	・960x540(30fps) ・720p(24fps)(*3)
MPEG-4	Profile	ASP(*4)	×	×	×
		SP	◎ （PSP用が可）	◎	◎
	最大解像度		不詳	不 詳	720x432(30fps)
	最大bitrate		8Mbps	不 詳	3 Mbps
特記事項			・本体 HDD、USBメモリ、HDD、ネットワーク上のPCのH.264ファイル再生可。 ・AVCHD(m2ts)認識不能。 ・HD DVDプレイヤー利用時のH.264のデコードに「緑色の大きなブロック状のノイズが発生してしまう」問題は未解決。 ほかにmovコンテナ（！）や、WMV (VC-1)対応。	･MPEG-1 ･MPEG-2(PS,TS) ･H.264/MPEG-4 AVC ･MPEG-4 SP ･Motion JPEG(Linear PCM)※ ･Motion JPEG(μ-Law)※ ･AVCHD（.m2ts)※ ※システムソフトウェア Ver1.60以上	iTunesと連携。 MP4以外は一切不可。 MPEG-1/2もmovもない(*5)。

【参 考】

1. Xbox 360のH.264対応「春のアップデート」を検証
2. SCE、PLAYSTATION 3の対応動画ファイルなどを公開
3. 本田雅一の「週刊モバイル通信」 ■ 第358回 ■Another Story of PS3 #2成長するビデオプレーヤーを目指すPS3
4. ageha Apple TVの対応動画～プログレッシブ・メインプロファイルとは～

【感 想】

1. 機械的性能はPS3が圧倒的と思われる。Xbox 360との価格性能比は人それぞれだろう。
2. linuxでMEncoderを、と言う事になると：
1. PS3 は手の出しやすさで勝る。しかし現状ではまだオープンソースはSPEをウマく使いこなすに至っておらず、PPC(3.2Ghz) x1という状態に近いと思われる。
2. Xbox 360はPPC(3.2Ghz) x3の素直さで勝る。エンコ専用機にするなら抜群の価格性能比だ。しかし現状ではlinuxの稼働に高いハードルがある。
3. Apple TVは良いところが無いが、ゲーム流ビジネスモデルを取れない以上、価格性能比はこれが精一杯という事らしい。また、機能の絞り込み、解りやすさ、使い 勝手というのはこうしたデータには出てこない。楽に使えるという点では非常に評価が高いようだ。
4. いずれもMPEG-4 ASP（B入り）をサポートしていない。Xvid/Divx.AVI のナカミが一様ではないことと関係があるかも。