rigayaの日記兼メモ帳

---

この問題は拡張編集を使用しているときに、誤って(拡張編集のタイムラインにではなく、)Aviutl本体側に音声を読み込ませてしまうと発生する場合があります。これは、拡張編集側の音声よりも、Aviutl本体側の音声が優先されてしまうためです。

この問題は出力プラグイン側では対処のしようのない問題のため、これまでこうした場合でも可能な限りエンコードを続行するようにしていました。しかし、実際のところ、長い時間をかけて映像エンコードが終わった後、意図した出力にならない場合がほとんどで、時間が無駄になっていました。

そこで、今回はこの問題を検出した場合には、エンコード開始時に下記メッセージを表示し、ユーザーに対処を促すようにしました。

一応、「いいえ」を選んでこれまで通り処理を継続することも可能ですが、おすすめはできません。



処理中断後、拡張編集のシーンを下の図のように一度切り替えて戻すと、再び拡張編集の音声が有効になり、再出力することで問題が解消する場合があります。(このあたりはx264guiExエラー集にも追記しました。)




ただ、拡張編集側の音声のサンプリングレートとAviutl本体側の音声のサンプリングレートが異なる場合には、これで解決できない場合もあります。

拡張編集使用時には、Aviutl本体側に音声を読み込まないようにご注意いただければと思います。

---

なお、バッチ出力中にはダイアログにより処理を中断するのは好ましくないので、ダイアログは表示されず、ログにエラーメッセージを表示してすぐにエラー終了します。

---

※x264guiEx 3.00から導入方法が変更されていますのでご注意ください。

ダウンロード>>

x264guiEx 3.xxの導入方法
x264guiExのエラーと対処方法

---

---

もう一つの課題というのは、KFMSwitchのis120オプションの問題。

現行のAmatsukaze付属のKFMDeint.avsiにはis120というオプションがあり、KFMSwitchなる関数でこれを指定していて、これは120fps精度でtimestampを計算するオプションになっている。

が、ソースコード(AviSynthCUDAFiltersのほう)のKFMSwitchのほうにはis120オプションがないため、これをコンパイルしてもエラーで終了してしまう。

AviSynthCUDAFiltersのほうのKFMDeint.avsiにはたしかにis120オプションはないので、どこかにタイミングでAmatsukaze付属のものだけ更新されたのかもしれないが、なんともいえない。

ということで、出力されるtimecodeの様子を見ながら、is120の動作を再現するコードを実装してみた。

いまのところ、ある程度はちゃんと動いているようで、オリジナルの実装と「ほぼ」同じtimecodeを出力できるようになった。

「ほぼ」というのは、多少の差はあるということで、24p⇔30p/60p区間の切り替わりのところで、1/120sずれることがあるのだけど、個人的には元の実装が完全にはわからないので、許容範囲内かなあという感じ。

---

ということで、とりあえずコンパイルしたものが使える状態にはなった。

ただ、それだけで特になにか変わったとかはないので、当面特に自ビルド版を使う必要はなさそう。

---

vpp-afsを高速化

---

まず効果はこんな感じで、vpp-afsで1440x1080の平均処理時間が高速化した。

	NVEnc 7.46	NVEnc 7.47
RTX4080	198.4 us	170.1 us
GTX1060	793.2 us	533.0 us

まあそれなりに速くはなっているけど、もともと十分高速なので、実際のエンコードで今回の高速化の効果を感じることはほぼないと思う。(フィルタよりエンコードのほうが遅いので)

---

やったことはシンプルで、GPUコードで絶対値を取る時にstd::absを使っていたのをfabsに置き換えただけ。

---

きっかけ

---

Nsight Computeでプロファイルを取って、実行した命令をみると、なぜか使った記憶のないFP64というのが紛れ込んでいた。

プロファイルを取ってkernel(CUDAの関数)の様子を見るとこんな感じだった。Compute Throughtputが妙に高く、Memory Throughputが妙に低い。



Compute Workload Analysisを見ると、なぜかFP64が上位にいる。使った記憶ないのに…。GeForceでFP64はとても遅いので、もちろん必要もないのに使うべきではない。



念のため、Memory Workloadも見てみると、Texture, shared memoryをちゃんと使えているが、あまり負荷は高くなさそうだ(Busyの値が低い)。処理の性質的に、もう少し高くてもよさそうだが…?



使用した命令の内訳。afsはビット演算を多用するのでLOP3は妥当、アドレス計算等で使うIMADも妥当。よくわからないのは上のほうにいるF2Fである。



SASSでF2Fがどこで使われているかを見ると、analyze_motion/analyze_stripeという関数の部分で使われていた。



試しにanalyze_motionを見ると、おそらくstd::absだろうなあ、と思いいたった。



std::absは引数がfloatの場合はfloatのオーバーロードが使われるはずだが、GPUコードだし、うまく解決されなかったのかなという感じ。まあ、そもそもデバイス用のfabsを使用すべきだ、ということでfabsに変更した。

---

変更後

---

変更後はkernelの実行時間が164.5usから51.2usに大幅に高速化した。

また、Compute Throughputが下がり、Memory Throughputが上がった。処理内容的に、このぐらいのほうが妥当なように思う。



Compute Workload Analysisを見ると、謎のFP64がなくなり、うまくいったことがわかる。



Memory Workloadも見てみると、転送量は変わらないが、kernelの処理時間が短くなったことで、Busyの割合が増加した。



使用した命令の内訳からはF2Fがなくなった。



実際に、analyze_motionの箇所を見ても、F2Fは発行されていないことがわかる。

---

ということで今回は本当に簡単なミスでGPU kernel(関数)の処理速度が全く違ってしまうという例だった(kernel単位でみると3倍高速化している)。GeForceでFP64関連命令は圧倒的に遅く完全に地雷なので可能な限り避けるべきで、今回はそれがちゃんとできていなかった。

ただ、一応ちゃんと動いてしまう分、正直見つけるのは簡単ではないようにも思う。今回みたくプロファイラでチェックしてみるのもたまにはいいかもしれない。

---

各フィルタの速度

---

参考までに1920x1080でのNVEncの主要フィルタの1フレーム当たりの平均処理時間(us)を確認してみた。フィルタの速度はパラメータでも大きく変わるけど、ここでは全部デフォルトで比較した。

GPUはRTX4080, GTX1080, GTX1060。

　　　　　フィルタ平均処理時間[単位:us]
　　　　　　1920x1080 YV12 8bit

	RTX4080	GTX1080	GTX1060
colorspace	82.9	221.3	441.9
cspconv	19.9	51.6	86.6
afs	224.2	355.8	658.6
nnedi	794.1	2312.7	4499.1
yadif	142.3	252.2	487.1
transform	23.5	42.5	77.3
convolution3d	73.0	237.1	482.6
smooth	229.3	821.6	1682.8
denoise-dct	852.7	3238.8	6113.4
knn	233.9	606.9	1267.9
pmd	229.3	562.4	1136.8
resize(720p)	142.8	611.1	1297.4
resize(1440p)	525.3	2394.7	5064.5
edgelevel	58.9	155.5	215.5
warpsharp	146.4	479.9	974.8
curves	45.9	165.6	276.3
tweak	8.3	24.0	46.6
deband	60.0	127.1	215.3
cspconv	22.4	39.3	68.0

フィルタごとの速度差とか、GPUごとの速度差がなんとなくわかると思う。

---

※NVEnc 6.00から導入方法が変更されていますのでご注意ください。
※Aviutl向けには、Aviutl_NVEnc_7.xx.zip をダウンロードしてください。
ダウンロード>>

NVEncの導入
NVEncCオプション一覧>

---

---

CrystalDiskInfoの表示。24000GB、一台のディスクとしてはほんとにすごい容量。

なお、Windowsからは22352GBとして認識される。



ベンチマーク結果(1GB)↓。278MB/sと、まあSSDベンチマークを見慣れるととても遅いが、HDDとしてはかなり高速。本当に少しづつだけど、大容量化とともに速度も上がってきている。

とはいえ、容量の増加には全く追いついていないので、278MB/sが維持できてもこれ1台全部書くのに23時間ぐらいかかる…。



キャッシュが512MBもあるので、64GBでのベンチマーク結果。RND4Kがちょっと下がる感じ。

---

参考までにこれまでのデータまとめ。

容量	メーカー	型番	Seq. Read	表	裏	info	bench
320GB	SA	HD321KJ	63.7	*	*	*	*
500GB	H	HDP725050GLA360	93.9	*	*	*	*
500GB	H	HDP725050GLA360						カッコンして死亡
1TB	WD	WD10EACS_00ZJB0	80.9	*	*	*	*	不良セクタ増
1TB	WD	WD10EACS_00ZJB0						不良セクタ増で死亡
1.5TB	WD	WD15WARS_00Z5B1	96.9	*	*	*	*
1.5TB	SA	HD154UI	114.6	*	*	*	*
2TB	H	HDS722020ALA300	132.9	*	*	*	*
2TB	H	HDS723020BLA642	149.0	*	*	*	*
2TB	H	HDS723020BLA642	172.4	*	*	*	*
2TB	H	HDS723020BLA642	172.4	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	120.6	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	118.8	*	*	*	*
2TB	WD	WD20EARS_00MVWB0	126.7	*	*	*	*
3TB	H	HDS723030ALA640	155.3	*	*	*	*
4TB	H	HDS724040ALE640	169.6	*	*	*	*	不良セクタ増
4TB	H	HDS724040ALE640		*	*
4TB	H	HDS724040ALE640		*	*
4TB	H	HDS724040ALE640		*	*
5TB	T	MD04ACA500	196.7			*	*
6TB	H	HDN726060ALE610	226.9	*	*	*	*
6TB	T	MD04ACA600	196.7	*	*	*	*
10TB	H	HUH721010ALE600	245.7			*	*
10TB	WD	WD100EFAX_6BLHPN0	202.8	*		*	*
14TB	T	MN07ACA14T	237.6	*	*	*	*
14TB	WD	WUH721414ALE6L4	265.4	*	*	*	*
24TB	WD	WD241KRYZ	277.9	*	*	*	*

H ... HGST / WD ... WesternDigital / T ... Toshiba / SA ... Samsung