続 x264の--threads

この前のx264の--threadsの続き。

この前は、Aviutlのフィルタはなし、という条件で、ほとんどx264しか動いていないような状況だった。

これが、Aviutl側でばんばんフィルタを使ったりする、つまりAviutlとx264がCPUを奪い合うような状況だとどうなるのかな、ということを試してみた。

まあ、あんま変わらないとは思うのだけど、一応…。

---

CPU使用率やスレッド表示はProcessHackerを使用。眺めてると面白いです。…わたしだけか。

---

まず、この前のCPU使用率。

こんな感じでAviutlが5～10%、残りがx264で、ほとんどx264ばかりが動いている状況。

スレッドとかの状況。

クリックで拡大

でも、自動フィールドシフトとか、その他いろいろな重いフィルタを使用すると、Aviutlのほうの処理が重くなるので、もっとAviutl側が動くようになり、x264の使用出来るCPU時間が減っていく。

ちょっと条件を変えて、
・自動フィールドシフト(スレッド=16)
・透過性ロゴ
・クリップ&クロップ
・リサイズフィルタ
・エッジレベル調整MT
・バンディング低減MT
(NL-Means Light GPUは省略)
あたりのフィルタを入れてみると

Aviutlが40%前後、x264が60%前後…

こういうAviutlとx264がCPUを奪いあうような状況では、x264の--threadsの値がエンコード速度にどう関係するのか…、デフォルトのままでいいのか…。

---

環境
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

素材
犬日々ED部分 1920x1080i 29.97fps 1分35秒

Aviutl フィルタ
・自動フィールドシフト(スレッド=16)
・透過性ロゴ
・クリップ&クロップ
・リサイズフィルタ
・エッジレベル調整MT
・バンディング低減MT
(NL-Means Light GPUは省略)

x264 オプション
--preset slow --crf 20 --qcomp 0.7 --aq-strength 0.4 --psy-rd 1:0.2 --min-keyint 4 --subme 9 --trellis 2

---

(参考)各スレッドの状況

クリックで拡大

Aviutlのスレッドの状況の拡大

クリックでもっと拡大

こんなかんじで、大量のスレッドがAviutlの方でも動き、さらにx264のスレッドもたくさん動く、というカオスな状況になっている。

---

結果

今回は、--threads 15～21あたりが最速。とはいえ、自動設定の--threads 12と差はごく僅か。あと、やはりスレッド数を増やしすぎると、少し遅くなるようだ。(--threads 22～24はやはりやや遅い)

--threads 10がなんか妙に遅いのは割り込みが入った(なんか裏で動いた)のかもしれない…寝ている間にやらせているのでよくわからないけど。

--threads 1の時に対する倍率に直すとこんな感じ。

AviutlのほうもCPUを食うので、高速化率は前回(最大×4.16倍)には当然及ばず、×3.2倍ほどだった。

---

これが当然の結果なのかはよくわからないけれど、Aviutlとx264がCPUを奪い合うような状況でも、前回(ほとんどx264のみが動く)時と同じ傾向のグラフになった。僅かな差はあるものの、基本的には--threadsの指定はデフォルトでいい模様(※1)。

つまり、特にいじらなくてもちゃんと速度が出るよ、という確認ができたのかな、と。

(※1)
まあ、今回の最速は--threads 15～21だったように、こんな感じで測定すれば最速となるところはわかるのだろうけど、ほんの少しの差だし、環境や設定によっても少しづつ変わるだろうし、この測定も結構面倒なので、もう自動でいいんじゃないか、とそういうこと。

続きます。(こちら>>)