或るプログラマの一生

今は久しぶりに来た「コア数が増えていく時期」です。こういった場合、いくらメモリアクセスをしたりして重い処理をしても、それが L2 キャッシュに収まっている限りはコア数を増やして殴り倒すことが期待できます。

UtVideo ではどうかというと、そういった「圧縮比を改善できる重い処理」を私が思いつかない（元々そういう専門家でもない）のですが、そういえば昔 Range Coder を試していたのを思い出しました。

どれくらい効果があるか調べたいところですが、Range Coder でどれくらい圧縮できるかは実際に圧縮してみないと分からない（つまり、圧縮するコードを書いて UtVideo に組み込まないといけない）ので、圧縮対象の情報量（エントロピー）を計算することで代替することにします。 Range Coder は情報量にかなり近いところまで圧縮できます。というわけで、 predict median の場合にハフマン符号と比較した場合のグラフが下の通り。

圧縮しづらいソース (crowd_run) だと効果がほとんどないのに対し、圧縮しやすいソース (Big Buck Bunny) だとかなりの効果が出ます。 YUV444 なんか圧縮比が33％も向上しており、計算合ってんのか心配になるレベルです。

なお、グラフでは省略しましたが、10bpc の場合は圧縮しやすいソースであってもほとんど効果が出ません。そもそも Range Coder にすると何故小さくなるのかというと、ハフマン符号は符号語長が整数に制限されるため、例えば 1.5bit あればいいシンボルに対しても 2bit 割り当てる必要があるのに対し、Range Coder では非整数長の符号語を使うことができるため、その差の 0.5bit 分が改善されるからです。 10bpc の場合はこの無駄の割合が小さくなるため、結果として効果が出なくなります。

ソースによるものの効果はあるということは分かりましたが、そうすると次に気になるのは速度の方です。10年前に書いたコードは残っていたので、ざっくりハフマン符号と速度比較はしましたが、エンコードもデコードも6倍以上遅いようです。UtVideo に組み込んでしまうと圧縮に関する細かいパラメータを後から変更するのは難しいので、まだいろいろ考えないといけないでしょう。