Huffyuv と本質的には同じ処理を、とりあえずエンコードの部分だけ実装したんですが、計測したところ期待したような速さにはなってなくて、Huffyuv と同じ速さにしかなってませんでした。ループの回り方が以前の Ut Video Codec Suite のものと若干異なるのですが、期待した速度になっていないのはそれが原因なのかも…（確証なし）。すごい苦労して実装して速度が同じとか徒労感で泣ける。
これ以上のアセンブラレベルでの最適化は無理っぽいので、このままだと「Huffyuv より圧縮率が悪くてエンコード速度が同じ」というものが出来上がってしまいます（デコード速度は作っていないのでまだ不明）。これじゃ作る意味ないよなぁ…。あきらめて、書いたコードを捨てて YUV420 対応に進むべきなんでしょうか。
ここんとこ不安定な天気が続いていますが、先ほどから東京都区内は猛烈な雷に見舞われております。実はさっきまで寝てたんですが、雷光と雷鳴で目が覚めるという凄まじい状態でして。
雷のせいで停電したりPCが壊れたりという被害はなかったので、個人的には大した問題ではない（せいぜい雨の中晩飯を食いに行くのが面倒なのでサトウのごはんにした程度）のですが、全国的には土砂崩れとかすごい被害になっているようですね…
しかし、開封時に手を切りそうなパッケージは何とかならないのだろうか。ゲイツポイントに限ったことではないのだが…（コントローラとかのパッケージもやっぱり手を切りそう）
元々は Huffyuv の符号長表を元に手作業で調整しようと思っていたのですが、やっていてこれは労力的に無理だと気づいて、長さ制限付きハフマン符号を生成するプログラムに放り込んで生成させることにしました。符号長が 24bit 以下でないと自分が書いたルーチンが使えないので。
長さ制限付きハフマン符号のアルゴリズムについては英語版 Wikipedia の記事でもどうぞ（日本語版 Wikipedia には当該記事がない）。