MTZ_AUF for エッジレベル調整 [高速化]

エッジレベル調整はがらくたハウスのがらくた置き場で公開してくださっているAviutlのフィルタ。

エッジ調整の効果がすごくいい、素晴らしいフィルタなのだけど、わりと重い。

作者様によると、これはどうも並列化されてないことが原因の一つらしい。3級以下のFlash置き場 - えっじれべるちょうせい

というわけで強引に高速化してみる、そういう話。

※素直に並列化 + 拡張命令の使用でこの方法よりも安定・さらに高速化したエッジレベル調整MT 0.7 v7をこちらで公開していますので、どうぞ。

テストした環境について

基本的な環境
Win7 x64 SP1
Core i5 2500 @ 3.8GHz (4C/4T)
RAM 4GB DDR3-1333

ソース
ts(MPEG2) 1920x1080i 29.97fps

出力
1920x1080p 自動フィールドシフト 23.976fps 180秒

Aviutl環境
Aviutl 0.99k2
MPEG-2 VIDEO VFAPI Plug-In 0.7.5a
x264guiEx 1.33
x264 x64 r2164+649 8bit
--preset slow --crf 21.5 --ipratio 1.5 --qpstep 12 --qcomp 0.7 --no-mbtree --vbv-bufsize 17500 --vbv-maxrate 17500 --aq-strength 0.4 --psy-rd 1:0.2 --scenecut 50 --keyint 300 --min-keyint 4 --subme 9 --ref 4 --no-fast-pskip --no-dct-decimate --trellis 2 --colormatrix bt709 --level 4
重くもなく、かといって軽くもない、そんな設定。

Aviutlフィルタ
自動フィールドシフト
透過性ロゴ
クリッピング
色域変換
PMD_MT
リサイズフィルタ(Spline36)
エッジレベル調整
バンディング低減



エッジレベル調整を使うとCPUが遊ぶ

エッジレベル調整を使うと、CPU使用率が上がらなくなり、エンコ速度がでない…なんて問題が起こる。例えば、4コアのCore i5 2500だと、CPU使用率が平均約70%ほどとなって、かなりCPUが遊んでしまっている。
mtz_auf_1thread_cpu

x264はオプションによっても異なるがかなり並列度は高い。なので、CPUが遊んでしまう場合、x264の前の段階で詰まってることが原因なことが多い。今回はエッジレベル調整が律速になってしまっている。

こういう場合、高速化の手段としては単純にAviutlを2つ起動して、2つ同時にエンコードするという手がある。

これは簡単だけれども、いろいろ使い勝手が悪い。2つエンコードするものがないときには使えないし、メモリも喰う(まあ最近はメモリ安いから、足りなければ買ってくればいいわけで、これはどうでもいいかな?)。そもそも2つのエンコードが2時間で終わるよりは、1つのエンコードが1時間ちょいで終わってくれたほうが個人的にはありがたい。

というわけで1つのAviutlでCPUの力を使い切って高速化したい。



フレーム分割による並列化(MTZ_AUFを使用する)

シングルスレッドのフィルタを並列化するために、YOUMEI様が「AviUtlのAUFプラグインを複数スレッド化するAUF (MTZ_AUF)」を公開してくださっている。ありがとうございます、素晴らしいです。

仕組みとしては、フレームをスレッド数だけ分割して、別スレッドで処理させる、というもの。
図は2スレッドの場合。
mtz_auf_orig


しかし、readmeには、
上下のピクセルが重要な意味を持つプラグインには適用しない方が無難です。たとえば画面の中央付近に問題(フィルタ適用ミス)などが発生する可能性があります。
とあって、分割境界付近の処理がおかしくなるかもしれないよ、とのことだ。

そして、エッジレベル調整がまさにこれで、mtz_aufを適用すると、こんな感じで分割境界にフィルタがかかっていない領域ができる。

エッジレベル調整を限界まで強くかけて、わかりやすくした例。
demo_without_overwrap_s1
demo_without_overwrap_s2

画面中央付近に横一線にエッジレベル調整のかかっていない帯が見える。フレームを分割した境界付近でエッジレベル調整がうまくかからなかったようだ。幅は6ピクセルぐらい?



オーバーラップさせて処理する

これをなんとかするには、フレームを分割するときに少しオーバーラップさせて処理をして、最終的に重複させた部分(境界のうまくフィルタがかからない部分)付近は捨ててしまえばいい。こんな感じ。
mtz_auf_overwrap
こんな感じでちょっと重複して処理をして、重複させた部分は最後に捨ててしまおう、という考え。

MTZ_AUFはソースを公開していただけているので、ちょこちょこ改造してオーバーラップ処理ができるようにしてみた。

この方法の問題点は、スレッド分割をすればするほど、2重に計算する領域が増えて、計算量が増えるということ。具体的には(スレッド数-1)×オーバーップ高さ×2×フレーム幅 分だけ2重に計算することになる。

つまり、並列化による高速化 > (増える計算量 + 同期待ちなどの並列化によるコスト) とならなければ、CPU使用率は上がっても速度は落ちてしまう。

どうなるのか、こればっかりはやってみないとわからない…のでやってみた。

で、とりあえず、これが今回作った改造版での画像の結果。
demo_with_overwrap_s1
demo_with_overwrap_s2
エッジレベル調整がかかってないせいでできてた線がきれいに消えてる。
さっきの画像とタブで開いて、切り替えてみるとわかりやすいかも。

とりあえず、この方法で「境界付近でフィルタがうまくかからない」問題は解決した。

次は問題の速度とかを見てみる。



並列化なし時の様子

mtz_auf_1thread_cpu
CPUは結構遊んでいる…

並列化なしの時のスレッドの様子
mtz_auf_1threads_t
こんな感じで、TID(ThreadID)=3372のスレッドがやたら仕事してるけど、これがAviutlのシングル用スレッドで、エッジレベル調整がここで動いてるんじゃないかなあ…と予想できる。



2スレッド並列時の様子
次に、エッジレベル調整を今回作ったMTZ_AUF改造版で2スレッド並列にしてみる。

2スレッドの時
mtz_auf_2thread_cpu
CPU使用率が少し上がった。まだ遊んでるけど。もっと働けい!

2スレッド並列の時のスレッドの様子
mtz_auf_2threads_t
TID=2208,4060というスレッドが出来て、エッジレベル調整が並列で動いている。



3スレッド並列時の様子

mtz_auf_3thread_cpu
十分仕事してる。

スレッドの様子>>



4スレッド並列時の様子

mtz_auf_4threads_cpu
こちらも同様。

スレッドの様子>>



速度の比較

さっきも書いたように、今回の方法ではCPU使用率が上がっても、オーバーラップして計算させることで増えた計算によって遅くなる可能性がある。なので実際に速度を比較。
mtz_auf_fps

やはりエッジレベル調整は重いようで、(効率はさておくとしても、)順調に高速化している。

もっとも、効率も悪くない。CPU使用率70%前後→100%で40%弱の高速化なので、結構いいほうじゃないかと。

ただ、Core i7みたいな論理8コアの場合にthreads=8まで順調に高速化するとはとても思えない。どうなるかわからないけど、物理コアは4だし、4以上にしても計算量が増えるせいで逆に遅くなるんじゃないかな…



安定性は?

avisynthでもMT("")とかいう謎のものがあって、同じように並列化ができる。で、2年ぐらい前遊んでみたんだけど…ものすごく不安定だった。エンコ開始時とかでもなく、エンコ途中で落ちて、さすがに手に負えなかった。

avsスクリプト書いたり、バッチファイルを書いたりするのが個人的にあまり楽しくなかったので最近avisynthはあまり触ってないけど、最近はどうなんだろうか。MTは諦めて、フィルタ内部で並列化してもらうのか。それともプロセス2つ走らせるのかな…。

とりあえず、今回のMTZ_AUF for エッジレベル調整はエッジレベル調整を対象とする限り安定して動きます。そのはずです…




MTZ_AUF for エッジレベル調整




今回、YOUMEI様に改造版の公開の許可を頂きました。ありがとうございます。

[動作環境]
Windows XP (x86)
Vista,7 (x86/x64)
Aviutl 0.99g4 以降
マルチコアCPU / SSE2に対応したCPU
エッジレベル調整用

[注意事項]
無保証です。自己責任で使用してください。
mtz_auf for エッジレベル調整を使用したことによる、いかなる損害・トラブルについても責任を負いません。

また、基本的にエッジレベル調整専用です。他のAviutlフィルタへ適用した場合は、おかしくなる可能性が高いです。

なんかおかしな点などありましたら、コメント欄にどうぞ。


[使用方法]
オリジナルのものと少し異なります。

1. mtz_auf.aufをAviUtl.exeと同じフォルダ、あるいはpluginフォルダに放り込みます。

2. edgelevelMT.aufを、並列化したいスレッド数だけコピーし、そのファイルの拡張子をそれぞれ「.mt0」、「.mt1」、…のようにします。

3. mtz_auf.aufの名前を変更し、edgelevelMT.aufとします。

4. mtz_auf.iniの名前を変更し、edgelevelMT_mtz.iniとします。このファイルを開き、値を編集します。
overwrapが(縦方向に)オーバーラップ処理する画素数、
threadsがスレッド数です。
エッジレベル調整ではoverwrapは4ぐらいがいいと思います。(少なくとも、これ以上にする必要はない)

5. Aviutlのファイル > システムの設定で、高さを (スレッド数-1)×オーバーラップ量×2 だけ増やしてください。

例えば、高さ1080を編集し、スレッド数4、オーバーラップ量4なら、1080 + (4-1)×4×2で1104、またはそれ以上に設定してください。

これを忘れて高さが不足した場合、メッセージが出るようになっています。

6. AviUtlを再起動します。
Aviutlが問題なく起動し、edgelevelMT.aufが無事に動作していること(設定ウインドウが表示される…など)を確認してください。



4スレッドの時の例

  [pluginフォルダ]
  edgelevelMT.auf
  mtz_auf.auf
  mtz_auf.ini

  ↓

  [pluginフォルダ]
  edgelevelMT.mt0 ← 元は edgelevelMT.auf
  edgelevelMT.mt1 ← 元は edgelevelMT.auf
    …
  edgelevelMT.mt3 ← 元は edgelevelMT.auf

  edgelevelMT.auf ← 元は mtz_auf.auf
  edgelevelMT_mtz.ini ← 元は mtz_auf.ini

edgelevel_mtz_full
クリックで拡大


さらにedgelevelMT_mtz.iniのthreadsを4に設定する。

[MTZ_AUF]
threads=4
overwrap=4



設定すべきスレッド数

スレッド数は2~32の範囲で、iniファイルのthreadsで設定できます。反映にはAviutlの再起動が必要です。32まで設定できますが、絶対必要ありません。

オーバーラップして計算するため、スレッド分割をすればするほど重複する演算が多くなります。

なので、増やしすぎるとCPU使用率は上がっても、逆に遅くなる可能性があります。

CPUの性能、Aviutlで使用するフィルタの重さ、x264のオプションなどによって最適なスレッド数は変わります。



需要あんのかな…
まあ、こんなことしなくてもAviutl2つ走らせればいいだろ…と言われそうだ。



※素直に並列化 + 拡張命令の使用でこの方法よりも安定・さらに高速化したエッジレベル調整MT 0.7 v7をこちらで公開していますので、どうぞ。
ダウンロード>>






MTZ_AUF.auf、エッジレベル調整を公開してくださっている作者様に御礼申し上げます。

YOUMEI様
http://www2u.biglobe.ne.jp/~youmei/

がらくたハウスのがらくた置き場
http://www.geocities.jp/flash3kyuu/



長くなりました。お疲れ様です。
スポンサーサイト



コメントの投稿

非公開コメント

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

Re: No title

どうもです。誤字修正しました。

No title

コイツを待っていました!!


我が家ではPhenomⅡx6利用しているのですが、どうしてもエッジレベルがネックになって使用率が60~70%止まりとなっていました。

早速組み込んでトライしてみます。

テスト結果

実6コアのCPUですので、余裕をみて5スレッド化、オーバーラップは4としてテストしてみました。


PC環境
WinXp SP3
PhenomⅡX6 1090T @ 3.6GHz (6C/6T)
DDR2-1066 4GB
Radeon HD6870-1GB


ソース:未来日記 後期OP(90s)
ts 1440x1080i 29.97fps

出力
1280x720p 自動フィールドシフト 23.97fps

Aviutl環境
Aviutl 0.99k2
MPEG-2 VIDEO VFAPI Plug-In 0.7.5a
x264guiEx 1.30
x264 r2164 8bit
--preset slower --crf 20 --ipratio 1.5 --qpmin 5 --qpmax 51 --qpstep 12 --qcomp 0.7 --no-mbtree --aq-mode 2
--aq-strength 0.05 --psy-rd 1.2:0.5 --scenecut 65 --keyint 240 --min-keyint 2 --deblock -1:-1 --partitions
p8x8,b8x8,i8x8,i4x4 --ref 4 --colormatrix bt709 --colorprim bt709 --transfer bt709 --level 4.1


Aviutlフィルタ
自動フィールドシフト
リサイズフィルタMT(Spline36)
NL-Means-light for GPU TypeC
エッジレベル調整
WarpsharpMT
スムージングフィルタSIMD
バンディング低減


結果

FPS:7.46→9.36
エンコード時間:4分49.5秒→3分50.9秒


ばっちり高速化されました、有難う御座いました。m(_ _)m

エンコテスト

4スレッド、オーバーラップ4でテストしてみました。

■PC環境
OS:Windows7 Pro 64bit
CPU:Intel Core i7 2700k @4.8GHz
MEM:DDR3-12800 16GB

■ソース
ひげさんと同じく、未来日記 後期OP(90s)
tsファイル 1440x1080i 29.97fps(ネットワーク上の別PCにあります)

■Aviutl環境
Aviutl 0.99k2
読み込みプラグイン:MPEG-2 VIDEO VFAPI Plug-In 0.7.5a
出力プラグイン:x264guiEx 1.33
x264バイナリ:POPさんビルド x264 r2164 64bit(L-SMASH)
インターレース解除:自動24fps

■オプション
--preset slower --crf 21 --qpstep 16 --qcomp 0.8 --vbv-bufsize 16000 --vbv-maxrate 16000 --aq-strength 0.6
--psy-rd 0.3:0 --scenecut 60 --keyint 240 --min-keyint 1 --bframes 4 --deblock -1:-1 --partitions p8x8,b8x8,i8x8,i4x4
--merange 32 --ref 4 --no-fast-pskip --no-dct-decimate --cqmfile "XXXX割愛XXXX.cfg"
--colormatrix bt709 --colorprim bt709 --transfer bt709 --level 4.1 --nal-hrd vbr --psnr --ssim --fade-compensate 1.0

■フィルタ
透過性ロゴ
リサイズフィルタ(1280x720、輝度・色差:Spline36、SIMD:AVX)
NL-Means Light(AVX)
エッジレベル調整 Ver0.7
バンディング低減フィルタMT

■結果
FPS:18.64fps→21.45fps
エンコード時間:1分55.7秒→1分40.6秒


CPUの遊びも少なくなり速度アップしました。
塵も積もればなんとやらです。
いい情報ありがとうございました。

エンコテスト

詳細なレポートありがとうございます。

いろいろな環境・設定でも、シングルスレッドのままだとエッジレベル調整はボトルネックになりやすいのですね。

みなさん高速化したようで、よかったです。

No title

とりあえず試してみて、確かに高速化は確認できたのですが、エンコードした動画を見てみると時折、オーバーラップ処理に失敗しているとおぼしき破綻(画が帯状に上下にズレる)した画像が一コマだけ混じっている部分が散見されました。

ただ、その部分と前後数秒だけでエンコードするとズレないなど、再現条件がはっきりしません。

レポートされている方で、同様の処理結果になっている方は他にいらっしゃらないでしょうか。

No title

>青さん
25分のものをエンコしてじっくり確認しましたが、当環境ではオーバーラップ処理失敗等は見られませんでした。

フィルタ等は前回コメントに記載したものと同じものです。(順序も上から順に)

何らかのバグがあるんでしょうかね・・・

No title

>青さん

一応私の方でも昨晩の「ちはやふる」と「パパの~」の2本をエンコードして、PCと居間の液晶TVに映してチェックしてみましたが、特に変に感じるシーンは有りませんでした。

まぁ、1フレームだけとかでしたら見ていても気付かなかった可能性が大きいですが(汗


ちなみにどの様なソースの映像をエンコされました?
ミスするフレームの間隔とか、規則性はありましたか?

上下にずれる問題について

報告ありがとうございます。

現象を再現させるべくやってみているのですが、今のところ再現できていません。

普段、アニメをエンコード中にこれを使ってエンコードをしているものを見ているのですが、これまで気づきませんでした。

問題が発生する場合の環境等を教えてくださると助かります。

これからソースコードの方をじっくりバグがないかチェックしてみます。

No title

お手数をおかけしております。
試したのが今のところソース一つだけなので、他のソースでどうなるか等分からない事だらけです。とりあえず不具合が出た環境を書いておきます。

PC環境
OS: Windows7 Ultimate 64bit
CPU: AMD Phenom II X4 945 @3GHz
MEM: DDR3-1333 8GB

ソース
輪るピングドラム第21話 BS11 PT2録画
ts 1920x1080i 29.97fps

AviUtl環境
0.99k2
MPEG-2 VIDEO VFAPI Plug-In 0.7.5a
x264guiEx 1.24
x264 r2164(x64)

Encoding settings
cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / fade_compensate=0.00 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=tff / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=15 / keyint_min=1 / scenecut=60 / intra_refresh=0 / rc_lookahead=37 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.80 / qpmin=0 / qpmax=69 / qpstep=12 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.50 / aq=1:0.60

フィルタ
エッジレベル調整 Ver0.7
NL-Means Light

リサイズ無し、インターレース維持でエンコードしています。
規則性ははっきりしません。数分ないこともあれば、10秒程度で連続して起きることもあります。

今後別ソースでも試してみますが、もしこちらの環境の問題か、設定ミスだったら大変申し訳ありません。rigayaさんには本当にお手数をおかけしますが、対応をよろしくお願いします。

No title

>青さん
前はプログレッシブだったので、今度はリサイズなし・インタレ保持でエンコしてみましたが(TSソースでOPだけですが)、映像の乱れはありませんでした。
あとで全編エンコしてみます。

まずはご報告まで・・・

No title

先ほどプログレッシブで当方でも同じ現象を確認しました(バクマン2 第15話)。
インタレ保持特有の現象ではないようです。

CPUがC2Dなので2スレッドで使用したのですが、

画面最下部から数ピクセルぶんが帯状にダブっており、そのぶん下駄を履いた状態の下半分の絵が上半分の絵に被ってしまってズレが生じているようです。

青さんが2スレッドで使用しているのなら、もしかして2スレッド特有の現象でしょうか?

No title

別ソースという事で、BS11のピングドラム第22話、Eテレの日常第8話のtsファイルで試してみましたが、同様の現象が出ました。

>syaさん
スレッド数4、オーバーラップ量4でやってますので、現象自体はスレッド数依存というわけでもなさそうです……。
プロフィール

rigaya

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先: rigaya34589@live.jp
github twitter

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutl 出力プラグイン
x264guiEx 3.xx
- x264を使用したH264出力
- x264guiExの導入紹介動画>
- x264guiExの導入
- x264guiExのエラーと対処方法>
- x264.exeはこちら>

x265guiEx
- x265を使用したH.265/HEVC出力
- x265guiExの導入>
- x265.exeはこちら>

QSVEnc + QSVEncC
- QuickSyncVideoによるHWエンコード
- QSVEnc 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC
- NVIDIAのNVEncによるHWエンコード
- NVEnc 導入/使用方法>
- NVEncCオプション一覧>

VCEEnc + VCEEncC
- AMDのVCE/VCNによるHWエンコード
- VCEEnc 導入/使用方法>
- VCEEncCオプション一覧>

svtAV1guiEx
- SVT-AV1によるAV1出力
- svtAV1guiExの導入>
- SVT-AV1単体はこちら>

VVenCguiEx
- VVenCによるVVC出力
- VVenCguiExの導入>

ffmpegOut
- ffmpegを使用した出力
- ffmpegOutの導入>


○Aviutl フィルタプラグイン
自動フィールドシフト (ミラー)
- SSE2~AVX512による高速化版
- オリジナル: aji様

clcufilters 
- OpenCL/CUDAのGPUフィルタ集
- 対応フィルタの一覧等はこちら

エッジレベル調整MT (ミラー)
- エッジレベル調整の並列化/高速化
- SSE2~AVX512対応
- オリジナル: まじぽか太郎様

バンディング低減MT (ミラー)
- SSE2~AVX512による高速化版
- オリジナル: まじぽか太郎様

PMD_MT
- SSE2~AVX512による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor (ミラー)
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
Amatsukaze改造版
- AmatsukazeのAV1対応版

tsreplace
- tsの映像のみを置き換えて圧縮

rkmppenc
- Rockchip系SoCのhwエンコーダ

fawutil
- FAW(FakeAACWave)⇔aac変換
- 二重音声の取り扱いにも対応

x264afs (ミラー)
- x264のafs対応版

aui_indexer (ミラー使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter (ミラー)
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (ミラー, 使い方, ソース)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定
- これまでの測定結果はこちら

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)
SVT-AV1 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR