スケーリング・アルゴリズムのひとつ。ffmpegXの選択肢にもある。妖精現実さん（Lanczos3）、Doom9 コデックコンテスト2005（Lanczos4）、その他AviSynthスクリプトでは良く見かける。拡大してもジャギが出にくいらしい。縮小の場合、 ほとんど違いが解らないところがナニだが、まぁ気分で^^;

　原理としてはinterpolation、補間フィルタ（補完ではない）の一種で、いくつかの点が与えられ たとき、それらの点を通る滑らかな曲線を求めること。画像の拡大・縮小処理の際にも用いられる。との事です（*1）3とか4とかはその「いくつかの点（タップと言うようで す）」 の数。

（*1）リンクがうまく行かない場合は、右クリックでURLをコピペして使って下さい。

-zoom -sws 9 scale=640:480:::4

-sws 9でLanczos。-vf scale=w:h:::Lanczos Filter Length。Filter Lengthの範囲は、1-10。

なお、-zoomはソフトウェアスケーリングの許可。

manの記載はこう。

scale[=w:h[:interlaced[:chr_drop[:param[:param2[:presize[:noup]]]]]]]

paramとparam2は-swsでナニを選ぶかによって指定値の意味が違って来る。Lanczosの場合はここは Filter Lengthだとあります。

paramかparam2のどっちに入 れても良いようです。

ただ、どうも再生時でないと効かないっぽい。

MPEG-PS file format detected.
VIDEO: MPEG2 720x480 (aspect 2) 29.970 fps 8001.2 kbps (1000.1 kbyte/s)
Opening video filter: [scale w=320 h=240 param2=4]
==========================================================================
中略

SwScaler: Lanczos scaler, from 0x32315659 (21VY) to 0x32595559 (2YUY) using AltiVec
SwScaler: using C scaler for horizontal scaling
SwScaler: using n-tap C scaler for vertical scaling (BGR)
SwScaler: 720x480 -> 320x240

MPEG-PS file format detected.
VIDEO:  MPEG2  720x480  (aspect 2)  29.970 fps  8001.2 kbps (1000.1 kbyte/s)
Opening video filter: [scale w=320 h=240 param=4 param2=4]
==========================================================================
中略

SwScaler: Lanczos scaler, from 0x32315659 (21VY) to 0x32595559 (2YUY) using AltiVec
SwScaler: using C scaler for horizontal scaling
SwScaler: using n-tap C scaler for vertical scaling (BGR)
SwScaler: 720x480 -> 320x240
VO: [macosx] 320x240 => 320x240 Packed YUY2  [zoom]

MPEG-PS file format detected.
VIDEO: MPEG2 720x480 (aspect 2) 29.970 fps 8001.2 kbps (1000.1 kbyte/s)
Opening video filter: [scale w=640 h=480 param=4]
==========================================================================
中略

SwScaler: Lanczos scaler, from 0x32315659 (21VY) to 0x32315659 (21VY) using AltiVec
SwScaler: using C scaler for horizontal scaling
SwScaler: using 1-tap C "scaler" for vertical scaling (YV12 like)
SwScaler: 720x480 -> 640x480

TMPGEnc講座 Ver.22 - 2ch,google キャッシュ

---

810 ：名 無しさん＠編集中 ：2006/03/19(日) 17:35:04 ID:1IA0QulE

DivX6にLanczos4ってあるけどXP3.0のLanczos3との違い判る人います?

812 ：名 無しさん＠編集中 ：2006/03/19(日) 18:19:24 ID:YvlfNtGV

>>810
参照するピクセル数がLanczos3よりLanczos4の方が多い。
その分時間は確実に多くかかるし、画質も必ずしもLanczos4の方が良いとは限らない。
Lanczos8とかLanczos16とかだと、えらくノイジーになるし。

まるも製作所 - 2001/07月の日記

---

７ 月６日（金）　縮小アルゴリズム（６）— デシメーション

　低域通過フィルタを使ったことのある人ならば体験的に理解してるはずですが、解像感を高めようとタップ数を増やせばリンギングノ イズが発生し、リンギン グノイズを減らそうとタップ数を減らせばエイリアスノイズが発生し、エイリアスノイズを減らそうと縮小サイズよりも小さい阻止周波数を指定すれば解像感が 失われるといった具合に、バランスの良い設定値を見つけることが困難です。

　しかし、Lanczos フィルタ（正確には Lanczos 窓関数を使用した FIR 低域通過フィルタ）は解像感・リンギング・エイリアスのバランスが高いレベルで取れているためその心配がなく、画像処理には最適であると言われています。

７月９日（月）　縮小アルゴリズム（９）— おまけ（補間の場合）

Lanczos フィルタは補間（拡大）にも使用することができます。補間の場合、参照画素数は拡大後の解像度によらず原画像の解像度によってのみ決定されます。

Lanczos フィルタは基本的に低域通過フィルタなのですが、その遮断周波数は基準にとる幅によって決定されます。具体的には、基準の幅のナイキスト周波数が遮断周波 数になります。

原画像の１画素の幅を基準にとると、遮断周波数は原画像解像度のナイキスト周波数に等しくなるので、オリジナルに含まれる（計算誤 差によって削除・追加される歪みを除いた）全情報をそのまま通すフィルタになり、補間に使用することができるようになります。

スポンサーサイト

【 もくじ】

1. 用 語
   1. フ レームとフィールド
   2. イ ンタレ解除と逆テレシネ
2. 基 本的なアプローチ
3. MEncoder のインタレ解除、逆テレシネ
   1. 例 １）filmdint： インタレ解除。映画・アニメ用
   2. 例 ２）filmdint：インタレ解除。大半のTV番組用
   3. 例 ３）yadif：インタレ解除。大半のTV番組用
   4. 例 ４）pullup：逆テレシネ。映画・アニメ用
   5. 実 験段階のインタレ解除）mcdeint：動き補償デインターレーサ
4. ク ロップについて
5. 参 考リンク

用 語

フ レームとフィールド

　空間軸画質：一時停止した時の画質。

　勝手な造語。情報量が多いほど奇麗。動画では解像度。320x240よりも640x480のほうが精細で、データ量も多い。ま た量子化（情報の間引きのようなもの）をしないほうが奇麗。

 ※デジカメは空間軸画質しか考え なくて良い。2006/秋 現在、大抵 のデジカメは 300万～500万画素あるが、640x480は約30万画素。"フルスペック・ハイビジョン"の1920x1080でも約200万画素。 

　時間軸画質：動きの滑らかさ。

　勝手な造語。情報量が多いほど滑らかで、データ量も多い。動画ではfps (frame per second)。

　フレーム：

映像の一コマ。完全な１枚絵。プログレッシブとも言う。

　フィールド：

TV放送映像の一コマ。シュレッダにかけたような、ブラインドごしに窓の外を見るような切り刻まれた絵。インターレースドとも言 う。奇麗な一こまに補完するのは脳の役目（残像現象）。一般的に、フィールドを２枚ひと組で1フレームと数える。アナログTV放送の為に案出された方式。

映像あり 映像なし 映像あり 映像なし

映像なし 映像あり 映像なし 映像あり

　映画カメラ：毎秒24000/1001フレーム

一般的に24fpsとか23.976fpsとか言う。正確には24000/1001fps

空間軸画質は映画カメラ（フィルム）が優れている。

　TVカメラ：毎秒 60000/1001フィールド(=30000/1001フレーム)

一般的に30fpsとか29.97fpsとか言う。正確には30000/1001fps。

フィールド基準なら60Hzとか59.94Hzとか。

時間軸画質はTVカメラが優れている。

イ ンタレ解除と逆テレシネ

　テレシネ変換：（他にプルダウンなど）

映画をTV放送する際にフレームを水増しし（24fps to 30fps）、さらに フィールド構造に切り刻む事（毎秒60フィールド）。

　逆テレシネ変換：（他にインバース・テレシネ、IVTC、プルダウン・リバーサルなど）

テレシネ変換された映像をフレーム構造へ再変換する事。

テレシネ変換固有のパターンを解析して、映画カメラで撮影した時点の映像を"復元"する。

映画カメラで撮った時点でインターレースは存在しないので、優れた逆テレシネフィルタはほぼ完璧な24fps映像を復元できる。

TVカメラ撮影素材に使うと、インターレース縞が取りきれない上に動きの速い箇所が「カクツく」事になる。

　インターレース解除：

2枚のフィールドから1枚のフレームを合成する事。

完璧なインターレース解除は存在し無い。

なぜなら2枚のフィールド間には約1/60秒の時差が存在し、単純合成しても場面によってはシマシマが残るから。

また、毎秒60000/1001フィールドの 映像を毎秒30000/1001フレームに 減らす事になるので、動きの激しい箇所が「カクツく」事になる。

基 本的なアプローチ

1. 映画・アニメ：
1. 逆テレシネ（pullup）を基本にビデオ・フィルタ・チェイン（-vf以下）を組み立てる。特に映画は空間軸画質・時間軸 画質ともにほぼ完全に"復元"可能。
2. 普通のテレビ番組：
1. フィールド to フレーム変換
1. 毎秒60000/1001フィールドの 映像を毎秒30000/1001フレームに 減らす。空間軸画質はフィールド同士を合成する手法によっては劣化する。時間軸画質は基本的に劣化する。
2. 毎秒60000/1001フィールドの 映像を毎秒60000/1001フレームにする。空間軸画質は補間手法によっては問題が残る。素材の時間軸画質はキープできる。
2. フィールド構造保持
1. 2006/秋時点ではx264は非対応。Xvidを選択する。

　時間軸fps混在：

　勝手な造語。可変フレームレート（VFR）と言った方が通りが良い。

　歴史的に映画カメラによるコマ撮りで始まったアニメは基本24fps。古いディズニーなどは絵描きががっつり24枚描く。国産 は戦前のウ ルトラ気 合いの入ったものなどごく一部を除いて8～15fpsだ が、製作工程のデジタル化で部分的に30fpsが使われるケースが増えている。らしい。8 や15に慣れているはずの業界がわざわざ 30使うという事はそこが"見どころ"なわけでもある。Winでは古くからココにこだわって120fps.AVIや、CFR.mp4をMKVに突っ込んでVFR.MKVにするいった手法がある。らしい。また AviSynthやAviUtilにはこれに適したフィルタ群があるようだ。

　話を戻すと、時間軸fps混在は映画カメラ撮影シーン（24fps）とTVカメラ撮影シーン(30fps)を繋ぎ合わせたもの は全て該当 する。『BSアニメ夜話』ではスタジオでゲストがダベるシーンと、アニメの名場面が交互に出て来るし、『なつかし映画名場面全集』、『全部みせます水戸黄 門総集編』、『親子で見ようゴレンジャーからボウケンジャーま で』みたいな番 組があったらバリバリに該当するだろう。TVドラマでも古いものは映画カメラ撮影だし、最近でも予算が許せばフィルム撮りがある。"表現"に拘る場合は映 画カメラの蓄積ノウハウやフィルム自体の質感が無視出来ないものらしい。さ らにさらにチャップリンやマルクス兄弟は15fpsだとか、『そのとき歴史が動いた』の戦争の記録フィルムまで「撮影カメラに忠実な画質を！」とか言 い出すと、、、言ってみただけですごめんなさい。ゼンマイならまだしも、下手すっと手回しもありそうだし。

　空間軸fps混在：映画字幕やTV局のロゴ

　勝手な造語。

　一場面の中で映画カメラ撮影成分（24fps）とTVカメラ撮影成分(30fps)が混在しているもの。字幕やTV局のロゴな どは、最初から毎秒60000/1001フィールドを想定して作られている。映画などはテレシネ変換の後で、字幕や局ロゴを合成している事が多い。

　こうした部分は逆テレシネフィルタではウマく扱えない。

MEncoder のインタレ解除、逆テレシネ

　適切なインタレ解除、逆テレシネフィルタは、素材の撮影カメラがどちらであるかに よって異なる。TVカメラ撮影素材に逆テレシネを使うと時間軸画質が落ちる（動きの滑らかさが減る）。映画カメラ撮影素材にインタレ解除を使うと空間軸画 質が落ちる（無駄な重複コマがビットを喰う）。どちらの場合もインタレ縞が取りきれずに残る。

　ffmpegXはインターレース解除にpp=md (median deinterlace、中央値補完)を使う。pp系はインターレース縞の存在しない部分も一律に「合成」するもので、素材がなんであれインタレ縞を徹底 的に消す事が出来る。 反面、一長一短が激し い。pp=md はpp系の中ではベストバランスではあるが、輪郭線部分にジャギが残りやすい。特にアニメで目立つ。pp=lb (リニアブレンド)はジャギも縞も完璧に消すが、色味や輪郭がかなりボケる。pp=l5はいわば弱っちいリニアブレンド。副作用が弱い代わ り、ジャギも縞も消しきれない。手許ではこのpp=l5を他のより「賢 い」フィルタの補助として使うが、kerndeintの方を好む人もあるようです。

　なお、特に断りが無い限り、以下の例はMPlayerでは動作しません。MEncoder専用です。

例 １）filmdint： インタレ解除。映画・アニメ用

-vf filmdint,pp=l5 -fps 30000/1001 -ofps 24000/1001

　映画カメラ（24000/1001fps）撮影素材を、TVの毎秒60000/1001 フィールドに直して放送した ものに向く。

　TV放送（MPEG2キャプチャやフィールド構造のDVD） からはコマを間引く事になるが、カメラ撮影時のfpsに戻すので動きがカクツクことは無 い。元々filmdintはTV放送向けの「万能ナイフ」。基本的には逆テレシネだ が"テレシネパターン"が見つからない場合は、シンプルなインタレ解除を行う。

　それでも稀にインタレ縞がとりきれない部分が残る、特に字幕や局ロゴなど。後ろにpp=l5を置く事で潰している。

　pp=l5は一律に前後のフィールドを混ぜる 「賢くない」タイプだが、先にfilmdintでほとんどのインタレ縞は取れているので副作用は少なめ。時間軸fps混在アニメでは30fps箇所でゴー スト状のコマができる事になるが、再 生時にはまぁまぁそれっぽく見える。

例 ２）filmdint：インタレ解除。大半のTV番組用

-vf filmdint=io=2997/2997 -fps 30000/1001 -ofps 30000/1001

　TVカメラ(毎秒60000/1001フィールド)撮影素材に向く。フィールド２個を合成してフレームにしてしまうが、ほとん どの場合で動きのカクツキは意識できない。ボクシングとかオリンピックとかダンスとかになると、目が慣れた人には厳しいかも知れない。上記では省いたが、 これもpp=l5などの補助を付けた方が良いと思う。

　filmdintには固有のデメリットがあり、字幕類（スタッフ ロールなど）が荒れる。

　また、手許でビルドするようになってから細かいブロックノイズ状のチラつきが出るようになった。ffmpegX版は 0.0.9t以降、同様の不具合が直っていない。0.0.9s 版（230105）は正常に動作する。逆テレシネ目的で使う場合はそれ専用のpullupの方が優秀なのだが、filmdintは「万能ナイフ」と呼ば れるだけあって使いでが広い。豊富な子オプションの設定を追い込んだり、その中でcropもできる。x86でなければ性能を引き出せない部分があると言う オープンソースにしては不思議な仕様なのだが、x86 Macでは動くかもしれないので残しておきます。

　実はコレがAltivec最適化してねぇかと期待してビルドに手を出したので少し愛着もあるのです。

例 ３）yadif：インタレ解除。大半のTV番組用

-vf yadif=0,pp=l5 -fps 30000/1001 -ofps 30000/1001

　filmdintよりも新しく、PPCでも安定動作する。稀に幽かにジャギが残る場面があるのでpp=l5でぼかしている。 2006/秋現在の常用。

　yadif=1で1フィールドを1フレームに変換して60000/1001fps映像が作れる。サッカーでいくつか試したが、 時間軸・空間軸ともに特に yadif=0との差は感じなかった。とくにx264はオプション次第で同じビットレートでも30fpsと60fpsの空間軸画質がさほど変わらないの で好みに応じて選べるだろう。

　60fpsで作れば映画やアニメにもオールラウンドに使えないかと思って試したが、静止画像の上をカメラがゆっくりパンしてゆ く場面でカクツキが出 た。コマ送り確認すると、できるだけ一こま一こまが奇麗になるように、インタレ縞の少ないコマのほうへ"吸着"、つまり、パンの途中で同じコマが２枚連続 していた。これで動きが一瞬カクンと止まって見えたわけだ。

MEncoder専用 1.0pre8（2006.06.11）以降。

※サッカーはドイツワールドカップだったので、EUのPAL（毎秒50000/1001フィールド）カメラが混在していた可能性 がある。

例 ４）pullup：逆テレシネ。映画・アニメ用

-vf pullup,softskip,pp=l5,harddup -ofps 24000/1001

　テレシネ固有のパターンを解析して、カメラで撮った時点の24fps映像を再構築するも の。MEncoderの真打ち。

　softskipは素材の全フレームを検証する 必要が有るフィルタの直後に置く。また、最終的にmp4boxで.mp4にmuxする場合は-vfチェイン末尾にharddupが必須。こ れがないと、ほとんど同一内容のフレームが連続した場合にきちんとフレームを書き出さず、「前のフレームリピートして」とAVI ヘッダ に書き込む。.mp4や.mkv作成用にrawvideo.264などで書き出す場合、このヘッダは存在しないので、最終 出力のフレーム数が不足する。

MEncoder専用。ffmpegX版でも使える。

　pullupは空間軸・時間軸ともfps混在を想定していない。そうした部 分でインタレ縞が残る。手許では時間軸混在も空間軸混在もpp系で一律に潰している。例：

-vf pullup,softskip,crop=720:480:0:0,scale=640:480,hqdn3d=4:3:6,pp=l5,harddup

　インタレ解除は先頭に置くのが定石。最初のpullupで縞はほぼ完全に消えてしまう。この後ろでpp系で時間軸混在箇所の縞を潰す。同時に空間軸混在箇所も潰す。pp系は 「賢くない」ベタ合成なので、30fps箇所は前後のコマが混ざっ たような不気味なコマになるが、通常視聴ではまぁ まぁ見れる。上記ではpp=l5（弱いリニアブレンド）を使っているが、クロップ、スケール、デ ノイズをかけた後に回す事で副作用（特に色ボケ）の緩和を狙った。好みによりkerndeintを使う人もあるようだ。

　フィルタチェイン内の順番だが 基本はインタレ解除・クロップ・スケール・デノイズ。上記では一律に合成するpp系の特性を考えて、デノイズの後に置いている。これで良いか 否かは不詳だし、結果も個人の視覚と感性によるだろう。

実 験段階のインタレ解除）mcdeint：動き補償デインターレーサ

-vf yadif=1,mcdeint=1:0 -ofps 60000/1001

　※上記が正しいか否かは確証が無いのでmanなどをよく読んで使って下さい。

　ここまでは手許で使い物になったものを挙げて来たが、まだ実験段階のmcdeintというインタレ解除がある。mcの名前の通 り、インタレ解除に動き補償を、しかもモーションベクトル算出精度の量子化値まで弄れるという豪快さんだ。かなり奇麗に作れるのだが桁違い に遅い。比喩でなくfpsの桁が変わる。フィールドオーダーの自動検出が無い点も惜しい。これが使い物になれば（そういう設定値が見つかれば）、 filmdintを超える万能ナイフになるかもしれない。あるいは AviSynthやAviUtilに肉薄できるかも知れない。カンタンにシアワセになりたい。

ク ロップについて

crop=w:h:x:y

mplayer INFILE.mpeg -vf rectangle=w:h:x:y

#!/bin/sh
# chelper.bash
echo
echo "==========================================="
echo " --- Crop Helper ---"
echo "==========================================="
echo
#
echo "入力ファイルをD&D"
read iFN
a1=y
while [ $a1 = "y" ]
 do
 echo =====================================
 echo "Cropしない ; そのままreturn"
 echo "Cropする ; (w:h:x:y)で指定してreturn"
 echo ""
 echo "# 参考（w,hは16の倍数、xは偶数、yは4の倍数が基本）"
 echo " 4:3 ;704:464:8:8"
 echo " 16:9 ;704:352:8:64"
 echo " シネスコ ;704:272:8:104 (640x272,2.35:1)"
 echo =====================================
 read cROP
 echo ===START==============================
 mplayer \
 ${iFN} \
 -vf rectangle=${cROP}
 echo
 echo "### 好きな方をCrop設定にコピペ ###"
 echo "-vf crop="${cROP}
 echo "-vf filmdint=crop="${cROP}
 echo
 echo "### もう一度？(y=Crop値再指定 / n=exit) ###"
 read a1
 done

参 考リンク

• DVD映像を高画質なMPEG-4 ("DivX")にする方法

• Video Filters

pp系の特徴

基本的に画面全体の一律処理。インタレ縞を完全に解除する。前後のフレームを混ぜる為、混ぜ方により色がボケたり、動くものが２ 重化したり、輪郭線にジャギがでたりする。混ぜ方はいろいろ、長所も短所もいろいろ。

pp系以外の特徴

様々な方式を駆使してインタレ縞を発見、「賢く」除去する。大雑把に言って色味はpp系よりクリアになるが、インタレ縞の解除漏 れがありが ち。子オプションで微調整が効くものが多い。

　MEncoder で使えるインタレ 解除としては間違いなく最高の部類。こうかはばつぐんだ。ただし、手許ではx264より遅く、実用には耐えない。
　インタレ解除のくせに8x8ブロックにqpelに複数参照まである。 訳しながら笑ってしまった。ビグザムだビグザム。完成の暁には！（不吉）

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

"missing" lineというのはこういう事だ。

左は料理番組の冒頭で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]

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

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

1.基本

2.結論

-vfm ffmpeg -vf yadif=3,pp=l5,framestep=2,,, -ofps 30000/1001

3.理由

4.実験

機　材：PowerMac G5(2Ghzx2)
ソ フト：MEncoder dev-SVN-r23205-4.0.1

設　定：x264 lossless, 30000/1001fps出力

#!/bin/bash
# yadif_test
#070502,charset="UTF-8",LF

for x in `ls *.mpeg`;do

echo "----"
echo "${x}"
echo "${x%.mpeg}".264
echo "START; `date +%m/%d" "%H:%M.%S`"
START_SEC=`date +%s`

mencoder "${x}" \
-vfm ffmpeg \
-nosound \
-ovc x264 -x264encopts qp=0:bframes=1:keyint=0:keyint_min=0:nodeblock:nocabac:subq=1:nointerlaced:threads=16 \
-vf yadif=0,scale=640:480:::3,hqdn3d=2:1:2,harddup \
-sws 9 -zoom \
-fps 30000/1001 -ofps 30000/1001 \
-of lavf -lavfopts format=mp4:i_certify_that_my_video_stream_does_not_use_b_frames \
-o "${x%.mpeg}".yadif=0_.mp4

expr `date +%s` - "${START_SEC}"
echo "END; `date +%m/%d" "%H:%M.%S`"

done

　※x264 lossless設定の詳細は、H.264/AVCロスレス～其の弐を参照。

4.1. 実験１：アニメ

素　材：アニメ, MPEG-2 PS, 5"30秒,221.9MB, 映画・あしたのジョー２冒頭部分（先日のBSアニメ夜話スペシャル）

　一般的に24fpsアニメの画像混濁コマは前後が均等に 混ざっている物 だが、この素材は不均等な画像混濁コマがある。本編中にあるのも珍しい。良く見かけるのはCMへの切り替えなどだ。
　なんつうか、力 石徹のカオが心霊写真のように中空に浮かんでたり。する。直前のコマには全身描いてあるのに。
　恐らく、一般的にはフィルムスキャナ のようなものでデジタルデータを作ってからテレシネ処理をするのに対し、この素材はフィルムを上映しながら撮影するタイプのテレシネをかけたと思われる。 きっとお金かかってる。NHKえらい。
　えらいんだけど、pullupで逆テレシネかけるとすんげぇカクツク箇所があった。カクツ クってよりガクガク。オリジナルは絶対フィルム撮りなのにフィルム撮りなのにフィルム撮りなのに！

仮番	-vf	メ モ	サイズ	時間
A1	yadif=0	1 フレームを1フレームとして出力。	1.45GB	543(09"03)
A2	yadif=2	0 同様。ただし空間軸のインターレース検出をスキップ。	1.46GB	537(08"57)
A3	yadif=1,framestep=2	1 フィールドを1フレームとして出力。	1.45GB	777(12"57)
A4	yadif=3,framestep=2	1 同様。ただし空間軸のインターレース検出をスキップ。	1.46GB	715(11"55)
B1	pp=l5	全 ラインを一律に混ぜる（5タップの低域通過フィルタ）。	1.50GB	471(07"51)
A4+B1	yadif=3,pp=l5,framestep=2		1.46GB	818(13"38)

感　想：

　Aシリーズの差は僅かでほとんど問題とするに値しない。 A1,2と A3,4の間に僅かにジッターの改善らしきものが見られた。
　空間軸のインターレース検出(yadif=0/1)は、不足ラインの埋 め方にやや問題があるようで、非常に細かい文字などが荒れる。空間軸のインターレース検出をスキップ(yadif=2/3)すると、地味な解除漏れが残る （Lair Of The Multimedia Guru » Deinterlacing filtersの図参照）。
　各コマが最も素材に忠実（主に心霊写真ぶりが）なのはB1だが、母線のジャギも最 も激しい。

B1	A4+B1

　つう か、↑ここで「あ。」とか思う自分がちょっとイヤ^^;。
　ただまぁ、B1以外はほとんど差を感じないと思います。アニメでは。 pullupなら二重化はほぼ完全に避けられるが、この素材ではやむを得ない。三回パンとか三回パンとか三回パンとか。ガタツクと「くっ、クロスカウン タぁッ！！」感が減る。減るんだってば。

4.2. 実験２：実写

素材：実写, MPEG-2 PS, 2"00秒,53MB, ＮＨＫスペシャル・「日本国憲法誕生」冒頭部分

　資料映像の白黒(24fpsフィルム)、バストアップの インタビュー、 紙資料のどアップが混ざっている。
　 落語の経験上、yadifは唇やまばたきにやや不満が残る。ズームイ ン、ズームアウト、パン（横方向のパン）、ティルト（縦方向のパン）も。
　また紙資料のどアップはなかなかインタレ解除が厳しいもの がある。インクの滲みまくった米軍文書はいいけど、明朝体の和文は文字の横線が厳しい。旧かな使いだと漢字ややこしいし。
　どうも動 きのあ る斜めの直線がジャギる。水平に近いほど激しくジャギる。肩とか。パンやズームの時の机のへりとか舞台のへりとか文字の横棒とか車中撮影の道路の白線とか ヘリ撮影の国会議事堂のてっぺんの段々とか。自動的にんなとこに視線が行く自分がちょっとイヤ。

仮番	-vf	メ モ	サイズ	時間
A1	yadif=0	1 フレームを1フレームとして出力。	713.8MB	222(3"42)
A2	yadif=2	0 同様。ただし空間軸のインターレース検出をスキップ。	省略	省 略
A3	yadif=1,framestep=2	1 フィールドを1フレームとして出力。	省略	省略
A4	yadif=3,framestep=2	1 同様。ただし空間軸のインターレース検出をスキップ。	716.3MB	270(4"30)
B1	pp=l5	全 ラインを一律に混ぜる（5タップの低域通過フィルタ）。	742.6MB	187(6"07)
A4+B1	yadif=3,pp=l5,framestep=2		719.8MB	303(5"03)

感　想：

A4で解除漏れが出た。紙資料のどアップ。極めて僅かでコ マ送りでないと 気が付かない。
B1は解除漏れはないが、ジャギが最も激しい。人間の肩や、図書館の人が資料を弄る軍手をはめた手、など。
A1 とA4+B1の差はほぼ完全に無いが、A1にはごく小さなジャギの痕跡らしきものがある。1ピクセルの白点、これもコマ送りでないと気が付かない。液晶の ドット欠けかと思った。

余談：

agehaにオリジナル無し

• Lair Of The Multimedia Guru » Deinterlacing filters
• ageha SSIMとPSNRとは

更新履歴

• 2007/04/29:初出
• 2007/05/03:実験結果等を追記