x264 rev 607でマルチスレッドの方式が変更され、速度が改善した。 手許(PowerPC G5 2Ghzx2)では、2パスで概ね3時間強かかっていた24分アニメが2時間半程度になった。こうかはばつぐんだ。
タイトル | FPS1 | FPS2 | FPS | Avg QP (P) | PSNR (Grobal) |
---|---|---|---|---|---|
threads=2平均(57件) | 14.42 | 5.26 | 3.85 | 20.68 | 45.25 |
threads=4平均(12件) | 18.69 | 6.42 | 4.75 | 19.02 | 46.83 |
概ね誰にでもお奨めできそう。
以前のrevでは threads=4は「まぁ、数秒くらい速く終わるかな?」程度だったので大進化。表のデータは実写もアニメも映画もテレビ番組もいっしょくたなので個別 に見れば、24fpsで吐いた映画とアニメはもっと早い。
Zero1氏(Turion 64 x2 TL-60 (2x2.0GHz)) のコメントでも、マルチスレッドが高速化し画質劣化が非常に少な くなった、お奨め。との事。もともと早いx86ではどこまでいくんだろう?
Changeset 607(06/12/16)
新しいスレッド方式:
各フレームをスライスに分割していたのを、複数参照フレームの併行処理に変更。副次効果:
速度改善、スレッディングのビットレート・ペナルティ緩和。
フレームの再エンコードはもうできないので、スレッデッド・シーンカット検出はpre-me pass(*動き予測の前のパス?*)でやらなければならない。これは高速だが、精度は落ちる。
CPU数より多くのthread数を使っても良い。--threads=autoはcpus*1.5を使うようにアップデート された。
他にレートコントロールのマイナーチェンジ。
rev 607以前の推奨はthreads=CPUコア数だったが、これで4コア以上のCPU(2007後半以降?)が出て来ても対応 できるだろう。Cell向け最適化もなんとかならんか。
なお、CPU利用効率も大きく向上した。-vfチェインにmcdeintの ようなボトルネックを使わなければ、概ねCPUメータが振り切れる。以前は振り切れる瞬間が無かった。スレッド数は最大5になる事が多い。この点、x264はApple-H.264に劣っていたが、だいぶ差が詰まった。2 パスでの画質はもとより勝負にならない。threads | Frames | Sec_1 | Sec_2 | Fps_1 | Fps_2 | PSNR | SSIM | Fps_1_diff | Fps_2_diff | PSNR_diff | SSIM_diff |
---|---|---|---|---|---|---|---|---|---|---|---|
1 | 3157 | 360 | 1124 | 8.77 | 2.81 | 40.244 | 0.9775031 | - | - | - | - |
2 | 3157 | 228 | 759 | 13.85 | 4.16 | 40.246 | 0.9775451 | 5.08 | 1.35 | 0.002 | 0.0000420 |
4 | 3157 | 240 | 649 | 13.15 | 4.86 | 40.240 | 0.9775352 | 4.38 | 2.06 | -0.004 | 0.0000321 |
16 | 3157 | 236 | 633 | 13.38 | 4.99 | 40.213 | 0.9774428 | 4.61 | 2.18 | -0.031 | -0.0000603 |
threads | Frames | Sec_1 | Sec_2 | Fps_1 | Fps_2 | PSNR | SSIM | Fps_1_diff | Fps_2_diff | PSNR_diff | SSIM_diff |
---|---|---|---|---|---|---|---|---|---|---|---|
2/16 | 3157 | 231 | 652 |
13.67 |
4.84 |
40.223 |
0.9774683 | 4.90 |
2.03 |
-0.021 |
-0.0000348 |
subq=2:frameref=1:partitions=p8x8,i8x8,i4x4:
x264 revision 610 - sliceless threading - what's new#3(Doom9)なんか16だけちょいと落ちてるけんども、これこそメニイ コア最適化であっちゅーまだべな。
(スレッドを増やすと若干の画質低下になるというのはどうなったのか? に対して)
今でもそう。だが以前ほどではない。したがって"reduces the bitrate penalty"(ビットレートペナルティの低減)。
上記はLinuxでの計測。Windowsでは効果的なスレッド同期を実現するのにたくさんの問題があった。そして現在に至る もパフォーマンスはここまでは良く無いかも知れない。Code:cpu: 4 core Xeon 5160
threads speed psnr loss
r606 r611 r606 r611
1: 1.000x 1.000x 0.000 0.000
2: 1.540x 1.739x -0.036 -0.004
3: 1.838x 2.384x -0.065 -0.002
4: 2.043x 3.224x -0.077 -0.005
5: 2.028x 3.512x -0.110 -0.009
6: 2.034x 3.629x -0.132 -0.009
7: 1.988x 3.680x -0.151 -0.015
8: 1.953x 3.702x -0.188 -0.017
9: 2.016x 3.729x -0.210 -0.020
10: 1.995x 3.742x -0.233 -0.031
11: 1.954x 3.749x -0.255 -0.030
12: 1.909x 3.765x -0.268 -0.040
13: 1.895x 3.770x -0.286 -0.045
14: 1.936x 3.759x -0.313 -0.046
15: 1.897x 3.781x -0.335 -0.045
16: 1.845x 3.765x -0.349 -0.046
scaling efficiency (speed / #cores):
r606: 51%
r611: 94%
クリティカルなことにスレッドを使ってこなかったので実際はかなり違うのかもしれませんが、Pthreadからwin32threadに移植するのはたいした手間ではないので逆もそれなりにいけそうなものですがどこで手間取ったのかいまいち分かりません。
スレッド同期はmutexと条件変数でやっているみたいですがmutexは両方にあるのですが条件変数の実装はwin32threadとPthreadでは微妙に違っていたような気がします。もしかしたらそこかもしれません。