x264の--threads 参

これまでの
x264の--threads
続 x264の--threads
の続き。

指定した--threadsの値によって変化する容量と画質について調べてみた。

---

x264の--threadsでは、bitrateの増加は気にしない、と書いた。で、今度は一応そのへんも気にしてみよう、ということ。

画質はとりあえずssimの値で評価する。(まあ画質をssimだけで比較するのは微妙だろうけど、それ以外に客観的に比較できないので)

---

環境
Intel Core i7 3770K (4C/8T, 3.9GHz @ 1.05V)
メモリ DDR3-1600 9-9-9-24 16GB

Win7 x64
Aviutl 0.99m
x264 r2208 x64 8bit
x264guiEx 1.57

素材
H.264 1920x1080p 23.976fps 2154frames

Aviutl フィルタ無し

x264 オプション
--preset slow --tune ssim --crf 20 --qcomp 0.7 --min-keyint 4 --keyint 240 --subme 9 --trellis 2 --ssim

Core i7 3770Kは論理8コアなので--threadsは自動設定なら"12"となる。

---

とりあえず、今回も速度から。

まあ、これまでとほぼ同じ傾向。--threads 12～21ぐらいまでが最速。22～24はやはり多すぎるのか、やや遅くなっている。

次に、容量(bitrate)とssimの変化を見てみる。

違いがあるとはいえ、そんなに大きな差じゃない。

わかりにくいので、--threads 1の時に対する値の変化をグラフにしてみる。

bitrateが増えたといっても今回は0.2%以内なので、そんなに気にする程でもない。

しかし、容量は画質とあわせて考えるべきもの。画質が良くなっていれば、容量が増えるのは当たり前だ。その点、このグラフでは容量と画質を合わせて考えるのには向いていない。

容量と画質を合わせて考えるためにグラフの書き方を変えてみた。

横に容量の変化、縦に(ssim)画質の変化をとっている。点の横についているラベルが--threadsの値。

左にいくほど高圧縮、上にいくほど高画質なので、左上にいくほど良くなっていて、右下に行くほどよろしくない。

--threadsを増やしていくと、徐々に低画質・低圧縮の「よろしくない」右下に移動していってしまう。あまりスレッド数を増やすのは良くないのかもしれない。特に--threads 15以上は特に速くなっていないのに容量・画質がわずかだが共に悪くなっているようだ。

---

スレッド数をむやみに増やすと速度がやや遅くなるだけでなく、画質・圧縮率もわずかに悪くなるみたいだ、ということがわかった。

繰り返すと、「画質・圧縮率もわずかに悪くなる」といってもたいした差はないので、あまり気にするほどではない。速度が上がるなら、--threadsは増やしたほうがいいと思う。

しかし自動で設定される論理コア×1.5以上に設定してもほとんど速度は上がらないし、画質・圧縮率の面でもいいことがない。--threadsは自動でいい、と。…というか結論はずっとこれですな。