EDIUS Pro 5 で Ut Video Codec Suite が使えない(読み込むとクラッシュしたり映像が激しく乱れたりする)、というのは昔から知られているのですが、ようやく体験版を使って原因を突き止めました。ちなみにアップデータバージョン 5.01 を適用した EDIUS Pro でも使えないそうです。
結論から言うと、EDIUS 側のバグだと考えています。EDIUS ユーザはバグレポートするといいでしょう。バグレポートの際に参考情報としてこの記事の URL を Canopus に教えるのは、もちろん問題ありません。
以下はバグの内容です。プログラマでない人は読んでも意味不明なんでスルー。
VCM インターフェイスでデコードする際、コーデックに送られる ICM_DECOMPRESS メッセージにおいて、
((ICDECOMPRESS *)wParam)->lpbiInput->biSizeImage
には、正しくはフレームのエンコード後(つまりデコード前)のサイズが入るべきなのですが、EDIUS ではそうなっていません。じゃあ何が入っているのかと言うと、(ULY2 を YUY2 にデコードさせる場合は)RGB24 で計算したフレームのサイズです。コーデックに要求した出力フォーマットで計算したフレームのサイズですらありません。多くのコーデックではこの値は見ていないので EDIUS でも正常に使えますが、Ut Video Codec Suite ではこの値を見ているので、異常な動作になります。
MSDN にはここに何を入れろとは書いていないようなのですが、マイクロソフトの実装(DirectShow でデコードする際に使われる wrapper など)ではエンコード後のサイズになっていますし、他のほとんどの実装でもエンコード後のサイズになっています(そうなっていない実装は EDIUS しか知りません)。さらに、Visual Studio 2005 に入っている vfw.h の 415 行目では
typedef struct { DWORD dwFlags; // flags (from AVI index...) LPBITMAPINFOHEADER lpbiInput; // BITMAPINFO of compressed data // biSizeImage has the chunk size LPVOID lpInput; // compressed data LPBITMAPINFOHEADER lpbiOutput; // DIB to decompress to LPVOID lpOutput; DWORD ckid; // ckid from AVI file } ICDECOMPRESS;
というコメントが付いています。というわけで、ここにエンコード後のサイズを入れるのが正しいのは間違いないでしょう。
BITMAPINFOHEADERにデコーダ固有の情報を入れるべきではありません。
多くのエンコーダでは独自に扱います。
biSizeImage はデコード時の1フレームの最大サイズが入ります。大きくても構わないのです。
DivXなんかはフレームのほうにデコード情報が入ってます。
BITMAPINFOHEADERで使われているフィールドはfccと解像度くらいかな。
あとコーデックやDirectShowの世界では、ドキュメントはあまり信じてはいけないです。
用語が揺れているので最初は読んでて意味不明でしたよ。
ドキュメントがあまり信用ならない、というのはDirectShowに限らず同意ですが、上の挙動はマイクロソフトの実装を見て判断しているので、ドキュメントが云々とは違いますね。