threads=<1-16>　ageha was here

2007/11/15を以て当ブログは更新を停止しました。記事は全てこのままですが、基本的に内容はOut of dateとお考え下さい。

threads=<1-16>

　x264 rev 607でマルチスレッドの方式が変更され、速度が改善した。手許（PowerPC G5 2Ghzx2）では、2パスで概ね3時間強かかっていた24分アニメが2時間半程度になった。こうかはばつぐんだ。

■VGA （1024kbps, 640x480）

タイトル	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 パスでの画質はもとより勝負にならない。

070105追記： threadsは最大16

PowerPC G5 (2GHzx2)の場合

akupenguin氏は「16 threadsでは画質劣化が最大1%になるが、まぁ常用してもいいんじゃないの」と言っている。ように読めた^^;。
そこで常用設定でthreadsだけ変更して計測してみた。プロセスの優先順位指定とかは解ってないので誤差が出る筈です。てゆうか出てます。
素材は約１分半のアニメのオープニング（例に拠ってケロロ軍曹）、1stはturbo=1。

■CPU:PowerPC G5 (2Ghzx2)

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

※結論：
　少なくともPowerPCx2で1stにturbo=1を使う場合は、1stはthreads= 2、2ndはthreads=16が最速になる。

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

　ただし、凄い勢いでメニイコア最適化が進む事は確実だから、1stと2ndでthreadsを変えるのは後々ちょいと根性が要るだろう。最終的な客観画質の低下も緩和しているがもとから無視しても問題ない範囲の話だ。threads=2/16かthreads=16/16かの選択はちょっと悩ましい。2ndの速度がやや落ちているのは誤差なのか、それとも statsの内容がthreads=2に最適化してたりすんのだろうか。
　

※画質劣化：PSNRは0.2dB違えば通常は充分に目で見て解る違いが出ると言う。もちろんPSNRは万能では無く、高くても画質に不満を感じるケースはある。しかしながら、主観画質は電気いっこつけるだけで随分と変わるものだ。モニタを変えればがっつり調整しない限りまず別モノになる（手許ではしてないから左右のモニタで色味がかなり違う）。数値的画質指標では少なくとも視聴環境と感性の影響を排除できるから、ネットの向こう側で通用する公算は「手許では」より高い。

　
※1st passでthreads =2が最高速となる理由は良く解らない。
　2ndがリニアに高速化しているのに比べて非常に目立つ。
　scenecutアルゴリズムはthreads=2で勝手に--pre-scenecut、すなわち「各フレームをスライスに分割していたのを、複数参照フレームの併行処理に変更」に切り替わる筈なので、少なくともオプション上はthreads=2だけが早い理由は無い。
　turbo =1をベタなオプションで書くとこうなる。

subq=2:frameref=1:partitions=p8x8,i8x8,i4x4:

　しかしながら、turbo=1に変えて上記を使い、1st, 2ndともthreads=2でエンコードしたところ、両パスとも低速化した上に、さらに最終的なPSNR、SSIMも悪化した。下手に弄らないほうが良さそうだ。
　この結果から、1stと2ndでは上記以外にも実際の処理内容が異なると思われる。例えば2ndはある程度の処理を 1stのstatsを信用して省いているとか。

4 core Xeon 5160の場合

　akupenguin 氏によると4 core Xeon 5160では上記のような不連続は無く、threadsを増やせばほぼリニアに高速化する。turboオプションの無いx264cliではオールラウンドに threads=16で良さそうだ。

x264 revision 610 - sliceless threading - what's new#3（Doom9）
（スレッドを増やすと若干の画質低下になるというのはどうなったのか？に対して）
今でもそう。だが以前ほどではない。したがって"reduces the bitrate penalty"（ビットレートペナルティの低減）。
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%
上記はLinuxでの計測。Windowsでは効果的なスレッド同期を実現するのにたくさんの問題があった。そして現在に至るもパフォーマンスはここまでは良く無いかも知れない。

　なんか16だけちょいと落ちてるけんども、これこそメニイコア最適化であっちゅーまだべな。

Windows固有の問題？

　なお、Windowsでの効果的なスレッド同期（ってなんだかわかりませんが）の問題だが、引用元のスレにはwin32threadsとかpthreadsの単語が散見される。linux系とWin系ではスレッドに必要なナニカの挙動が異なるらしい。x264cliにwin固有のスレッド方式を組み込んでしまえばよさそうなものだが、それやるとmencoderで受け付けないとかで、akupenguin氏はx264ライブラリでそこまでwinに特化できないと言っている、あたりまで読んだ。ということで、実は引用元のスレはあらかたがx264.exeでの動作検証と、MeGUIへの実装方法の話で埋まっている。Sharktooth氏を筆頭に奮闘が続いている様子なので、winでx264cli、特にMeGUIな方は是非ご一読されたい（そしてどうなってんのかどっかに書いて下さい（⇒MasaHeroの日記：スレッド処理、スレッドに関するメモ））。

070117追記：MEncoderマニュアル改訂

MEncoderマニュアルの改訂に気が付きました。

threads=<0−16>：平行処理でエンコード

default=1
複数CPUでパラレル・エンコードをするためにスレッドを分散。
圧縮品質に僅かな悪影響がある。
0 または ’auto’でx264はCPU数を検出し、適切なthread数を自動選択する。

MEncoder dev-SVN-r21948-4.0.1 (C) 2000-2006 MPlayer Team
x264 core:54 svn-618M

Man/CODEC固有オプション/-x264encopts/threadsは改訂済みです。

スポンサーサイト

[ 2007/01/05 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(2)

そこまで違ったかなあ

確かにソースを見る限りrev608でWindowsNativeなスレッドからPthreadを使ったスレッドに移っているようです。
クリティカルなことにスレッドを使ってこなかったので実際はかなり違うのかもしれませんが、Pthreadからwin32threadに移植するのはたいした手間ではないので逆もそれなりにいけそうなものですがどこで手間取ったのかいまいち分かりません。
スレッド同期はmutexと条件変数でやっているみたいですがmutexは両方にあるのですが条件変数の実装はwin32threadとPthreadでは微妙に違っていたような気がします。もしかしたらそこかもしれません。

[ 2007/01/11 16:13 ] [ 編集 ]

遅くなりました。

MEncoderマニュアルのほうに反映されました。
MeGUIも内部的にthreads=0かautoで凌いでいる様子です。

[ 2007/01/17 23:44 ] [ 編集 ]

コメントの投稿