或るプログラマの一生

Ut Video Codec Suite は、開発初期の目標はともかくとして、「そこそこの圧縮率でかなりの速度の編集用コーデック」という方向にバージョンアップを重ねています。「かなりの速度」という点に関しては、アルゴリズムレベルや実装（アセンブラ）レベルでの継続的な改良により、満足できるレベルを達成できていると思っています。

さて、エゴサーチしていると、たまに「デコード速度優先より圧縮率優先の方がデコードが速い」と言っている人がいます。デコードアルゴリズム的にはそのようなことはありえないので、おそらく HDD がボトルネックになってそうなっているのでしょう。一般論としては、データ量が絶対的に大きい分野で CPU ではなく HDD で律速するというのはよくある話です。特に、最近はマルチコア化によって CPU 側の性能は飛躍的に伸びたので、相対的に HDD が遅く感じられるかもしれません（RAIDなりSSDなりにすればいいんですが）。個人的にも、昔 Huffyuv で単発の HDD にキャプチャしていた時は、書き込み速度が微妙に足りず Predict Left だとフレームドロップするので、CPU で多くの処理を行う代わりに圧縮率が良い Predict Median を常用していたことがありました。

というわけで、CPU をより多く使う代わりに圧縮率を向上させることを考えてみます。

今後も編集用コーデックであることを前提とするならば、フレーム間圧縮は一般にランダムアクセス性能を低下させるので、採用するのは難しいところです。そうするとフレーム内圧縮に限ることになりますが、フレーム内予測を複雑にしても可逆である限りそれほど圧縮率は向上せず、コード量は確実に大幅に増えるので及び腰です。また、そのような処理はエンコード速度を大幅に低下させることになるので、編集用コーデックとしてはやはり使いづらいものになりそうです。（保存用コーデックとしてならアリだと思います）

さて、ある程度大きなデータであるならば、ハフマン符号を（広い意味で）算術符号の一種である Range Coder に置き換えることで大抵の場合圧縮率が多少向上する（その代わり速度は結構低下する）わけで、その実装例が Lagarith です。ハフマン符号処理部分を Range Coder にすると Lagarith とほぼ同じ圧縮特性になり、しかも頑張ってマルチスレッド化されているので比較的速いものができます（というか Lagarith の並列性が低いのが謎）。

手っ取り早い圧縮率改善方法として Range Coder は検討に値するわけですが、Range Coder 自体の学習であるとか、高速なエンコード/デコードの実装を考え付かなければならないとかあって、検討しているだけのところで止まっているのが実際です。まとまった時間が必要ですねぇ。