x264 エンコード実験 --subme編

x264 r1724 で 1280x720p 3501frameエンコード実験
環境とか条件とか詳細->

基本となるオプション
--preset slower(-> --me umh --direct auto --partitions all --trellis 2 --rc-lookahead 60 --b-apapt 2) --crf 22 --ipratio 1.5 --qcomp 0.70 --qpstep 12 --ssim --psnr --scenecut 60 --min-keyint 4 --keyint 300 --no-dct-decimate --no-fast-pskip --no-mbtree --aq-strength 0

このオプションに加えて、--refを 1～9、--bframesを 0～6、--submeを 0～10 まで変化させてエンコードを行い(9*7*11=693回エンコードを行った)、ログを保存するプログラムを適当に作り、あとでエクセルの表にして分析した。

今回はとりあえず、--ref 5 --bframes 3 の時、--subme を変化させるとどうなるかをグラフと表にしてみる。 左目盛りで
CPU使用率(%)、
エンコード速度(fps)、
(エンコード後の)容量 (MAX の時を100%としたもの)

右目盛りで
SSIM(db) (ようは画質)

CPU使用率やfpsはその時のパソコンの状態による。たとえば、OSのバックグラウンドタスクとか。
また、CPU使用率の取得方法が割と適当なので…参考程度に。6コア/12スレッドはさすがになかなか使い切ってくれない。

あと、SSIMは画質をあらわすが、SSIMの値と人間から見た動画の見た目は必ずしも一致しない。
だが、画質を数値としてあらわすにはSSIM(やPSNR)しかないので、とりあえずSSIMを使う。


クリックで拡大

ただし、subme 0 の時は --direct auto が許されないので、自動的に --direct spatial に変更されている。

まあ、submeの値を上げるにしたがって、
・高画質化
・遅くなる
・subme 3 ぐらいまでは容量もちぢむ。

とりあえず subme 0,1あたりは使わないでしょ…
それにしても、subme 2 以降
CPU使用率は(ほぼ)上がり続けるのに、
速度は下がり続ける…

subme 9 と 10 がなにも変わらんのは--aq-strength を 0 にしたせいかな。
なんか subme 10 って AQ を使うらしいので。

CPUパワーと時間があれば subme はどんどんあげればいいかな。
だいたい順調に高画質化するので。
時間に対するパフォーマンスがいいのは subme 3-5 かな。