NEXT | PAGE-SELECT | PREV

スポンサーサイト


このエントリーをはてなブックマークに追加


上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


このエントリーをはてなブックマークに追加





このカテゴリの最新記事一覧


| スポンサー広告 | --時--分 | comments(-) | trackbacks(-) | TOP↑

x264でmpeg4動画圧縮のマルチスレッドベンチマーク


このエントリーをはてなブックマークに追加


x264_fire_400.jpg


x264ではH.264をマルチスレッドエンコードできますが、普通にシングルスレッドと比べてどれくらい性能が上がるかを確認します。

どうしてこんな事しようと考えたかというと、-threadsオプションで4以上で適当な数値で圧縮してました。そのときタスクマネージャを開いてみると、4以上の値にしてもタスクマネージャでCPU利用率がほとんど上がらないことに気づきました。

-threads N を指定すればそれなりに高速にエンコードできることは体感してましたが、実際どれほどマルチスレッドが効いているかは感覚的にしか把握してませんでした。
そこで、-threadsの数値を変化させて最適値を求めることを目的とします。
自分も含めこのエントリーを見ていただいた人が、エンコードマシンを選定するときの参考になればと思います。

P.S.
画質は余り綺麗ではありませんが、今回の趣旨ではないので割り引いて見てください。






今回使ったx264はMinGW/msys使って自分でコンパイルしたものを利用してます。(条件は一番下に記載)

動画1は、720p(1280x720)、60fps、合計7941framesで約2分12秒です。
まず、x264にインプットファイルを渡すためのavsファイルですが、最低限の内容にしてます。


C:>  cat nmpb01.avs

DirectShowSource("nmpb01.avi")
# ChangeFPS(60000, 1001)
LanczosResize(512,288)
ConvertToYV12()
return last




./x264_ken859.exe --bitrate 710 --bframes 16 --ref 5 --no-deblock --partitions p8x8,b8x8,p4x4,i4x4 --8x8dct --keyint300 --min-keyint 1 --mixed-refs --no-fast-pskip --trellis 1 --progress --me umh --merange 64 --qpstep 10 --subme 7 --b-pyramid --b-rdo --direct auto --bime --thread-input --no-dct-decimate --no-ssim --no-psnr --no-fast-pskip --stats x264.log --threads N --pass 2 --output nmpb01.mp4 nmpb01.avs



AVSファイルを見ればわかりますが、1280x720の動画を、512x288に縮小してます。

また、前もって言っておくと、画像はお世辞にも綺麗ではない。性能検証だから画質はまいっかと思ったのも事実。 (いつもはffmpeg使うからx264の画質チューニングできてないんだよね、だから適当に見つけたオプションをコピペしただけ、と言い訳しておく。画質気にする人は真似しないように。あと音声は圧縮してません)





検証1 60fps: x264ベンチマーク 01 60fps

画質はさておき、-threads N の部分はスレッド数の指定です。Nを色々な値にして、H.264エンコードのスレッド性能を表とグラフにしました。

  • Table1 60fps:pass1指定とpass2指定の時の秒数を縦軸表示。横軸はx264で指定したスレッド数
  • Figure01-1 60fps:表の縦軸を実行時間(real)にした折れ線グラフ
  • Figure01-2 60fps:pass1の実行時間を1.0とし、各々が何倍速くなったかを倍率で表示

これだけの結果ですが先ずわかることをズラズラ書きます


  1. マルチスレッドで性能があがるといっても最大でもせいぜい3倍強。4コアマシンなら3倍は悪くない数字だけど、必ずしもコア数に比例して性能が上がるわけでもない。
  2. 6スレッド以上(N=<6)指定しても性能があがらない。Web上ではコア数の2倍がいいという話を聞くが、4コア以内のマシンであれば確かに間違ってない。
    しかしこの検証では4コア以上あるマシンで、6スレッド以上を指定しても性能はあがらないようだ。

  3. スレッド数がわからなければautoを指定するってのは間違ってなさそう。

  4. 2スレッドでは性能向上が少ないのに、3スレッドで急に性能があがり始める。アルゴリズム的な問題なのだろうけど、理由はわからん。とりあえず奇数指定はよろしくない気がする。

  5. 1passと2passでは性能差があまりない。同じオプションを使っているから2passと1passで性能が異なっても困るわけだが・・・・。シーンチェンジの多い絵じゃない限り性能差がつくことはないかもしれない
  6. そうは言っても2分強の動画でエンコ-ディング時間が143秒だから、ほぼリアルタイムエンコーディングだね(解像度があれだけど)。





検証1 30fps: x264ベンチマーク 01 30fps

次に、60fpsは見る方も重いとかカクカクするとか良く言われるので、30fpsにしたときのベンチマークもしてみました。
AVSファイルは以下のようにしてます。(FPSだけ変更)


C:>  cat nmpb01.avs

DirectShowSource("nmpb01.avi")
ChangeFPS(30000, 1001)
LanczosResize(512,288)
ConvertToYV12()
return last

x264の実行方法はこのエントリーの最初と全く同じです。


  • Table1 30fps:pass1指定とpass2指定の時の秒数を縦軸表示。横軸はx264で指定したスレッド数
  • Figure01-1 30fps:表の縦軸を実行時間(real)にした折れ線グラフ
  • Figure01-2 30fps:pass1の実行時間を1.0とし、各々が何倍速くなったかを倍率で表示

60fpsの結果の比例くらいだと思ったのですが、思いの外結果が異なりますね。


  1. 30fpsの1スレッドでは、300秒強となり60fpsの時の6割程度の時間でエンコードでき、かなり速くなってる

  2. N=6以上にしても性能向上はない。これは60fpsの時と同じ。またN=4とN=6もそれほど差はない。

  3. N=6以上でも性能向上率は60fpsの3倍強ほどない。だいたい2.4倍くらい。

  4. マルチスレッドの性能向上率に差があることから、30fpsが129秒、60fpsが143秒となり10%くらいしか変わらない。


1スレッドの時は、60fpsに比べてかなり早く終わったのでこれは期待!! と思ったけどNを増やして行くとだんだん60fpsと大差なくなり少しがっくりした。




検証1 結果と考察

上のデータは家にあるXPマシンで計測しましたが、その他Linuxを使ったり、物理的なコア数を強制指定したり、gcc4.3のコンパイルオプション(core2とか)を色々試したり、海外のサイトを確認してわかったことをまとめると、

  • エンコード目的で購入するならDualCoreで最速CPUよりも、そこそこのクロックでもQuadコアが良い
  • 可能な限りクロックは高めが良い。(このあたりは財布と要相談)

  • 5コア以上はいらない。 (同時に複数の動画をエンコードする場合を除く)

  • DualCoreやSingleCoreでもauto指定すると良い。数字で指定しても良いけどautoと誤差程度しか変わらない

  • ConroeとPenrynの性能差は余りないらしい。クロックが同じなら数%程度。x264には余りpenrynの機能は効かないかもしれない。(とある英語サイトより。サイト名忘れた。すまん。)


当たり前といえば当たり前だが、時間と電気代がかかったわりには当初の予想よりも余り面白くない結果になってしまったな。



P.S.
ちなみに、この検証した時に使った環境はClovertown X5355 2個、WindowsXP 32bit、Avisynth2.5, x264 rev859, yasm0.7.0, mingw5.14, gcc4.3.0 です。
あとx264知ってる人ならわかりますが、rev859って結構昔のリビジョンです。このときやった結果をまとめるのが面倒で今まで放置してただけです。あしからず。

なにげに、Google Chart使ってます。便利なような面倒なような・・・。少なくとも1個だけ図を作るのには向いてないことはわかった。素直にExell使いましょう。



関連記事


MPEG4入門―「圧縮の基本」から「MPEGの基本」「MPEG4の実際」まで (I・O BOOKS)
MPEG4入門―「圧縮の基本」から「MPEGの基本」「MPEG4の実際」まで (I・O BOOKS)瀧本 往人

工学社 2006-09
売り上げランキング : 96181

おすすめ平均 star
star各CODECのポイントをつかむのに適しています

Amazonで詳しく見る
by G-Tools




このエントリーをはてなブックマークに追加





このカテゴリの最新記事一覧


| ―携帯, iPod, PSP 動画変換 | 21時08分 | comments:2 | trackbacks:0 | TOP↑

だいぶ前の記事にコメントするのは気が引けるのですが
気になったことがあったのでコメントさせていただきます
スレッド数が増えてコアの使用率があがらない件ですが
あくまで可能性の話なのですが
ChangeFPS(60000, 1001)
LanczosResize(512,288)
ConvertToYV12()
このあたりがシングルスレッドで処理されて
この速度に律速されて,マルチスレッドの処理能力を
有効に使えなかったのではないでしょうか.

| 通りすがり | 2011/09/26 16:08 | URL |

Re: タイトルなし

通りすがりさん。
こんな古いエントリーにコメントどうもです。

私もだいぶ前のエントリーなのであんまり覚えてないですが、
シングルスレッド処理されてる場所が律速になって、指摘のあったところが一番怪しいのは同意です。

本来であればx264のエンコード部分だけ抜き出してベンチマークするのが筋ですが、
x264が読み込める形式が無圧縮しかなく、ファイル容量が膨大になりI/Oのほうががボトルネックに
なりそうなので、Avisynth経由にしたというのもあります。
(今から思えばもしかしたら無圧縮じゃなくても良かったかもしれませんが)

それと、もしそれが出来ても、実用的にはあんまり意味のないベンチマークと思ったので、
前処理部分も追加して計った記憶があります。

あと結果については、この手のマルチスレッド処理はアムダールの法則に縛られるので、
コア数を使うほど性能は上がらないとは思ってました。
なので性能が上がらないことは案外気にしてませんが、それにしても3倍程度では少なすぎでしたw

まあ古いバージョンのプログラムなので、新しいバージョンにしたり、新しいCPUに
すればフリーソフトとはいえ、だいぶ良い値になる気はしますが、、、、

| kenchan3 | 2011/09/27 20:52 | URL |















非公開コメント

http://kenknown.blog42.fc2.com/tb.php/87-8a50c239

≪ NEXT | PAGE-SELECT | PREV ≫

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。