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

高速化版+8
もっと高速化。
afs_analyze_xxとafs_analyze_shrink_infoを統合

高速化版+7 (結局この時点では公開しなかった)
・VC++2012のWinXP互換ビルドに変更。
特に影響はないと思うけど、VS2012 Update1で利用可能になったので、念のため。

・popcntの確認をSSE4.2のフラグの有無で確認していたのを、正しくpopcntのフラグで確認するようにした。
AMD Phenom等における、「SSE4.2非対応だけどpopcntはある」ケースにも対応。

・メモリアクセスパターンを変更することで、HD映像処理向けの高速化。
詳細は続きに。

・AVX2対応の準備。
Haswell実機で確認後、AVX2対応版を公開できるかも?

x264のAVX2は意外と効果が小さいようで(+5%)残念だけど…afsはどうだろう…。まあ自分で試してみてなんぼですわな。

---

ダウンロード>>

---

続きに高速化の細かい話とか。

---

続きを読む

続きを閉じる

---

今回は、いくつかの関数のメモリアクセスパターンを変更した。

効果としては、
・主にHD映像において高速化が見込める。
・HDエンコ時に、自動フィールドシフト(afs) + QSVEnc + その他フィルタ無し、のようなエンコ時のafsの比重が非常に大きい場合、10～30%高速化。
・afs + x264guiEx + x264(preset=slow)だとx264の比率が大きいのでそんなでもない。ただ、afsがボトルネックとなり、CPUが遊んでいる場合には効果が大きく出ると思う。

---

afsには、メモリ空間に対し飛び飛びにアクセスする部分がある。こういった飛び飛びのアクセスは、非常に時間が掛かってしまう。

そもそも、(キャッシュに入っていない)メモリアクセスというのはとんでもなく遅い。メモリ上を飛び飛びにアクセスしていると特にひどい。

これに対し、オリジナルのafsでは、

・MMXの使用により、64bitまとめて処理
　　→64bitずつのアクセスになり、メモリアクセスの回数自体が減る。

により高速化していたし、さらにこれまでの高速化版では、

1. SSEの使用により、128bitずつ処理
2. prefetch命令の挿入により、必要になる飛び飛びのメモリの断片を明示的に先読み

して高速化していた。prefetch命令の挿入は非常に効果が大きかった(高速化の1/3ぐらいはprefetch命令のおかげだった)。

しかし、いくら先読みしているとはいっても、煩雑な飛び飛びのアクセスをしていることには変わりなく、根本的な解決にはなっていない。

今回の高速化版では、なるべく連続的なメモリアクセスをするようにプログラムを変更した。こうすることで、
・prefetch命令不要
・効率的なメモリアクセス
となり、さらに高速化できた。

HD映像で効果が強く、SD映像の場合にはそれほど効果がないように思う。

SD映像の場合は1フレームのデータが小さいので、フレーム全体がキャッシュに乗りやすい。キャッシュに乗ってさえいれば飛び飛びのメモリアクセスもどうということはないので、もともと高速に処理されていて、今回のメモリアクセスパターンの変更が大きな意味を持たないのかな、と思う。

参考:
L1キャッシュ = 32KB/core
L2キャッシュ = 256KB/core
L3キャッシュ = 8MB/CPU (Core i7 2xxx/3xxxの場合)
YC48 SD = 720x480x6 = 約2MB
YC48 HD = 1440x1080x6 = 約9MB
YC48 fullHD = 1920x1080x6 = 約12MB

---

QSVEnc 0.23

[共通]
・エンコード情報表示を改善。

[QSVEncC]
・AVI(vfw)読み込みに対応。

続きを読む

続きを閉じる

---

QSVEncCのAVI(vfw)読み込みについて

---

avi/avs/vpyなど、vfw経由で読み込めるものについて、直接読めるようにした。拡張子avi/avs/vpyで自動的にavi読み込みに切り替え。明示的な指定は--avi。

YV12/YUY2/RGB24/RGB32読み込み対応、YV12推奨。

YV12/YUY2読み込みについてはインタレ対応。一方、RGB24/RGB32読み込みはvppにてRGB32->NV12変換を行うため、インタレ非対応。

また、進捗状況と残り時間を表示。

---

もともとは、パイプを通さず、avsを直接読みこめば速くなるんじゃないかな～ということで作った。

が、速くない…、ごくわずかに速い気がするぐらい。

理由としては、
・実質的なメモリコピーの回数が減らない
・パイプによる遅れは入力バッファ + 先読みスレッドで遮蔽できていた
あたりかなあと思う。

結局avi読み込みの利点は、
・進捗状況、残り時間の表示
・avs2pipemodなどを用意せずに済む
といったあたり。うーん、しょぼい。実用的にはたいして変わらん…。

---

ちなみにavsを直接読ませる場合は、QSVEncC(x86)ならAvisynthも32bit、QSVEncC64(x64)ならAvisynthも64bitでなければならないので注意。基本的にIntel Media SDKはx86(32bit)のほうが高速だとSDKの自体に書かれているので、メモリ制限に引っかからない限り32bitのほうがいいと思う。

---

テスト動画に変猫のOP使い続けたら中毒になってしまった…

---

QSVEnc ダウンロード>>

---

QSVEnc 0.22

・vppによるインタレ解除にbob化(60fps化)を追加。
--vpp-deinterlace bob。

某所での要望の反映。vppで倍フレームレート化によるインタレ解除を行う。正常に動作していれば、これはGPU側で高速に処理される。

実際にやってみると…

- 解除性能はまあまあ。そんなに綺麗ではないし、もっと言えば全体的に雑。ただ、「全く使えない」レベルのvppの24fps化(it)よりは全然マシで、許容範囲内かなと思う。

- 当たり前だけど容量が膨らむ。

- GPU内でフレームレートが倍になるため、処理速度が跳ね上がる。結果GPU Boostもよりかかりやすくなると思う。


・最大GOP長を"0"とすることでfps×10を自動的に設定するようにした。

---

QSVEnc ダウンロード>>

---

QSVEnc 0.21

[QSVEnc]
・0.20より、映像一時ファイルが残ってしまう問題を修正。
ご指摘ありがとうございます。

[QSVEncC]
・y4m入力時にアスペクト比を読み取るようにした。

---

QSVEnc ダウンロード>>

---

QSVEncCの速度について

0.20で以前よりやや速くなった。

速度を出すには、とにかくGPUのクロックが最大まで上げる必要がある。GPU-Zで確認。いかにデコードからQSVEncCに渡すまでを速くするかを考えていただければと。

VapourSynth+L-SMASH Worksのdr=1で速度を出したい場合、VapourSynthでCropせず、QSVEncCのcropを使ったほうが高速。(例えば、1440x1088->1440x1080にしたい場合、QSVEncCで--crop 0,0,0,8とする)

---

QSVEnc 0.20

いろいろ細かく高速化のための調整と、要望の反映など。

続きを読む

続きを閉じる

[QSVEnc / QSVEncC 共通]
・HWエンコ時の入力フレームバッファのデフォルトを4→3。
3でも十分高速であるため。

・内部のパイプラインバッファ数を調整し、少し高速化。

[QSVEnc]
・yuy2→nv12変換を調整してわずかに高速化。

・x264guiEx 1.75までの更新を反映。
- mux時にディスクの空き容量の取得に失敗した場合でも、警告を出して続行するようにした。
- 設定画面で「デフォルト」をクリックした時の挙動を修正。
- 音声設定のパイプ - 2passのチェックボックスの挙動を修正。
- エンコ前後バッチ処理を最小化で実行する設定を追加。

[QSVEncC]
・フレーム読み込み時のyv12→nv12変換を調整して高速化。
わりと効くんじゃないかと。

・cropオプションを追加。
要望の反映。
--crop <int>,<int>,<int>,<int>
左、上、右、下の順で。例えば、1440x1088の下を切る場合、--crop 0,0,0,8 とする。

L-SMASH Worksを入力とし、dr=1で使用する場合、Cropが必要なことがある。このとき、VapourSynthのCropはあまり速くないので、QSVEncC側でCropできれば…ということだった。

>bob様
なるべく速度を意識して、読み込みながらCropするようにしましたが(vppのさらに前段階で処理してしまう)、いかがでしょうか? 試してみていただければと思います。あまり変わらないかもしれませんが…。

・エンコード後の結果表示が崩れていたのを修正。

---

もう一つの要望、「ログウィンドウをエンコ開始時に最前面に」は何故かうまく行かなかったので見送らせてください。すみません。

---

QSVEnc ダウンロード>>

---