readme ファイル/（英語） インストーラ（msi 形式） ソース
「より速いコーデック」はあきらめることにしましたが、実装過程で細かい変更を行ったので、それをリリースすることにします。
エンコードテーブルやデコードテーブルを生成する処理を劇的に高速化しました（具体的な数値に関しては忘れました）。それがどれくらい効いてくるのかという話になるわけですが、テーブルの生成は全体の 1% 程度でしかないので、せいぜい 0.5% 程度の高速化になります。たぶん計測誤差に埋もれます。
Huffyuv と本質的には同じ処理を、とりあえずエンコードの部分だけ実装したんですが、計測したところ期待したような速さにはなってなくて、Huffyuv と同じ速さにしかなってませんでした。ループの回り方が以前の Ut Video Codec Suite のものと若干異なるのですが、期待した速度になっていないのはそれが原因なのかも…（確証なし）。すごい苦労して実装して速度が同じとか徒労感で泣ける。
これ以上のアセンブラレベルでの最適化は無理っぽいので、このままだと「Huffyuv より圧縮率が悪くてエンコード速度が同じ」というものが出来上がってしまいます（デコード速度は作っていないのでまだ不明）。これじゃ作る意味ないよなぁ…。あきらめて、書いたコードを捨てて YUV420 対応に進むべきなんでしょうか。
元々は Huffyuv の符号長表を元に手作業で調整しようと思っていたのですが、やっていてこれは労力的に無理だと気づいて、長さ制限付きハフマン符号を生成するプログラムに放り込んで生成させることにしました。符号長が 24bit 以下でないと自分が書いたルーチンが使えないので。
長さ制限付きハフマン符号のアルゴリズムについては英語版 Wikipedia の記事でもどうぞ（日本語版 Wikipedia には当該記事がない）。
AC4 の OP もないだろうということで、HD ハンディカムで実写風景を撮ってきました。手ぶれすごいですが。
計測条件は前回とほぼ同じです。HD ハンディカムから HDMI 経由でキャプチャした 1080i のソースでテストします。なお、あまり使われないコーデックは除外していますが、どれがあまり使われないのかは恣意的です :-p
Read the rest of this entry
readme ファイル/（英語） インストーラ（msi 形式） ソース
ULRG に RGB32 で渡すソフト（たとえば TMPGEnc）からエンコードして、できた AVI ファイルを Premiere に渡すとアルファチャンネル付き映像だと思って読み込まれるのですが、その時にアルファチャンネルだと解釈される場所は 0 （完全透明）で埋めていたので、一見真っ黒な（正確には透明な）映像になっていました。このバージョンでは 255 （完全不透明）で埋めるようになったのでこの現象がなくなります。また、このバージョンでエンコードした AVI ファイルは Premiere に渡してもアルファチャンネル無しとして読み込まれます。
# コーデックのベンチマーク終わらん…
「Ut Video Codec Suite」は「ユーティー ビデオ コーデック スイート」と読むんだよ！
「Ut Video Codec Suite」は「ユーティー ビデオ コーデック スイート」と読むんだよ！
大事なことなので2度言ったよ！
# Huffyuv よりは読み方は自明だと思っていたのだが甘かったらしい。
## というか俺釣られた？