UNIX/Linuxとはなんぞや。と思ってもなかなか掴みどころが無い。雑誌とか見てもどれが使える情報なのやら見分け難い（ど素人マカー向けの*nix雑誌なんて無いしねぇ）。Divxと3ivxとXvidでわけわかめになった時の経験から、歴史を調べてみた。

UNIX

1973に誕生

70年代のUNIX

80年代のUNIX

90年代のUNIX

2000年代のUNIX

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

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

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

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

---

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

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

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

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

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

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

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

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

パラメータの選び方

以下。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　自分の感性ではインタレ解除の良否が画質を決めます。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には好感を持ちにくいですけどね。マカーとして。

　動画も*nixもど素人。Cも読めない。しかもPPCMac。しかも英語も怪しい。数学？ナンデスカそれわ？
　ちょっとコケるとわりとすぐ目の前がまっくらになる。根性もすぐ尽きる。挫折、吐血、昇天、輪廻、転生、ただいまー。
　そうゆう時に読みかえすもの。太字化オレ。

ＰＳ用ソフト「高機動幻想ガンパレード・マーチ」の攻略サイト「ゲームの落とし穴。」内：坂上語録 より

重要なのは、武器ではなく、その使い方…戦術なのです。

腕には腕の、剣には剣の戦い方があります。
本物のサムライとは、要するに目にうつる全ての物を武器にして戦う者ですよ。
千の戦場で、千の戦い方で千の勝利を収める。
それがサムライであり、あなた方が最終的に目指す存在です。

千の戦いを覚えなさい。
私の授業は、腕には腕の、銃には銃の戦い方を教えること。
よく覚えなさい。これを戦術と呼びます。
強いのは、能力があるとか、性能がいいとかではありません。
一人の意思を持った人間が、明確な目標の下で戦術を駆使することが強いのです。
その気になれば、指一本、鉛筆一本でも幻獣は殺せます。
私が育てるのは、その強い人間です。
明確な目標…命令の下で、戦術を駆使するサムライを育てるのです。

　　いや別にエンコ侍とか目指さないけど。netのおかげでこうゆう先生は思いのほか見つかる。我以外皆我師。
　　それにしてもGPM面白いよGPM。PSP版出してよPSPごと買うよ。


　いやまぁ、こういうの読んで脳沸かすのも中学生かおれわと思わん事もないが、いろいろとど素人なもんで。

1. ■MPEG-4 SP/ASP時代（2000～2004）
   1. 総 括
   2. 年 表
2. ■H.264/AVC 時代（2005～2010）
   1. 総 括
   2. 年 表

■MPEG-4 SP/ASP時代（2000～2004）

総 括

　MPEG-4 ASPビデオの隆盛は概ね2000年を境に始まった。
　DVDのプロテクトは1999年に破られた。その後イロイロあって（おいらDVD触らないから別にどーでもいい）、
　2004末の北米ではCDドライブの一つも買えばDivXと3ivxがオマケで付き、家電売り場ではDivX.avi対応のDVDプレイヤが主流という 状態になっていた。
　この状況はMicrosoftのDNAがもたらした偶然の産物と考える。彼らが後方互換性を考慮せず、全てのユーザーにDirectShowへの移 行を強制し、それを強力に保護し、vfw/AVIをシステムから取り去っていたら、ジェローム＝ロタ（gej）がMsMPEG4をクラックするような事は 無かっ ただろう。ネットがあろうが無かろうが、それが普及する事も、オープンソースの開発が進む事も無かったと思う。
　事実上、全ての母体となったのはvfw/AVIインフラだ。放置されたvfw/AVIが、 フリープログラマー達の、枯れて、安 定した、自由な、遊び場となった。

年 表

　※細部はかなり乱暴に端折ってあります。先人のみなさんは怒らないで下さい。

年	名称	主なコンテナ	インフラ	提供	備考
？	MsMPEG4	.asf	DirectShow	Microsoft 社	ISO-MPEG4 規 格策定途上でMicrosoftが出したコデック。 先制に出たのはいち早く.asfでデファクトを取る為だったと思われる。 .mp4コンテナにはQuickTime.movのパテントがあり、普及すれば同社はAppleにパテント料を払わざるを得ない。シェアから言って莫大な 額となるだろ う。 2006現在も同社は.mp4をサポートしないと明言しており、実際していない。 同 社は映像コデックのパテントを数多く保有しており、この点からもちんたら規格確定を待つより先行したほうが儲かる。性能は高かったようだ。.ASFは現在 の.wmf。
？	divx;-) (aka divx3.11)	.avi	vfw	オープン ソース？	MsMPEG4 の.avi非対応に怒ったおっさんがクラック。.avi用に公開。 Divx+MP3.aviの元祖にして、"リップしてエンコして放流"の端緒。 出自と使われ方は黒い。
2000	MPlayer、開発 開始（当時の名称はmpg12play）、2001にはOpenDivX のエンコードも可能になっている。
2000	3ivx	.mp4	DirectShow QuickTime	3ivx社	DivX代 替を目指して設立された会社。 『　Windowsで は、3ivxの強みは MPEG-4 Audio, Video, .mp4 ファイルフォーマットを扱ったり、DirectShow フレームワークの元で動くコンポーネントを幅広く取り揃えている。ソフトウェア開発者は3ivx フィルタを自分のアプリケーションに取り込み、完璧なMPEG-4サポートを備えたソフトを開発できる。 　DirectShow 以外では、Mac OS と Windowsの QuickTimeアーキテクチャもサポート。Apple MPEG-4との互換性があり、3ivxコデックでMPEG-4 Videoのライブ配信ができる。』 http://htffmpegx.seesaa.net/article/3776508.html から孫引き 　他にUnix/linux、BeOS、Amiga版まで取り揃え、最近だとソニーのロケフリの中の人だったりもする技術番長。真の国際標準規格伝道者。 ザ・正統派。 　マカーの間では最速のMPEG-4 ASPとして名高い。自分は"神速の"3ivxと枕詞をつけていますよ。
2000 ～ 2002	Divx 4 Divx 5	.avi	vfw QuickTime	DivX社	Divx３ 開発者の一部が会社設立。オープンソースではなくなる。 成果を持ってっちゃったらしく、他のメンバーから反発をくらう。このへんちょっと錯綜。 フルスクラッチでキレイなカラダになる。 最初は拡張子.divxを使っていたフシがあ る。 DivX+MP3.aviの立役者の一人。
2002	mencoder誕 生。デフォルトコンテナは2006秋現在もAVI。
？	Xvid	主に. avi	vfw QuickTime	オープン ソース	Divx３ 残党によるオープンソース。 DivX社に対する対抗意識（明白な目標）と、需要あるところかならず誰かがパッチを書くオープンソースの特質がかみ合って着々と性能を上げ、 Doom9コデックコンテストでは僅差ながらDivXに勝ち続ける。2005にはマルチスレッドにも対応。MPEG-4 ASP 最強。
？	Apple-MPEG4	.mp4	QuickTime	Apple 社	ISO-MPEG4 規格策定を待ってApple社が出したMPEG-4 SPコデック。 性能的に見るべきものは無く、 「.MP4は始まる前から終わっている」とまで言われた。 同社は映像圧縮に関するパテントを保有しておらず、登場時点でWin界では当たり前だったBフレーム（ASP）非対応など。 2005のQuickTime7でようやくB対応を果たしたが、既に安定して代役を果たしていた3ivxやXvidなどのASP QuickTime コンポーネントをミナゴロシにし てくれやがった上にエンコ性能もそれら以下という『バージョンアップの皮を被った優越的地位の濫用』。 Xvidだけならまだしもちゃんとパテント料払ってる3ivxさんになんてことを。
2004	私事。 ふゆ：動画エンコなるもので遊ぼうとCaptyTVを買う。 なつ：ffmpegXにおちつく。 あき：高速化ソフトで怪しい文字列を見つける。 ふゆ：ターミナルというものにそのまま打つと 動く事に気付く。←ポイントオブノーリターン
2005	Divx 6	.divx	vfw？	DivX社	性能向上で XviDに遅れをとり始めたDivX社は他の分野に生き残りの道を探っているようだ。 コンテナ形式の変更はその一貫。 拡張子.divxはDVDメニュー的な要素や字幕・副音声などを付加するもので、コアの映像・音声はAVIを踏襲。 従ってVLCではそのまま再生できる。ハードウェアXvid+MP3.AVI再生機の中にもそのまま再生可能なものがある筈だ。

■H.264/AVC 時代（2005～2010）

総 括

　ASP時代とは動画エンコを取り巻く条件が結構ちがう。

【vfw/AVIの終焉】

　vfw終焉の影響は広範囲に及ぶだろう。例えば、H.264/AVCコデックの数があんまり出揃わない。 vfw/AVIにとどまる人が比較的多い。など。いずれにせよ動画エンコの進化はちと鈍る。 フリープログラマー達の、枯れて、安 定した、自由な、遊び場はもう無い。プロプライエタリ企業の集金マシーン（DirectShowやQuickTime）の上で足掻くか、ゼロから整備する linuxに参加するかだ。

　ただし、この事態が開発者の間で想定されてないわけも無く、既にwinでは移行の痛みを緩和する様々なエンコ環境の整備が進ん でいるようだ。一例はMeGUI。
　 内部的にはAviSynth（ビデオフィルタ）、MEncoder（統合エンコ環境）、x264cli、Besweet（音声全般）、mp4box （.mp4コンテナmuxer）などの詰め合わせで、方向としてはffmpegXに近い。Mac/linux/Winはオープンソースをベースに、ある程 度共通の動画インフラを持つ事になるかもしれない。

【動画需要の変化】

　YouTube.flv/PodCasting

　少なくとも2010までのコンピューテングは「ブラウザがあればあとは要らない」が軸になる。コンテンツ側の軸がCGMである ならば、それは既に動画の内容にも波及している。鮮度と話題性が命。画質は問われない。SDならミドルクラスCPUでCDリッピング並の速度が欲しいとこ ろだが、それならMPEG-4 ASPで十分。軽薄短小。それがweb2.0。

　H.264/AVCはこのトレンドに逆行する。

【知的財産権サイドの戦術高度化】

知的財産権サイドはDVD/MPEG-4 ASPから戦訓を得た。総じて「自宅PCでのエンコード」はより高度化した 『アメとムチ』に直面する。

年 表

年	名称	主なコンテナ	インフラ	提供	備考
?	wmv3 (aka wmv9, VC-1)	.wmv	DirectShow	Microsoft 社	Microsoft ここでも先制。AVC規 格策定途上なのも一緒。 H.264/AVCとは異なるが要素技術には共通点が多く、性能は悪くは無い。 画質と速度のバランスを取ったコデックと独自コンテナで先行逃げ切り戦略。 なお、H.264/AVCに於いても同 社はパテントを保有している。
?	x264	.avi, .mp4, .mpeg, など	vfw cli ？	オープン ソース	2005 中、米露２箇所のコンテストで最強のH.264/AVCと目されている。 2006年10月にvfwサポートを停止したが、これは更なる符号化効率を追求するためと推測。 なお、符号化効率を追求する上で最大の障害となるパテント問題はソース配布のみと言う形で迂回。他にも工夫はあるらしいが、可能な範囲でソースからのビル ドを検討して欲しい。
2005	Apple-H.264	.mp4, .mov, .m4v	QuickTime	Apple 社	Apple ここでも規格策定を待って後発。 映像圧縮にかんするパテントを保有しておらず総合性能は低い。しかし前回の反省からか、速度を捨てて画質に振り切ったコデックになっている。 これでハイエンドを掌握、ローエンドはiPodとiTMSでコンテンツ流通を独占するハイ・ロー挟撃。 なお、国際標準規格とは言いながら、拡張子.m4v/.m4aは規格に無く、慣習的にrawvideo, rawaudioに使われて来たもの。デファクトだからかんけーねーですかそうですか。

　この他にXvid AVC、3ivx AVCなどが進行はしているようだがまだ。
　その先にDWT系のSNOWが控えてはいるが、 JPEGとJPEG2000、GIFとPNGなどの例もあり、判断が難しいところ。

　※この記事は2005年10月09日に書いたものの改訂版です。

１）これを繰り返して向上を図る。「業務改善」と かのキホン。らしい。

　

２）サイクルってんだから、繰り返し～たぶん無限の～がミソ。

　


３）マテマテ。２パス目はこれで良いが、1stパスの"Plan"はどうやって立てるんだ？

　　なんか素 材が要るでしょ素材が。

情報は集めるだけじゃ意味が無い。消化しないと。

消化というのは、優先順位 をつける事。重要なものとそうでも無いもの、あと関係ないもの。

脳内の秩序構築を怠るとすぐに「駅の名前を全部言える子供」になってしまう。まぁ、怠るんですけども。

2パス目以降は"3. See"からのフィードバックが当然、材料になる。

0. の部分は「情報収集」にした方が通りが良さそうだが、とりあえずIntelligence：知識とした。

モノの本では「情報分析」とかになっている。日本語には InformationとIntelligenceの違いが無いともある。

４）優先順位をつけるには、「目的」が必要だ。

　


５）目的は、可能な限りシンプルに。複数目的は御法度。でないと結果検証で混乱する。ド素人だからね。
　

　色彩劣化や他の悪影響が有るかも知れないが、そこでおたおたしない。インタレ縞を潰したければ、まずそこに目標を絞る。他の事 は別に実験 するべき。すっげえ時間喰う。でもそこでおたおたするともっと時間喰う。

　「鉄人」とか「職人」とか呼ばれる人たちの頭のなかあるのは、こうしたデータベースなんであらふ。彼らの脳内にはこの他にもいろんなフォルダがあるに違 いない。それが巷間「経験値」と呼ばれるものの正体だ。たぶん。

　知識だけじゃ足りないし、経験だけでも足りない。両方を脳内でどれだけ整頓してあるか。それが自分のエンコード能力を左右する。知識と経験が増えるにつ れて分類項目は増え、必要に応じて全体が再構築され、整合性が高まり、応用範囲が広がってゆく。たぶん。

　さて、ど素人の自分が手持ちのリソース（お金と時間と能力）で、この脳内データベース構築を加速するには？書き留めればいい。外部記憶で充分。
　後でぐぐれる方が良い。どうせ頭 わりーんだから。

　面倒なので毎度は書いていませんが、自分はx264も MEncoderも万人向けと言うつもりはありません。JPEG2000やPNGのようにどマイナーな地位にとどまる可能性もあると思いま す。いずれにせよ、iTunesのCDリッピングくらいの手軽さがなければひとさまにお奨めできるものではな いです。エンコードそのものが実 時間の1/3を切るまでは、マニアの遊びでしょう。

• 1. はじめに
• 2. 妥協の前には理想が要ること
• 3. 必要のないものに深入りしないこと
• 4. 検証のない経験は非効率なこと
• 5. おわりに

1. はじめに

　動画エンコードにおいて、画質、速度、ファイルサイズは相互に矛盾する要求です。
　画質「だけ」を追求するなら無限のファイルサイズが必要です。あまり大きくては圧縮の旨味が薄れます。
　MPEG-1/2/4はどれも、ある程度の画質を諦めてずっと小さなファイルサイズを実現するものです。劣化は必ずあります。
　画質劣化を食い止めるにはある程度複雑な処理が必要です。これは時間がかかります。
　最終的にどれを重視するかは人それぞれな ので正解はありません。が。
　
　このエントリでは、何 を重視するにせよ最初に必要となるのは「いかに高いレベルで妥協するか」という精神だ。と 言い切ってみます。
　その上で、自分が心がけている基本的な事柄を書いてみます。かなり抽象的なものになると思いますが、よろしければお付合い下さい。

『国産ロケットはなぜ墜ちるのか』151p

---

　理工系とひとくくりにされがちだが、理と工の差は、通常想像されるよりもはるかに大きい。理学は自然を理解する事を目的とする 学問で、その基本には「妥 協なき真理の追究」という態度がある。それに対して工学は、理解した自然の力を応用する学問であり、基本にあるのは「い かに高いレベルで妥協するか」とい う精神だ。

　要するにこの本が面白かったんでなんか書いてみようと^^;。

2. 妥協の前には理想が要ること

　「妥協」の前には「理想」が必要です。理想の無い妥協は迷走 ですから。

画　質：素材と同じ。 速　度：一瞬。 サイズ：限りなく小さく。 　100=100点だと思ってください。

　現実にはこれは有り得ません。しかし、要素分解がミソです。多くても大変なのでとりあえずここでは三 つで。この青い三角ができるだけ大きくなるようにあれこれ工夫して「望み得る最善」に近づい ていくわけです。
　大雑把でも理想がないと、自分の妥協が適切なものかどうかがわかりません。そもそも何を・どの程度差 し出せば何を得られるのかが、いくらやっても見えてきません。漫然とエンコを繰り返してもストレスが溜まるばかりです。雑で充分です。 まず理想。
　後は手数を重ねれば重ねる程、問題点が整理され、その姿がより明確になっていきます。決してそこに手が届く事はありません。が、習得効率は上がります。
　余談ですが「理 想を要素分解して考える」ことは、 様々なケースで使えると思います。QuickTimeかlinuxインフラか、3ivxか Apple-H.264か、ffmpegか MEncoderか、などなどなど。一番重要なエンコツールは、たぶん自分自身です。
　繰り返しますが、たかが動画エンコにわざわざこんな面倒を考えるのは万人向けではありません。あくまでそれ自体を楽しめる人向けの遊びだと思います。

3. 必要のないものに深入りしないこと

　ここから先はMPEG-2 PSのアナログTVキャプチャをMEncoderのx264で、2passを使って、rawvideo.264に吐き出す前提で 書いて行きます。

　最初に書いたように、画質・速度・サイズは相互に矛盾する要求です。それでなくても動画エンコは面倒の連続です。
　なにか最初に「固定条件」 を作ってしまうと、多少は 他の要素の見通しが良くなります。ではもっとも固定しやすい条件は何か？
　画質や速度はやってみなければわからない部分が大きいですし、速度はCPUに、画質は様々な要素に左右されます。またこれらは目標を決めたところ で確実に守れるものでもありません。最も固定しやすい（そして誰が見ても比べやすい）条件はファイルサイズで しょう。 これは解像度とビットレートで決まります。

3.1. まずは解像度。手許では横幅640で固定しています。

解像度	横幅	高さ	画素数
4:3	640	480	約30万画 素
16:9 （ビスタ）	640	352	約22万画 素
シネスコ	640	272	約17万画 素

　2006秋現在、世間的には720x480や704x480の人が多いようです。
　もともと720x480は普通の4:3や映画の16:9のどっちにも使え ると言 う事で決まった中間解像度なので、正直に720x480で表示すると人間がデブになったりノッポになったりします。もちろん通常は再生時にソフト/ハード が4:3なり16:9 なりに拡大・縮小してくれるので問題はありません。が、
　手許で縮小している理由は以下：

1. 再生時に使う拡大・縮小アルゴリズムは当然リアルタイム でなければなりません。ですから性能もそれなりです。どのみち視聴時には720x480のサイズでは無い。と割り切って、MEncoderでもう少し優れた拡大・縮小アルゴリズムを使っています。
2. 720x480と640x480では5万画素ほど違います。そのぶん速度も、圧縮効率 も向上します。
3. TVキャプチャで入りがちな黒帯をなるたけcropしたいという理由もあります。そのぶん速度も、圧縮効率 も向上します。

　なお、16:9以下では高さの数値が正確な比率になっていませんが、これは縦横とも16の倍数でなければならないというMPEG-1/2/4の基本原則 に従っています。
　720x480や704x480でエンコして、拡大・縮小は再生時に行うと言う事は、映 像データをできるだけ弄らない、という事です。できるだけ弄らないという事は、素材に対する忠実度が高い～画質が良い～事に繋がります。未来のプレイヤ （ハード・ソフト）に期待している、とも言えます。

3.2 次に、ビットレート。手許では一律に1024kbpsで揃えています。

bitrate	1024kbps

　1024kbpsのx264映像と128kbpsのaac音声を.mp4に突っ込んだ場合、30分番組が概ね250MB、 CMカットして24分なら200MBになります。
　これは出来上がりサイズのキリの良さで選んでいます。
　他に、Doom9 の投票でこのくらいのビットレートがもっとも多い事。北米ではいまだに映画の1CD化が主流なのかなんなのかは解りませんが、これ はx264は1000kbpsあたり のビットレートで最も多くテストさ れており、従ってその付近で最も安定した性能を発 揮するようチューニングされている筈だと考えています。特に、オプションからは弄れない部分が、です。
　また、最新のHDレコーダでは4MbpsのMPEG-2でも まぁまぁ見れる画質と言いますから、これよりはうんと縮めたいところでもあります。

3.3 最後に、2パスしか使わない理由
　これは、特定のビットレート制限の範囲で「望み得る最善の画 質」を要求するなら最低でも2パスが必要だからです。


　この解像度とビットレートが万人向けかどうかは良く解りません。もともと画質を基準に決めたわけでは無い事に注意して下さい。単に見通しをよくする為 です。
　特定の解像度とビットレートの範囲でビットを有効に使う＝1bitあたりの画質を追求するアプローチについてはMEncoderドキュメントの『DVD映像を高画質なMPEG-4 ("DivX")にする方法』を参考に しています。

4. 検証のない経験は非効率なこと

　理想の構成要素のうち、面倒なものや自分に必要のない部分を固定すると、それ以外の部分、～例えばx264のオプション～、に集中する事ができま す。

　2005年10月から2006年10月現在まで、手許では地アナ録画のMPEG-2全てを2パス, 1024kbps、横幅640でx264+ aac.mp4にエンコード していま す。
　その条件下での画質は概ね以下の通りです。

種類	Avg QP(p)	主観画質（通常視聴）
アニメ	4:3 （640x480）は18～23程度 16:9（640x352）は14～18程度	良好 良好
実　写	落語：ノイ ズが酷くなければ20～23。ノイズが酷い場合は28程度。 サッカー：ノイズが少なくても28付近。	不満・着物 や顔のディテイル 充分
映　画	内容やノイ ズにより 様々。最悪で28程度。	素材により 様々

　Avg QP(p)と言うのはPフレームに適用された量子化値です。低いほど画質が良いので「画質劣化度」くらいに思っても良いと思います。
　ビットレート制限がある場合は、MEncoderがひとこまひとこま「画質劣化度」を調節して指定サイズに収めてくれるわけです。
　ffmpegXの作者さんはAvg QP(p)=20以下を無駄に高画質としていますが、実写素材ではビットレートを上げるなどしてもう少し低めのQPを狙っても良いかも しれ ません。

　なお、手許ではエンコード設定と数値的な結果をテキストに書き出すシェルスクリプトを 作り、毎回それを読んでいます。表計算に要点を書くのは結構サボりますが、記憶・経験・主観的な印象だけだとどうしてもあやふやになるの で、できるだけ数値的な結果を読む。違和感のある数字が出たら、なぜこの番組はこうなるのか考える、、、これで意外な事に気が付くこともあります。
　ソースコードは読めませんし、理屈を読んでもろくに理解できないので、少しでも効率よく経験値を稼ごうと思って始めた筈だったんですが、もはや番 組よりログ見るほうが楽しみなカラダに、、、。

5. おわりに

　しつこいですが、動画エンコなんてものは所詮、マニアの遊びです。

　ほんの少し、自分の服を自分で作るのに近いんじゃないかと言う気もします。そんで気が付いたらミシンの分解組立てにハマってやんの。うお、今度の新型はボタン付けができ るぞスゲェ！みたいな。地アナのインタレ縞が見えるとか地デジのブロックノイズが見えるとか。あんま意味ないです。所詮、マニアの遊びです。

　ここに書いたのはホンの一例で、実際には全くもって自由で す。それぞれの「望み得る最善」を探してみて下さい。
　遊びはマジにやらなきゃ面白くないです。

エンコード十戒

1. きれいな絵を得ようとするより、うまい設定を組もうとするべきである。
2. その絵の前の絵、その絵の次に来る絵の動きやポーズをしっかり捉えるまでは、GOP関連設定を終わってはならない。
3. 1bitも無駄にしないこと。どのbitも姿勢、雰囲気、動作、あるいは性格を表現できるのだ。
4. これが最高だと確信出来るまで、他にどんなイメージも持たないこと。あなたの使命はスクリーン上にもっとも作り手の意思に忠実なイ メージを展開することだ。
5. オプション過剰にならないこと。
6. 各ピクセルは常に、空間を動く、モーションベクトルに作用されたかたまりとして考えられなければならない。
7. あなたに欠けているものを与えてくれる人々に頼るべきである。
8. 知識を具体化するために物事を学ぶのではなく、独創的に応用するために、原理から学ぶべきである。
9. 常に量という概念を念頭に置くこと。
10. 注意深く！ しかし臆病になってはならない。

---

参考
■[アニ メ]大塚康生の「クリーンアップ十戒」（愛・蔵太の少し調べて書く日記：2007年1月10日）