『CPU使用率100％を引き出すにはどうすればいいのでしょうか？』のクチコミ掲示板

[Ｍｏｕさん]

動画エンコードの高速化のため、このCPUを購入しました。

ｘ２６４エンコードをするのですが

プラグインツールAviutlでは使用率12〜20％

TMPGEnc 4.0 XPressでは33％程度と

100％とは程遠い状態です。

同時エンコードをする数を増やせば、その分使用率は上がるみたいでしたが
効率が悪そうです。

こんなに無駄があるので、OCでパワーを引きだせばもっとすごくなると思うのですが、通常使用時で使用率100％にならないというのでは話になりません。

1つのエンコードに6コアのパワーをドンとつぎ込む方法はないでしょうか？
マザーボードはASUS　Rampage III Extremeを使っています。

よい知恵をお貸しいただければと思っております。
どうぞよろしくお願いします。

書込番号：11749056

[ゼルビーノ]

http://bbs.kakaku.com/bbs/03408019760/SortID=11361900/

書込番号：11749079

[ピンクモンキー]

タスクマネージャーから操作してみる、というのも…。
当方、PhotoShopCS3をこのように。
体感的には判りませんが（笑）エンコードの場合は時間的経過があるので、はっきり判るのではないかと。

書込番号：11749221

[Ｍｏｕさん]

みなさんありがとうございます。
ピンクモンキーさんの方法は、試しています
約5〜10％くらいの速度UPがありました。
100％にはまだ程遠いといった感じです。

書込番号：11749592

[パイル]

aviutilとTMPGEnc4.0EXでコーデックX264は、自分も使っていますが、マルチスレッドのフルスレッドは対応していないようです。CPUはi7-930ですが、1タスクで処理するとほとんど、使用率は上がりません。たぶん、フィルターを含めてマルチスレッドにフル対応してくれないと、打開策は見つからないと思います。TMPGは、使用率は変わらないけど、CUDA使用で、フィルターを多数処理する場合は、速くなりますが、CPUは遊んでいる状態のままです。
自分は1ファイルを3-4分割して同時にエンコードをかけて、出力されたファイルを連結して、使用しております。面倒ですがそれが一番速い方法だと思います。
　フィルターなしで使うならGomEncoderでｘ264-aviからX264-MP4の再変換のときに8スレッドで95-100％の使用率で爆速Encodeできますが、フィルターが使い物にならないのでトランスコーダーとして使っています。
　x264コーデックの12コア対応のマルチスレッド化を待つより方法がないと思います。

書込番号：11749757

[カメカメポッポ]

CPUの差なのかな？
860ですが、aviut＋X264でts画像を変換する時は、7〜9割程度の使用率ですけど？

aviutもX264に新しいバージョンでしょうか？

TMPGEnc 4.0 XPressだと7割程度かな？（BIOS更新で3割程度だったのが、7割程度まで出るよようになった感じです。）

１CPUとか２CPUのように100％近い数字で動いてくれれば早く終わるだろ！とも思った時期もありますが、他の編集/他のエンコも同時並行作業可能なので重宝してますけどね。同時エンコしても処理予測時間も大きく変わらないし・・・。

書込番号：11750550

[Ｍｏｕさん]

カメカメポッポさん　ありがとうございます。
aviutは最新のものにしてみましたが変化なしです。
ところでカメカメポッポさんのOSはXPですか？
それとも最新OSなのでしょうか？
OSがXPだとフルに性能を発揮できてないのかなと…

書込番号：11755253

[uPD70116]

Hyper Threadingは切った方がいいかも知れません。
そもそもWindows XPで9コア以上だと正常に動作しないという問題があります。
一応この問題を修正したパッチもありますが、マイクロソフトから入手しないといけないみたいです。

書込番号：11755496

[(｀・ω・)]

処理が100%近く並列化できない限り100%の使用率にならないのは当然です。

こちらの「並列化」の項目を参照して下さい。
http://ja.wikipedia.org/wiki/アムダールの法則

この式に依ると、プログラムにおいて並列化できない部分がたった10%でもある場合(=90%は並列化可能)、
6コアCPUでの性能向上率は1コア比4倍にしかなりません。

その場合CPU使用率は　性能向上比/コア数　＝　4/6 ＝66%が上限となります。
もっとも、この公式は複数のコアに処理を分割することで発生するオーバーヘッド(同期処理や遅延等)を考慮していないため、実際はこれよりも性能向上率(∝CPU使用率)は低くなります。

同様に処理において20%並列化できない部分があればCPU使用率は40%が上限になります。

一般的にコア数が多くなればなるほど、同じ処理に対する性能向上率は小さくなるため、
CPU使用率も低くなります。


CPUのリソースを100%使うためには、各処理を完全に並列に実行できるようにスケジューリングをする必要があります。(分割された各スレッドの処理時間が同じになるように、処理を分割する等)。

それらはプログラムの作りに依存するのでユーザー側からはどうする事も出来ない問題です。

書込番号：11766082

[えりかです。]

>一般的にコア数が多くなればなるほど、同じ処理に対する性能向上率は小さくなるため、
CPU使用率も低くなります。

これはマチガイじゃないの！？
だってあんたのリンク先（ウキペディア！！）の公式によるとN→∞のときは1/F（MAX）に収束するじゃない。
つまり、コア数が多くなっても1/F以上には性能向上率は伸びず、コア数の増加に伴いCPU使用率が低下するってことじゃないの！？

まぁ、スレ主が問題にしているエンコの並列処理が、実際どこまでアムダールの法則とやらに従うのか知らないけど、結論が「プログラムに依存するのでどーしょーもない」だけなら必死で調べたアムダール君がただの“いらない子”になっちゃうね。

書込番号：11768598

[(｀・ω・)]

まずは言葉づかいを覚えましょう。あと無駄な煽りは結構です。
イライラさせて喜びたいなら別でしょうけど。

そして私の記載ミスですね。
＞一般的にコア数が多くなればなるほど、同じ処理に対する性能向上率は小さくなる
同じ処理に対する性能向上率は(P/N)を意味し、これがコア数が多くなれば小さくなるというのは間違いです。

私が本来意図したのはコア数が多くなるにつれて性能向上率の変化量(dP/dN)が小さくなるというものでした。

＞つまり、コア数が多くなっても1/F以上には性能向上率は伸びず、コア数の増加に伴いCPU使＞用率が低下するってことじゃないの！？

そう私は書いたつもりでした。しかし、間違った言葉を用いていたようです。お騒がせしました。

書込番号：11769353

[(｀・ω・)]

訂正を書きます。

↑の書き込みにおいて、Pは性能向上率と定義しています。
しかし、PはWikipediaの参照ページの上部で別の物を定義しているため、不適切です。

よく見ると性能向上率はSとWikiでは定義しているので、Sとおくことにします。
dP/dNはdS/dNと置き換えてください。

そして
同じ処理に対する性能向上率は(P/N)を意味し
これも根本的に間違っています。無視してください。

寝ぼけているうちは書きこまないほうが良いですね。　スレッドを汚してしまい申し訳ない。

書込番号：11769383

[Ｍｏｕさん]

みなさん書き込みありがとうございます。
ここ数日やってきた事を報告いたします。
使用ＯＳがWindowsXP　32ビットだった為、Windows7　64ビットに入れ替えて
エンコードを試してみましたが、大きな速度向上見られませんでした。
Hyper Threading　入りで12〜20％　切33〜44％くらい（Aviutl）
なので、1スレ当たりは同じ程度の使用率
(｀・ω・)さんのご指摘にある、アムダールの法則の壁に当たっているといった感じです。
カメカメポッポさんの70〜90％（860）が不思議でなりません。
「BIOS更新で3割程度だったのが、7割程度まで出るよようになった感じです。」
マザボのBIOS更新をするといいのかな？
最適化される？

書込番号：11769481

[(｀・ω・)]

まとめますと

処理が100%並列化出来ない限り、
コア数を増やした時の性能向上率の変化量(dS/dN)が小さくなっていく為、
CPU使用率(=S/N)はN＝コア数が大きくなるほど小さくなる。(dS/dN＜1より)

ある処理を行う際に、それが何%並列に実行されるかは一般にプログラムをコンパイルした時点で決定されるため、
処理を変えずに「CPU使用率100％を引き出す」
事をユーザー側で試みても無意味。


というのが私の意見となります。
これで完全に訂正されたでしょうか。


もっとも、ソフトウェアの設定を変更すると処理の流れが変わる為、設定次第で使用率が変わることは多々あります。(ただし出力も変わってしまう)
出力が変わっても良いのであれば、スレ主さんの問題はソフトウェアの設定で対処出来るでしょう。

スレ主さんへ。

AVIUTL+x264で20%程度しか出ないのは、各種フィルタやサードパーティのプラグインを用いている場合、全体として(処理の流れが変わり)他の人の条件と比べ並列性が下がっている事が考えらます。
一度フィルタや外部プラグインを無効にし、素の状態でエンコードしてみてください。
その結果、向上されるのであれば、用いるプラグインの問題となります。

プラグインを利用していない場合、考えられる点としては、
2passエンコード時にBフレームの最大連続数を大きくすると1pass目の処理並列度が下がります。連続数を小さくしてみてください。

おそらく他にも影響を与える設定はあると思いますが、自分が考えられるのはこの程度です。

書込番号：11769534

[groov28]

参考意見です。
私の環境では100％になります。

入力プラグインが原因ではないでしょうか。

aviutl + x264では入力プラグインによって出力のCPU使用率が変わります。
入力プラグインにDirectShow File Readerを使えばCPU使用率100％近く行くかもしれません。

たとえば私の環境では、以下のような値が出ています。

■環境
CPU:Core i7 920 (HyperThreding ON)
MEM:12G
OS：Win7
グラボ：GeForce GTS250
入力コーデック：(たぶん)CoreAVC、（もしかしたら)DivX,xviD
エンコードファイル：H.264 -> H.264

■CPU使用率（平均）
DirectShow FileReader：ほぼ100％
MP4FileReader：80％
(参考）MPEG2 VIDEO PLUGIN ：50％

つまり、入力プラグインによってCPU負荷率が変わります。
私の環境ではDirectoShowで、CPU8スレッドすべて100％まで行きます。

■豆知識
DirectShowの性能は環境依存します（グラボ、入力動画の形式、入力に使うコーデック等）。
たとえば、グラボによってはCPU負荷が100％にならなかったりします。
入力動画の形式によっては、動画ファイルが壊れて出力されることもあります。
使用しているコーデックによってはCPUが100％にならなかったりもします。

ちなみに私の場合、H.264 -> H.264の変換時は問題なく変換できています。

�@入力プラグイン
�A入力コーデック
�B入力動画の形式
�Cグラボ
あたりをいろいろ変えて、いろいろ試して実験して、最適な組み合わせを見つけれれば満足のいく処理ができるかもしれませんね。

以上、ご参考になれば幸いです。

書込番号：11800194

[makt7]

各種コーデック(デコーダYV12)→入力プラグイン→(色空間変換YUV2toRGB24)→AVIUtil→フィルター→(色空間変換RGB24toYUY2)→(色空間変換YUY2toYV12)→x264出力プラグイン(H.264エンコーダ)

処理順としてはこんな感じでしょうかね。
フィルター無しの素通しでもAVIUtilは劣化してくれる素敵仕様です。

見ての通りマルチスレッドでCPUをしっかり使うには全ての段階においてマルチスレッドに対応している必要があります。
例えば、最初のデコーダがシングルスレッドにしか対応していない場合はそこで処理が詰まってしまいます。
途中のフィルターがマルチスレッドに対応していない場合も同様です。
AVIUtilだけがマルチスレッドに対応していてもあまり意味がありません。
x264.nlのDarkShikari氏はCPU負荷ではなくエンコードの処理時間を見るように言っています。
CPU負荷が高いからといって処理が早くなるとは限らず、ソフトウェア側に無駄な処理やバグがあった為に余計な処理が行われCPU負荷が高まっている(処理速度は遅くなる)こともあるからです。

HyperThreadingは有効にすると同時実行可能なスレッド数が増えますが、L2キャッシュメモリの割り当ては簡単に言うと各コア256KB→128KBに減少します。
マルチスレッドへの最適化が十分ではない場合はこれにより性能が更に低下する場合があります。
スレ主さんの例では無効に設定した方が良いでしょう。

デコーダがボトルネックになっているかどうかは一旦非圧縮AVIとして3分ほど切り出してみて、それをソースとして試せば分かります。
AVIUtilで時間軸ノイズリダクション使う場合はフィルタ順の設定で直前に「フィルタキャッシュ」プラグインを入れると良いでしょう。
x264がボトルネックになっているかはx264のオプションを最高速度と最低速度でそれぞれ出力した時のCPU負荷を見ればわかります。
高コストなオプションはマルチスレッド化が難しく、結果としてCPU負荷を低下させます。

試しに、Core i7 920@4GHzの環境でAVIUtilに1024x600 30fpsのWMVを投げ込んでフィルタ無しで拡張x264出力でプリセット「高速」設定で出力してみた所、CPU負荷は97〜100%で1秒間に74fps前後でした。
プリセットを「高画質」設定で出力した時のCPU負荷は80〜100%でした。(16fps)

フィルターにノイズリダクション(強さ128、範囲2、しきい値28)だけを設定してプリセット「高速」で出力したところ、97〜100%(60fps前後)となり処理時間は少し延びましたがCPU負荷には変化がありませんでした。

この辺は環境によって違ってくるので自分で試すしかありません。
ボトルネックになっている部分を探し出してプラグインを差し替えるなど試してみてください。

書込番号：11903371

[Ｍｏｕさん]

makt7さん　ありがとうございます。
処理順の設定はどこを開けばいいのかわりません…

いま現在、動画フィルタの順番は

1　透過性ロゴ
2　クリッピング＆リサイズ
3　サイズ変更
4　ノイズ除去（時間軸）
5　ノイズ除去
6　アンシャープ
7　Ｗａｒｐ　Ｓｈａｒｐ
8　ＵＶダウンサンプリング

になっています。

問題点があれば教えてください。
よろしくお願いします。

書込番号：11907126

[makt7]

適当で申し訳無いですが、一応試してみました。
環境:Core i7 920@4GHz、MEM 12GB、Windows7 x64
ソースファイルは1280x720 60fps 3分半で17GB前後の可逆圧縮AVIです。(Huffyuv-MT,RGB24)
※Huffyuv-MTのコーデックはv712を使用↓
　http://www29.atwiki.jp/lossless/pages/11.html

AVIUtilとプラグインは以下のものを使用しました。
------------------------------------------------------
AVIUtlのお部屋
http://spring-fragrance.mints.ne.jp/aviutl/
・AVIUtil (aviutl99i8.zip)

MPEG-2 VIDEO VFAPI Plug-In
http://www.marumo.ne.jp/mpeg2/
・ (m2v_vfp-0.6.57.lzh)

DirectShow File Reader プラグイン for AVIutl
http://www.tenchi.ne.jp/~yoko/aviutl/
・ (ds_input026a.lzh)

AviUtlプラグイン ＠零
http://typezero.ddo.jp/auf/
・unsharpMT v7 Xbyak組み込み版 (unsharpMT7.zip)
・warpsharpMT v1.33 (warpsharpMT133.zip)

AviUtl プラグイン フィルタ by うえぽん
http://auf.jpn.xxxxxxxx.jp/
・UVダウンサンプリングフィルタ (uvpack_0.6.0.zip)
-----------------------------------------------------

AVIUtlの[ファイル(CTRL+O)]メニューを開く→環境設定→「入力プラグインの優先度の設定」を開いて、
「DirectShow File Reader」を一番上にしてあります。

AVIUtlのフィルタ順とパラメータは以下の通りです。
1　クリッピング＆リサイズ ： ※未使用
2　サイズ変更：(640,360)
3　ノイズ除去（時間軸）：(256,3,36)
4　ノイズ除去：(256,2,24)
5　unsharpMT　：(25,10,50,field=true)
6　warpsharpMT：(128,3,128,-6,0,0,0,0,range=false)
7　UVダウンサンプリング：(2,YUV420=true)

この状態でプレビュー再生をさせてみたところ以下のようになりました。
※AVIUtlの[表示]メニューを開く→再生ウィンドウの表示、で再生ボタンを押す。
上記設定時のCPU負荷は83〜90%でスムーズに再生出来ていました。
殆どの処理がマルチスレッドで行われCPU負荷が低下するようなことはありませんでした。

Ｍｏｕさんが使っていると思われるフィルタ類に関してはCPU負荷を低下させる原因となるボトルネックは見当たりませんでした。
もしどれかのフィルタがボトルネックになっている場合はそこで処理が詰まってCPU負荷の低下が発生してプレビュー画面で動画の再生がガクガクになるからです。

---------------------------------------
今回はもう1つテストを行いました。
1920x1080 30fps(16:9)のTSファイルをAVIUtlで開きプレビュー再生するというものです。（フィルタ設定は上と同じです）
※[ファイル(CTRL+O)]メニューを開く→環境設定→「入力プラグインの優先度の設定」を開いて、「MPEG-2 VIDEO VFAPI Plug-In」を一番上にしてあります。

こちらはCPU負荷が25%〜31%で頭打ちとなり1コアしか使用してくれないようでプレビュー画面で再生時はガックガクでした。
(3フレーム/秒ほど)
「DirectShow File Reader」を一番上にして再度読み込ませた場合はCPU負荷は47%となりスムーズに再生出来ていました。
この際、インストールしておいたCCCPを呼び出していたようなのでそちらのMPEG2デコーダ(マルチスレッド対応)が使用されたようです。
少なくともMPEG-2 VIDEO VFAPI Plug-Inを使う場合はそこがボトルネックになる場合がありそうです。

http://www.geocities.jp/aji_0/
こちらの「フィルタキャッシュ」を時間軸フィルタ(フレームの前後を参照するフィルタ)の前に来るようにフィルタ順を調整して使うと少し早くなるかもしれません。

書込番号：11911411

[Ｍｏｕさん]

皆さん！やっと問題が少し解決に進みました！

私はAVIコンテナ（ｘ264+mp３）.avi でエンコードしていました。
CPU使用率は最高で30％でした。

今回試したのが　拡張 ｘ264 出力 (ｘ264+AAC).mp４です。
使用した動画は　PV4で切り出した1600×1080　30フレーム　24分の動画です。

使用フィルタは

1　透過性ロゴ
2　クリッピング＆リサイズ　
3　サイズ変更　1600×1080→1280×720
4　ノイズ除去（時間軸）
5　ノイズ除去
6　Ｗａｒｐ　Ｓｈａｒｐ
7　ＵＶダウンサンプリング

AAC変換に10分（これは時間がかかりすぎてると思う）CPU使用率0〜5％　ほとんどCPUが働いていません…

ｍｐ４変換に　１時間２０分　約45％

拡張 ｘ264 出力でノーフィルタで試したところ　80〜90％強に跳ね上がりました

この事から、100％に近い使用率が出ないことは無いことが分かりました。

ちなみにノーフィルタのAVI出力だと50％でした。

どうもｍｐ４出力のほうがCPU使用率は上がるようです。

書込番号：11935462

[Ｍｏｕさん]

CPU使用率低下の原因は　unsharp　warpsharpがマルチスレット版ではない
古いものを使用した為、そこがボトルネックになっていたようです。
平均で70〜80％くらいのCPU使用率をたたき出してくれる様になりました。
unsharp　warpsharpを同時に掛けるとCPU使用率が下がる傾向ですが
2ファイル同時にエンコードすればトータルで90％台をキープできるようになりました。瞬間的に100％も出ています。
これならオーバークロックさせて、さらなる速度UP効果も期待できそうです。
私が購入したマザーボードの設定で　4Ghz　4.2GhzでOC出来るアプリがあるので
比較してみたいと思います。
皆さん色々と助言ありがとうございました。

書込番号：12018892

[Ｍｏｕさん]

ホームネットワークを使って、録画用のＰＣのデータをエンコードさせていたのが
最後の20％のボトルネックになっていることが判明しました。
エンコード時に必要になるデータ量がギガビットラン環境で転送されるデータ量を超えることは無いと思っていただけに盲点でした。
さらに、エンコードした動画にもエラーが出ており、ラン経由でエンコードは
自殺行為になるようでした。

回答をいただいたすべての皆さんありがとうございました。

今回の不具合のまとめ
・マルチスレッド対応のソフトを使う
・ランネットワーク越しにエンコードをしない

書込番号：13154183