Deinterlacing (using MVTools2, perhaps?)

[CarlEdman]

What is the current state of the art for deinterlacing interlaced DVD or 1080i broadcast content?

For the last few years, I've been using:TomsMoComp(1,5,1)

And actually, I'm pretty happy with it. It is simple (and most content where I really care about quality is progressive anyway), fast, and does not create any major artifacts like many of the other de-interlacers I tried in my experimental stage.

That is not to say that TomsMoComp is by any means perfect. It does leave small, visible artifacts in certain material. It is just that I've been willing to live with these.

I have also been using the current MVTools2 MDegrain3 filter:Interleaved2Planar()
super = MSuper(planar=true)
bv1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
fv1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
bv2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
fv2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
bv3 = MAnalyse(super, isb = true, delta = 3, overlap=4)
fv3 = MAnalyse(super, isb = false, delta = 3, overlap=4)
MDegrain3(super,bv1,fv1,bv2,fv2,bv3,fv3,thSAD=400,planar=true)
Planar2Interleaved()
This is, needless to say, a CPU hog, but produces output which (to my eye) is of such a high quality that I'm willing to spend as many cycles on it as on 'x264 --veryslow' encoding. (Not to mention that it tremendously improves compressibility while--again, to my eye--actually producing visually better final output).

But, and here I would appreciate correction and advice by the real avisynth/video boffins, much of the hard work in doing real high quality de-graining and de-interlacing (i.e., motion compensation) is really the same job.

So ideally, I'd love to use a de-interlacer which could piggyback on the hard work of my de-grainer and produce even better de-interlacing with a little or moderate additional CPU impact.

I understand that two of the most highly regarded de-interlacers (MVBOB and MCBOB) do take this approach. However, both seem to be (a) based on the original MVTools, rather than the current MVTools2, and (b) no longer maintained/under development. So I am not quite sure how to integrate approaches like MVBOB or MCBOB with my de-interlacing.

Any and all advice (including unrelated to MVTools2) gratefully appreciated!
:thanks:

[Didée]

You might want to have a look into TGMC (http://forum.doom9.org/showthread.php?t=133826) (where it all has started - the initial appetizer (http://www.mediafire.com/?mzdzmbyjnmg)), and better yet into QTGMC (http://forum.doom9.org/showthread.php?t=156028) (what in the meantime has evolved from that.)

[CarlEdman]

Thanks, Didée. Not exactly what I was looking for because it replicates the motion compensation work of the MVTools (right?), but results you posted are so impressive, I'm going to try it anyway.

[Didée]

Not exactly what I was looking for because it replicates the motion compensation work of the MVTools (right?),
Huh? Sorry but I don't quite see your point here?

Long story short - in regards to result's quality, QTGMC is unrivaled on planet Avisynth. To get something comparable from a "commercial solution", you'd have to pay big money. :)

[CarlEdman]

Actually, I may have been wrong. Upon studying the code and documentation of QTGMC, it appears that it generates the MVTools2 motion vectors itself and makes them available for later use. So, I imagine that I can just reuse them for MDegrain3 later in the avisynth script.

And, I agree, the results are excellent.

Any advice on whether to SelectEven() the QTGMC output? That would preserve the 30 fps rate, but the frame-double output should compressed by x264 to something only very slightly large, should it not? So if the frame-doubled output looks better, I might be inclined to go with that, regardless.

[Didée]

When set up accordingly, QTGMC can do your MDegrain3-Denoising in one go. If it's only for that, then there's not much need to re-use the motion vectors to use them manually in a separate MDegrain.

Regarding bitrate - generally, 60p needs more bitrate than 30p, that's obvious. However, since QTGMC basically is a (specifically drilled) temporal smoother, the output is particularly compressible. Some time ago I compared a interlaced source Yadif-deinterlaced to 30p with TGMC-bobbed to 60p, and the 60p required about the same bitrate than the 30p did. (Actually even a bit less bitrate, at same CRF in x264 ... which is a bit whacky, since x264 nowadays interprets the same CRF a bit differently, in relation to the actual framerate.)

[CarlEdman]

:thanks:Very interesting. And thanks again for sharing your knowledge.