自動フィールドシフト 高速化 7.5a+20

この前は、自動フィールドシフトではいろいろやってだいぶ速くなったのだけど、これ以上は速くするのが難しくなってきているという話だった。

ただ、実はまだ方法が残っているといえば残っていて、実際にコメントを頂いたこともあった。そこで、もう少しやってみたというのが今回。やったのは2つで、

・YUY2フィルタモードへの対応して高速化。
・通常(YC48)モードで高速な簡易解析モードを追加。


どういうことなのかをちょっと書いていく。

AviutlのYUY2フィルタモード



Aviutlはふつう、編集で使うために内部で持っているフレームをYC48という形式で持っている。これは言ってみれば12bitのYUV444の亜種なので、高精度だがデータサーズとしては非常に重い。

一方、YUY2フィルタモードは、Aviutlで内部で持っているフレームをYC48でなくYUY2にする。YUY2は8bitのYUV422なので、データサイズは1/3になる。

YUY2フィルタモードへは、Aviutlの設定画面から切り替えることができる。(下から2つ目)

afs_aviutl_yuy2_filter_mode.png

もちろん、その分、編集時の精度が落ちてしまうという問題がある。ただ、データサイズが1/3になるだけあって、高速化には非常に効果がありそう…ということで、自動フィールドシフトのYUY2フィルタモード対応をやってみた。



自動フィールドシフトのYUY2フィルタモード対応



自動フィールドシフトのYUY2フィルタモードでの処理の流れを、通常の内部YC48モードと比較するとこんな感じ。

afs_process_02.png

まあ、流れとしてはいままでと同じで、単に入出力フレームがYUY2になるだけ。

ただ、問題は、かなり複雑な処理になっている「scan_frame」の処理と自動フィールドシフトの「解除レベル」ごとに処理の異なる「blend」の処理のところでSIMDコードを全部書き直さないといけないというところ。…かなりしんどかった。




YUY2フィルタモードの問題点



実際に作ってみると、ちゃんと速くはなる(後述)のだけど、やはり縞や動きの判定などで、少し差が出てしまう。この原因は2つあって、

・縞や動きの判定を12bitでやっていたのが8bitに。
4bit分精度が落ちているので、設定する閾値に対する応答が離散的(あるところで判定結果が急に変わるような感じ)になって、差が出てしまう。すこし調整しづらいことも?

・色差が横方向に半分に間引かれているので、そのぶん横方向の解像度が落ちている。
少し判定領域が横に広がりやすくなっている。

という理由で、わりとどうしようもない気がする。

実際に比較するとこんな感じ。(自動フィールドシフトを「調整モード」を有効にして判定結果を見た場合)

通常(YC48)モード

afs_aviutl_analysis_full_s.png
クリックで拡大

YUY2フィルタモード

afs_aviutl_analysis_nv16_s.png
クリックで拡大

とまあ、若干差があるのがわかると思う。

先程も書いたけど、8bit化の影響で、閾値を変えたときの応答が変わり、あるところで判定結果が急に変わるような感じになってしまってい、調整しづらくなっている。なので、特に縞の判定などで小さい閾値を使っている場合には、調整しづらく、ちょっと使えないといったこともあるかもしれない。



YUY2フィルタモードのもうひとつの問題は、AviutlのYUY2フィルタモードでは使える他のフィルタの数がとても少ないということ。まあ、YUY2フィルタモードはおまけのような位置付けのようなのでしょうがないのだけど…。

YUY2フィルタモードのオンオフで、有効になっているフィルタを比べるとこんな感じ。

afs_aviutl_yuy2_filter_mode_filters.png

だいぶ少なくなってしまっていて、これだとほとんどフィルタはかけられない…。



Aviutlの通常(YC48)モードに高速簡易解析モードを追加



ということで、やはりYUY2フィルタモードは、使えるフィルタが限られていて、使いにくい。

そこで、通常(YC48)モードで、解析だけYUY2フィルタモードでやるという、両方の合いの子みたいなことをやって「高速簡易解析モード」というのを追加した。

具体的な処理の流れは下の図のピンクの矢印のような感じで、AviutlからYC48でフレームを受け取り、インタレ解除後のフレームもYC48で出力するが、自動フィールドシフトの内部ではYUY2フィルタモードのときのように8bit/YUV422で持つようにしてみた。内部でYC48から一度8bit/YUV422に落とすことになるけど、そもそもインタレ解除はフィルタ処理の最も最初に行うので、インタレ素材のほとんどが8bit/YUV420であれば、そこは問題にはならないと思う。

afs_process_03.png

こうすると、YUY2フィルタモードほどではないが、ある程度高速化しつつ、ほかのフィルタとの組み合わせも使用できるようになる。ただ、縞や動きの判定方法はYUY2フィルタモードのときと変わらないので、閾値の問題はYUY2のときと同じ。



高速化結果



じゃあ実際どんだけ速くなるの、という話。

計測環境

OSWin10 x64Win10 x64
CPUi7 4770K (4C/8T)i7 6700K (4C/8T)
CPU世代HaswellSkylake
Core4.0GHz4.3GHz
UnCore4.0GHz4.1GHz
キャッシュL3=8MBL3=8MB
メモリDDR3-1600, 2chDDR4-2933, 2ch
CL8-8-8-24-216-18-18-34-2


その他計測環境・計測条件
Aviutl 1.00
入力プラグイン: L-SMASH Works r917 (POP氏ビルド)
入力: MPEG2 1920x1080 29.97fps 10240フレーム
一発勝負


i7 4770K

r20 簡易 = 通常(YC48)モード + 簡易高速解析オン
r20 yuy2 = YUY2フィルタモード
afs_speed_20161118_full_4770k.png


i7 6700K

r20 簡易 = 通常(YC48)モード + 簡易高速解析オン
r20 yuy2 = YUY2フィルタモード
afs_speed_20161118_full_6700k.png

というわけでまあ、久しぶりに大幅に速くなった。YUY2フィルタモードが非常に速いのはもちろん、通常(YC48)モードの簡易高速解析でもかなり速くなったことがわかる。ひとつの目標であった5msを割れてとてもうれしい。

大量にSIMDコードを書きまくる羽目になって疲れたが…。

まあ、YUY2モードや簡易モードは若干精度が落ちるので、気になる人は使えないかもしれないが、速度重視の場合には使えるんじゃないかなあ、と思う。

というわけで需要があるか謎だけど公開しておく。



7.5a+20の変更点



・YUY2フィルタモードに対応した。

・処理モードを選択できるようにした。
フル解析 / 簡易高速解析

・サブスレッド数を指定できるようにした。
scan_frame以外の部分のスレッド数。たいてい1~2で十分。"4"は、i7 5960Xなど、4chメモリーを持つPC用。

・設定をファイルに保存 / ファイルからロードできるようにした。

・save_stg_afs.exeを追加。
Aviutlのプロファイル(cfgファイル)から自動フィールドシフトの設定を抽出して保存する。





7.5a+20の注意点



・YUY2フィルタモード及び簡易高速解析モードは先程も述べたように判定が若干荒くなるのでご注意ください。

・YUY2フィルタモード及び簡易高速解析モードは、afs.aufのみの機能です。afsvf.aufからは利用できません。

・かなりデバッグしましたが、大きくいじっているのでまだバグがあるかもしれません…。

・従来の自動フィールドシフトを7.5a+20に更新すると、Aviutlのプロファイルに保存されている自動フィールドシフトの設定が消えてしまいます。これは、設定の数が増えると、保存されている設定を初期化してしまうAviutlの動作によるもので回避できません。

ただ、消えてしまうので、自分でなんとかしてね、というのはさすがにないかなと思ったので、プロファイル(具体的にはAviutlのcfgファイル)から、"自動フィールドシフト"と"自動フィールドシフトVF"の設定を抽出して保存するプログラムを作成しました。

プロファイルの設定を保存するには、7.5a+20の導入前に、Aviutlフォルダの中にsave_stg_afs.exeをコピーして、ダブルクリックして実行してください。そうするとすべての「プロファイル名.cfg」ファイルに対して、「プロファイル名.cfg.afs.ini」という名前で、現時点での自動フィールドシフトの設定が保存されます。

その後、7.5a+20を導入して、自動フィールドシフト右側の「設定ロード」からロードしたいプロファイルのiniファイルを選択してください。もとの設定がロードされます。

※save_stg_afs.exeはダウンロードしたzipファイルに同梱してあります。



ダウンロード>>
ダウンロード (ミラー) >>



ソースはこちら。
ソースを見るとOpenCLでごちゃごちゃなんかやってますが、まだうまくいってません



というわけで、執念深く(?)やってきたおかげで、だいぶ速くなってきたのではないかと思う。自動フィールドシフトが「遅い」と言われない時が来ることを願って、今後も頑張りたい。

なんならAviutlの24fps化最速を目指したいがさすがに無理か…。


スポンサーサイト



コメントの投稿

非公開コメント

No title

いつもありがとうございます。
ボタン一つでプリセットを復元されると便利なのでafs.cppをいじって使ってるので今回もと思いビルドしようとしたところ下記のエラーが出てビルドが止まりました。
これは非Intel環境ではビルドできないということでしょうか?
(Intel SDKのインストールはしています)

(略)
1> Assembling: D:\Date\_dev\afs-master\afs-master\afs\afs_mmx.asm
1> compiling asm...
1> Assembling: D:\Date\_dev\afs-master\afs-master\afs\afs_yuy2up_mmx.asm
1> Preprocessing: afs_opencl.cl
1> Using build options: -D PREFER_SHORT4=1 -cl-std=CL2.0
1>D:\Date\_dev\afs-master\afs-master\afs\afs_opencl.cl : error CL: Failed to get OpenCL device...: -1 (CL_DEVICE_NOT_FOUND)
1> Build failed!
1>
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\IntelOpenCL.targets(98,5): error MSB3721: コマンド ""C:\Program Files (x86)\Intel\OpenCL SDK\6.3\bin\x86\ioc32.exe" -cmd=build -input="D:\Date\_dev\afs-master\afs-master\afs\afs_opencl.cl" -output="D:\Date\_dev\afs-master\afs-master\Win32\Release\afs\obj\afs_opencl.out" -VS -device=GPU -simd=default -targetos=current -bo=" -D PREFER_SHORT4=1 -cl-std=CL2.0"" はコード -1 で終了しました。
========== ビルド: 0 正常終了、1 失敗、0 更新不要、0 スキップ ==========

Re: No title

ああ、すみません。おそらくOpenCLドライバがない環境だと、そういうメッセージが出るかもしれません。

現在OpenCL関係は使用していませんので、afs_opencl.clのプロパティから、「ビルドから除外」を「はい」にして、afs_opencl.clのコンパイルを停止してしまってください。
http://blog-imgs-98.fc2.com/r/i/g/rigaya34589/afs_disable_opencl_compile.png

No title

無事ビルドできました。
早い返信ありがとうございました。

No title

afsはほぼメモリの速度に律速するということですが、これから新規にメモリを購入する場合は

CLの小さなDDR4-2400

CLの大きなDDR4-3200

とではどちらを購入したほうがafsは高速化するのでしょうか?

Re: No title

>> afsはほぼメモリの速度に律速するということですが
いえ、メモリで足を引っ張られることは確かですが、だいぶキャッシュを有効利用できるようになっているためか、やはりCPUの速度のほうが重要です。例えば、上のグラフでもSkylakeではHaswellの倍近い速度のメモリですが、afsの速度自体はそれほどでもありません。

メモリ高速化によりafsが速くなることは確かですが、その効果は限定的です。実際にはafsだけでなく、エンコードを行うことも考慮すれば、やはりCPUの性能のほうがエンコ速度には直結すると思います。

>> CLの小さなDDR4-2400 と CLの大きなDDR4-3200
比較してみたことがないので、よくわかりません。たいてい高速なメモリはCL値は大きくとも実質的なレイテンシは小さいと思います。

No title

> rigaya様

そういうことならメモリは予算第一で選んでも影響は少なそうですね。
返信ありがとうございました。

No title

AVX-512に対応させる予定はありますか?
あるならCPUを新調しようと思うんですが…

Re: No title

AVX-512対応はしたいとは思っていますが、お約束はできません…。

また、問題のCPUが出るのが9/25らしい(?)ので、実装作業に時間もかかることを考えると、実際に動かせるものができるのはだいぶ先になると思います。
プロフィール

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様

clfilters 
- OpenCLベースの複数の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対応版

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