或るプログラマの一生

単なる 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 のまわりがめんどくせぇなぁ。