Well, that's a side-effect of the temporal processing. (There often is a positive effect on dotcrawl, but it's not a specialised feature --> "YMMV").
The main point of that small comparison is instability & flickering of the actual detail.

Just yesterday I played with a DVB cap of a 50i TV show, and compared TGMC with HW-deinterlacing via DGDecNV. No need to mention that TGMC was stable and NV-Bobbing was flickering. But another point was the encoded filesizes:

x264 @ CRF 18:

TGMC-bob: ~5100 kbps
NV-bob: ~9500 kbps

That is, HW deinterlacing required almost double the bitrate to encode something with noticeable lower quality.

__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)

That is, HW deinterlacing required almost double the bitrate to encode something with noticeable lower quality.

Based on what it did to the dotcrawl, which can be quite expensive to encode and the massive boost to over-all temporal stability from TGMC, I would be much more surprised if there wasn't a large difference in file size.

A more apples to apples comparison might be denoising the other bobbers with mvtools and then checking their file sizes, though that isn't a very realistic usage scenario, pretty much everyone would just use TGMC in such a situation (or rather, they should). I suppose for speed purposes actual usage might look like hardwarebob->fft3dGPU, which is no longer directly analogous to TGMC qualitatively (almost purely spatial vs almost purely temporal processing, everyone knows how that ends).

- Plain CUDA bob is not good at deinterlacing, forces very big bitrate, but at least it is fast.

- CUDA with MDegrain2 is same bad at deinterlacing, still requires much bitrate, and it is not fast anymore.

- TGMC is TGMC.

All in all, this is too much noise about something very simple: HW deinterlacing can be an option for live viewing, but for encoding it is not a good choice. (Well okay, maybe for "burst encodings" ... in any case it's beyond me how someone with functionable eyes could rate this as "good quality" ...)

__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)

All in all, this is too much noise about something very simple: HW deinterlacing can be an option for live viewing, but for encoding it is not a good choice. (Well okay, maybe for "burst encodings" ... in any case it's beyond me how someone with functionable eyes could rate this as "good quality" ...)

I think I may have been unclear, my intention wasn't to indicate that your conclusions were wrong. TBH I have always completely agreed with your conclusions regarding hardware bobbers, I just felt there was a bit of sloppiness in demonstrating it, so I played a bit of devils advocate. No harm meant.

Using 'import' is an option that some might prefer. However, Avisynth will autoload any '.avsi' files in the plugins folder, which is often more convenient. Downside being that you get problems if you end up with multiple versions of the same plugin in the autoload folder.

Edit @FlaShow: those QTGMC settings will not do any noise processing. Please read the manual:

Quote:

Originally Posted by documentation

Important: You must use a non-zero value in one of EZDenoise, EZKeepGrain or NoiseProcess or no noise processing will occur

Nevermind this! Everyone reading this, please see the next few posts before bothering with the files I mention here.

Just a quick note, I see in the OP that you're offering an older release of RemoveGrain 1.0, with the SSE3 issues; there's actually a newer version available (binaries and source), as per the final post in this thread on kassandro's forum. Apparently it was a problem with the Intel compiler he had used at the time, but the bugs have been addressed with these 2007 releases.

I've been using the SSE3 libraries from those archives for some time now, and have had no problems beyond what one expects when trying to multithread (Q)TGMC.

Fizick: The plugin package only contains unmodified binaries, so I only need link-to / offer the original source. I'll add a text file to the zip.

Robert Martens: Thanks, I'll check that out. I knew about the SSE3 problems - the plugin package contains the SSE2 version. But this might make things simpler. Although I recall that there's very, very little SSE3 code in it in any case...

pio_fawad: I assume you are deinterlacing, and want to remove some grain and other artefacts at the same time? Well QTGMC with those settings will help, you could add "TR2=2" or "TR2=3" for more smoothing/degrain. Or "EZDenoise=X" to remove noise, where X is a value that depends on how noisy your source is (anywhere from 0.5 to 40). However, there are many other specialized plugins that might be more effective at the clean-up.

Basically, I agree that the "official" v1.0 version should be preferred over the older pre-v1.0 versions. But then, how it comes that e.g. a certain Mr. Didée is regularly recommending the old pre-v1 version?

- v1.0 final is only backwards-compatible with pre-v1 in regards to the spatial filters.

- v1.0 final is backwards-incompatible in regards to the temporal filters. Namely, clense().

In effect, when v1.0 is getting used, then 99% of all scripts/functions that are using clense will not work anymore.

Of course the older scripts can be adapted accordingly. But it'll be a long way to go, with dozens or hundreds of mini-scriptlets out there that people might pick up from here, there, or elsewhere.

And, the final showstopper:

RemoveGrain v1.0 final is not documented. There are substantial changes that cause backwards incompatibility, and there is no documentation how to use v1.0 correctly.

That's a problem.

Staying with the old version might be somewhat unsatisfactory, but the situation is so that it avoids lots of problems.
The other way round, there's actually not much to "gain" from switching to the v1.0.final version. People crying for the SSE3 filters simply are clueless. The potential speed gain is practically irrelevant.

__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)

I must admit to being a bit confused with the various RemoveGrain packages; I was under the impression the only difference between the version Vit has been offering in the first post and the one I just linked to was that the newer release fixed a problem with SSE3 instructions.

I'm not terribly concerned about using said instruction set, and can easily imagine there's minimal performance gain, but if it's a choice between recommending and distributing a broken release and one that's been fixed, I thought the latter would be preferred.

Of course, as you explain, that's apparently not all that's changed from one version to the next.

If I could bug you to clarify something, however, what do you mean by "1.0 final"? The file I mentioned is listed as "1.0 prerelease" on the wiki. Do you recommend using what that page labels "1.0b" instead? That is to say, Vit's got nothing to change in his recommendations and I will instead need to modify mine?

Robert: I thought you were referring to a version of RemoveGrain I hadn't seen (I haven't really explored Kassandro's forum), but this is one that I deliberately avoided using after reading Didée's points above in an earlier thread.

There are three versions:
- v0.9 is the only one to contain SSE3Tools, which I need for YUY2 support. But it doesn't contain some newer modes which QTGMC uses. So I link to that one in the OP but indicate to take only SSE3Tools
- v1.0b (beta) contains all the modes, has source code and documentation, but doesn't contain SSE3Tools. It also has an SSE3 bug, but no real SSE3 code. I link to that in the OP and indicate to take the SSE2 versions
- v1.0 (pre-release) contains the SSE3 fix, but also some other undocumented changes and no source code. I cannot recommend that one.

I have noticed that the html documentation needs to be updated on these points though.