たまには書かないとね…。
後続記事もどうぞ
D3DVPが更新された
D3DVPを試してみる(AMD/Renoir)
更新履歴
2018/3/25 Ver 0.2.4 公開に合わせて修正&次の記事への誘導
D3DVPとは
nekopanda氏作成のAviSynth/AviUtl用フィルター。Direct3D11のVideo APIを使ったインターレース解除フィルタで、GPUを使ってインターレース解除ができるものです。
Windows7では動かないようです。Windows8以降必須。Radeon、GeForceはもちろん、IntelのCPU内蔵GPUでも動作するようです。
このページではAviSynth版をIntel環境下で色々といじってみます。
テスト
インターレース解除の品質はどうなのか?GPUドライバの設定で結果はどう変わるのか?速度は速いのか?気になりますよね。というわけで、色々とテストしていきましょう。
テスト環境
OS | Windows10 Pro (Ver.1709) |
AviSynth | AviSynth+ r2580 |
CPU | E3-1225v3 (Haswell) |
GPU | HD P4600 |
GPU Driver | 20.19.15.4835 |
D3DVP | 0.2.2 |
CPUとGPUは、ほぼi7-4770みたいなものなので、i7-4770と思って見てください。GPUの世代やドライバによって結果が大きく変わる可能性があるので、この記事はあくまで参考程度に見るようにしてください。
特にRadeonやGeForceでは大きく結果が変わるでしょうから、この2つの環境の方は参考にしないようにしてください。
RadeonもGeForceも持ってません。それらのテストは誰かやって★
テスト映像素材
- 動きが激しい
- 字幕がある
- ブログで使っても怒られなさそう
そんな素材がいいんじゃないかなと思いました。ということで
壺おじさんを少し録画しました。解像度は640×400で、fpsは60です。プログレッシブ映像です。静止状態が長く続くような部分はあまりない動画です。
GPUドライバの設定
D3DVPはGPUの画質補正を使うこともできますが、挙動はドライバの設定通りになります。テスト前にまず設定項目にどういうものがあるか確認しておきます。
Intelの場合、こんな設定画面です。全部の項目分SSを貼ると画像だらけになってしまいそうなので、表にします。
分類 | 項目 | 設定 |
色調整 | 標準色補正 | アプリケーション設定 |
入力範囲 | アプリケーション設定 | |
総合色補正 | 無効 | |
画像調整 | 鮮明度 | アプリケーション設定 |
スキントーン調整 | 無効 | |
ノイズリダクション | アプリケーション設定 | |
コントラスト調整 | 無効 | |
フィルムモード検出 | 無効 |
全てを アプリケーション設定 or 無効 にすると、GPUはインターレース解除のみを行い、画質補正をしなくなります。まずは全部無効にしました。1つだけ有効にして変化をチェックしたいと思います。
テスト
では実際にテストしていきましょう。
まずはフィルタが動くかどうかだけのチェック。
1 2 3 4 5 6 7 8 9 10 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() src = Subtitle( "元ソース" , font="meiryo", size=26) d3da = D3DVP(mode=0, device="Intel") d3dat = d3da.Subtitle( "D3DVP" , font="meiryo", size=26) StackHorizontal(src, d3dat) return last |
するとこんな結果になりました。
元ソースではツルハシが左よりわずかにあがっていますが、フィルタを適用したものではわずかに下がっていて別の時間の映像になっています。
なぜかD3DVPフィルタを適用すると、 先頭フレームが2フレーム重複して表示→以降1フレーム遅れ→最終フレーム欠落 となってしまいました。GPUが悪いのか、ドライバが悪いのか…
画質の変化を追うために、テストではD3DVPフィルタを適用後1フレームずらすことにします。
※D3DVP Ver 0.2.4で上記症状は回避できるようになりました。詳しくは次の記事で。
次にautopオプションの確認。有効にするとドライバの設定通りに映像が変化します。
ためしに色調整の項目をめちゃくちゃにしてみました。右のプレビューの女の子もめちゃくちゃになっています。
1 2 3 4 5 6 7 8 9 10 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() src = Subtitle( "元ソース" , font="meiryo", size=26) d3da = D3DVP(mode=0, device="Intel", autop=true).Trim(1,0) d3dat = d3da.Subtitle( "D3DVP + autop" , font="meiryo", size=26) StackHorizontal(src, d3dat) return last |
そしてautopオプションを有効にすると
めちゃくちゃになりました。と、こんな感じでドライバの設定が反映されるようになります。
フィルムモード検出のチェック
フィルムモード検出は、フィルムから作成されたビデオの画質が向上するオプションのようです。色調整は元に戻して、今度はこの機能を確認してみましょう。
60pの場合
キャプチャした60pの映像にフィルタをかけてみます。本来プログレッシブなものにインターレース解除のフィルタかける意味なんてないのですが、フィルム検出モードの効果を試せると思います。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() src = Subtitle( "元ソース" , font="meiryo", size=26) d3da = D3DVP(mode=0, device="Intel", autop=false).Trim(1, 0) d3db = D3DVP(mode=0, device="Intel", autop=true).Trim(1, 0) cmp = mt_lutxy(d3da, d3db, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) d3dat = d3da.Subtitle( "フィルムモードオフ" , font="meiryo", size=26) d3dbt = d3db.Subtitle( "フィルムモードオン" , font="meiryo", size=26) cmpt = cmp.Subtitle( "フィルムモードオンオフで変化のある部分" , font="meiryo", size=26) StackVertical( StackHorizontal(src, d3dat), StackHorizontal(cmpt, d3dbt) ) return last |
次にこんな感じのavsを書きました。autopオプションは、GPUの画質補正を使うかどうかです。フィルムモード検出のみ有効にしてtrueにすれば、フィルムモード検出の効果だけ反映されます。
右上が単にD3DVPをかけたもの、右下がD3DVP+フィルムモード検出です。左下がその2つの差です。
差についてですが、白色がY(輝度)の差がある部分、青色がUの差がある部分、赤色がVの差がある部分、とみてください。紫はUとV両方に差がある部分ですね。
背景(空)の部分は差がなく、おじさんやオブジェクトには輝度、色差ともに差がでています。ツルハシに注目してみると、右上は不自然に細くなっているのに対し、右下はソースと同じように見えます。見にくい場合はクリックしてみてください。
実際にフィルムモード検出で、画質は向上してそうです。
ソースとの差をみてみました。フィルム検出モードが効くと、D3DVPでの変化は色差成分のみで、輝度は変化しないようです。映像の変化が抑えられています。ただ、TDeintのfullオプションやtryweaveオプションとは違い、色差の変化は避けられないようです。なんか不思議な仕様ですね。
ざっと確認してみたところ、60pのソースでは最初の4フレームを除いてほぼすべてのフレームでフィルムモード検出が効き、輝度の劣化は避けられました。プログレッシブフレームが続いたら効果が発動するようです。
60iの場合
ではインターレース素材ではどうなるのでしょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() AssumeTFF().SeparateFields().SelectEvery(4, 0, 3).Weave() src = Subtitle( "元ソース" , font="meiryo", size=26) d3da = D3DVP(mode=0, device="Intel", autop=false).Trim(1, 0) d3db = D3DVP(mode=0, device="Intel", autop=true).Trim(1, 0) cmp = mt_lutxy(d3da, d3db, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) d3dat = d3da.Subtitle( "フィルムモードオフ" , font="meiryo", size=26) d3dbt = d3db.Subtitle( "フィルムモードオン" , font="meiryo", size=26) cmpt = cmp.Subtitle( "フィルムモードオンオフで変化のある部分" , font="meiryo", size=26) StackVertical( StackHorizontal(src, d3dat), StackHorizontal(cmpt, d3dbt) ) return last |
ということで、60pを60iに変更してテストしてみました。
フィルムモード検出のオンオフで差がでなくなりました。compareコマンドを使って全フレーム解析してみましたが、全フレーム差がありませんでした。効果がまったく現れませんでした。
テレシネの場合
60pから間引いて24pにしたあと、テレシネして30フレームにしてからフィルタをかけてみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() SelectEvery(5, 0, 2).SeparateFields().SelectEvery(8,0,1,0,3,2,5,4,5,6,7).Weave() src = Subtitle( "元ソース" , font="meiryo", size=26) d3da = D3DVP(mode=0, device="Intel", autop=false).Trim(1, 0) d3db = D3DVP(mode=0, device="Intel", autop=true).Trim(1, 0) cmp = mt_lutxy(d3da, d3db, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) d3dat = d3da.Subtitle( "フィルムモードオフ" , font="meiryo", size=26) d3dbt = d3db.Subtitle( "フィルムモードオン" , font="meiryo", size=26) cmpt = cmp.Subtitle( "フィルムモードオンオフで変化のある部分" , font="meiryo", size=26) StackVertical( StackHorizontal(src, d3dat), StackHorizontal(cmpt, d3dbt) ) return last |
アニメなどでよくみかけるpiipp形式にしてからフィルタをかけてみました。
pの部分は60pのときと同様に、輝度だけ処理していました。iの部分はフィルムモード検出オフのときでは残像のようなものが残っていましたが、オンでは消えています。iの場合は意味がない、というわけではないようです。
フィールドマッチングしてるのか確認するために、次はテレシネ前のpのときと比べてみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() src = SelectEvery(5, 0, 2).SelectEvery(4, 0, 1, 2, 2, 3) SelectEvery(5, 0, 2).SeparateFields().SelectEvery(8,0,1,0,3,2,5,4,5,6,7).Weave() d3da = D3DVP(mode=0, device="Intel", autop=false).Trim(1,0) d3db = D3DVP(mode=0, device="Intel", autop=true).Trim(1, 0) cmp = mt_lutxy(src, d3db, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) d3dat = d3da.Subtitle( "フィルムモードオフ" , font="meiryo", size=26) d3dbt = d3db.Subtitle( "フィルムモードオン" , font="meiryo", size=26) cmpt = cmp.Subtitle( "元のプログレとフィルムモードオンの比較" , font="meiryo", size=26) StackVertical( StackHorizontal(src, d3dat), StackHorizontal(cmpt, d3dbt) ) return last |
わかりにくいですが、
- 60pから24pにしたあと、フレームを水増しして30pにしたもの
- 60pから24pにしたあと、テレシネしてpiippの30フレームにしたあとD3DVP(フィルムモード検出ON)をかけたもの
この2つを比較したものです。
左上と右下の差が左下ということです。iiの部分の比較をしましたが、輝度成分は一緒になったので、輝度成分はフィールドマッチングでプログレッシブ化したようです。
30pと60iが適度に混ざっている場合
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() p30 = SelectEven() i60 = SeparateFields().SelectEvery(4, 0, 3).Weave() p30.Trim(0,99) ++ i60.Trim(100,199) ++ p30.Trim(200,299) ++ i60.Trim(300,399) ++ p30.Trim(400,499) ++ i60.Trim(500,599) src = ScriptClip("subtitle(string(current_frame))") d3da = D3DVP(mode=0, device="Intel", autop=false).Trim(1,0) d3db = D3DVP(mode=0, device="Intel", autop=true).Trim(1, 0) cmp = mt_lutxy(d3da, d3db, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) d3dat = d3da.Subtitle( "フィルムモードオフ" , font="meiryo", size=26) d3dbt = d3db.Subtitle( "フィルムモードオン" , font="meiryo", size=26) cmpt = cmp.Subtitle( "フィルムモードオフとオンの比較" , font="meiryo", size=26) StackVertical( StackHorizontal(src, d3dat), StackHorizontal(cmpt, d3dbt) ) return last |
100フレームごとに 30p → 60i → 30p… と変わるものに対してフィルタを適用してみました。
最初の30pの100フレーム(0-99)は、60pのときと同じでした。5フレーム目からフィルムモードの効果が表れ始めました。
しかし、60iゾーン開始1フレーム目で右下のフィルムモード検出でインターレース解除漏れが起きました。
101フレーム目も同様にインターレースが解除されていません。多分フィールドマッチングしようとしたけど、マッチするフィールドがないのでコーミングのまま残ったのでしょう。
102フレーム目で解除漏れがなくなりました。フィルムモード検出のオンオフでの差もなくなりました。コーミングフレームが続いたらフィルムではないと判定するようになっているのかもしれません。勝手な憶測ですが。
フィルムモード検出にも副作用があることがわかりました。運用には気を付ける必要がありますね。
また、200フレーム目から30pになるのですが、フィルムモード検出は効きませんでした。一度効かなくなるとずっと効かなくなるようです。ただし、200フレーム目以降プレビュー中、一度F5を押して更新してからシークすると効果が復活します。
おま環くさいですが…
30pと60iが適度に混ざっている場合 (mode=1)
さっきからずっと mode=0 で試していましたが、Bob化の mode=1 も確認しておきましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() p30 = SelectEven() i60 = SeparateFields().SelectEvery(4, 0, 3).Weave() p30.Trim(0,99) ++ i60.Trim(100,199) ++ p30.Trim(200,299) ++ i60.Trim(300,399) ++ p30.Trim(400,499) ++ i60.Trim(500,599) src = interleave(last, last) d3da = D3DVP(mode=1, device="Intel", autop=false).Trim(1,0) d3db = D3DVP(mode=1, device="Intel", autop=true).Trim(1, 0) cmpa = mt_lutxy(src, d3db, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) cmpb = mt_lutxy(d3da, d3db, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) #~ compare(last , d3db, "Y", "test,txt") d3dat = d3da.Subtitle( "フィルムモードオフ" , font="meiryo", size=26) d3dbt = d3db.Subtitle( "フィルムモードオン" , font="meiryo", size=26) cmpat = cmpa.Subtitle( "ソースとフィルムモードオンの比較" , font="meiryo", size=26) cmpbt = cmpb.Subtitle( "フィルムモードオンとオフの比較" , font="meiryo", size=26) StackVertical( StackHorizontal(cmpbt, d3dat), StackHorizontal(cmpat, d3dbt) ) return last |
30p/60i混在から60pにします。
先頭の1フレームがインターレース解除されませんでした。1フレーム削った後なので、実際は先頭2フレームが解除されていませんでした。
※D3DVP Ver 0.2.4で上記症状は回避できるようになりました。詳しくは次の記事で。
10フレーム目からフィルムモード検出の効果が出ました。mode=0のときは5フレーム目からだったので、単純に倍になってます。そして200-204フレーム目でコーミングが発生しました。mode=1でも解除漏れが起きてしまいました。
mode=1でも、TDeintのtryweaveのように効果が出ることがわかりましたが、先ほどと同じように一度効かなくなると復活しません。
速度比較
フィルムモード検出オンとオフで速度に差が出るか確認してみます。60pソースに対してフィルタをかけ、AVSMeterで速度を計測してみました。
FPS(avg) | CPU usage | GPU | |
フィルムモード検出オフ | 826 | 29% | 50%程度 |
フィルムモード検出オン | 841 | 31% | 60%程度 |
一応5回平均。一応オンの方がGPU負荷は少しあがりました。速度はわずかながらオンにした方がはやくなりました。GPUのがんばりに引っ張られたのかもしれません。
フィルムモード検出まとめ
あくまで執筆時の私の環境上での話であることをご理解ください。環境によって全く違う結論になるかもしれません。
有効にした場合
- プログレッシブフレームの輝度の劣化を抑えられる場合がある
- テレシネソースでも輝度の劣化は抑えられる場合がある
- 適用範囲が雑。プログレッシブなのにかからなかったり、コーミングフレームを残してしまう場合がある
TDeintのfullやtryweaveと比べてはいけない…。このオプション目当てでD3DVPを使うくらいならTDeintを使った方がいいんじゃないでしょうか。オフの方が無難という印象です。
Bob化性能のチェック
さて次は本題(?)のBob化の性能をチェックしていきましょう。60pのソースを60iにしてフィルタをかけていきます。
品質チェック
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() SeparateFields().SelectEvery(4, 0, 3).Weave() src = Subtitle( "元ソース" , font="meiryo", size=26) d3d = D3DVP(mode=1, device="Intel", autop=false).Trim(1,0).Subtitle( "3DDVP" , font="meiryo", size=26) yadif = yadifmod2(mode=1, edeint=nnedi3(field=-2)).Subtitle( "Yadifmod2 + nnedi3" , font="meiryo", size=26) tdtmm = TDeint(mode=1, edeint=nnedi3(field=-2), emask=TMM2(mode=1)).Subtitle( "TDeint + TMM + nnedi3" , font="meiryo", size=26) qtgmc = QTGMC().Subtitle( "QTGMC" , font="meiryo", size=26) StackVertical( StackHorizontal(d3d, yadif), StackHorizontal(tdtmm, qtgmc) ) return last |
Yadifmod2、TDeint、QTGMCと比べてみましょう。Yadifmod2はedintにnnedi3を、TDeintはTMM2とnnedi3を併用、QTGMCはデフォルト設定(preset=slower)です。
ツルハシを激しく振り上げるところです。QTGMCは前後のフレームのツルハシの動きが残像のようにでてきています。D3DVPも次のフレームのツルハシが少しうつりこんでいます。前後のフレームを見ながら処理しているのかもしれません。
右上から左下に落下しているところです。ツルハシの柄、おじさんの後ろの黒い背景、テロップなどがわかりやすい差かもしれません。「食」の字はYadifmodとQTGMCがこのフレームでは潰れていますね。
おじさんを拡大してみました。「入り」の上、QTGMCとD3DVPはなめらかな斜面になっていますが、Yadifmod2とTDeintはジャギってます。ツルハシの柄はQTGMCはなめらかですが、他はジャギってますね。QTGMCは前後のツルハシの先端が少しうつっています。D3DVPは前のフレームのおじさんや柄の残像が見えます。
ジャギーに関してはフレームによってジャギり具合が変わって、動画だとチラついて見えるので、動画だとこの静止画以上に差を感じます。動きのある部分をBob化させたらやっぱりQTGMCの品質が圧倒的です。
お次にテロップがフェードインしてくるところ。D3DVPが非常にきれいです。YadifmodやTDeintは「達」や「思」が潰れています。QTGMCはこのフレームはまともですが、別のフレームでは潰れます。D3DVPも後ろのオブジェクトと被って映像的に複雑になる「戻」のあたりでは潰れるフレームがでたりしますが、最も安定していました。フェードしきると、TDeintも同等の品質な印象でした。
スクロールする60iテロップの解除品質チェック
次にアニメ等でよく見る流れる60iテロップの場合の品質をチェック。
しかしこの壺おじさんには横スクロールのテロップは確かありません。縦スクロールなら終盤にあったような気がしますが、ネタバレを見せるのもどうかと思ったのでやめておきます。
決して終盤までいくのが大変だからではありません。
ということでAviSynthで表現することにしましょう。
1 2 3 4 5 6 7 8 9 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() Animate(800, 1199, "Subtitle", "結婚式前、お気に入りのシャツをクリーニングに出したのに、食べ物をこぼしたり。", 640, 60, 800, 1199, "MS ゴシック", 20, $FFFFFF, \ "結婚式前、お気に入りのシャツをクリーニングに出したのに、食べ物をこぼしたり。",-640, 60, 800, 1199, "MS ゴシック", 20, $FFFFFF) SeparateFields().SelectEvery(4, 0, 3).Weave() return last |
Animate関数なんてはじめてつかいました。
下は本物のテロップとかぶって見辛くなりそうなので仕方なく上に表示。一応それっぽくなってると思います。ではこれにフィルタを適応してみます。
あれ、思った以上に差がついてしまいました。やっぱ例としては不適切だったかな…。QTGMCだけやたら綺麗で他が結構崩れてしまってます。静止画だと判断しづらいですが、動画としてみると QTGMC > TDeint+TMM > D3DVP > Yadifmod2 な印象でした。
実際よくある60iテロップをTVTest等でGPUでデインターレースさせて視聴したときにはもっと綺麗なテロップになるので、この画像の品質はあまりアテにしないでください。ただ傾向としてはTDeint+TMMに少し劣るくらいの品質な印象です。
動画で確認
見たい奇特な方は こちら から。ブラウザによっては保存は右クリックから保存してください。本来ロスレスでやるべきだったのでしょうが、重すぎるので圧縮してます。
葉と花と岩肌の部分の岩肌が隠れたり出たりしないQTGMCとその他、とか、あとは斜めのジャギの比較とか、そういうところを見ると差がわかりやすいかもしれません。
速度チェック
Bob化の速度を比較してみました。AVSMeterに投げただけです。21603フレーム分処理させました。
FPS(avg) | CPU Usage | |
D3DVP | 1266 | 47% |
Yadifmod2+nnedi3 | 321.9 | 70% |
TDeint+TMM+nnedi3 | 87.20 | 28% |
QTGMC(slower) | 27.45 | 17% |
D3DVPが圧倒的な速度です。TDeint、QTGMCはMTを使えばマシにはなると思いますが、無いとやっぱり遅いですね。
他のフィルタと併用すればここまで差がでなくなると思いますが、単純なデインターレース速度勝負ではここまで差がでます。
Bobまとめ
速度は圧倒的、品質はQTGMCには遠く及ばないものの、Yadifmod以上、TDeint+TMMとも十分わたりあえるという印象です。
ただし、おま環ぽいですが、先頭2フレームにコーミングフレームが表示されるという不具合(?)があるのが玉に瑕。そこを気にしない、または1フレーム速く抜き出してBob化して先頭2フレームカットする等のひと手間をかけるのが苦ではないないのであれば優秀かも。
Bob化の手段がまともになかったAviUtlユーザーにとっては大変ありがたい存在であることは間違いないと思います。
nrオプションのチェック
D3DVPにはノイズリダクション(nr)のオプションがありますが、
※nr,edgeはドライバによっては実装されていないこともあります。
とのことなので、実装されているか確認しておきましょう。まずはドライバの設定の項目を確認しておきましょう。
ドライバ自動設定、ドライバカスタム設定ともに「部分的に削減」と「全体的に削減」の2種類の設定が用意されています。またドライバカスタム設定ではnr強度を設定できます。
また、nrを有効にするとパフォーマンスが低下する可能性があるとの記述があります。
nrなしとMAXの比較
1 2 3 4 5 6 7 8 9 10 11 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() d3d = D3DVP(mode=0, device="Intel", nr=-1).Trim(1,0) d3dnr = D3DVP(mode=0, device="Intel", nr=100).Trim(1,0) cmp = mt_lutxy(d3d, d3dnr, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) cmpt = cmp.Subtitle( "nrなしとnr=100の差" , font="meiryo", size=26) cmpt return last |
nrなしとMAXで変化の出るピクセルを表示させてみます。
白いところが輝度、赤・青が色差の変化があった部分です。少しわかりづらいかもしれませんが、白だけではなく青や赤も少しだけあります。今更だけど、「差」って言い方は正しくないや…
色々と条件を変えてやってみましたが、以下のことがわかりました。あくまでIntelの場合です。またGPUの世代やドライバによって違う結果になるかもしれません。
- 数フレーム動かしてF5を押して再読み込みすると少し結果が変わる
- nr=1でも100でも差はない
- nr=1以上のとき、ドライバで ノイズリダクション → ドライバ自動設定 → 部分的に削減 を選択したときと同じ結果になる
- ドライバカスタム設定にして数値をいじってもドライバ自動設定と同じ結果になることはない
部分的と全体的の違い
次に「部分的に削減」と「全体的に削減」の差でもみておくことにしましょう。
全体的に削減に設定して
1 2 3 4 5 6 7 8 9 10 11 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() d3d = D3DVP(mode=0, device="Intel", nr=100).Trim(1,0) d3dnr = D3DVP(mode=0, device="Intel", autop=true).Trim(1,0) cmp = mt_lutxy(d3d, d3dnr, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) cmpt = cmp.Subtitle( "部分的に削減と全体的に削減の差" , font="meiryo", size=26) StackHorizontal(last, cmpt) return last |
比較してみることにしましょう。フレームはさっきと同じフレームです。
左が元のソースです。輪郭付近の色差だけ違いが出ました。色んなフレームを見てみましたが
- 違いは色差だけ
- 動きが大きいときはまったく差が出ない
- 止まっている部分が大きく、かつその時間が長いときのみ差が出る?
- 止まっている時間が長く続くとnrの効果も大きくなる?
どういうところが「部分」なのか「全体」なのか、よくわかりません。
一応「全体」の発動具合がわかるかもしれない動画をぺたっと。
速度チェック
パフォーマンスが低下する可能性がある、という説明書きがあったので確認しておきます。
FPS(avg) | CPU usage | GPU | |
nrなし | 826 | 29% | 50%程度 |
自動(部分) | 1183 | 57% | 75%程度 |
自動(全体) | 1191 | 56% | 75%程度 |
FPSとCPUはAVS Meterから、GPU(3D)はベンチ実行中のタスクマネージャーのGPUの項目からアバウトに拝借。nr有りの方がGPUががんばるようになり、その分速度もあがってボトルネックがなくなったのか、逆に速くなりました。
上の表は640×400の動画でのテスト結果ですが、試しに解像度を横幅だけ倍にしてからかけてみたらGPU負荷が85%まであがりました。解像度が上がる or GPUがしょぼくなる などしたらGPU負荷が100%になり、パフォーマンスが低下しそうですね。
普通の動画の再生用途であれば60fps以上出ているうちはパフォーマンスの低下は実感できないでしょうから、よっぽどのことがないかぎり体感できないでしょうね。
nrまとめ
あくまで今回のテストでは、の話ですが
- nrオプションを1以上にするとドライバ自動設定(部分的に削減)と同じ効果になる
- 「全体的に削減」は「部分的に削減」より色差に効果が出ることがある
- 一応少しGPU負荷があがる
画質の補正に有用かどうかは私には判定が難しいので、そちらはご自身で確認してみてください。
edgeオプションのチェック
最後に、エッジ強調のオプションをチェックしてみます。まずはドライバの設定から。
鮮明度がedgeに相当するところです。まずはアプリケーション設定(=ドライバ側では無効)にしておきます。
edgeなしとMAXの比較
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() d3d = D3DVP(mode=0, device="Intel", edge=-1).Trim(1,0) d3ded = D3DVP(mode=0, device="Intel", edge=100).Trim(1,0) cmp = mt_lutxy(d3d, d3ded, "x y - abs ", y=3, u=3, v=3).mt_binarize(1, y=3, u=3, v=3) cmpt = cmp.Subtitle( "edge無効とedge=100の差" , font="meiryo", size=26) d3d = d3d.Subtitle( "edge無効" , font="meiryo", size=26) d3ded = d3ded.Subtitle( "edge=100" , font="meiryo", size=26) StackVertical(StackHorizontal(src, cmpt),StackHorizontal(d3d, d3ded)) return last |
では比較してみましょう。
元ソースとedge無効を両方表示する意味は特になかったのですが、スペースが空いたので…。edgeオプションは輝度にだけ効果があるようです。さすがMAX設定、かなりキツくシャープになってますね。
色々と条件を変えてやってみましたが、以下のことがわかりました。あくまでIntelの場合です。またGPUの世代やドライバによって違う結果になるかもしれません。
- nrと違い1~100で結果はちゃんと変わる
- nrと違いドライバ側で鮮明度を設定すると、autop=falseでもその値が反映されるようになってしまう
- edge=100 と ドライバカスタム設定の強度64 は同じ
- ドライバ自動設定 と ドライバカスタム設定の強度44 と edge=67 は同じ?
大体こんな感じのようです。nrのときとは色んな意味で違う挙動でした。ドライバ側でのカスタム設定は強度0-64、edgeオプションは0-100ですが、ドライバ側での数値に1.5倍したものをedgeオプションで指定すれば同じ結果になるようです。
速度チェック
特にこのオプションについてはnrと違いパフォーマンスへの言及はありませんでしたが、一応チェックしておきます。
FPS(avg) | CPU usage | GPU | |
edge無効 | 826 | 29% | 50%程度 |
edge=100 | 810 | 28% | 50%程度 |
一応5回平均です。ほーんの少し遅くなったかもしれない、程度でした。処理としては軽いようです。輝度だけだからかな?
edgeオプションについては特にまとめません。ご利用はお好みで。
エンコード中にドライバの設定を変えてみる
autop=trueのときに、エンコード中にドライバの設定を変えたらどうなるのでしょう。一応確認してみましょう。
1 2 3 4 5 6 7 |
LWLibavVideoSource( "test.mp4" ) Trim(1800,3599) AssumeTFF() D3DVP(mode=0, device="Intel", autop=true).Trim(1,0) return last |
これでエンコードします。エンコード中に
色の設定をめちゃくちゃにしてみました。結果は…
はい。autopを有効にしたらエンコ中は設定を変えちゃだめだゾ★
感想
たまには長文記事を書かないと忘れられてしまいそうと思ったので、久しぶりに書いてみましたが、なんか無駄なところばかりチェックしてしまった感じがします。久々に凄いプラグインが登場したので、普及に一役買えればいいな。
D3DVPというよりも、動画再生時のIntelのドライバの設定項目の効果の確認になってしまった感じがしますね。
あくまで今回私がテストした環境では、mode=0 で先頭1フレームが、 mode=1 で先頭2フレームが怪しいので、本番に導入するのは気が引けてしまいます。DGDecIMのときも作者がIntelにブチ切れてた記憶があるので、Intelが悪いような気がしますがどうにかなるものなのでしょうか。
その点さえ工夫して解決できればすばらしいプラグインだと思います。
※D3DVP Ver 0.2.4で解決しました。詳しくは次の記事で。
コメント
詳細なレビューに圧倒されました。
質問なのですが、IntelとNVIDIAではどちらが精度、画質、速度に優れるでしょうか。
一部ネットの意見で画質はRadeon > Intel > NVIDIAということのようですが、自分が同梱の比較用avsファイルで比較した際は、Intelのみたまに小さなデジタルノイズ(?)が入るように見受けられました。おま環な気もしなくもありませんが。
また、ノイズ除去にGPUフィルタである_GPU25を使用している場合、_GPU25がNVIDIAを使用している場合はD3DVP側をIntelにしておいた方が効率的でしょうか。
それともキャパ的にNVIDIAでも影響ないものでしょうか。
お時間のある際にご返信いただけましたら幸いです。
こんばんは。
残念ながらRadeonもGeForceも現在手元にないため、比較できないんです。
今後購入したら比較記事を書こうとは思っているのですが、いつ頃買うかはまだ決めてないので
予定は未定状態です。
D3DVPでは特に負荷が大きくかかることはないので、他にGPUを使うフィルタを使っていても
おそらく特に影響はないんじゃないでしょうか。試したことがないので迂闊なことは言えないのですが…
ご返信ありがとうございました。
D3DVP自体の負荷はあまり気にしなくてよさそうなんですね。
参考になりました。
今後自分でも色々なソースで見比べてみようと思います。
力作ですね、動画で見比べられてとても参考になりました。
ご丁寧にありがとうございます。
D3DVPが出たばかりの時に書いたので宣伝になればいいなーと思ってがんばった記憶があります
D3DVPというよりIntelの記事になってしまった感がありますが><