2011年1月18日火曜日

AviSynth2.6.0α

さまざまな試行と思索(ってほどのものでもないが)の結果、現在の自分はAviSynth2.6.0α(32bit)を使っている。

Q.なぜ64bitAviSynthじゃないの?
A.いろいろ不具合が多い上に開発が止まっているから。
 開発が順調なら人柱覚悟で使ってバグレポートもするが、現状停止中でforkする人もいないでは使う甲斐がない。
 まあ、気長に待つしかないかなぁ。

Q.なんでMT使わないの?
A.SetMTMode()はとにかく不安定すぎる。
 しかも同じスクリプトでもクラッシュしたりしなかったりと運用で回避を図ろうにも傾向がつかめない。
 たとえ速くても、完走出来ないマラソンランナーは正選手にはなれないのである。
 MT()のほうはSetMTMode()ほどひどくはないが…。

Q.なんでstableな2.5.8ではなく、2.6.0αなの?
A.安定していて速いから。

そう、2.6.0αはまだアルファなのに安定している。
どれくらい安定しているかといえば、既知の問題がα2公開後1年以上経つのにこの程度しかないくらい堅い。
しかも2.5.8に存在するバグもいくつか取れている。(これではどちらがstableなのかと小一時間…)

そして速い。 2.5.8->2.6.0の最適化の進み具合はすさまじい。 例えば次のようなベンチマークをしてみるとよくわかる。
#benchmark.avs
ImageReader("test_1280x720.bmp", 0, 999)
BlackmanResize(720, 480)
Spline64Resize(1920, 1080)
GaussResize(512, 384)

$ for i in {1..3}; do avs2avi benchmark.avs -c null -o n; done
これを2.5.8と2.6.0αでやってみると結果は
              2.5.8                   2.6.0α
1st   00:02:26.256(6.84fps)    00:01:10.753(14.13fps)
2nd   00:02:26.256(6.84fps)    00:01:10.764(14.13fps)
3rd   00:02:26.257(6.84fps)    00:01:10.753(14.13fps)  (CPU使用率はすべて30%弱)
特に重めなresizerをRGB32でかけた結果がこれである。
たまに高速化のためと称してMT()使って縦横別々にリサイズとかしてる人を見かけるけど、そんなもの手間をかけて無駄にCPU使用率を上げているだけですな。

2.6.0αはMT対応はしていないが、それ自体は高速である。
問題はプラグインのほうで、これがボトルネックになるわけだが…でもその場合はCPU自体はそれほど使ってないよね?
CPUに余裕があるなら同時に複数本走らせればいいだけだ。
この場合、1本あたりのスピードは低下してしまうが、3本同時にやれば終了するまでにかかる時間は1本ずつ3本エンコするのと比べてだいたい半分程度にはなるだろう。
1本あたり最大2GBのメモリを使うことになるが(pipeを使えばもう少し増える)、自分の環境は64bitOSで8GBつんでいるので、まだ余裕はある。
・スピードが結果的に倍程度まであがり
・CPUを無駄なく使い
・安定した出力を得られ
・互換性も特に気にする必要がない

現状ではやはりこれが一番いいんじゃないかなぁ。

0 件のコメント:

コメントを投稿