|
|
-vf filmdint,pp=l5 -fps 30000/1001 -ofps 24000/1001
-vf filmdint=io=2997/2997 -fps 30000/1001 -ofps 30000/1001
-vf yadif=0,pp=l5 -fps 30000/1001 -ofps 30000/1001
-vf pullup,softskip,pp=l5,harddup -ofps 24000/1001
-vf pullup,softskip,crop=720:480:0:0,scale=640:480,hqdn3d=4:3:6,pp=l5,harddup
-vf yadif=1,mcdeint=1:0 -ofps 60000/1001
crop=w:h:x:yw:hは16の倍数でないものを使うと画質劣化。MPEG系は基本的に16x16ピクセル単位で動き分析を 行う。特にMPEG4 ASP(xvidなど)では、端っこの黒いとこが残ってると、黒みが映像に侵入したり戻ったりを繰り返すので、ギリギリではなく「うそ!!」ってくらい バッサリ行くのが基本。x264ではさほど深刻では無い。
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
名称 | 共通項 | 説明 | 利点 | 弱点 | |
---|---|---|---|---|---|
p p 系 |
pp=lb | 縞完全除去 | linear blend 全ライン処理 リニアブレンド |
完全にインタレ縞が消え、ジャギも出ない。 | 画像全体がややボケる。動くものが2重化する。 |
pp=li | linear interpolating 2ndライン処理 リニア補間 |
素早く動く人物の輪郭(ジャギ)はmdより上。 | 輪郭線などにジャギが出る。 動きの少ない部分はpp=mdより悪い(特に直線に弱い,文字や車の縁な ど) |
||
pp=ci | cubic interpolating 2ndライン処理 三次元(?)補間 |
素早く動く人物の輪郭(ジャギ)はliより上。 | 輪郭線などにジャギが出る。 動きの少ない部分はpp=liより悪い(特に直線,文字や車の縁など)。 |
||
pp=md | median 2ndライン処理 中央値補間 |
pp系の中ではベストバランス。 他はmdより良い部分と悪い部分があ る。色のボケは最も少ない。ffmpegXが使う。 |
特に人物の輪郭がジャギが出る。 特にアニメで主線がぶつぶつ線になりが ち。 |
||
pp=fd | ffmpeg deinterlacer 2ndライン処理 |
特に無し。 | 全体がボケる。動くものが2重化する。ジャギも散見。 ffmpegで使えるものより性能が悪い。 |
||
pp=l5 | lowpass5 全ライン処理 低域通過フィルタ 5タップ? |
動きの少ない部分ではmdよりクリアかも。 | 全体がややボケ、動く物も2重化するが、pp=lbよりは良い。 映像内容によってはインタレ縞が残る事もある。 |
||
非 p p 系 第 一 世 代 |
kerndeint | 解除漏れリスク(素材・設 定次第) | ピンポイント縞解除 | 動きの無いコマはfilndint並みにクリア。 微調整可。 |
シーンチェンジ直後のジャギが激しい。激しく動く部分はpp=mdに劣る事
も。 オリジナルの作者自身がもう古いから他の使えと言っている。 |
逆 テ レ シ ネ 第 三 世 代 |
pullup | 解除漏れリスク(素材・設 定次第) | インタレ解除ではなく、逆テレシネ。 | MEncoder最大の強み。 24fpsカメラ撮影素材専用。 解除漏れはまず無く、極めてクリア。 |
30fps素材に向かない。 CGやNTSC字幕などが合成されていると元映像にあったコマが消失するし、縞付きのゴーストが出たりする。 |
filmdint | 逆テレシネ+インタレ解除。 万能ナイフ。 |
pp=mdより全体にクリア。動く物の2重化、人物の輪郭ジャギ、アニメの 主線のぶつ切れ現象、いずれも僅か。詳細な微調整可。 | インタレ縞が残る事があり、素材傾向別の微調整が必要。 シーン の変わり目で一瞬ジャギが出る(kerndeintよりは良い)。 字幕やテロップが小刻みに荒れる(固有の現象)。 基本的にmmx/3DNOW!に激しく依存し、05'夏頃を境にPPCでは正常動作しない。 |
||
第 四 世 代 ? |
yadif | NTSCの60fps化または 30fps化が選べる。 | yet another deinterlacerの略 |
filmdintの代役としてオールラウンドに使える。 字幕やテロップが小刻みに荒れる事が無いのが強み。 |
実写で首を傾げるなどの些細な動きに弱く、ジャギが残る。 60fpsで吐く際は一時停止時の奇麗さを最重視する傾向。これは静止画像のパンでカクツク事が ある。 |
mcdeint | mcは動き補償の略 |
yadifより地味にジャギが少ない。 | 猛烈に遅い。 これ一個でエンコードfpsが小数点以下に落ちる。 まだフィールドオーダーの自動検出が無い。 |
名 前 | コメント試訳 | メモ |
---|---|---|
1.RC 06/06/11@ 9:21 | 静
止画での比較は適切ではない。デインターレーサは動かしてみて動き回るエッジのジャギを見なければ正しい評価はできない。 | |
2. mean 06/06/18@ 18:27 | mcdeint
に関しては、avcodec_close/free missing in the uninit part(*不詳*)があるかも知れない。 | |
3.Michael 06/06/19@ 10:17 |
それはもう無い、たった今avcodec_close()を追加した | |
4. Sigdrak
06/06/19@ 17:01 | Interesting
results for yadif. What litterature have you checked on edge-directed interpolation that led you to this? Speaking of the implementation, I notice that there are such statements as: 1) if((y ^ parity) & 1) 2) uint8_t *prev2= (tff ^ parity) ? prev : cur ; 3) uint8_t *next2= (tff ^ parity) ? cur : next; inside of the loops. While I believe that nowadays CPU’s branch prediction will optimize it, couldn't it be made “cleaner”? (”patch welcome” is the reply I expect from you) | エッ ジを重点的に補間する手法? |
5.Sigdrak 06/06/19@ 17:03 | 最 適化の問題は気にしないで。既にテストしたでしょうから。恐らく register pressure (*不詳*)のほうが重要です。 | |
6.
Michael 06/06/19@ 23:55 | edge-directed interpolation
related
litrature(*重点的エッジ補間に関する文献?*)は1年ほど何も読んでいない。随分前に少し読んだ。正確には覚えていないし、現在のyadif
がやっている事がとの類似がどの程度かも知らない。しかし、一般的な補間ではないデインターレーシングに関する文献は、オンラインでフリーのものは1、2
個しかないので(この事は確信してる)。いつもは他の文献を読んでいない。もしかしたらciteseerがなにか見つけているかもしれない、、、。 tomsmocomp もなにかのdirectional interpolation code を使っているようだ。知ったのはyadifを書いた後だったが、、、。 そ して、時間軸と空間軸のpredictors(*予測子?*)を混ぜるのは完全に自分のアイデアだ。 最適化につ いては、yadif と mcdeint はまだまだなのでパッチ歓迎。例えば、mmxでかなりの向上がある事は確実だ。 filter() も inline functionに変更できる(*以下不詳*)。 about optimizations, yadif and mcdeint are not really optimized and patches are always welcome, for example iam sure they could benefit alot from mmx filter() could also be changed to a inline function and called with “constant” tff and parity so that the compiler can optimize the related checks away while the source code would stay clean … | *TomsMoComp:動き補償デインターレーサ。transcode、 AviSynthで使える。 |
7. compn 06/06/20@ 4:36 | mplayer
-vf lavcdeint が無いのはどうして?比較する価値が無い?dscaler deinterlace filterの事は知ってる? http://dscaler.org/ あ なたが libavfilter か libavmunge (as LAVF is taken by libavformat)を作るのはいつ? そして全プロジェクト(vlc, xine, mplayer, transcode, etc)のフィルタを統合してしまえば、みんな車輪の再発明を止めて、もっとスゴいフィルタに集中できるのに! | そ
れが成立すればMac OSXはCore Video/QuickTimeに競合する「もうひとつの動画インフラ」を持つ事になる。 プ ロダクションレベルならPhotoshopが必須だが、カジュアルユースならGimpで間に合う。 |
8.
Michael 06/06/20@ 9:08 | -vf lavcdeint は -vf pp=fd と同じだ。 dscaler については、linuxで簡単に使う手はあるだろうか?(qemuとかそういうのじゃなくて)。もし無いなら関心が無い。あればテストする、、、 今 のところ、libavfilterに取りかかるには私は怠惰すぎる/やる気がおきない。パッチは歓迎 :)。 しかしながら、(*以下 不詳*) its highly nontrivial if you want to allow all the speed related tricks like direct rendering and slices together with arbitrary filter graphs, and no 1 in = 1 out design. | 不詳部分: 例えば ダイレクトレンダリングや自由なフィルタグラフのスライス、そして"非 1 in = 1 out デザイン"などの速度向上手法は非常に重要だ。 // 非VfW モデルはLinuxにも存在しない? |
9.
compn 06/06/20@ 14:22 | dscalerはwindows only
だと思う。でも誇大宣伝(*過大評価?*)が多いよ。 | |
10.
MuldeR 06/06/21@ 13:08 | だ
れかmcdeintのしくみを説明してくれないか?自分の理解では、mcdeintより先にyadif=3を通さなきゃいけない。でもyadif=3の
段階でフレームレート2倍のインタレ解除済みになる。であれば、その後でmcdeintを使う理由は何?既にインタレ解除済みの映像に対して
mcdeintは何をするの?この時点でどんな向上があるの? どんな事でもいいです。教えて下さい。 mcdeintの情報はレアなので、、、 | |
11.
Michael 06/06/21@ 19:16 | mcdeint
は “missing” line を埋める為に動き予測と動き補償をやる。 うまく動き予 測をするには、元になる映像が要る。単純に奇数/偶数ラインを使う手も試したがうまくいかなかった。単純にフレームレートを倍増させるデインターレーサで すら、mcdeintの後では向上が見られた。 mcdeint はオーバーラップド・ブロック・ベース(*マクロブロック分割の際に、端っこをオーバーラップする。ブロックノイズ根絶手法*)の動き予測と動き補償を使 う。このコードはsnow codec(*離散ウェーブレット変換、DWTを使う次世代コデック、H.264/AVCより重い*)から持って来た。だから、snowに進展があれば自 動的にmcdeintも進化する。 mcdeint=0 :オーバーラップド・ブロック予測/補償を使わない。16×16 blockの 1/4 精度。 mcdeint= 1:8×8 blockサポートを追加、予測ゾーンサーチのダイヤモンド・サイズを拡大。 mcdeint=2 :反復的オーバーラップド・ブロック・ベースの動き予測と動き補償 mcdeint=3 :複数参照(*multiple reference frames*)を追加 | 笑った。x264より 遅いわけだ。 |
12.
MuldeR 06/06/21@ 20:18 | お
返事ありがとう! mcdeintが“missing”ラインを埋めるというのは解った。で もyadif=3 の時点で既にmissingラインの無いフルフレームになる。mcdeintはどこを埋めるの?それとも奇数/偶数ラインを上書きする? そ れから、yadif=3,mcdeintはフレーム枚数を倍にする。だから(*コマンドオプションの*)フレームレートを手で修正しなきゃいけなくて、 で、最終的にできあがりは2倍のfpsになる。mcdeintを使ってもTomsMoCompみたいにオリジナルのfpsを維持出来ないのかな?なにかオ プションが要るのだろうか。 yadif=3,mcdeint,framestep=2.は、MEncoderでウマく動くみたいだ。 でもCPUパ ワーがスゴく無駄になると思う(mcdeintが計算したフレームの半数をskipするから)。しかしながら、結果は面白い!唯一の問題はMPlayer では全く動作しないことだ。framestep=2があると映像がいったりきたりジャンプする(*前後関係が変わる?*)。 | |
13.
Michael 06/06/21@ 21:55 | は
い。上書きします。 mcdeintは前のデインターレースドフレーム(達)を動き予測/補償の参照フレームに使 う。だからその計算をスキップはできない。そうしないと前のデインターレースドフレームが存在できないから。 mplayer -vf yadif,…,framestep=2 は動くようになった。 | |
14.MuldeR
06/06/21@ 23:23 | 了解 ちょうど長いエンコードが終わった。 mencoder -vf yadif=3,mcdeint=1,framestep=2良 い結果だ。僕のマシンでは凄く遅いが、、、 動くようになった。とは最近直したと言う事? | |
15.MuldeR
06/06/25@ 16:52 | 最新のMPlayer build
(2006-06-25)を試したら直ってなかった :-( | |
16. Michael
06/06/25@ 20:27 | mplayer-svn
r18781を。それが上のコメント時点での最新版 | |
17.MuldeR
06/06/25@ 22:36 | 僕が使ったビルドはr18812だ。r18781で直ったのならその
ままの筈だが、残念ながら直っていない、、、 | |
18.
Rich 06/08/02@ 8:00 | MuldeR、インターレースド
素材のオリジナル・フレームレートは倍の数だ。50とか60とか60000/1001とか。単に各フレームのライン数が半
分なだけだ。フィールドをペアにして、一つのピクチャ上に交互配置してフレームレートを半減させるのは、それがコンピュータに保存されたときのやりかた
で、オリジナルビデオの性質というものを考えると語弊がある。 | |
19.JR 06/09/05 @ 12:26 | yadif と
mcdeint
のコンボはmencoderで逆テレシネと同時にフィルタチェインに書いても使えるものだろうか(例えばNTSCからfilmへ[23.976
fps])。-vf yadif=3:1,mcdeint=2:1:10,framestep=2,filmdint=dint_thres=256,… -fps 30000/1001 -ofps 24000/1001を 試したが、結果は常に動きの早いシーンでのフレーム複製だった(dint_thres=256の 効果でfilmdintはインタレ解除をしない。逆テレシネだけだ)。 そして、私はこうした素材のどの- fpsを指定すれば良いのかまったく手がかりを持っていない。pullup, divtcなどの他の逆テレシネはまだ試していない。しかし結果が変わるかどうかあまり自信が無い、、、 たすけて。 | |
20.
Justin 06/12/14@ 15:45 | 私
はyadif=3:1,mcdeint=2:1:10,framestep=2を試 したが、ぴょこぴょことした不審な動きが出る(時折フレームの順番がおかしい)。使っているのはmencoder rc1だ。 -vf pullup,softskip,pp=lbも 試したがこれは10~15倍も早いだけでなく、自分の見るところyadif,mcdeintの奇妙なダンスより良い(でもyadif,mcdent, framestepの苛つく動きを止める方法が見つかればまだ試すけど)。 誰かmencoderのTomsMoComp相当のフィル タを知りませんか? たすけて。 | |
21.
Michael 06/12/14@ 17:39 | もしもpullupなどの逆テレ
シネで
“interlacing”アーティファクトが除去できたのなら、そのビデオはインターレースドではなくテレシ
ネされたものだ。だからデイ
ンターレースの使用は可能でも、賢明でもない。 もし -vf yadif=3:1 がうまくインターレースド・ビデオでうまくいかなければ -vf yadif=3:0 または -vf yadif=3を試して。 […] & gt;誰かmencoderのTomsMoComp相当のフィルタを知りませんか? mencoderに TomsMoCompは無いです。transcodeを使って。 | *TomsMoComp:動き補償デインターレーサ。transcode、
AviSynthで使える。 *transcode:Linux、BSD、MacOSXで動くエンコーダ。 コマンドライン、使い方はものすんごく簡単に見える。 |
22.Justin
06/12/15@ 13:50 | 素
早い返事をありがとう。 自分はキャプチャーカードからdumpしたNTSC-M 29.97 fps素材を使っている。場面がテレシネかインターレースドかは50/50のようだ。似たような事のあるはいないかい? 自分は今、短 いクリップで以下のような逆テレシネを試している。 -vf,pullup,softskip, etcそ してもしそれがjittery(*神経過敏の*)に見えたら、以下を試す。 yadif=3:1,mcdeint=2:1:10,framestep=2,filmdint=dint_thres=256こちらのほうがかなり良い。 ど ちらの場合でも出力は24000/1001 fps。というのは少しでも縮めたいのと、ほとんどの素材が23.97fpsに見えるからだ。 こ れはアプローチとして正しいだろうか? |
MEncoder で使えるインタレ 解除としては間違いなく最高の部類。こうかはばつぐんだ。ただし、手許ではx264より遅く、実用には耐えない。
インタレ解除のくせに8x8ブロックにqpelに複数参照まである。 訳しながら笑ってしまった。ビグザムだビグザム。完成の暁には!(不吉)
MEncoderマニュアルの説明
mcdeint=[mode[:parity[:qp]]]
動き補償デインターレーサ。
1フレームにつき1フィールドの入力が必要となるので、tfields=1 や yadif=1/3、または同等のものと一緒に使う必要がある。
- <mode>
- 0: 高速
1: ミディアム
2: 低速, 反復動き予測
3: 超低速、複数参照フレームを2以上にしたのと同等。
- <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用に合成する段階で切り刻まれている。コックさんが「物理的にこういう手の人」だったという可能性も無くは無いが稀であろう。 もともとTVカメラの走査線は一本飛ばしで映像を捉える。空間軸画質を最初から大胆に間引いてあるのだ。パソコンの言い方で言うと、解像度が 720x480あったとしても、一枚のフィールド上の実データは720x240しか存在しない。もしも正確にフィールドだけを表示できるなら、ブラインド越しに見たような絵しかでてこないハズだ。これが上で言う"missing" lineの意味。 インタレ解除の本質は「失われたデータの復元」ではなく「もともとこの世に存在しないデータのでっち上げ」。 余談ながら、インターレースはもともとブラウン管の構造に則したしかけ。電子銃による管面走査機構のない機械に余分な機構を強いる。これは液晶、PDP、 SEDを問わない。高柳健次郎博士御存命なれば、地デジ規格は断然 1080p/720p@30fps以上を主張されたであろう。 |
-vf yadif=3,mcdeint,framestep=2 -ofps [素材fps]
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の処理速度といい感じにバランスするのでしょう。処理密度とか、命令粒度とかいうのかな。
yadif=[mode[:field_dominance]]【メリット】
Yet another("もちっと気の利いた"みたいな語感があるらしい)デインターレースフィルタ。
- <mode>
- 0: 1フレームを1フレームとして出力。(*実験ではデフォルトの模様 *)
1: 1フィールドを1フレームとして出力。
2: 0 同様。ただし空間軸のインターレース検出をスキップ。
3: 1 同様。ただし空間軸のインターレース検出をスキップ。
- <field_dominance> (DEPRECATED(*非難された?論争中?*))
- tfieldsと同 様。
NOTE:このオプションは将来削除される可能性があります。
その場合は、-field-dominanceで 代用して下さい。
インタレ解除能力は概ねfilmdintよ
り上。解除漏れは僅かで細かい文字等の潰れもほぼ無視できる。またPPCでは、x86専用の感が有るfilmdintより安心して使える。
以前は30/24fps混在アニメに使うと、24fps部分に止め絵のスクロール(カメラパン)でカクツキが発生するケースがあったが、07年04月現在
はほぼ気にならないレベル。
pullupベースのビデオフィルタチェインに比べると、アニメでカクツキを感じるケースは大幅に減
る。
手軽なのでめんどくさかったら全部コレに任せてもいいかも。
時おり映像全体が1ピクセル上下する。おそらくこれが原
因で、ズームイ
ン、ズームアウト、パン(横方向のパン)、ティルト(縦方向のパン)、実写のまばたきや唇の動き、アニメの主線などにpp=mdに似た、しかしもっと細か
い地味なジャギが出
る。「縦方向のジッター」と言うようだ。確かに地味にイライラする。
とくにyadif=3:1,mcdeint=2:1:20などで60fps化するとジッターは
distractingの
レベルになるようだが、これは後述。
ちなみにmcdeintで30fps化する場合でもこのジッターをベースに動き補償を行うので手許では最終画質に大差を感じない。
AviUtil
やAviDemuxで見かける「(自動)フィールドシフト」という概念は、おそらくこの辺をなんとかすんのだと思う。閾値に基づいて適応的にトップフィー
ルドとボトムフィールドの合成手法を弄るとか、そんな感じか?
したがって、純粋性能はAviUtil/AviSynthで使えるも
のに劣ると思われる。
また、pullupベースのビデオフィルタチェインに比べると、x264のSSIMが落 ちる。まだ充分な経験値は溜まっていないが、手許の設定では0.97台後半になるケースが多い。経験上、x264では24fpsだろうが30fpsだろう が60fpsだろうが、skip/directマクロブロックの効果でそうびっくりするほどの差はでないと思っていたが、CPUに言わせりゃジッターは縦 1ピクセルの「ディテイル」だ。数は少なくてもなかなかビットを喰うと思う。全体的な画質に目で見て解る程の違いはないし、時間軸画質の向上を考えるとお 釣りがくるので目くじらを立てる程のもんではないが、アニメが0.98切るのは悔しいな。
作者はmcdeintと同じく
Michael's
Niedermayerさん。ffmpeg、MPlayer、libavcodec、なかんずくSNOWのキーマン。
mcdeint
と同じく、mmxなどへの最適化余地が大きい模様。Altivecもよろしくおねがいします。
-vfm ffmpeg -vf yadif=3,pp=l5,framestep=2,,, -ofps 30000/1001
※-vfチェイン内部は書いた順番に適用されます。
TV放送のフィールドオーダー(トップフィールドとボトムフィールドの順番)は、通常はトップフィールド・ ファーストらしいのだが、なぜか不規則であるらしい(続 フィールドオーダーのナゾ)。
おそらくコレが理由で、yadif=0または2(1フレームを1フレームとして出力)では、映像全体が1ピクセル上下するコマが出る事がある。「縦方向のジッター」と言うらし い。
おそらくこれがびみょ~~~にジャギが残って見える理由だと思う。ズームイ ン、ズームアウト、パン(横方向のパン)、ティルト(縦方向のパン)、実写のまばたきや唇の動き、アニメの主線などで、地味にイラつく事がある。
また同じ理由から、yadif=1または3(フィールドをフレームに展開して60fps化)では、フレームの時間軸スイッチバックが起きる。可能性があ る。
AviUtilには(自動)フィールドシフトという理屈を使ってこのへんを良きに計らってくれるプラグイン があるようだが、当然ながらMacでは使えない。悔しいので一応DLして読めるとこは読んだ。すげぇ巧緻な事をやっている印象を受けた。フィールドシフト はAviDemuxにもある。でもPAL専用だ。MEncoderの-vfにフィールドシフトと解釈できそうな文言は無い。
そこで、だ。
まずyadifで60fpsで吐き、吐いたもんをpp=l5で一律に混ぜちゃえば、バー
チャル・フィールドシフトになりゃしませんか、
と。
yadifで殆どのインタレ縞は取れる。ただし、ジッターとフレームの時間軸スイッチバックが残る。
pp
=l5で一律に混ぜちゃえば、ジッターのズレも混ざる。ボケだからあんま望ましくはないが、ここで混ぜるのは60fpsで吐いた前後フレームだ。悪影響は
30fpsを混ぜるより弱い。
最後にframestep=2でフレームを一個飛ばしで捨てれば、時間軸スイッチバックが消える。
、、、 ハズだ。
pp=l5は単独ではジャギと色合いの劣化が目立つけど、yadifの後ならインタレ縞はほとんど取れ ている。また色情報はYUV4:2:0では前後フレームで共有してるから、60fps化したものを混ぜるならフィールドオーダーがどうだろうと色の混濁は 最小限になる。ハズである。
#!/bin/bash※x264 lossless設定の詳細は、H.264/AVCロスレス~其の弐を参照。
# 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
仮番 | -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) |
B1 | A4+B1 |
---|---|
![]() |
![]() |
仮番 | -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) |
経験上、結果は素材によって非常
にばらつくので、手
許では実験の時だけ死ぬほどコマ送り
で見ます。
でも目が疲れるのでほどほどにしたほうがいいと思った。あとMacだと拡大してもOSがなんか補間してくれるっぽいの
で、素直にピクセルの角が出
ません。
agehaにオリジナル無し
更新履歴