とにかく QuickTime の技術的メモ
- AVI ファイルを開いてデコーダにフォーマットが渡されるとき、一般的な情報(幅、高さ、dpi、など)以外は BITMAPINFOHEADER の状態で渡される。特に、BITMAPINFOHEADER の後ろに独自の拡張情報を格納するコーデック(Huffyuv や Ut Video Codec など)は、このことを知った上で情報を取り出す必要がある。
- これはつまり、コーデックは自分の拡張情報がどうコンテナに格納されるかを知っていなければならない、ということである。コーデックはコンテナを知っていなければならない。(拡張情報が不要なコーデックの場合はこの限りではない)
- 一方、インポーター(データストリームをコンテナフォーマットにしたがって解釈して映像/音声ストリームに分解するコンポーネント)は、コーデックを知っている必要はない。実際、QuickTime 標準の AVI インポーターで、 ULRG な AVI ファイルを開き、ULRG のデコーダに渡すことができる。コンテナはコーデックを知らなくてもよい。まあ、そりゃそうだ。
Ut Video Codec Suite 的には元々 AVI ファイルだけしか対応するつもりはないので、別にこれでも問題ないんですけどね。
単なる 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 じゃねぇかと小一時間(ry
一方で、 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 はよく見たらデコーダしかないんですな。エンコーダで参考になりそうなソースがあったら教えてください…
- バグ修正
-
- DMO デコーダで、出力フォーマットを列挙する際に矛盾したフォーマットを返していた。
Read the rest of this entry
最初にことわっておくと、Linux には SO_REUSEPORT はない(追記: Kernel 3.9 で追加された)。Windows (Winsock) にもないし、Linux に近い環境を構成する Cygwin にもない。(Solaris はどうだったかな…) 今現在簡単に入手できる OS のうち SO_REUSEPORT があるのは、大まかに BSD に分類される OS、つまり {Free,Open,Net}BSD の系統と Mac OS X だけである。
Read the rest of this entry
まあ、ちょっとだけですけど。間違ってたらツッコミかもん。長かったので畳んでおきますね。
Read the rest of this entry
- 機能追加
-
- DMO インターフェースでデコーダを使えるようにした。
Read the rest of this entry
以前のエントリで書いたとおり、Ut Video Codec Suite に DMO デコーダを追加しようとしています。
ひとまず DirectShow グラフに追加できるように、DMO エンコーダをコピーしてフォーマットのネゴシエーションだけ書きかえて GraphEdit で読み込ませようとしましたが、ULY2 な AVI ファイルを Render File しても DMO デコーダを使ってくれません(VCM コーデックを AVI Decompressor でラップしたものが使われる)。
Read the rest of this entry