単なる 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

まあ、ちょっとだけですけど。間違ってたらツッコミかもん。長かったので畳んでおきますね。

Read the rest of this entry

機能追加
  • DMO インターフェースでデコーダを使えるようにした。

Read the rest of this entry

バグ修正
  • utv_vcm.dll のインストール先が間違っており、VCM インターフェースでコーデックが使えなかった。

Read the rest of this entry

バグ修正
  • ULY2: x64 版で RGB からエンコードする時に、映像が壊れたりエンコーダがクラッシュしたりする可能性がある。
その他
  • utvideo.dll から VCM インターフェースを分離して utv_vcm.dll とした。

Read the rest of this entry

Premiere Pro 以外でも試してみました。具体的には、Adobe After Effects CS5、Thomson-Canopus EDIUS Pro 6、Sony Vegas Pro 10 です。すべて Windows 版。

試してみたんですが、どれも汎用 AVI 出力する際にコーデックに 8bit を超える色深度で渡そうとしないようです。Vegas に至ってはそもそも外部コーデックを使う方法が分かりません(だれか教えて…)。それぞれの独自の出力プラグインを経由して 8bit を超える色深度で渡すことはできるようですが、汎用のインターフェースではどうやらできないように見えます(QuickTime だとどうなるかは不明)。Vegas なんか出力プラグインを追加できるかどうかすら分かりませんでした。

汎用インターフェースが存在してそれを使ってくれるようであれば、それに沿ったコーデックを書けばおしまい(8bit 色深度では VCM インターフェースがこれに相当する)ですが、編集ソフトごとに出力プラグインを書くとなるとかなり大変なことになります。ソフト全部集めてこなきゃいけないし。

ちくしょー

一応、技術的興味はあるので、仮想環境内に Pr CS5 の体験版をインストールして、Pr が VCM コーデックに対してどんなエンコード入力フォーマットをチェックしてくるかを見てみたのですが、Premiere Elements と同様、8/16/24/32bit RGB しかチェックしてきません。アカンがな…

ひょっとして QuickTime 経由じゃないと RGB 以外のフォーマットをコーデックに渡すことができない?