x264、vfw廃止とmencoder API互換　ageha was here

　※ご注意：すいませんちょっと一部脳が不自由な人に見える箇所がありますがねむいからいーや。

　x264のrevアップが止まらない。マカーでめんこでらーでただのユーザーなおいらには直接影響しないが、なんか大物連発に見える。

　特にvfw廃止でwin界では「その時歴史が動いた今日のその時です」と松平アナに追いつめられてる方があるようですが裏返せばvfw版は「事実上のリリース」と考えて因果地平に転生するのも良いと思います。長年使い慣れたツールを手放すのは実際ツライもんですし、しばらくの間、自分の能力が落ちたような地味な敗北感が拭いきれないものがあります。アプリやCPUも重要ですが、一番重要なエンコツールはあなたが楽しめる事ですから、枯れたAviUtilの使い勝手も含めて移行時期はよく考えて下さいね。vfwにとどまる方はこれ読んで元気を出すが良いです。あとなよっちい声で「ボクが一番ウマくAviUtilをつかえるんだぁ～」と叫んで見るとか。あ、実際に声に出すかどうかは自己責任でお願いします。これを機会にAviSynth+x264cliにハマって行く方には此方が実践的かもしれませんがちょっと瘴気が濃いんでペジテのマスクじゃムリでした。
　いや余計なお世話ですがなにやら他人事に思えませんでつい出過ぎた事をはっはっは、、、OS9って知らないよね？うん、なんでもない。

　おう、くされマカーども。Doom9がMeGUIに集結するぞ。気合い見せろや。「キサマらの画質はAviSynthのおかげとゆー事を忘れるな！」、、、ってなんかすぐ死にそうだなぁヲイ。ま、一生ゲリラだろマカーはよ！QuickTimeでもなんでもいーからヤツらに一泡ふかせてやろーぜ。決起てよマカー。いや精神的な意味で。起立しちゃキーボードうちにくいでそ？ってもちろん性的な意味でぢゃないしまえぇぇ！まぁたおまえどっかでエロwmv拾って来ただろー？いーから！そーゆーのいーから！これは卒業までせんせー預かっうわすげナニこれドコで拾っ、、ち・がーうっ！！
　手を止めるな足を止めるな仮説を立てろ実験しろ検証しろ考えろ考えろ考えろThink! Think! Think! Think differentは最後の武器だ！Jobsの出すもん無条件にマンセーしてんぢゃねぇ！！ん・な・も・ん・マカー・ぢゃ・ねぇっ！！！
　OSの差が決定的な違いでない事を、教えてやるうっ　いやだから声ださなくていーから。ね？

　競争なき世界に向上はありません。お互い頑張りましょう。うわーねみー。一番頑張ってないのはてめーだ＜オレ

https://trac.videolan.org/x264/timelineから抜粋

---

■10/05/06:

10:15Changeset [581] by pengvado

no more vfw

03:57Changeset [579] by pengvado

accept mencoder's option names assynonyms (api only, not in x264cli)

１）no more vfwについて

　04/07月にDoom9のbond氏が書いた『MPEG-4のB- frameを AVI/VFW に入れるハッキング（裏技）について（試訳）』から推測するに、vfw/AVIインフラ下でx264が真価を発揮するのは難しい。マルチプル・レファレンス、ミックスド・レファレンス、b_pyramidなどはいずれもvfw/AVIインフラの " 1フレームイン・1 フレーム アウト "原則と矛盾する。これらの符号化ツールをハッキングで実現することはいずれも上記より難易度が高い。
　x264がこの先きのこるためにはコデックの性能でAtemeやNero DigitalAVCやXvidやDivxを突き放す事が必要だが、vfwはその足枷になる。コデック単独で実現できる画質に限っては、失礼ながらこのGUIで弄れる設定でApple-H.264に勝つのは難しいかもしれない(*1)。

２）accept mencoder's option names as synonyms (api only, notin x264cli)について

　これはコデック本体のAPI互換という事なので、おいらのようなユーザーには全く関係が無い。
　コデック本体というのはx264.aやx264.soなどの"ライブラリ"の事で、x264cliはどうもコデック試験用インタフェイスのようだ。
　x264cliとmencoder -x264encoptsは書式が異なり、オプションの分類方針も一部違う。
　書式の違いはユーザーだけの負担だが、分類方針の違いはmencoder開発コミュニティの負担のはず、、、地味に作り易くなった？


　一時期、MPlayer/MEncoderメーリングリストに於いて、x264の「リリース」をmencoderに内蔵する形で実施しようという話が出た事がある。去年の今頃（05/秋）だったと思う。その後、mencoder自身がvfw/AVIをモデルとして作られた事に起因する（とおもわれる）問題が相次いで発見され、そのトピックは立ち消えになった感があるが、賛成ばかりで反対意見は見なかったように記憶している。また、mencoder自体は"x264に変更があればいつでも追随する"方針を維持している。

　自分の理解では、mencoderはビデオフィルタやコンテナmuxerを拡張できる統合エンコード環境だ。その内部構造は以下の通り：

0.素材ファイル
　　│
1.コンテナ判定
　　│
2.映音分離(demux)
　　│
　┌┴─────────────────────┐
　│　　　　　　　　　　　　　　　　　　　　　　│
3.コデック判定（映像）　　　　　　　　　　　　コデック判定（音声）
　│　　　　　　　　　　　　　　　　　　　　　　│
4.対応コデック呼び出し　　　　　　　　　　　　対応コデック呼び出し
　デコード　　　　　　　　　　　　　　　　　　デコード
　│　　　　　　　　　　　　　　　　　　　　　　│
5.フィルタ　　　　　　　　　　　　　　　　　　フィルタ
　（-vf、インタレ解除・デノイズ等）　　　　　　（-af、詳細不詳）
　│　　　　　　　　　　　　　　　　　　　　　　│
6.指定コデック呼び出し　　　　　　　　　　　　指定コデック呼び出し
　エンコード　　　　　　　　　　　　　　　　　エンコード
　（-ovc x264等） 　　　　　　　　　　　　　　　（-oac faac等）
　│　　　　　　　　　　　　　　　　　　　　　　│
　└┬─────────────────────┘
　　│
7.映音統合
　（指定コンテナにmux、コンテナヘッダ書き込み。-of ）
　　│
8.ファイル書き出し
　（-o）

　※Bフレームを使った場合、.mp4書き出しは不可（06/10月現在）。あと字幕や副音声は触った事ないです。

　mencoderの内部は様々な部品に別れており、それぞれのコデックや映/音フィルタやコンテナmuxerは部品としてmencoder.c（に相当する部分）が呼び出す。mencoder.c本体は作業全体の統括者に過ぎない。
　例えば手許ではx264をビルドするとx264.aができる。これはアーカイブ形式ライブラリと言って、ビルド時にmencoder内部に取り込まれるものだ。これがコデックとしてのx264の本体。他にmencoder本体の外に置いておき、必要に応じて呼び出すダイナミックリンク形式ライブラリというやり方もあるようだが、怖いのでやって無い。

　MPlayer/MEncoderのコマンド総数は800余り。各OS固有のVideo/Audio driverや、デコード後、フィルタに渡す映像形式を指定するようなオプションや、TVキャプチャカードやストリーミングから、直に入力を受けるものもある。全体としてはlinuxの動画インフラと呼んでも構わないと思う。
　そこにはナニカ統一されたルールがあるはずだ。mencoder固有のAPIみたいなものが。でなきゃここまで膨れ上がる筈が無い。

　問題はその全体を統括するmencoder.cがvfw/AVIをモデルとして作られている事。その結果VFRもBフレームに伴うフレーム並べ替えも扱えないのだが、全体を統括する根幹部なだけに迂闊には手が出せなくなっている。コデックやコンテナの中にはVFRやBに対応したものがあるわけで、どこにどんな形でvfw/AVIモデルの制限を回避するハッキングが潜んでいるか解らないからだ。-of mpegすらexperimentalが取れたのは比較的最近だし、Bフレームはハッキングで実現している。オープンソースでは需要あるところ誰かが必ずパッチを書くものだが、それは増築に増築を重ね続ける温泉旅館でもある。

　駄菓子菓子。希望が無いわけではない。
　vfw/AVIインフラそのものに手を入れる事はマイクロソフトにしかできず、そしてその可能性はゼロだが、mencoder.cなら、C/C++のリテラシーとド根性があればできる。API互換で別モノをフルスクラッチする手もある。可能性は限りなく低いがゼロでは無い。オープンソースでは需要あるところ誰かが必ずパッチを書く。己の名誉と、達成感の為に。必要なのは注目と需要。それだけだ。集まれば集まる程、実現可能性が高まる。x264のインタレ保持だって"パンドラの箱"と呼ばれていたのだ。

　mencoderのビデオフィルタはたぶんAviSynthやAviUtilに劣るし、MP4 muxerはQuickTimeに劣る。それでもMac/Win/*nixにまたがる汎用動画インフラとしては最右翼だろう。Gimpの成果物がlinuxのデスクトップ環境の礎となったように、再生のVLC、エンコのmencoder、それらを支えるffmpegがlinuxのQuickTime/DirectShowの役割を担う日が来るかもしれない。もう来てるのかもしれない。

　動画エンコードに於いてMacとWinの間に埋め難い差が開いた原因はvfw/AVIにあると思っている。後方互換性命のマイクロソフトの血が、商売に役に立たなくなった後もそれをシステムから取り除く事を許さなかった。結果的にvfw/AVIはホビープログラマーの自由な遊び場となり、そこから無数のコデックとツールが産まれた。
　vfw/AVIが時代遅れなら、新しい遊び場があった方がいい。一定のひな形が用意されている事。情報が広くいきわたっている事。自由である事。

　QuickTimeは、使うぶんには簡単で、ラクチンで、最高だ。でもJobsの掌から一歩でも踏み出そうとすると、Macはずいぶん不自由になったもんだとも思う。
　息苦しい。

　Mac OSX には、もう一つの動画環境があったほうがいい。
　手を止めるな足を止めるな仮説を立てろ実験しろ検証しろ考えろ考えろ考えろ。
　ゴミのようなファイルを山のように積み上げてやる。そのてっぺんで自由が手に入るならな。たぶん、そのほうが楽しい。