自動フィールドシフト 高速化版 +16

+16
フレームバッファ確保を分割して行うことで、メモリ確保エラーを減らし、安定性を向上。
提案してくださったHayatePP様、ありがとうございました。

+15
2つの処理を統合することで高速化。(2% 前後)

これまで並列化されていなかった部分も並列化(サブスレッド)。
これにより、Sandy-E / Ivy-E / Haswell-E などで、~25% 高速化。



サブスレッドの導入 (並列化されていなかった部分を並列化)



自動フィールドシフトはこれまでフレームを解析する部分(scan_frame)しか並列化されていなかった。トラックバーで設定できる「スレッド数」はこのscan_frame部分のスレッド数に相当する(afs メインスレッド数)。

これは(以前の開発環境では)他の部分がメモリアクセス中心の処理のため、並列化してもあまり速度が上がらないため。

ところが、以前測定したように、5960XなどQuad-Channelな環境では、マルチスレッドにしても比較的よくメモリ帯域が伸びていく。

ということは、たとえメモリアクセス中心の処理だったとしても、こういう環境では速度があがるんじゃないかなと思ったので、scan_frame以外の部分の並列化を行う「サブスレッド」を導入して、速度を測った。



環境
Aviutl 1.00
Win8.1 x64
MPEG2 1920x1080i, 29.97fps, 10240frames
m2v.aui 0.7.5a

Core i7 4770K Core 3.9GHz / UnCore 3.9Ghz, DDR3-2600, 2ch, 16GB
Core i7 5960X Core 4.4GHz / UnCore 4.0GHz, DDR4-2666, 4ch, 32GB

afs設定
映画/アニメ プリセット、(scan_frame)スレッド数 16



測定するときには、自動フィールドシフト設定画面のトラックバーにある「スレッド数」(下の図で灰色のscan_frame部分のスレ数)は16にしたまま、今回導入したサブスレッド(灰色のところ以外の並列数)を1~4まで変化させて測った。

1フレーム平均所要時間 [メインスレッド数: 16 固定] (+14 / +16 (サブスレッド数: 1~4))
afs_16_speedup.png

scan_frame部分(灰色)のスレッド数は変わらないので、当然その部分の速度は前と(ほぼ)変わらない。

5960Xでは、サブスレッドを増やしていくと、他の部分が高速化され、所要時間が大幅に短縮されていくのがわかる。サブスレッド数を1(並列化なし)から2並列にすると25%近く高速化し、その後も少しづつ速くなっている。

一方、4770Kでは、サブスレッドを1から2に増やしても所要時間の短縮はほんのすこしで、さらにサブスレッド数を増やすと今度は逆に遅くなっていってしまう。



5960Xではサブスレッド数を2にするだけで大きな効果があるので、4770Kとのバランスも考えて、公開版ではサブスレッド数を"2"にしてある。

大きな効果があるのを確認したのはHaswell-Eだけだけど、似たような傾向にあるSandy-E, Ivy-Eでも効果があるんじゃないかと思う。



あと、HayatePP様にご提案いただいて、今回からafsで使うバッファ用のメモリを16フレーム分一気に取るのではなく、フレームごとに取るようにして、メモリ確保の失敗の回避を試みている。メモリの断片化のせいで、まとまったメモリ確保に失敗することがあり、細かく確保することでこれを回避しやすくなる、と教えていただいた。

指摘していただきありがとうございます。

メモリの確保は初期化時にしか行わないので、メモリ確保回数が増えることで遅くなることは考えなくても良さそう。

こちらの環境では意図的にメモリを食いつぶすなどしないとメモリ確保失敗は起こらないので、わたしには効果の程はよくわからないけれど、メモリ確保失敗が起こりにくくなっていればと思う。

あと64bitOSなら、Aviutlの設定でLargeAddressAwareにチェックを入れていただければ、さらに発生しにくくなるかと。



ダウンロード>> (skydrive) (dropbox)



スポンサーサイト

コメントの投稿

非公開コメント

お暇があれば・・・

配布元が半閉鎖状態になって久しい l-smash works の件なのですが、このプラグインを使って読み込ませた場合、フレームレートがおかしくなる問題とx264gui exとの組み合わせで出力が正常に行われない場合があるのですが、l-smash worksを お暇があれば一度見ていただけないでしょうか?

主な症状:
・29.97fps映像(30000/1001)の場合、29.97fps未満になる(aviutl側のシステム設定でfps調整して対処)
・23.976fps映像(24000/1001)の場合、23.976未満になる。(対応策なし)

fpsが微妙に少なくなるのでBDAV/BDMVなどの規格に合わせることが出来ないのと、元のfpsと異なるので映像も微妙におかしく・・・

よろしくお願いします。

Re: お暇があれば・・・

現在のlwinput.auiはtsについても(dropなどなければ)fps誤爆はとても少ないと思っています。最近はm2v.aui(0.7.5a)+aacfaw.auiばかり使っているので試していませんでしたが、試しにtsを40ファイルほど読み込みテストしてみたところ、fpsはすべて30000/1001と正しく算出されました。

他の形式についてもmkv以外、ほとんど正常にfps算出されると思いますが…。

Re: お暇があれば・・・

的外れでしたら申し訳ないのですが、○○○さんは特定の放送局で放映された番組の事を言っているのではないかと思います。

当方もこの問題に直面しましたがlwinput.auiでfpsが正確に読み込めない放送局があります。
(BSジャパン、Dlife、BSアニマックス、AT-Xなど)

当方は現在はm2v入力編集に切り替えましたが、久しぶりにlwinput.auiでBSジャパン(カードファイトヴァンガードG)、Dlife(進撃の巨人)、BSアニマックス(空の境界)を入力してみると以前と同じく29.97fps未満のファイル情報となり、それに伴い番組の後半に行くほど動画と音声がズレて行きます。

m2v入力編集に切り替えて日が浅く、当方ではまだまだ検証不足(BSジャパンやDlifeの番組を編集した事がない)ですが、そちらも解決策の一つではないかと思います。

No title

どうでも良いけどRFFじゃないの?
ファイル>環境設定>入力プラグインの設定>L-SMASH(以下略

ここのApply repeat flagにチェックを入れてOKを押して設定を適用。その後Aviutl自体を再起動して読み込んでみる。
すると30000/1001と同等か限りなく近いfpsになる。
少しズレるのは仕様のようなものだから
編集>再生速度の情報を変更
ここから30000/1001として綺麗に合わせる。

この再生速度の情報を変更は23.976(24000/1001)に微調整するときにも使える
ちなみにシステムの設定の29.97に近いものは・・・は個人的に地雷だと思う

最後にL-SMASH Worksはrigaya氏本人とは一切関係ないのでここに書き込むのは筋違いかと
自分も返答として書き込んでますが・・・

あんま書きたくなかったんだけど

L-SMASH Works rev731はAT-X (SD)のサンプルの提供によりNTSCでのfpsの検出精度を向上させました。
AT-Xソースのケースでしたら、Apply repeat flagを有効にした上で、試していただけたらと思います。

自動フィールドシフト

rigaya様、
私の提案を採用してくださいましてありがとうございます。
私はrigaya様が高速化されていないオリジナル版を、自身で改良して使用しておりましたが、rigaya様の高速化版をそのまま使用できるようになればありがたいです。

その後のテストで、私の環境では解析用のCacheでも同様にMemoryがAllocateできない場合があることが確認されました。解析用のCacheはSourceCacheの半分程度の容量でして、めったにAllocに失敗しませんが、バッチ処理でExportを繰り返した場合にAllocationErrorが発生する場合が確認されました。
SourceCache同様に、分割してAllocateする対処が可能で、この対処によって私の環境では以降自動フィールドシフトのErrorは観測されなくなりましたのでお知らせしておきます。
更新される機会がございましたら、SourceCacheの対処も行っていただければ幸いです。

Re: 自動フィールドシフト

確認させていただきたいのですが、解析用キャッシュの確保失敗は今回の高速化版+16でも発生するという理解でよろしいのでしょうか。

というのも+16(今回の更新)では解析用キャッシュについても少し考慮して、2分割で取るように変更してあります。具体的には、fullHDだと一気に約48MB確保していたものを、約32MB + 約16MBに分けて確保するように変更しており、これで大丈夫かなと思っていた次第です。

自動フィールドシフト

rigaya様、
お世話になっております。

> 解析用キャッシュの確保失敗は今回の高速化版+16でも発生するという理解でよろしいのでしょうか。

すいません。今回の高速化版ではまだ十分な検証はできておりません。
私の作成したテスト版で、前回rigaya様にお知らせしました後で、何日間か使用しまして、SourceCacheだけでは不十分であることに気づいた次第です。

メモリを2分割されたということですので、おそらく問題の発生確率はぐっと減ったと思います。
しかしながら、まだ32MBのBlockが残るのであれば、私の環境では問題が再現するかもしれません。私の環境では25MBのAllocに失敗したログが残っていますので。

メモリブロックのガベージをできるだけ減らすという観点からもできるだけ小さな単位でAllocしたほうが良いかと思います。
私のテストではFrame単位に分割し、SourceCacheは16分割、解析用Cacheは24分割しました。

Re: 自動フィールドシフト

解析用キャッシュ分割しました(@ 高速化版+17, http://rigaya34589.blog135.fc2.com/blog-entry-548.html)。

お試しいただければと思います。

No title

ありがとうございます。本日より使用させていただきます。
プロフィール

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先(@を半角にしてください!)
rigaya34589@live.jp
github

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

○Aviutlプラグイン
x264guiEx 2.xx (ミラー)
- x264を使用したH264出力
- x264guiExの導入>
- x264.exeはこちら>

x265guiEx (ミラー)
- x265を使用したH.265/HEVC出力
- x265.exeはこちら>

QSVEnc + QSVEncC (ミラー)
- QuickSyncVideoによるH264出力
- QSVEncCはコマンドライン版
- QSVEncC 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC (ミラー)
- NVIDIAのNVEncによるH264出力
- NVEncCオプション一覧>

VCEEnc + VCEEncC (ミラー)
- AMDのVCEによるH.264出力

ffmpegOut (ミラー)
- ffmpeg/avconvを使用した出力

自動フィールドシフト (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: aji様

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

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

PMD_MT (ミラー)
- SSE2~FMA3による高速化版
- オリジナル: スレ48≫989氏

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

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

○その他
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 (ミラー)

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

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

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