State of the Art in De-Interlacing?

[CarlEdman]

What is the currently accepted state of the art in deinterlacing 60i to 30p content?

I have been using scripts of the form:
...
Bob()
...
MFlowFps(super, bv1, fv1, num=30000, den=1001, ml=100)
...

That seems to be working pretty well for much content and takes advantage of the fact that I'm doing all the MAnalyse() steps for degraining anyway.

But I have noticed some unpleasant artifacts in some content anyway and would like to get rid of it. I used to use a lot of specialized deinterlacing filters in the old days, but I am sure people have come up with something better by now.

Any suggestions?:thanks:

[StainlessS]

Try QTGMC a few posts below this one. I dont really use it myself but believe that it is considered pretty good by many.

[johnmeyer]

I think QTGMC is pretty much the "go to" script for this sort of thing. As always YMMV.

[Sparktank]

I've mostly had just film content, not too much real interlacing, so I've used primarily tfm().TDecimate() with DGdecNV as my indexer.
the old dgdec is also decent, but the NVidia version is much more updated.

I've looked at QTGMC a lot. It seems to look very intensive with a lot of praise.
Did some tests on really old computer and liked it.
But it's very slow, on one hand. But considering the reviews, if I had to go deeper, I would scour through the QTGMC thread for all available updates to get the newest versions for compatible plugins.

I think it's quite jumbled, even if you use the search function to find a download for any updated plugins. not everyone uses the same words when posting an update to any plugin/script.
Using the word "update" as a search term just brings up people asking about udpates.
There are updates and some patches and other versions (not maintained by -Vit-) that are not included on the first post (first post maintained by -Vit-).
You would need resolute patience to sift through that thread (I suggest start from the end and go backwards) to find the most you can from there.

[johnmeyer]

I've mostly had just film content, not too much real interlacing, so I've used primarily tfm().TDecimate() with DGdecNV as my indexer.Just to make sure we are on the same page, inverse telecine (IVTC), such as that provided by tfm().TDecimate() is not deinterlacing. Yes, there are some film telecine patterns that do result in some residual combing that must be removed, and perhaps that is what you are talking about.

[Sparktank]

Yes, IVTC residuals combing was what I was talking about.

[johnmeyer]

Ah, that's a little different problem. I wish I had a good suggestion for you, but the only thing I can think of is to play around with the various TFM/Tedicimate post processing settings.

[feisty2]

vinverse maybe?

[CarlEdman]

Thanks for all the advice!

I use tfm.tdecimate() all the time for telecined content. It not only does a perfect job on exactly telecined content, but also a very creditable job on the small fraction of non-telecined (i.e., interlaced) content commonly found even on mostly telecined DVDs. But of course that is not the right solution for content which is actually 100% (or nearly so) interlaced content.

As for QTGMC, I did try it some years ago as an upgrade to my current mostly MDGrain3() based standard script. But I found that at settings which appeared comparable to what I currently use with my own pretty CPU intensive scripts and settings, processing speed declined from about 16-18 fps for SD and 6-7 fps for HD content to 1-2 fps which was just too slow even for my setup. Also, I've been a little reluctant to use QTGMC because I've been doing this for a long time and I like to understand exactly what is going on and QTGMC is just a little too much of a incomprehensible black box to me.

Anybody else try vinverse? It does seem to be modern, in contrast to a lot of the ancient avisynth tools most of us still use, but does require upgrading to avisynth 2.6 alpha. I assume you need to use it to improve the results of another deinterlacer, rather than as a deinterlacer in its own right?

That said, maybe I'll give QTGMC another try if there is nothing competitive out there. Any other suggestions?

[StainlessS]

Dont be afraid of Alpha 5, it hardly ever bites you, fixes many problems in 2.58.
There are a couple of problems (1 in particular with Overlay, [EDIT: YV24]) in 2.6 but on the whole is a much better
job than 2.58. (If IanB is truly deserting us, then would be nice if at least the few current known problems could be cured before farewell).

[Reel.Deel]

Anybody else try vinverse? It does seem to be modern, in contrast to a lot of the ancient avisynth tools most of us still use, but does require upgrading to avisynth 2.6 alpha.

That particular Vinverse in the wiki (http://avisynth.nl/index.php/Vinverse) is indeed for AviSynth 2.6 only. It's part of tp7's modernization effort (http://forum.doom9.org/showthread.php?t=169832). It's faster than the old one, it also supports all planar formats, and it includes Vinverse2 (a less aggressive variant of Vinverse). If you're looking for the original Vinverse for Avisynth 2.5.8 you can find it here (http://avisynth.nl/index.php/Vinverse/2.5). But beware, 2.5.8 is considered outdated and less stable than Avisynth 2.6.0 Alpha5 (http://forum.doom9.org/showthread.php?t=168764) (see this thread here (http://forum.doom9.org/showthread.php?t=168478)).

[StainlessS]

see this thread
In particular this: here (http://forum.doom9.org/showthread.php?p=1629125#post1629125)

[foxyshadis]

Remember that QTGMC has presets from Ultra Fast all the way to Placebo; it defaults to Slower because it's meant to be top-notch quality, but it can go a hundred times faster, and no matter how fast you go it should be better than an equivalent standard deinterlace. It'll never match the speed of Bob or Yadif, of course.

[hello_hello]

If I use QTGMC I generally create a copy of the script and add Trim() to the end of each one so they both encode around half the video, then I run the encodes simultaneously. If you have a quadcore CPU that should keep it busy and even if you're encoding at 6-7fps, it should be 2x 6-7fps. Just make sure to add --stitchable to the x264 command line so you won't have a problem appending the encoded video.

The main (maybe only) criticism I've read regarding QTGMC's default de-interlacing settings is it's a bit sharp, so some people reduce that a bit. I don't like sharpening as a rule and the default settings are mostly fine for me.

I don't encode much interlaced video these days, but a while back I started experimenting with filtering a bit more and made the mistake of trying QTGMC in progressive mode. Now it tends to be my go-to filter for stabilising the picture and removing noise. A few initial comparison encodes of a fairly horrible progressive source (http://forum.videohelp.com/threads/358043-A-comparison-of-AVIsynth-denoise-filters?p=2283228&viewfull=1#post2283228). The default settings for each filter/script.... aside from adjusting QTGMC's EzDenoise strength. ie QTGMC(InputType=1, EzDenoise=4)

[hello_hello]

Remember that QTGMC has presets from Ultra Fast all the way to Placebo; it defaults to Slower because it's meant to be top-notch quality, but it can go a hundred times faster, and no matter how fast you go it should be better than an equivalent standard deinterlace. It'll never match the speed of Bob or Yadif, of course.

The Ultra Fast preset uses Yadif for de-interlacing doesn't it? Even if it does though, I'd assume it'd still be better than Yadif on it's own, although I've not compared them myself.

[foxyshadis]

I started experimenting with filtering a bit more and made the mistake of trying QTGMC in progressive mode.

I love the way you put that. Once you step into the woods, you can never go back! I should play around with it for stabilizing.

The Ultra Fast preset uses Yadif for de-interlacing doesn't it? Even if it does though, I'd assume it'd still be better than Yadif on it's own, although I've not compared them myself.

It does! But it still runs motion-compensation, temporal smoothing, and a quick attempt at repair at the end, so it's still somewhat slow. There's even a "Draft" mode that uses bob and does no repair, but otherwise isn't much faster.

[Mole]

I too have discovered that InputType=1 can do quite wonders on many progressive sources. There are several commercial DVDs here in Thailand where they have for some reason decided to use something which looks like pointresize (perhaps the result seems to be more "sharp" than other resample methods) when they mastered the DVDs. The shimmering during movement is quite distracting and InputType=1 does wonders to fix this.

[aldix]

If I use QTGMC I generally create a copy of the script and add Trim() to the end of each one so they both encode around half the video, then I run the encodes simultaneously. If you have a quadcore CPU that should keep it busy and even if you're encoding at 6-7fps, it should be 2x 6-7fps. Just make sure to add --stitchable to the x264 command line so you won't have a problem appending the encoded video.


How does that work exactly? I know I've attempted to use --stitchable in the past, but once I'm done and try to mux everything together with mkvmerge, it whines about matching whatnots and just fails.

What am I doing wrong?

Edit: Yeah... just wasted about a day doing two mkvs with --stitchable enabled, and once I tried to mux it threw an error and as a result I have a video file with 2 video tracks...

Edit #2: thanks for all the 'help'. Finally figured it out on my own (as always pwnt fools). Have to encode with .264 and then use vjoin and mkvmerge with specific config. Never would've figured it out without using Ripbot, though. Uses the exact same tactic, that.