Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
23rd March 2011, 09:23 | #501 | Link | |
Registered User
Join Date: Feb 2004
Posts: 1,348
|
Quote:
|
|
23rd March 2011, 11:26 | #502 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
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!) |
23rd March 2011, 18:23 | #503 | Link | |
Registered User
Join Date: Feb 2004
Posts: 1,348
|
Quote:
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). |
|
23rd March 2011, 23:35 | #504 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Well, it'll never be apples to apples. Because of the different technics, there will always be some flavour of peas and bananas.
For reviewing, a 15sec sample ... Code:
x264 --crf 18 --tune filme CUDA-bob, direct: 8530 kb/s +86% CUDA-bob + MDegrain2: 6422 kb/s +40% TGMC: 4585 kb/s [ref] - 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!) |
24th March 2011, 03:06 | #505 | Link | |
Registered User
Join Date: Feb 2004
Posts: 1,348
|
Quote:
|
|
26th March 2011, 17:20 | #506 | Link |
Registered User
Join Date: Aug 2010
Posts: 47
|
Hello,
I want to run this code: Code:
AVISource("Kids_16.avi") QTGMC(Preset="Slower",ChromaNoise=True,denoiser="dfttest",DenoiseMC=True) dfttest() deen("a3d",4,8,9) aWarpSharp(depth=12,blurlevel=4,thresh=0.2,cm=1) nnedi3_rpow2(2) LanczosResize(1024,600) What should i do ?!! |
26th March 2011, 19:03 | #507 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Make sure you have installed avisynth properly. You must put the QTGMC.avsi script in your Avisynth plugins folder.
I have added a zip of all the required plugins in the first post. It contains instructions where to put everything. |
26th March 2011, 20:27 | #509 | Link | |
Registered User
Join Date: Jul 2010
Posts: 448
|
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:
Last edited by -Vit-; 27th March 2011 at 04:42. |
|
27th March 2011, 14:48 | #512 | Link | |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
Quote:
__________________
My Avisynth plugins are now at http://avisynth.org.ru and mirror at http://avisynth.nl/users/fizick I usually do not provide a technical support in private messages. |
|
27th March 2011, 17:15 | #513 | Link | |
Registered User
Join Date: Feb 2011
Posts: 38
|
hi,
thanx 4 script can u please tell if i leave script as Quote:
THanx please tell |
|
27th March 2011, 17:25 | #514 | Link |
Registered User
Join Date: Feb 2010
Location: New York
Posts: 116
|
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. Last edited by Robert Martens; 27th March 2011 at 18:50. |
27th March 2011, 17:29 | #515 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
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. Last edited by -Vit-; 27th March 2011 at 17:40. |
27th March 2011, 18:05 | #518 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
The situation with RemoveGrain package is tricky.
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!) |
27th March 2011, 18:21 | #519 | Link |
Registered User
Join Date: Feb 2010
Location: New York
Posts: 116
|
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? |
27th March 2011, 18:41 | #520 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|