AviSynth＆MVToolsによるフレーム補間

フレーム補間とは、ぬるぬる化である。

一般的に動画は30fps(1秒間に30枚の静止画)や29.97fps
もしくはそれ以下のフレームレートが用いられていることが多い。
フレーム補間ではこういった動画のフレームの間に新たなフレームを計算して作り出しフレームレートを上げることで、
より滑らかな動きの動画にすることが可能である。大体60fps化されることが多い。

ちなみに30fpsなどの動画を60fpsなどにしてエンコードしただけでは
再生負荷が高まるだけでぬるぬるにはならない。フレーム補間には専用のプラグインが必要である。

（ニコニコ大百科記事より）


導入方法はこちらのブログの記事がわかりやすいです。



こういう動画が需要あるかどうかは別として、
興味があったので色々と試行錯誤してみた経緯などをストレージしておこうと思います。





■フレーム補間のメリット
動きが滑らかに見える（ぬるぬるするという表現の方が正しい）
同程度のBPPが確保出来ていれば、同じ30fpsの動画に比べて高画質に見える（停止中を除く）

既に見たことのある動画が（うまくいけば）全然違った印象になって楽しいです。
昔のフレームレートが低いソースとかでやって視聴すると感動するかもしれません。


■フレーム補間のデメリット
何よりもファイルサイズの肥大化。
30fpsが60fpsになれば、単純にデータの量も二倍になります。

同じ画質を維持するために、ビットレートも倍必要です
h.264の場合、倍までは必要ありませんが、同じビットレートだと結構劣化します。
アップロード目的でサイズ制限などがある場合、
ビットレートを満足に振れない結果として30fpsのものより画質が悪くなる可能性が高いです。

当然、30fps→60fpsとなることで再生負荷も倍増します。
SD解像度の60fpsなら、一昔前のデュアルコアCPUでも何とかなりますが、
（それでもGPUがショボイorオンボードだとコマ落ちが起きるので厳しい）
HD以上となると再生できる環境を選びます。
フレームサイズに対してCPU（GPU）の性能が足りな過ぎるとコマ落ちしまくりで本末転倒。

また、ソースの向き不向きの差が大きいことには要注意。
そもそも動きがほとんどないような動画だと容量が増えるだけで意味がありません。
元からボケボケな映像、ブラーがかかっているようなシーンにもあまり効果がありません。

動きが単純な方が効果がわかりやすいです。
スクロールとかワイプのようなものに対してはメチャメチャ強力です。
最たる例がエロゲーのムービー。
ただ、色の変化については大して違いがわかりません。

あと、補間の設定はスクリプトを書いて行うのですがこれが厄介でして。
MVToolsのフレーム補間は、動きや色の変化が激しい部分ではブロックノイズが発生します。

これは設定で減らすことが出来るのですが、
基本的には減らす方向に振るほどぬるぬる感がなくなるため妥協が必要です。
というか、どれだけノイズを減らす設定にしても抑制しきれないことがあります。
なのでソースの見極めと妥協が重要になります。
何も考えずにやると、ブロックノイズのせいで画質が悲惨になって逆効果です。

また、設定のコツなどを解説しているサイトは日本では皆無なので、
英語のわからない人だと暗中模索になってしまいます。



上が補間処理後、下は処理前です。
極端な例ですが、何も設定を考えずにやるとこうなってしまいます。
ブロックノイズは他のノイズに比べて誤魔化すのがかなり難儀というか、無理に近いですからね…。



それと一つ。MVToolsが作る補間フレームは決して完璧じゃありません。
MVToolsは物体の微妙な加減速や移動方向の変化まで計算してくれないからです。
AのフレームとBのフレームの差分の平均を取ってぼかしているようなイメージで、
シーンによってはかえって動きが不自然というか、不快に感じることが多々あります。

30fps前提で、絵として一枚一枚作られるアニメとかでは、
確かにぬるぬるにはなりますが、動き方が全然違うイメージに見えてしまう可能性もあります。
実験としてはアリですが、見せる目的でアニメをフレーム補間するのはオススメしません。

ちなみに、フレーム補間した動画は動画としては滑らかで美しくなりますが、
一時停止して静止画として見るのには向いてません。



というわけで、ぶっちゃけ問題のほうが目につきやすい書き方ですが、
それでも設定がうまく行った動画は見てて楽しいです。

いい加減にやられても見る側としては迷惑ですし、
投稿者の自己満足という側面も否定できませんが、
動画作成の一つの手法として追究していくには十分面白いかなと。




■スクリプトの記述について

記述方法の説明→http://avisynth.org.ru/mvtools/mvtools2.html（英語）


先に述べたように、日本語で丁寧に解説しているサイトはほとんどありません。
私も英語がわからない人なのですが、わかる範囲でちょっとだけ紹介します。

#記述例

AVIsource("#")#変換する動画のパスに書き換える
#ConvertToYUY2() #動画の色情報がRGB等の場合は最初の#を外す
SetMTMode(2)
super=MSuper(pel=1, hpad=0, vpad=0)
backward_1=MAnalyse(super, chroma=false, isb=true, blksize=32, blksizev=32, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1=MAnalyse(super, chroma=false, isb=false, blksize=32, blksizev=32, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=16, blksizev=16, searchparam=2, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=16, blksizev=16, searchparam=2, search=3)
backward_3 = MRecalculate(super, chroma=false, backward_2, blksize=8, blksizev=8, searchparam=1, search=3)
forward_3 = MRecalculate(super, chroma=false, forward_2, blksize=8, blksizev=8, searchparam=1, search=3)
MBlockFps(super, backward_3, forward_3, num=60, den=1, mode=0)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

MTモードというのは、確かマルチスレッドの設定です。
これでエラーが出る場合はおそらくAviSynthとかがマルチスレッドに対応していません。
よくわからなければ～MTmode～の記述は全部消しとけばいいです。


"pel"
動き予測の正確さ。設定できる値は1、2、4のいずれか。初期値は2。
1で1ピクセル、2で1/2ピクセル、4で1/4ピクセルの精度。
増やすと滑らかさを損ねずにブロックノイズが減少するが、エンコード負荷が飛躍的に増える。
また常に4にすればいいというわけでもないらしい。
2か4を推奨。

"blksize"&"blksizeV"
ブロックマッチング法で使用するブロックの横および縦(Vertical)のサイズ。
4、8（初期値）、16、32を指定できる。
大きくするとソース自体のノイズに影響されにくくなり、処理が軽くなるが、補間フレームの正確さが失われる。
16以下を推奨。フレームサイズが小さく良ソースならもっと低めにしていいかもしれない。

"searchparam"
動き予測方式に対する追加的パラメータ。デフォルトは2。
このスクリプトでは下げるとブロックノイズが減るが、滑らかさが失われる。
2～3程度を推奨。

"search""
動き予測方式。0～7の指定した値に応じて予測方式が変わる。
上と合わせてx264の動き予測オプションみたいなもの？
3はx264のExhaustive search、デフォルトの4はHexagonal searchに相当するらしい。

"plevel"
penalty factor lambda level scaling mode…？調べたがわからなかった。
指定できる値は0、1、2。
デフォルトは0。2にするとブロックノイズが減るが、滑らかさが失われる。

"num"
目標とするフレームレート。30fps化なら30、60fps化するなら60を入力。

"mode"
これも調べたがよくわから（ｒｙ
0－5（5はデバッグ用）。初期値0。
2にするとエンコード負荷が増え、ブロックノイズが減るが、滑らかさが失われる。
0はエンコード負荷最小。


■その他知っておくとよさそうなこと
AviSynthに読み込ませる動画は、リサイズフィルタで可能な限りアップスケーリングしておくと、
ブロックノイズが控えめの綺麗な補間フレームを作ってくれます。
（ただしそれなりに状態の良いソース限定です）
もちろん処理は重くなるので、妥協点をうまく探して下さい。



とりあえずソースを見ながら上で挙げた部分を弄る感じになると思います。
こんな有様なので、ここはこうじゃない？などの情報提供は大歓迎でございます。



↓実験例を集めたマイリストです（自分のと他の方のを一緒にしています）