とにかく QuickTime の技術的メモ
- AVI ファイルを開いてデコーダにフォーマットが渡されるとき、一般的な情報（幅、高さ、dpi、など）以外は BITMAPINFOHEADER の状態で渡される。特に、BITMAPINFOHEADER の後ろに独自の拡張情報を格納するコーデック（Huffyuv や Ut Video Codec など）は、このことを知った上で情報を取り出す必要がある。
- これはつまり、コーデックは自分の拡張情報がどうコンテナに格納されるかを知っていなければならない、ということである。コーデックはコンテナを知っていなければならない。（拡張情報が不要なコーデックの場合はこの限りではない）
- 一方、インポーター（データストリームをコンテナフォーマットにしたがって解釈して映像/音声ストリームに分解するコンポーネント）は、コーデックを知っている必要はない。実際、QuickTime 標準の AVI インポーターで、 ULRG な AVI ファイルを開き、ULRG のデコーダに渡すことができる。コンテナはコーデックを知らなくてもよい。まあ、そりゃそうだ。
Ut Video Codec Suite 的には元々 AVI ファイルだけしか対応するつもりはないので、別にこれでも問題ないんですけどね。
World IPv6 Day も終わって別に問題なさげなので、ネットワークエンジニアとしては IPv6 対応しなきゃいけないよなぁ、とは思っています。
Web サイトとして IPv6 対応するには以下が全て満たされなければいけません。
- ISP が IPv6 接続性を提供する
- DNS に IPv6 アドレス（AAAA レコード）を設定できる
- OS のサポート
- Web サーバソフトウェアのサポート
このうち、OSとサーバソフトウェアに関してはとっくの昔に対応しているので問題ありません。
DNS サービスは、ホスト名を見ての通り DynDNS を使っています。W6D 時点では Dynamic DNS では AAAA レコードには対応していなかったはずなのですが、今さっき社内 IRC でボヤいたら「いや対応してるみたいよ？」と言われました。おぅ、いつの間に… DynDNS の IPv6 Implementation Plan を見てもいつ対応したかは書いてないのですけどね。若干不親切ですが、まあいいか。
最大の問題である ISP ですが、法人向けサービスでは予定が立っているものの、個人向けサービスでは未定のようです。この調子ではまだまだ先のことになりそうです。
単なる QuickTime の技術的メモ。Mac OS X 10.6 + QuickTime 7 環境下。
- kImageCodecPreflightSelect で CodecDecompressParams::wantedDestinationPixelTypes にコーデックがサポートするピクセルタイプを設定しないと無限ループする。より正確には、QuickTime Player が扱えるピクセルタイプが設定されていないと無限ループする。
- ピクセルタイプの k24RGBPixelFormat は
実際には何故か1ピクセル4バイトで←ごめん嘘、k24RGBPixelFormat だけサポートしてると返したのに k32ARGBPixelFormat の PixMap が渡されていた、バイトの並びが (A) R G B の順序でラインがトップダウンとなっている。これは、Windows BMP の BI_RGB 32bit の時にバイトの並びが B G R (A) の順序でラインがボトムアップ（biHeight が正の値の場合）なのとはちょうど逆である。なお、A の所に 0 を入れると QuickTime Player では（RGBの値が何であっても）黒になって表示されるので、お前それ ARGB じゃねぇかと小一時間（ｒｙ
一方で、 k32ARGBPixelFormat は QuickTime Player は対応していないようだ。- kImageCodecDrawBandSelect で QuickTime Player 側（あるいは ImageBaseCodec 側）がコーデックに渡してくるバッファは稠密ではなく、しかもライン間の隙間の空き方が妙である。たとえば、手元の環境で
k24RGBPixelFormatk32ARGBPixelFormat で幅 640 ピクセルの映像をデコードさせようとすると、最初のラインの先頭と次のラインの先頭とは 640×4=2560 バイト離れていることが期待されるが、実際には 2576 バイト離れており、16 バイトの隙間があることが分かる。Windows BMP のように「必ず n バイトアライメントにする」といった規則は無いように思える（2560 バイトは十分にキリのいい数字である）。なお、この値は ImageSubCodecDecompressRecord::rowBytes に格納されている。
- ImageSubCodecDecompressRecord::rowBytes はバッファのフォーマットが packed でないと意味のある値を保持できないように思えるので、試しに planer なフォーマットである kYVU9PixelFormat でどうなるか調べようとしたが、QuickTime Player ではサポートされないので分からずじまいであった。
- そもそも QuickTime 用語で Band ってなんなの？
rowBytes のまわりがめんどくせぇなぁ。
相変わらず QuickTime for Mac の挙動を調査しているところです。
骨組みだけ書いて走らせると、QuickTime 側がコンポーネントを開いて閉じてを無限に繰り返す状態になってしまいます。Perian にデバッグコードを仕込んで HFYU （Huffyuv ね）な AVI ファイルを開いた場合は当然ながらそうはならないので、何か実装が間違っています。試しに Perian を「HFYU だけ除いたもの」と「HFYU だけ実装したもの」とに分解してビルドしてもちゃんと動くので、コーデックを実装する際に他の要素（たとえば AVI ファイルを開くコード）も書かなければいけない、ということも無いようです。
ちょっとずつ Perian を削ってってどこがクリティカルなのか調べるしかないかなぁ…
とりあえずコーデックコンポーネントの骨組みを書いて挙動を調べているところで、ようやく Open イベントが飛んでくるようになったところです。先は長い。あと、コンポーネントの拡張子は何でもいい（.component でなくてもいい）みたいですね。
ところで、Perian を参考にして書いているのですが、Perian はよく見たらデコーダしかないんですな。エンコーダで参考になりそうなソースがあったら教えてください…