| 名 前 | コメント試訳 | メモ |
|---|---|---|
| 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
がやっている事がとの類似がどの程度かも知らない。しかし、一般的な補間ではないデインターレーシングに関する文献は、オンラインでフリーのものは１、２
個しかないので（この事は確信してる）。いつもは他の文献を読んでいない。もしかしたら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の
段階でフレームレート２倍のインタレ解除済みになる。であれば、その後で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はフレーム枚数を倍にする。だから（＊コマンドオプションの＊）フレームレートを手で修正しなきゃいけなくて、 で、最終的にできあがりは２倍の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に見えるからだ。 こ れはアプローチとして正しいだろうか？ |
