スポンサーサイト

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

雑記 - エンコードの高速化についてのまとめ

 10, 2014 19:14
高速化に関して絶対的な正解はなく、環境によって最適な設定が異なるので難しい議題ですが
あくまで私の環境で役に立った情報をまとめてみました。

■ AviSynth

マルチスレッドを活用する

thread.jpg

コア数の多い CPU を使っていても、スレッドを 1 つしか使っていなかったら勿体無いです。
マルチスレッド( 通称 MT )化することによって、持て余しているスレッドを少しでも多く活用しましょう。

 SetMtMode() の追加
 blur(0.1) ⇒ MT("blur(0.1)")
 crop(0, 1, 0, 0) ⇒ crop(0, 1, 0, 0).TreadRequest()

しかし、MT 化することでエンコードが不安定になり、ランタイムエラーなどが発生する確率が上がります。
設定値を変更したり、MT 化する関数の取捨選択、順序の変更などにより解決することもあるので
じっくり調整して最適なスクリプトを組むと良いです。
どうしてもエラーが出る場合は SetMemoryMax() でメモリ領域を抑制することで落ちなくなったりもします。
余談ですが、時間軸に干渉するフィルタに対しては MT 系の処理を加えないほうがいいです。

mt.jpg



フィルタの順序を考え直す

フィルタの種類も重要ですが、種類を厳選したあとに出来ることは "順序" の設定です。
特に、重いフィルタをリサイズの "前" に使うのか "後" に使うのかによって速度に大きく影響します。
広い画像範囲をフィルタ加工するよりも、狭い画像範囲に加工したほうが処理量が少なくて済むからです。
また、 NR も一般的に 3 次元系2 次元系の順番に使うのが良いとされています。


色空間を考える

v2.5 以降からは YUY2(YUV422) や RGB 以外にも YV12(YUV420) という色空間を扱えるようになっています。
YV12 のクリップは最後まで YV12 のまま return しましょう。
途中で RGB などに変換すると速度が落ちます。
また、YV12 以外のクリップを読み込んで、様々なフィルタ加工をする場合は、予め ConvertToYV12() で変換しておいたほうが、エンコードが速くなると思います。
また、ソースの入力関数のオプションで色空間を指定するものも存在するので、そちらを利用するのも手です。

■ AviUtl

キャッシュフレーム数を増やす

AviUtl v1.00 のデフォルト値は 8 ですが、この "キャッシュフレーム数" の値を増やせば出力速度が向上します。
プレビューのシークのサクサク感も向上するので多少盛ることをお勧めします。

system.jpg
ファイル > 環境設定 > システムの設定

しかし、数値を上げすぎるとエンコード中にエラーで落ちる可能性が上がるので、環境に合わせて微調整が必要です。


フィルタの順序を考え直す

理由は AviSynth の同じ項で説明した通りです。

order.jpg
設定 > フィルタ順序の設定 > ビデオフィルタ順序の設定

ちなみに、上のスクリーンショットの順序は適当な物が多いので参考になさらないように…


入力プラグインを確認する

AviUtl はソースファイルの入力について、独自ロジックを使用していません。
外部プラグイン経由で読み込んでいるので、プラグインによって読み込み可能なファイル形式も様々です。
長所や短所をよく理解し、最適なプラグインで読み込む必要があります。
どのプラグインを使って読み込んでいるかの確認は、下記のダイアログで出来ます。

info.jpg
その他 > ファイルの情報

また、目的のプラグインを使って読み込みたい場合は、優先度の設定で上位に移動させてください。
読み込んだソースファイルの拡張子によって、上のプラグインから順に使用されます。

input.jpg
ファイル > 環境設定 > 入力プラグイン優先度の設定


■ その他

不要なメモリ使用領域を開放する

エンコードする時、メインメモリの空き領域が少ないと若干ですがエンコード速度に影響します。
メモリの開放ソフトは数多く存在しますが、ここでは Microsoft 純正のメモリ開放ソフト empty.exe をお勧めします。
下記の要領でバッチファイルに組み込めば、不要なメモリ領域を開放してくれます。

 empty.exe * > nul

こまめに使用すれば、常にベストなメモリ状態でのエンコードが望めます。
入手先はこちら


x264 のバージョン(ビルド)を変更する

x264.exe も日々進化しています。
稀にエンコード速度が大幅に改善されることがあるので、こまめにチェックすることをお勧めします。
参考:2ちゃんねる【x264+Avisynth】実用エンコベンチ Part3


マルチパスエンコードの場合、最終パス以外は null 出力する

ファイルに出力をすると、HDD へのアクセスでボトルネックが発生する可能性があります。
最終 pass でファイルが出力されればいいので、N-pass エンコの時は --output nul を活用しましょう。
AutoVFR のログ出力など、エンコードを走らせてログを採取することだけが目的のエンコードでも同じことが言えます。


AutoVFR は分割解析を利用する

ver 0.1.0.5 から、解析に分散処理が出来るようになり、ver 0.1.0.6 で利用方法が簡易化されています。
環境によって分割数の最適値は異なると思います。
私のマシンは 12 スレッドですが、実験を重ねた結果 4 分割が最速でした。
参考:Auto_VFR ver 0.1.0.6


AutoVFR の WriteFile をマルチスレッド化する

AutoVFR は解析した情報をログに出力しますが、Auto_VFR() 関数内でログを出力している部分をマルチスレッド化することによって解析スピードを高速化出来ます。
公式で勧められている方法なので是非活用しましょう。

autovfrmt.jpg

参考:ログの作成が遅い場合




twitter
↑参考になったという方は、是非記事のツイートをお願いします





スポンサーサイト

Tag:エンコード Avisynth Aviutl AutoVFR

COMMENT - 0



WHAT'S NEW?

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