QuickTimeとその他の違い。　ageha was here

　自分の理解では、QuickTimeはOSの中の「動画やマルチメディアを扱う枠組み」ではなく、「時間軸を取り扱う仕組み」だ。
　Quick"Time"と命名した以上「時間軸を軸足にデータを取り扱う」という発想が芯。でなければ描画関連のQuickDrawと並べる形で、QuickMovieなどとしたハズだ。プログラミングを知らない自分から見るとほとんど思想に近い。たぶんドキュメントの言い回しや部品のネーミング一つとってもそうなってんだと思う。

　 CPUパワーが足りなければ勝手に映像を間引いて（ほとんど放棄してでも）同期を保つ、だけでなく、指定したtimescaleに合わせて式と数値からCGをレンダリングしてみせるなどの未来予想もあったと思う。QuickTime3DもQuickTimeVRも統合時間軸に貼付けるコンテンツの地ならしという志向を持っていたのかも知れない。今から考えれば、だけど。

　んなブッ飛んだ発想が普通に理解できるハズもなく。当時の雑誌では「よーするに動画が扱えるわけだ！」という事になっていた。おいらもそうとしか思えなかったし、今でもユーザーとしちゃそれで充分だと思っている。脳内を動画に限っていると、Video for Windows/Audio Video Interleaveという名前の方が断然明瞭で、飲み込み易い。恐らくはドキュメントの言い回しや理解が必要な概念などもそうなのだろう。

　MPEG-4がコンテナ形式の土台としてQuickTime.movを採用したという事は、ISOの専門家がこのブッ飛んだ思想をある程度受け入れた事を意味する。
　gpac公式に「シーン記述言語のチュートリアル」というのがあるが、なんのことやらわけわかめ。映像・音声・テキスト以外の部分の規格の幅広さを見ても、それがどこでどんなふうに必要になるのか想像もつかない。いっそ「コンピュータでデータを扱う事」ソレ自体のパラダイムシフトと思ったほうが早いんでねぇのか。とか思う。

　などと知ったかぶってても役にも立たないので徐々に話しを戻すと、

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

---

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

　たぶんQuickTimeは理系。徹底的な理想追求。立派だがちとうんちくが長い。
　vfw/AVIは工学系。現世利益最優先。田舎の温泉旅館みたいに建て増し、建て増しで、迷う、、、ぬお、こんなところに階段が！みたいな。


　てな事をだらだら考えたのはMyCometG3さんとこにこうゆう記事が出たから。

20061004：MyCometG3　概念の違い

---

QTの世界では、フレーム自体が表示位置と表示時間長の属性を持つのだけれども、libavcodecのAVFrameには表示位置の属性しかない。pts(Presentation Time Stamp)しかないんだ。
／／
だから、頭から順番に再生している場合はいずれも問題ない。けれど後者の場合、フレームの終了時間という概念がないので、頭だしや切り貼りをする際に考え方が曖昧になる。この仕様上、逆転再生が困難なのも容易に理解できる。

　固定フレームレートが前提のAVIモデルから表示時間長という概念は生まれようが無い。時間軸操作のインフラなら、時間にからむ属性は佃煮にするほどあるハズだ。vfw/AVI由来(*1)とQuickTimeは土台というか、世界観が違う。「CPUのキモチ」になる事をインフラの作り手に求めるか、アプリの作り手に求めるか。みたいな？

　libavcodecでフレームの終了時間が必要な場合は前フレームのPTSと当該フレームのPTSから引き算するなどのシカケをアプリの作り手がいちいち用意する事になる。他にもその場しのぎの弥縫策が佃煮にするほどあるはずだ。

　ちなみに、mencoder.cはPTSはおろかDTS（Decoding TimeStamp）すら一切知らない。メーリングリストで誰かが言ってた。
　デコーダバッファに入って来た順に先入れ先出しする。しかできないらしい。再生はfps指定値命。
　MPEG書き出しはvideo stream内の規則性を逆手に取ってPTS/DTSを推算で書き込んでんだとか。

　だから、mencoderで.mp4を吐くには、-x264encoptsからBを完全に排除して、ちょっとスゲェオプションを使う必要がある。（*2）。
　B付きは一旦rawvideo.264で吐いて、mp4boxで固定fps映像を.mp4に突っ込む方法しか見つからないのはPTS/DTSサポートの欠落が理由だ。これもメーリングリストで誰かが言ってた。
　以下は根拠レスの推測になるが、
　rawvideo.264を直吐きするって事は、mencoder.cに、x264.a（*3）の出力に触れさせないという事だと思う。
　すなわち、rawvideo.264の中にはDTSが残っており、PTSはmp4boxがfps指定値から推算、、、してんだろーなー？コレ。まぁ、そうだったらイイナ！
　建て増しだらけの温泉旅館。

　.mp4の直吐きができるx264cliはもう少しマシに見えるが、AviSynthが吐くのはたぶん固定FPSのrawYUVだからやっぱ決めうちでPTS書いてるだけかな。出力fps指定オプションあるし。いずれにせよAviSynthの無いMacでは実用性に乏しく、また妖精現実さんによれば.mp4直吐きは信頼性が低い。
　そもそもfaacもlameもffmpegもコデックとセット配布のcliは、コデックが吐くraw datastreamのテスト用と思った方が良いらしい。CPUのキモチ的には、rawdataのままで実用になり普及もした.mp3と、最低でも映像と音声を一個のコンテナに詰め込んで同期させなきゃいけない動画とは異なる。

　コンテナの規格適合性ではQuickTimeインフラが最善。なにより.movは.mp4の母体なのだから。コデックとビデオフィルタが致命的に弱い。
　良いコデックとビデオフィルタ、すなわち画質ではMEncoderが最善。これはもう断定しちゃうよオイラ。
　winでどうなのか、つまりAviUtilやAviSynthは知りませんが、" 1 フレーム イン・1 フレーム アウト "ベースのvfw/AVIインフラを経由するワークフローでは、データ配置が著しく自由なH.264/AVCの真価を発揮する事は困難と推測しますです。つまりコデックは豊富だがプロプライエタリのvfwインフラが足をひっぱる。まぁインタレ解除やデノイズの方が重要ですけど。
　MEncoderに移行して優れたフィルタを移植するとか、MPlayerG2（-vfの構造はそのまま）やgpacやMatroskaの開発に参加するとか、してくれる人が増えると嬉しいなっと。天下万エンコ厨の為にw（*4）。

（*1）libavcodecに限らず、linux全般が目指すのはWindowsへのキャッチアップだ。Ubuntuがスッキリ解り易いといってもやっぱMacのほうがラク。
（*2）つまりBaselineprofile＝iPod向けなら直に作れるハズ。PSPが要求するSPS・PPS回りのオプションも最近出来た。この辺は携帯動画変換君=ffmpegユーザーのフィードバックのおかげだと思う。
（*3）どちらもバイナリ内の相当部分。
（*4）あ～でもCから直にmmx呼ばないでねおいらPPCだから。SPE呼んだら天才。



　目先の役に立たないもんには苛つくが、車輪が発明された後も、何年もコロの方が実用的で信頼性も高く、広く使われていたハズだ。コンピュータ業界の1年は他の10年に相当すると言うのはまだぜんぜん未成熟とゆう事でもある。Win95登場以前にQuickTimeを考えついたおっさんには、どうやってそういうアイデアに至ったのか一度聞いてみたい気もする。