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は自動でいい、と。…というか結論はずっとこれですな。
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は自動でいい、と。…というか結論はずっとこれですな。
スポンサーサイト