mcdeint　ageha was here

MEncoderマニュアルの説明

---

mcdeint=[mode[:parity[:qp]]] 
動き補償デインターレーサ。
１フレームにつき１フィールドの入力が必要となるので、tfields=1 や yadif=1/3、または同等のものと一緒に使う必要がある。

<mode>

0: 高速
1: ミディアム
2: 低速, 反復動き予測
3: 超低速、複数参照フレームを２以上にしたのと同等。

<parity>

0 または1でどちらのフィールドを使うかを指定（note:自動検出はまだ無い！）

<qp>

高い値ほどモーションベクトルがスムースになるが、個々のベクトルは最適ではなくなる。

開発者、Michael's Niedermayerによる解説

---

mcdeint は “missing” line を埋める為に動き予測と動き補償をやる。
うまく動き予測をするには、元になる映像が要る。
単純に奇数/偶数ラインを使う手も試したがうまくいか なかった。単純にフレームレートを倍増させるデインターレーサですら、mcdeintの後では向上が見られた。

mcdeint はオーバーラップド・ブロック・ベースの動き予測と動き補償を使う。このコードはsnowのコードから持って来た。だから、snowに進展があれば自動的にmcdeintも進化する。

mcdeint=0 ：オーバーラップド・ブロック予測/補償を使わない。16×16 blockの 1/4精度。
mcdeint=1 ：8×8 blockサポートを追加、予測ゾーンサーチのダイヤモンド・サイズを拡大。
mcdeint=2 ：反復的オーバーラップド・ブロック・ベースの動き予測と動き補償
mcdeint=3 ：複数参照（＊multiple reference frames＊）を追加

Comment by Michael — June 21, 2006 @ 19:16

左は料理番組の冒頭でCGのタイトルが出るシーン。 　赤い球体が画面に侵入してくるが、図の通り縞がある。コマ送りで見ても縞の消える瞬間が無い。中華鍋を振る料理人の手も同様。どちらも1/60秒の間にこれだけ動いてると言う事だ。 　CG製作の時点でこうしたシマシマデータを作るわけが無いので（できなくは無いが無駄）、TV用に合成する段階で切り刻まれている。コックさんが「物理的にこういう手の人」だったという可能性も無くは無いが稀であろう。 　左図は59.95HzのTVカメラで撮ったインター レースド・フィールドを2枚、同時に表示している。 　 もともとTVカメラの走査線は一本飛ばしで映像を捉える。空間軸画質を最初から大胆に間引いてあるのだ。パソコンの言い方で言うと、解像度が 720x480あったとしても、一枚のフィールド上の実データは720x240しか存在しない。もしも正確にフィールドだけを表示できるなら、ブラインド越しに見たような絵しかでてこないハズだ。これが上で言う"missing" lineの意味。 　インタレ解除の本質は「失われたデータの復元」ではなく「もともとこの世に存在しないデータのでっち上げ」。 　これに対して逆テレシネは「もともとのフィルム上にあったハズのデータだけを拾い集めてあとは捨てる」。 　ホントは別モノ。 　 余談ながら、インターレースはもともとブラウン管の構造に則したしかけ。電子銃による管面走査機構のない機械に余分な機構を強いる。これは液晶、PDP、 SEDを問わない。高柳健次郎博士御存命なれば、地デジ規格は断然 1080p/720p@30fps以上を主張されたであろう。

-vf yadif=3,mcdeint,framestep=2 -ofps [素材fps]

1. mcdeint が動き予測と動き補償をやるには元になる参照フレームが要る。そのときに、インターレ−スドを参照しても（現状では）うまく行かない。だから、mcdeintより先になんらかの「各フィールドをフ レーム化するインタレ解除」をかけてやる必要がある。素材フレームレートを倍増するものなら何でも、実はインタレ解除でなくても効果があるが、開発者自身 がyadifを使っているのでここではそれに倣う。
   　yadif=1または3で1フィー ルド＝1フレーム（フレーム レート２倍）となる。yadif=3は、 空間軸のインターレース検出をスキップ。yadif=1は スキップしない。
   　なお、ここではyadifのフィールドオーダ自動判定を使っている（デフォルトなので書かなくても、yadif=3:-1になる）。 フィールドオーダの指定が素材と合わないと、後ろにあるべきフレームが前に来てしまうなど、出力フレームの時系列が前後する事があるようだ。これはTVキャプチャではフィールドオーダがランダムに切り替わるためらしい。やや古い経験になるが、手許でもfilmdint使用時、Bottom field first!というメッセージを見る事があった。経験上は30分番組で数十回程度。素材のフィールドオーダが確実に固定である場合は、yadif=x:1または 0でフィールドオーダを指定できる。
2. mcdeintは、yadif=3の出力結果を上書きする。この段階でもまだフレーム数は２倍。
   mcdeintには（まだ）フィールドオーダーの自動判定が無いが、動作原理上、 実装の優先度は低そうだ。
   
3. framestep=2は出力フ レームを飛ばして2コマ置きにする。
   例えば素材が30fpsならこれで倍増したフレームを半分捨てないと、出力フレーム数が 60fpsぶんになる。
4. 従って、素材が30fpsなら-ofpsは30000/1001。

　MEncoderで使えるインタレ解除フィルタの中では、 抜群だ。

　 理屈を読むとかなり無駄っぽい印象を受ける上にいーのかそれでという感じもあるが、フィールドを半分捨てるといってもフレーム内の大部分のデータは重複しているものだし、必要な部分は動き補償で（単純なブレンドなどでなく）出力されるフレームに加味されている。時間軸fps混在だの空間軸fps混 在だのの厄介ごとを気にせず、とりあえず、オールラウンドに使っても相当の性能を発揮する。

　手許の実写は落語が多いので、細かい動きのジャギが気になりがちなのだけれど、yadif単独では地味に気になっていた唇の端っこのジャギやズーム時のちらつきなどが緩和した。

　なお、少なくとも動作原理 上、pullupとの併用は無意味と考えられる。pullupは素材映像の中のテレシネパターンを頼りに元の film映像を復元するものだ。その後でyadif,mcdeintをかけると画質劣化のデメリットのほうが大きく、yadif,mcdeintの後では テレシネパターンが残っていない。逆テレシネはテレシネ素材にしか効かず、逆テレシネが効くならインタレ解除は適切ではない。映画とアニメはpullup を軸にした方が良さげ。

　桁違いに遅い。x264より重い。

　 手許（Power PC G5, 2Ghzx2）では1分半のクリップに2時間以上。turbo使用の1stと、より重い2ndがきっちり1時間ずつと同じだったので、mcdeintが最 大のボトルネック。CPU利用効率も激減していた。速度を計算すると0.0xfpsと文字通り桁違い。mcdeint を使うなら事前に中間生成物で吐くべきだろう。

　また、インタレ解除である以上は「もともとこの世 に存在しないデータのでっち上げ」という限界があるのでpullupに比べれば印象はやはり落ちる。
　

　MEncoder ユーザーメーリングリストでもyadif単独がいまのところ最も実用的なのではという意見が一般的なようだ。
　そこで、yadif=3でフィールドをフレーム化し、 framestep=2で半分捨てる手を軸に、間に挟む調整（前後フィールドから必要なデータを持って来る）にmcdeint以外のものを使う手はどうかと思った。例えば、

-vf yadif=3,pp=l5,framestep=2 -ofps [素材fps]

-vf yadif=3,framestep=2,pp=l5 -ofps [素材fps]

　pp=l5に全フィールドを見させるなら前者。データの混合を実際に残るフレーム同士に限りたければ後者。
　なお、pp=l5を重用しているのは それが最も優れているからというわけではないです。手許でビルドしたMEncoderではkerndeintやfilmdintがなんか動作が怪しいだけです。
　ちゃんと動作するなら、kerndeintのピ ンポイント縞除去や、filmdint=io=2997:2997にした上で、 dint_thresを調整した方が良いかも知れません（yadifの後ならテレシネパターンなど残っていないから、インタレ解除しか作動できないハズ）。

　気になる速度面ですが、やっぱ倍増しますなyadif単独にくらべると。-vfチェイン内だけとはいえ、書き出しフレーム数が倍増してるわけだし。一方面白い事にCPU利用効率がyadif単独の30fpsより上がりました。threads=4と一緒に使うとCPUメーターが天井に張り付きっぱなしの 185～195%になります。たぶんx264の処理速度といい感じにバランスするのでしょう。処理密度とか、命令粒度とかいうのかな。