或るプログラマの一生

久しぶりに C/C++ のコードを書く気が出てきたので、今のコードを眺めているところです。

amaman氏（アマレココの作者）が、ちょっと前にAMV2コーデックを発表しました。AMV2コーデックについては後日書くとして、今回はその比較ベンチマーク記事にあった Ut Video Codec Suite のベンチマーク結果についてです。

性能向上

• 共通: エンコードをほんのわずかだけ高速化した。
• 共通: デコードをほんのわずかだけ高速化した。

readme ファイル/（英語） インストーラ（msi 形式） ソース

「より速いコーデック」はあきらめることにしましたが、実装過程で細かい変更を行ったので、それをリリースすることにします。

エンコードテーブルやデコードテーブルを生成する処理を劇的に高速化しました（具体的な数値に関しては忘れました）。それがどれくらい効いてくるのかという話になるわけですが、テーブルの生成は全体の 1% 程度でしかないので、せいぜい 0.5% 程度の高速化になります。たぶん計測誤差に埋もれます。

どれくらいの人が気づいているか分かりませんが、現在のバージョンでは横幅が 4 の倍数でなければいけないといった制約はなく、それどころか奇数でも動くようになっています。奇数でも動くようにするために、プログラム側（特にアセンブラバージョン）では、かなり汚い部分があります。アライメントの問題もありますし、できればこういうのはナシにしたいところです（今更

Huffyuv と本質的には同じ処理を、とりあえずエンコードの部分だけ実装したんですが、計測したところ期待したような速さにはなってなくて、Huffyuv と同じ速さにしかなってませんでした。ループの回り方が以前の Ut Video Codec Suite のものと若干異なるのですが、期待した速度になっていないのはそれが原因なのかも…（確証なし）。すごい苦労して実装して速度が同じとか徒労感で泣ける。

これ以上のアセンブラレベルでの最適化は無理っぽいので、このままだと「Huffyuv より圧縮率が悪くてエンコード速度が同じ」というものが出来上がってしまいます（デコード速度は作っていないのでまだ不明）。これじゃ作る意味ないよなぁ…。あきらめて、書いたコードを捨てて YUV420 対応に進むべきなんでしょうか。

元々は Huffyuv の符号長表を元に手作業で調整しようと思っていたのですが、やっていてこれは労力的に無理だと気づいて、長さ制限付きハフマン符号を生成するプログラムに放り込んで生成させることにしました。符号長が 24bit 以下でないと自分が書いたルーチンが使えないので。

長さ制限付きハフマン符号のアルゴリズムについては英語版 Wikipedia の記事でもどうぞ（日本語版 Wikipedia には当該記事がない）。

以下の順序で進めようかと思っています。

4.0.2 を出してからだいぶ経ちますが皆様いかがお過ごしでしょうか。

今後の方向性ですが、どのように進めるかはそれほど考えているわけではありません。以下、まとまらない文章をどうぞ。

AC4 の OP もないだろうということで、HD ハンディカムで実写風景を撮ってきました。手ぶれすごいですが。

計測条件は前回とほぼ同じです。HD ハンディカムから HDMI 経由でキャプチャした 1080i のソースでテストします。なお、あまり使われないコーデックは除外していますが、どれがあまり使われないのかは恣意的です :-p

ちょこっとだけベンチマークをとった結果を書いときます。エンコードするソースの選定は間違ってるかも知れない（笑）。こういうソースにしろよ、という意見はコメントあたりでお願いします。