ちりとまとチャンネル

チリトマト好きがゲームや動画などについて取り扱っています
トップ → 2011年11月

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

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"
これも調べたがよくわから(ry
0-5(5はデバッグ用)。初期値0。
2にするとエンコード負荷が増え、ブロックノイズが減るが、滑らかさが失われる。
0はエンコード負荷最小。


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



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



↓実験例を集めたマイリストです(自分のと他の方のを一緒にしています)
スポンサーサイト

BPPで目標とする画質ごとの最適ビットレートを計算してみる

ニコ動は一般会員だとビットレートは600Kbpsまでしか指定できません。
プレミアムだとビットレートは無制限ですが、うpできるファイルサイズが100MB以下なので、
それなりに再生時間のある動画だと、結局のところ

ビットレート→サイズ制限ギリギリの量を指定


という感じになることが多いです。

2~3分程度なら4000~5000Kbpsという贅沢な値を指定できますが、
上げすぎるとシークバーの溜まりが遅くなって再生途中で止まります。
しかも、ニコ動の標準解像度(512x384や640x360)だと、
画質は大して変わらないのに無駄に重くなってるという可能性が高いです。


そこでアップロード制限は置いといて、どれくらいビットレートを振ればいいのか
(これ以上増やしても画質が変わりにくく、重くなるだけというライン)を考えてみる。


しかしネット上でその線の情報を調べても、
保存用途が前提でありったけ高いビットレートを推奨していたり、
「この解像度ならこれくらいあれば綺麗に見える」という主観的な情報が多くて悩みました。



そんな時に、よさげなものが見つかったのでご紹介。
http://service.jp.real.com/help/faq/prod/faq_4226.html


BPPとは Bits Per Pixel(ピクセルあたりのビット数)、
つまり1ピクセルにどれくらいビット数を割り振るかを意味します。


サイズとフレームレートが決まっている場合、

ビットレート = BPP × フレームレート × 幅 × 高さ

という計算式を使うことで、自分が望む画質を得るにはどれくらいビットレートを振ればいいかがわかります。
BPPには下の表のような数値を当てはめます。

動作品質
最高
高度0.2250.1750.1250.100
中度0.2000.1500.1000.075
低度0.1750.1250.0750.050

動作は映像の動きの激しさで、この表では以下のように分けられます。

高度-スポーツやミュージックビデオ
中度-映画
低度-ニュースなど


例えば、映画をHDかつ最高品質でエンコードする場合、

ビットレート = 0.2 × 30 × 1366 × 768 = 6294528 となり、

目的の画質を得るためにはビットレートが約6300Kbps必要になると考えられます。



ここまでなら同じような内容を載せているページは結構あります。
それじゃあ、ニコ動くらいのスケールではどうなるんだ?という話をこれから致します。

よくありそうな設定では、ゲームのプレイ動画を16:9サイズかつそこそこの画質でアップしたい場合、

0.1×30×640×360=691200 →約690kbpsが必要です。

つまり、一般会員の制限である600kbpsでは正直苦しいです。
(実際は656kbpsとすると、音声に80kbpsは使うとして映像部は最大でも560~570kbps程度)
そんなに動かず、グラフィックがシンプルとかなら十分な画質になるかもしれませんが、
アクション、特にFPSとかだとキツイです。


もっともh264はそれ以前のコーデックより性能がいいので、
そこまでこの表のBPP値を真に受けなくても大丈夫です。
動きが多いか少ないか、アニメか実写かでも結構違います。

プレミアムに関しては、BPP=0.12前後(640x360で830kbpsくらい)あれば十分な画質になります。
動きの激しいアクションやFPS、弾幕ゲーとかだとBPP=0.14~0.15(1000kbpsくらい)、
極端なケースだともっと必要かもしれません(MHP3のラスボスとか)


ひたすら高画質にしたい!という場合、BPP=0.165程度として
・512x384なら970Kbps(音声96Kbpsで13分)
・640x360なら1140Kbps(音声96Kbpsで11分)

くらいを目標にするといいでしょう。
それでもまだビットレートに余裕があって画質が不満なら、
あとはご自身の目で確認しながら満足するまでビットレートを振って下さい。



最近はニコ動のプレイヤーの標準解像度より大きい動画も増えてきたので、そっちにも触れてみる。


ニコ動のプレイヤーが通常モードで等倍表示できるのは、アス比4:3で512x384、16:9で640x360(か384)。
それよりデカいサイズとなると、基本的にはフルスクリーン表示での視聴が前提となります。

当然ながら解像度を上げるほど、画質を維持するのに必要なビットレートは増えます。
そしてビットレートを増やしすぎると、
サーバからの読み込みが遅くなって再生が止まり止まりになります。
1500Kbpsくらいなら大概は安定しますが、休日の10時~12時とかだとこれでもキツイかったりします。

最も混雑する数時間さえ避けてスムーズに再生出来るならいい!というのであれば、
人と時間帯にもよりますが4000Kbpsでも行けないことはないです。

フルスクリーン再生を前提とする動画は、高画質を売りにしたい場合が大半なので、
むしろ多少のリスクを負ってもそれくらいのビットレートは指定していいかもしれません。


いずれにせよ解像度とビットレートを上げすぎるとフルスクリーン表示でコマ落ちが発生したり、
再生中で止まったりと害も多くなるので、限度があります。

HDサイズの場合 BPP=0.13 すなわち、

0.13 × 30 × 1366 × 768 = 4091443.2 →約4090Kbps

この辺りを限度にしといたほうがいいでしょう。

よほど動画にコダワリがあるとか、視聴者のPC性能を試したいとか、ベンチマーク上等ォ!
という場合を除き、これ以上はやらないほうがいいです。


実際はフルHD(1920x1080)の動画もニコ動には上がっていますが、
フルHDは同じ品質を維持する場合、HDに対して二倍ものビットレートが必要であり、
BPP=0.1の並品質ですら6000kbps以上というシャレにならないビットレートを要求されます。

マトモに再生できない環境&時間帯のほうがおそらく多くなるので、
実験とかベンチマークでない限り解像度はHD程度で留めておくほうが無難です。
エンコードする方も相当キツイですからね…。

ニコニコ動画向け記事まとめ

・ニコニコ動画まとめwiki(http://nicowiki.com/
動画サイト向け動画の作成方法はこちら

・VIPで初心者がゲーム実況するには@wiki(http://www18.atwiki.jp/live2ch/
ゲーム映像の生放送、動画の作成方法はこちら

・上記サイト内 キャプチャーについての総説(http://www18.atwiki.jp/live2ch/pages/266.html


エンコードオプションについてはこちらが参考になります。
拡張 x264 出力(GUI)Exの設定項目とその機能について
魔道学研究所 動画エンコード ニコニコ動画 2011ねん9がつごう

この辺りを抑えることが出来れば、とりあえず立派に投稿するところまでは行けると思います。
当ブログでは、動画作成についての記事は一通りエンコードと投稿のやり方がわかるという方向けに書く方針。



■関連記事

・AviUtl使用フィルタ紹介
 ノイズ除去系
 >NL-Means系
 リサイズ系
 輪郭補正系

【AviUtl】エラーとかへの対策メモ
BPPで目標とする画質ごとの最適ビットレートを計算してみる
h.264 Bフレーム設定に関する覚書
AviSynth&MVToolsによるフレーム補間
【AviUtl】NL-Means系フィルタの速度?
SSIMによる画質の個人的な目安(あまりアテにならないので非公開に)


あくまでメモを晒す以上の目的はないので、基本投げっぱなしです
質問に対しては私の知識の範囲内でしかお答えできませんのでご了承ください。



うp主の制作環境
(2012年10月現在)

OS : Windows 7 Home Premium 64bit Service Pack1
CPU : Intel Core i7-3770 3.40GHz
RAM : 8GB

キャプチャーデバイス : DC-HA1

録画ソフト:アマレコTV(utvideoコーデック使用)
編集ソフト:Aviutl version 0.99m/拡張編集プラグイン version 0.90d3
h264出力:拡張 x264 出力(GUI) Ex version 1.57

その他:
GIMP(画像切り抜き用)
SofTalk/棒読みちゃん(ゆっくりの声)
MediaInfo(エンコード設定を確認したい時)
bitrate viwer(ビットレート変動幅のチェック)


(2012年9月以前)

OS:Windows Vista Home Premium 32bit
CPU:Intel Core 2 Duo T7250 2GHz
メモリ:2GBx2(実質3GB)

使用キャプチャーボード
DN-UVC231C(PSP専用)
DN-UVC252C(据置ゲーム用、DC-HA1のおかげで完全レガシー化)

録画ソフト:アマレコTV(utvideoコーデック使用)
編集ソフト:Aviutl version 0.99i8/拡張編集プラグイン version 0.88b

その他:
GIMP(画像切り抜き用)
SofTalk/棒読みちゃん(ゆっくりの声)
MediaInfo(エンコード設定を確認したい時)
bitrate viwer(ビットレート変動幅のチェック)
AviSynth/MVTools2(フレーム補間60fps化用)

h264出力:拡張 x264 出力(GUI) Ex version 0.27
(最新版は1.18なので注意。バージョンアップHAEEE)


↓古いのでアテにしないで下さい。いい加減何とかしたい…


aviutlで使っているプラグインフィルタ


※はAviUtl標準フィルタ
系統/使用頻度常用状況に応じて使用検討中あまり使わない・使わなくなった
リサイズ系リサイズフィルタ超解像(テスト)Lanczos 3-lobed 拡大縮小
色補正系色調補正・改AviUtl標準※UVダウンサンプリング
色褪せ軽減β
ヒストグラム先鋭化2
ノイズ除去(NR)系

色差ノイズ除去
NL-Means Light

メディアンフィルタ差分保護
PMD MT
ノイズ除去(時間軸)※
輪郭補正系エッジレベル調整アンシャープマスクMT
スムージングフィルタ
WarpSharpMT
非線形先鋭化
シャープフィルタ※
輪郭保持平滑化
その他虫眼鏡
ノイズ表示
縞検出ジャンプ
インタレ縞低減++
拡大ツール
自動フィールドシフト

とりあえず常用のフィルタはかなりオススメ、むしろ必須級だと思ってます。
主に扱うソースがゲームやCGムービーなので、アニメエンコードでよく紹介されるものはあまり使いません。
というか使いこなせません。例としてはNLSとかWarpSharpとかバンディング低減とか。

ブログ改装オープンです

動画作成用のメモやブックマークの類がかなり溜まっていてまとめたかったのと、
これから動画やらゲームやらのためにブログを用意したいと思い始めました。

そこで、既に捨てられていたこのブログを軽~く作りなおして使おうと思ったわけです。

(当初、このブログは2009年からリリースされたアーマードコア・ポータブルシリーズがメインコンテンツでした)


昔を知っている方がおりましたら、どうかそれらの一切はお忘れ下さい。
(まだエントリーとして残してはいますけどね)


ということで、どうもニコ動の界隈で細々と生活しているチリトマト廃人です。
私に関することは右上のニコ動のところを見て察して下さい。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。