QTGMC Deinterlacing Script (v3.32)

[henryho_hk]

Sometimes heavy grain kinda confuses (Q)TGMC.... and I find degrainmedian(mode=2, interlaced=true) helps. I also prefer "tr2=3"

[-Vit-]

Single-rate motion-blur: would slot-in nicely at the end of the script, and would be able to reuse the motion vectors (they might need a reanalyze). I'll try it at some point, but I'm looking at other things at the moment. Not so hard to try yourself - do it in the "Post-Processing" section on the clip "addNoise2" - can see all the mo-co settings a few lines further up where there are some MDegrains.

Static areas: It's not right to say that QTGMC doesn't care for static areas. QTGMC with source match is damn good on static areas. It's much better than the standard TGMC algorithm.
QTGMC( SourceMatch=3, Lossless=2, Sharpness=0.05 ) is near perfect in most cases. QTGMC( SourceMatch=1, Lossless=2, Sharpness=0.05 ) is almost identical, but faster. You can drop the Lossless=2 part for a bit more speed, a bit less accuracy and to avoid worries about artefacts with lossless processing. Tweak the sharpness in each case, may need more if you switch Lossless off - the default for source-match is 0.2

@matfra: I tend to use QTGMC + noise bypass to remove the worst of the noise, but not all of it as that can reduce the quality of the QTMGC processing (the mo-co needs a bit of fine detail to "grip" on to, if your "denoising" starts to become "blurring" then that's a problem). I follow up the QTGMC with a finer denoise step (mdegrain, another FFT3DFilter with a lower Sigma, whatever). Edit: And yes, I may well expose the thSAD settings again.

I hadn't anticipated so much interest in the denoising aspect of QTGMC. It was never intended to be a denoiser, I originally wanted to retain grain in some vids. Recently my interest was caught when I realized you could nicely "deinterlace" noise with motion compensation. However, that's about retaining noise too (or more precisely, detail that has "noise-like" properties). This part of the script is going to undergo some change: (a) to finalize my mo-co noise-bypass technique and deal with chroma noise, (b) simplify the settings, so it's more obvious what the settings actually do, and (c) reluctantly, I'll put some more control over the straight denoising aspects as obviously some people want a one-stop solution for their sources [but QTGMC is never going to be a replacement for a fully featured denoiser].

[Didée]

Perhaps my wording was not good.

What I meant is: neither Q nor TGMC do a "detection" of static areas. Deinterlacers like e.g. tdeint try to detect static areas, then perform "static->weave, motion->interpolate". Which is okay when the detection is okay, but problematic when the detection is wrong. See tdeint's plentitude of parameters that are dealing with / related to artifact protection.

And yeah, QTGMC's source match delivers good results. Though, I think something should be done about "lossless=2". It's not really convenient to first have a "lossy" deinterlacer, then offer a "lossless" option, but still produce a "lossy" result in the end. Lossy is lossy, lossless is lossless.

Nothing against the operations as such, they are fine. It's just that they should be structured differently, somehow.
(I like to drink milk as well as beer. Both are fine. But when I order "beer", then I want to get beer, not milk.)

[-Vit-]

I don't like the name of the Lossless=2 setting either, and considered alternatives. From a scripting point of view, it really is exactly the same process as Lossless=1 (real lossless), just done earlier. But from a user point of view it looks like a source-match extension - yet it's completely independent of source-match. The "logical" alternative is to make Lossless a boolean (true, false) and add a new setting, say "SourceMatchBoost" or something, also a boolean. Before I was sensitive to adding even more settings because I thought that you couldn't have more than 60 of them, but now I think that's a limitation from an earlier version. So maybe I will make a change like that...

[Robert Martens]

I think the simple merge() is out of consideration as we can use a simple and speedy blend-deinterlacer at the first place, no need for the sophisticated QTGMC() script.

I agree that it's probably the way to go for those who want things done as fast as possible, but I'd still recommend people at least give Merge() a shot; it's been a while since I've done any real investigation, but I've never seen a blend deinterlacer (or any deinterlacer, for that matter, save MCBob) that comes close to (Q)TGMC as far as producing clean curves and diagonal lines. Using Merge() gives blend-style results while retaining the neat, smooth edges TempGauss and its variants manage to create.

I don't mean to suggest that there's a perfect solution, but if you're as easily irritated by aliased diagonals as I am, you may find Merge helpful for same-rate output.

[sadie]

Well after a full 24 hours of encoding I've obtained 3 full 1-hour encodes using the triad of Yadif, Tdeint and QTGMC. To be frank, much of what I'd commented on earlier this morning turn out to be unfounded. A 1-minute source using single pass settings with non-geometrical subject matter cannot be the litmus test for deinterlacing which excels at straight lines and curves. In fact it was a pure pleasure to go through scene after scene, the first such joy I've felt in some time now in this domain. Finally, a real wheel that works.

To be short, Yadif can match QTGMC in some areas but fails in others. Tdeint can match QTGMC in other areas but fails in turn elsewhere. But none of them can match OTGMC all the time in all areas, much less surpass it. And surpass QTGMC does most of the time. As for detail in static areas, I again spoke to soon. What I mistook for 'sharp details' in Tdeint were in fact artefacts, that because they were in a natural milieu (a stone here, a water droplet there) were not readily apparent as 'errors'. In fact, even with my still captures edges with your program were as good if not not a tad better than even Yadif.

The noise present in my source (for better or worse) was reproduced perfectly. Like Vit, I'm no enemy to noise as such except for certain classic areas such as fade to blacks over bright blue skies or darkish monochromatic walls. It's been my bane for years and perhaps I'll take a stab at some of your suggestions above, or again just throw a whole lot of 'bitwidth' at it (or is that bandwidth). I think Henry Ho will remember a few years back we had huge go around on this board to try and fix an earlier problematic clip.

It took me nearly 6 hours per pass using the 'fast' preset (no MT). I take it if I dared to take the source match route we'd be talking at least double time, no? Which brings me back to Didee and his partial answer to my question. The 'fast' preset did not eradicate all errors. In fact, in those rendered slow motion sequences where the rate was .5x or less QTGMC cleaned it up. But on two static but unstabilized examples where the slow down went as low as .2x it had no effect. So if I'd delaced before using the filter, I'd probably not have suffered the consequences. Or not? Which brings me also to ask whether there is a version in the works of this avisynth script to be of use in a major commercial NLE. Is there a practical workaround (other, that is, than that of delacing the entire body of source material from the outset)?

I may have noticed a slight anomaly. The QTGMC encode (via virtualdub x264 fast recompress) appears slightly darker/contrastier/more saturated than any either the Yadif or Tdeint encodes (using Avidemux x264) or the straight to DVD route with Procoder v3. The latter three are identical luma & chroma-wise? On my screen the effect is actually an improvement under mplayerhc using either VMR 7 windowed or Haali renderers. Any explanation? And I'd still be interested if anyone could compare their experience with Oppo/Faroudja.

For the anecdote, I was so ticked off last week about the whole interlace to progressive problematic that I decided to kiss it all good-bye and gave my daughter my Panasonic GS400. Trouble is she's a tough cookie and I fear there is now no getting it back. Well, maybe I'll just go and write a detective novel.

[STC-Fan]

STC-Fan ,
Can you explain me the difference between MDegrain2 and you Mdegrain2i2 ? Its it for interlaced source ?
MDegrain2i2 is for interlaced content only. The code is straight from fizick's MVTools2 page but with values from Cnr2 passed to it, which was added by someone on the VideoHelp forums.

This video isn't interlaced, there aren't two different fields in each frame. It's more like there's an offset between the odd and even lines in places giving combing-like effects.

Yes, I am seeing them now - and as henryho_uk pointed out just doing a SeparateFields() operation shows it up as well. I'll certainly make use of this a bit more in future as I suspect a lot of the other files I have have come out in this way, and are not really interlaced at all. I haven't really given it much thought before, aside from noticing the smaller and less frequent nature of combing artifacts, but I think only the content I have from the 1990s / 1980s is truly interlaced, so I probably need to treat more of the post-2000 content in the same way as for this Castrol video.

If you do use QTGMC, then flag it as progressive input, e.g:
QTGMC( Preset="xxx", InputType=1, TR2=3 ) # TR2=1,2,3 for some temporal denoising (mdegrain-based)
VInverse() # This helps too

EDIT: I've dropped in those settings (including Vinverse) as above, commented out the separate MDegrain2i2 and the results are very good - I hadn't realised MDegrain was actually used in QTGMC but looking at the preview in MeGUI and the final output encoded to x264, using QTGMC with TR2=3 removes all the noise that MDegrain2i2 was removing before, but is leaving a sharper finish. And the encoding speed hit nearly 10 FPS so that's a big improvement on the previous settings :)

[-Vit-]

I take it if I dared to take the source match route we'd be talking at least double time, no?
Not so much as that: I just did a quick single-threaded test and it's around 15% slower with SourceMatch=1, Lossless=2 when using Preset="Fast". Nice detail improvement too. A slower system might suffer more though...

The QTGMC encode [...] appears slightly darker/contrastier/more saturated [...]. Any explanation?
Try "Precise=true". To get a tiny bit more speed, QTGMC removes a couple of minor adjustments by default. I haven't looked at that setting for a while, it may or may not be relevant. I'll be looking carefully at the chroma side of the deinterlace for the next significant release - I'll take the time to do some similar comparisons.

[Didée]

The QTGMC encode [...] appears slightly darker/contrastier/more saturated [...]. Any explanation?
I reckon it's a playback issue, and/or the video got flagged differently by the different applications, or sth like that. When I compare bob/yadif/tdeint/qtgmc with levels(), the histograms are virtually identical. No darkening / lightening / contrast spreading is taking place. Everything's like it should be.

[sadie]

Thanks Vit, for your encouragement on the source match info. Doesn't sound as bad as all that. I'll give it a try next.

As for the eventual luma/chroma shift, yes, Didee that's what I originally thought as well. I've experienced it often in the past where it seems to be related to one of two issues, perhaps related. One is somehow connected with overlay. If I open any mplayerhc file under Xpsp2 system default (VMR7 windowed) I'll be presented with an image that is to my eyes flat, over-ex, washed out. If I open a second instance (or more) of that same file the video will then manifest the richer deeper color associated with my edit. Windows is apparently using a different color space the 2nd time around. Yet in the past the simple action of switching to Haali renderer corrected this anomaly. Haali would open all instances of the video with same color space/balance (whatever you want to call it). Except in this case. Here, Haali too reproduces the same aberrant behavior as VMR7. Which is why it lit up a bulb in me. Also, some time back I'd had a similar issue when dealing with Coreavc decoder and the luma variance turned out to be associated with TV vs Computer levels. Now, I haven't a clue what I might have done in virtualdub to possibly force/expand 601? levels artificially. It remains a mystery.

[sadie]

A little update. I tested (Preset="Fast", SourceMatch=1, Sharpness=0.30) and found it hardly any slower. Fine. But the visual quality is inconsistent. In an amorphous natural setting, detail in foliage seems indeed a bit crisper. Yet in an urban more geometric context, I find the contrary. Building details seem slightly softer. Flat areas even more. Is this merely an issue with the sharpness setting? In which case, I'd be hard pressed at this point to distinguish between resurgent hidden detail and newly fabricated noise. Anyway, I don't wish to risk too much haloing as I'd like to attack a 720p upscale at some point. Secondly, I've found that the doubling/bobbing of the image merely reinforces that 'video effect' so I may stick to the SelectEven setting and suffer the occasional judder. Besides aren't the 100/120 hz TV functions one of the few options that actually work well on a set top? Also, in order to limit processing time I'm leaning toward just using a CQM mode (I've got 4000kb/sec to throw at it). What is the incidence of using single vs dual pass with QTGMC?

I've found a possible small bug (or one that is encoder related). SourceMatch mode in Avidemux will cause it to crash when a screen saver kicks in. This doesn't happen with any other of the modes I've tried. And it doesn't happen in VirtualDub using SourceMatch. Any ideas?

The only systematic problem areas I have are those which involve NLE interference: slow motion & still captures. Improvement I suppose might marginally help by deinterlacing before operating those filters. To ask my previously posed Q differently, have they invented a way to import an avisynth function on a specific clip on a timeline and not the whole project? Whatever happened to Avisynth Studio development? I'm still googling for that one...

[matfra]

Can someone tell me if its possible to add a pre-filtered clip for QTGMC that Tr2=3 can use. I would like to strengh the denoising. Any Idea ? Here's my current script.
Thanks

###############################
# I7 950 4.3 MHz @ 100% CPU #
# 0:25s @ 33,80FPS #
###############################
import("C:\Program Files (x86)\AviSynth 2.5\plugins\MDegrain5.avs")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\SeeSaw.v0.3e.avs")
SetMTMode(5)
SetMemoryMax(768)
DirectshowSource("C:\1.avi")
SetMTMode(2)
QTGMC(SourceMatch=3,Lossless=2,EdiMode="nnedi3",tr0=2,tr1=0,tr2=3,rep0=4,rep1=0,rep2=4,Sharpness=1.00,MatchEnhance=1.0,NoiseBypass=2, NoiseRemove=1.0, DetailRestore=0.0, NoiseRestore=0.0, Sigma=1, NoiseDeint="generate")
AssumeTFF()
SelectEven()
Seesaw(nrlimit=0,nrlimit2=0,sstr=1.5,sootheT=0,sootheS=0,Slimit=3,Sdamplo=29,Spower=3,SdampHi=35)

[-Vit-]

Edit: @matfra: No, you can't provide a pre-filtered clip for TR2 - such a clip would have to be smart-deinterlaced already. Possible within the algorithm I suppose but I haven't tried.
____

But the visual quality is inconsistent. In an amorphous natural setting, detail in foliage seems indeed a bit crisper. Yet in an urban more geometric context, I find the contrary. Building details seem slightly softer. Flat areas even more.
What you are seeing is what your source is like.

I had almost the exact same feeling when I first experimented source match - better on foliage, but softer on some edges/detail. I realized that I'd simply got used to the results of standard TGMC, which tends to strongly sharpen "real-world" edges/detail (as opposed to static logos, text etc), but in doing so it loses fine detail like foliage making it look plastic-like. DoubleWeave, Bob and NNEDI3 your source and compare stills with standard (Q)TGMC and source match QTGMC. But don't do it side-by-side, do it by switching between full-screen images. Believe me I've done this in exhaustive detail and with a huge range of sources (I should calculate some metrics really). With source-match, what you see is what you've got, although SourceMatch=1 is actually only half-way there...

Source-match is about accuracy, which is not quite the same thing as quality. Unlike standard (Q)TGMC source-match does not seek to denoise nor increase compressibility. It is about giving you the most representative shimmer-free deinterlace of your source without adjusting it in any way (so if you do find an example where source-match is actually further from the source than the standard algorithm I'd be very interested). In practice, I tweaked the application of the algorithm, so you can still do some denoising or sharpening, but both of these work against what source-match tries to do (not necessarily a bad thing - balancing requirements).

And sure the differences are fairly minor - I have been careful to highlight that. The best aspect is an increase in vertical detail - losing the very "interpolated" look of TGMC, especially with SourceMatch=2,3. This increased detail is unequivocal, but whether you can actual notice it or not is a different matter. If you can't then don't use source match. It really is for those who use a big screen/upscale and for pedants like myself. Makes it most appropriate for SD too.
_____

Crashes: I've noted earlier the various reasons for instability under MT which are to do with avisynth multithreading and caching - both of which become more problematic as scripts become complex. I am currently looking at some workarounds.
_____

"Double-rate "video" look": I have implemented some new settings to simulate a different shutter angle in the output (just the motion-blur implications) - for single or double-rate. It uses MFlowBlur, as discussed earlier. It does help with single rate output on my sources. As expected it suffers whenever MVTools struggles to analyze the motion, but for less chaotic sources it's not too bad. Main problem is that MVTools operates on blocks not exact shapes, so the motion blur "bleeds" into areas that are actually fairly static. I'm going to look if there are any ways to repair this bleeding then I'll post this version (later today or tomorrow)

[Boulder]

Crashes: I've noted earlier the various reasons for instability under MT which are to do with avisynth multithreading and caching - both of which become more problematic as scripts become complex. I am currently looking at some workarounds.Whenever you have something to test, I'm available. It seems that me going back to tsp's MT build only works in some cases. I usually have to lower the number of threads quite low and get much less than optimal performance.

[Didée]

Regarding "MT crashes", I've also fiddled with various things. Some things "improved", but when you start with, say, a 90~95% crash probability, and manage to come to a, say, 35-40% crash probability, then this might be an improvement, but it's still not usable.

Though ... almost all crashes disappear magically when I switch to SEt's latest Avisynth 2.6 build. Therefore I assume that all 2.5.x MT-builds are not stable. As simple as that.
Question is - what sorts of "MT-related fixes" have been done to 2.6, that 2.5.8.5 is missing? :devil:

[Boulder]

With the current video in the pipeline, I've been experimenting with all three known MT builds but with bad results. It usually takes 10-15 minutes to crash no matter what I do :( I usually get better results by encoding to lossless ffdshow HuffYUV first but this time even that doesn't work.

Mind you, my dual core was much more stable but that was probably simply because of less threads utilized ;)

[sadie]

Well, Vit, I finally hit at least one nail on the head. "Accuracy vs quality". You know there's the spark of a major philosopical debate in there somewhere. You suggest that SourceMatch is for "those who use a big screen/upscale". Is that to say that my above concern about haloing or bordering would be mitigated by sticking to SourceMatch if I were to go 720P? All in all, in real time viewing the 'foliage' improvement outweighs the 'non-resharpened' scenes so maybe I'll stick with it. I'll give SourceMatch 2 a try as well. Did I mention that avidemux crash was in single-thread mode?

[matfra]

Edit: @matfra: No, you can't provide a pre-filtered clip for TR2 - such a clip would have to be smart-deinterlaced already. Possible within the algorithm I suppose but I haven't tried.
I hope you could add this new feature in your next build of QTGMC. I would be nice to specify a Pre-sourceNR to the Tr2. I hope my cry will be listen by a master !
Thankx

[Didée]

I would be nice to specify a Pre-sourceNR to the Tr2.
Anyone explain to me what this whould be supposed to do? I don't see it.

Though, my guess is you're looking at the wrong place for a solution. (Solutions are good, but they need to fit to the problem.)
You're working with a VHS capture?

[-Vit-]

I figured matfra might be looking for one of those situations where you use a different source and super clip to enhance/reduce something based on the motion match. But my sentence is rather vague because I too have no real idea what is being suggested. Matfra: QTGMC cannot solve all problems.
____

Crashes: I have seen plenty of examples (from numerous systems) indicating that no MT version of avisynth is stable, neither 2.58 nor 2.6. Crashes vary by script, plugins, avisynth version, software, OS and hardware.

The caching in avisynth is overeager. It's a real problem in MT, but could affect non-MT too, especially HD. By default avisynth caches every intermediate filter result, which number in the hundreds per-frame in QTGMC. It also caches every output frame, which is redundant when encoding. However, the system is smart and will attempt to drop unneeded frames from the cache. Unfortunately it can think that unneeded intermediate results are actually important and will continue to eat more and more memory. Until it runs out of memory and crashes (and if you're using a 32-bit workflow, you have a memory cap of 2Gb per process regardless of physical memory).
____

Haloing & Source Match: Haloing in (Q)TGMC is caused by the Sharpness setting, which recovers the source sharpness after the initial shimmer-removing temporal blur. The standard algorithm has a high default Sharpness intended to keep static areas accurate, but potentially producing significant halos elsewhere. The source-match approach recovers most of the source sharpness without resharpening, so the Sharpness setting is just 0.2 producing minimal haloing. You can set it even lower with the better source match modes + lossless (about 0.05), giving no haloing at all (other than what is in the source).

However, if you want to increase sharpness from the source... well, increase the Sharpness delicately with source-match as there's no limiting by default (because sharpness limiting also limits the accuracy of source-match).

[Didée]

The standard algorithm has a high default Sharpness intended to keep static areas accurate, but potentially producing significant halos elsewhere.
In theory it shouldn't. The sharpened intermediate clip is limited by the (compensated) neighbor frames. Therefore the sharpening shouldn't introduce new halos on its own ... the limiting makes processed pixels stay in range produced by original source pixels.

Practice is a little different. First, even such limiting can make already-present halos more prominent. (As known from LSF - even with overshoot=0, source halos are more obvious after LSF).
Another point is the pel subsampling ... pel=2 is sharp, and to that extend, it is acting quite similar to a "sharp" resizer like e.g. lanczos4resize. Means, pel=2 will also introduce some ringing, and will amplify already-existing halos.

I don't claim that the "pel2hr" option in TGMC is particularly good. But it is there for a reason. Partly to help with the problem ... and partly to indicate that the script creator was aware of the problem from the very start. ;)

[-Vit-]

No criticism intended Didée, just communicating practicalities. I, more than anyone perhaps, appreciate the thought and detail that has gone into the TGMC algorithm.

[-Vit-]

I've posted the latest version v3.05 in the OP (http://forum.doom9.org/showthread.php?t=156028).

This version can simulate the motion blur of different shutter speeds using MFlowBlur as discussed earlier. In fact I decided to use shutter angle for units to avoid involving the frame-rate in the settings (didn't want to use MVTools non-standard percent either).

You need to choose an output frame rate and shutter angle, and also provide (or estimate) the effective shutter angle of your source. It's all switched off by default, so it will not affect any other scripts. Here's an example (edited: I missed the vital MotionBlur setting when I first posted...):

# Output every 2nd frame (i.e. single-rate), source filmed with high speed shutter, standard "film-like" shutter angle for output
QuickTGMC( Preset="Slower", MotionBlur=1, FPSDivisor=2, ShutterAngleSrc=45, ShutterAngleOut=180)

FPSDivisor=1 means select every frame (double-rate - the default). FPSDivisor=2 means select one out of every 2 frames (single-rate output - SelectEven() isn't needed). FPSDivisor > 2 is allowed. If this sounds backwards, it's simply the same concept as SelectEvery for those of you who script. I will leave detailed discussions of shutter angle to other experts. In summary, higher shutter angles mean more motion blur. You can estimate shutter angle on a source by looking at the motion blur on a moving object [on a still]. Perfectly crisp is 0, full blur from previous frame to next frame is 360. 180 is considered the norm for a film-like look, many non-film sources I see are rather sharper than that. Artificial output angles > 360 are possible in limited circumstances (extra blurry).

Things to watch out for: the motion blur can bleed into static areas due to the block-based nature of MVTools, there are settings to help repair that (read the "Motion Blur" section in the script docs). These repairs are slightly switched on by default. If the motion analysis makes bad decisions then there's little can be done - there's no effective way of detecting analysis errors that also doesn't detect most of the motion blur as errors...

I did a quick test with progressive input and it worked too. Note that you would usually set FPSDivisor as 1 since progressive input comes out as same-rate so you want to keep every frame.

Results are better than I expected for non-chaotic input. I would certainly consider it for single rate output as it smooths out the stutter I get (the above example suits my sources). However, it's not going to work well on some sources, and in any case consider this feature experimental.

[Robert Martens]

My god, you work fast! A quick test on my own material suggests you've succeeded in your aim. I'd love to comment in more detail, but the relationship between framerate and shutter speed, the difference between mechanical and electronic shutters, and the difference between exposure time, angle, and percent are all way over my head. I managed to wrap my mind around the basic idea, but beyond blending two fields together I'm out of my league.

I've just started working on a small update to my own script, and with any luck I can incorporate the new QTGMC options in there somehow. Looks like I may have occasion to use the 'val' data type for one of my parameters after all.

Thanks for the effort, this sounds like it'll come in handy!

[sadie]

Great, Vit, I'll have to give it a whirl myself. At the risk of exposing my naivete on this I'll dare ask why the need for FPS=1 at all. I mean isn't the 'video effect' a two-fold phenomenon? Either you have single-rate output with 'pseudo-motion blur' and judder or you go the double-rate route and suffer the full impact of zero temporal/motion blur while correcting the judder. So inasmuch as FPS=2 all at once alleviates the judder by emulating a true motion blur doesn't that obviate the need for going to double-rate (FPS=1) in the first place? There's no longer any judder for the doubling to correct. Or is it strictly meant for progressive sources? Be so kind as to tell me what simple principle I'm not connecting with. Thanks.

SourceMatch=2, Sharpness=0.30 on two samples gave me images that oddly closer resembled both the default TGMC test AND the source. SourceMatch=1 even transformed a woman's open mouth into the shape of an old black & white TV. Uncute. Yet SM=2 meant twice the encoding time. I'm wondering again what I was seeing in my foliage stuff. Oh well, more testing. And for something that in real time viewing won't be discernible for 99% of the population. Still, great product of yours (and Didee's).

[matfra]

I figured matfra might be looking for one of those situations where you use a different source and super clip to enhance/reduce something based on the motion match.

You understand right -Vit-. I would like to know if it possible to add to the script athe option to use a different source and super clip to enhance/reduce something based on the motion match.
:)

[-Vit-]

sadie: Double-rate material can and does contain motion blur, how much depends on the shutter speed used when filming it. But interlaced content shot with a shutter speed suitable for double-rate may not have enough motion blur for single rate, making it judder when you drop half the frames. And that's the primary use for these settings. But that's not their only use, they can smooth material shot with a very high shutter speed, even whilst keeping double rate. They can be used to give exaggerated blur, or to blur something that would normally be perfectly sharp (e.g. game footage). As a scripter, I prefer not to care about the why, and just provide for everything that's possible. The formula used is general, and supports all FPSDivisor & shutter angle values with a single piece of script.

Also, FPSDivisor=1 doesn't exactly mean double-rate, it means use every frame (field). In the case of progressive input, you would need FPSDivisor=1, or you would drop half the frames. [personally I don't like the moniker double-rate, though I understand why it has come about. If a video contains 60 images per second then that's its rate as I see it. Interlacing is just a form of compression scheme; if in decompressing you drop or merge half the images then that's half-rate, not single rate]

Standard TGMC will smooth the source, which you might prefer. I spent some time wondering why a line in one shot was aliased with source match but not without, until I realized the source itself was aliased on that shot. Whilst source match occasionally does introduce errors, often it is the source itself that you are unsatisfied with, and the stronger temporal smoothing of the standard algorithm is what you want. [I knew that adding a feature billed as "precise" would cause problems]

matfra: You're joking, right? That sentence was deliberately too vague to be useful.

[sadie]

Before my last fine tune-up and final output and then moving on, I thought I'd pass on a last rather serious quirk I discovered yesterday. I don't think it's related to QTGMC, but since it occurred with me for the first time in this context...well, who knows?

Yesterday, I did a half a dozen consecutive CRF 18-26 range tests (avidemux 2.5.3 medium preset) with regular QGTMC fast preset and all came out with finger-width horizontal smears across the center of the screen, occasional smears elsewhere and even some flickering in those areas. Static areas were much more affected than scenes with movement in the subject or camera.

The problem is I've since tried to reproduce the effect and simply cannot. Mediainfo confirms exact same settings for identical encodes. The only possible explanation I can imagine for this is that I had a few firefox windows open and was doing moderate surfing, but memory use remained well under 2gb (4gb ram installed). I'm not especially reassured that it hasn't resurfaced. Anyway, to whom it may concern...

[-Vit-]

sadie - non-reproducible problem: I believe all the plugins used by QTGMC are deterministic (i.e. produce the same output every time given the same input/settings). The script itself is deterministic. The bugs in avisynth may not be, the crashes certainly show up randomly. As you're running single-threaded it may be a case of memory corruption if you can't reproduce the error. I've processed hundreds of hours of footage with QTGMC and the only time I've ever seen non-reproducible effects was when I had a bad memory stick.

[henryho_hk]

Any sample snapshot, sadie?

[henryho_hk]

I know inputtype=2 is meant for fixing badly deinterlaced footages. But it will appear to me that the original TGMC is doing a much better job, especially for those ill-brained field-duplicated deinterlacers. What parameters I should be tuning for these sources?

[-Vit-]

Have you tried InputType=1? That's should be the same as what original TGMC does but without the frame duplication (which interferes with the motion analysis). It can be the appropriate method for less degraded sources.

InputType=2,3 drop half the fields - which is pretty extreme, but necessary when the source is a real mess.

There's also this approach from a previous post:

s = WhateverSource("Your.src")

# Make versions from upper fields and lower fields (use TR2 and ProgSADMask also if you wish)
t = s.QTGMC( InputType=2, ... ) # These lines work well with "SourceMatch=1, Lossless=2" (need v3.01+)
b = s.QTGMC( InputType=3, ... )

# Now merge the results in some way. Choose ONLY ONE of the lines below and delete the other
Merge( t, b ) # Smooth result, may need more sharpening
t.Repair( Merge( t, b ), 1 ) # Sharper result, could try 2 at end of this line


I find that latter approach works very well on some sources, less so on others. It's slower than it could be of course...

[@MeGui]

Vit, nice one mate...:)))
I have i7 core, so can u tell me how to use max of my cores?
I have Avisynth 2.5.8 MT installed.
What would be "lines" only for pure de-interlacing?

Tnx in advance...:)

[-Vit-]

Straight deinterlacing using multi-threading:

SetMemoryMax(M) # Optional line. Leave it out at first. See below for value M
SetMTMode(5, X) # See below for value X
WhateverSource("Your.src")
SetMTMode(2)
QTGMC( Preset="Slow", EdiThreads=Y ) # Choose preset based on overall speed/quality you want. See below for value Y
Distributor() # This line may or may not be necessary, try it without - it may be faster


Setting X
- Start at the number of cores in your machine
- If it crashes, decrease 1 at a time
- Otherwise increase 1 at a time until CPU usage is very, very close to 100%, don't go too far or it will slow down

Setting Y
- Start at about half number of cores and tweak upwards or downwards for best speed. I find Y=1 often works best when using SetMTMode.
- Obviously this is a balance with X

Setting M
- Using the SetMemoryMax line and choosing a good value for M can allow you to use more threads and so get more speed. Particularly important for slower settings
- Try 400,600,800,1000 etc.

[I should add this to the OP / docs...]

[@MeGui]

hmmm, using Virtualdub 1.9.11 and no meather what, crashed...

[-Vit-]

With Virtualdub I don't think you need the Distributor() line.

Try different versions of MT AviSynth if you get stability issues: Standard 2.57MT (http://avisynth.org/mediawiki/MT), SEt's 2.58MT (http://forum.doom9.org/showthread.php?t=148117) or SEt's 2.6MT (http://forum.doom9.org/showthread.php?t=148782)

[@MeGui]

I think is not Avisynth issue...this "MT" running good...

http://pastebin.com/EAmLksev

[-Vit-]

I don't know what that paste was about.

But in any case, MT avisynth is buggy. It might work with one script but not another. You should try the other versions. SEt's versions appear to be most reliable, but each system is different. There are many posts on the subject in this thread.

[kolak]

hmmm, using Virtualdub 1.9.11 and no meather what, crashed...

I have constant crashes also- my source is 1920x1080 50i and new QTGMC is almost unusable with MT.

Works fine when using simple command:
QTGMC(Preset="Fast")- any setting above crashes.


Andrew

[@MeGui]

Yes, indeed ...but, i can still get only 1.14 rendering...not more :(

[-Vit-]

New QTGMC is almost unusable with MT
I would be interested to know which version of QTGMC you last had stable...

I've made very few changes to the core algorithm for several versions. There's nothing new in version 3 - the presets on their own should result in the pretty much same filter graph as always. I have been adding extra features, but they're all off by default so it should run just as before when you just provide a basic preset. However, I used to have more explicit conditions to remove unused filters, I now rely on avisynth to do that job when it builds the filter graph - I wonder if that is causing a problem. Maybe I should revert to doing things manually again...
____

EDIT: A quick look at the avisynth parsing code and I think if you don't explicitly put a conditional around an unused filter then its constructor is called anyway [correct me if I'm wrong devs]. That's unfortunate, it could cause unnecessary memory use at the least.

In practical scripting terms it appears to mean that this:

input = last
processed = (setting == 1) ? input.ComplexFilter() : input
return processed

is better than this:

input = last
processed = input.ComplexFilter()
return (setting == 1) ? processed : input

These two scripts are equivalent. If setting = 2 then the ComplexFilter plugin isn't going to get used. However, in the second example it will be constructed when the script is parsed at the beginning - this will use up memory unnecessarily. The first example guards it with a condition, the plugin will neither be constructed nor called. [At least, that's what I surmise from a quick glance over the avisynth source code]. I had assumed the second method was OK as I had seen it in a number of other scripts and examples.

I'll revert back to my original method and see if there's a stability difference... stay tuned...

[Gavino]

A quick look at the avisynth parsing code and I think if you don't explicitly put a conditional around an unused filter then its constructor is called anyway [correct me if I'm wrong devs]. That's unfortunate, it could cause unnecessary memory use at the least.
That's correct. And with multi-threaded Avisynth, you will get an instance for each thread, using more memory.

How much impact this has will of course depend on how much memory the filter allocates on construction - many simple filters have nothing beyond a few simple variables, but something that keeps its own frame buffer (for example) will obviously use more.

[sadie]

...and I thought I was out of here. Well, I managed to reproduce my bug/error albeit in a still not completely conclusive way. And I'm also at the stage where in passing I'd like to apply a couple of old human adages to this technology: A: Honeymoons never last B: Life is a crap shoot.

That said, and after two successive crashes I managed to get a successful 9 hr encode (fast preset) for my l hr 10 min video. I also managed to custom start three threads for my modest core duo T8100. That should have given it some elbow room. Again, the encode and subsequent tests were avisynthproxy in avidemux and an x264 medium quality preset.

On playback without even looking too hard I noticed some soft softs which are discernable in the following captures which reflect the order with which I tested various things. Areas to look for are bldg to far right, lst floor window 2nd from left and 2nd fl window lst on left. (1) shows the smoothing/obliteration equal to my full encode. I re-reproduced it using different crt and abr settings with identical results. (2) here, I rebooted avisynthproxy in SourceMatch 2 25p mode. The anomaly disappeared. (3) further reboot back into default QTGMC and here the smoothing went bananas, equivalent to what I experienced on Saturday. (4) booted avs script with default QTGMC in 25p (selecteven) mode...the problem disappeared. (5) finally back to original avs in 50p and once again the error was gone. I should add that I think the source sample is not virginal. It might have undergone some slight slow motion filtering.

Vit, you mentioned 'memory corruption'. Whatever that's supposed to mean it doesn't get me very far. From my amateurish experience with computers over the years, in a case like this I'd always thought a hardware problem generally either translate into something that works or breaks. Be it the hardware itself or the task it was trying achieve. But it doesn't 'bend'. And this random smoothing strikes me as being just that: bending.

The problem isn't systematic except for the fact it's only ever occurred in 50p mode, never with 25p. Is there something to be learned here? Maybe I should play it safe and stick with that. (SM=2 by the way was a decided upgrade from SM=1). Further, is there any reason NOT to do a quality archive copy @7000-8000 kbs using sourcematch just in 25p and either a) count on my Sony flatscreen's 100mhz 'motion flow' to iron out the judder or b) later on down the line when I'd like to play around with some 720p upscaling go about doubling the frames then and hopefully not suffer a quality hit. As I always back up the finished DV render on mini-DV tapes that shouldn't be a such a huge risk.

You say, Vit, you've never had a 'failure' in hundreds of cases of QTGMC. But maybe you're on systems using quad-cores or far better. Which brings up the 'minimal configuration' issue. Is there one for this avisynth plugin?

I just had a last thought as I write these words. All the tests I've done were through to an x264 encode. Wouldn't the truly rigorous method be to output to another DV avi file? How much might the encoder end of these operations be interfering in performance/image quality? As I recall x264 loop filter settings bear on perceived sharpness. Doesn't this complicate matters? Thanks for your continuing help.

[sadie]

Oops, my attachments disappeared.

EDIT: Sorry for error. I'd thought attachments would remain in a link form with info file name. Didn't want to bloat the thread. I've removed pics 4 & 5. The middle image represents what the correct encode should like anyway.

[marcopolo80]

For this kind of source file (known as 1080-60i):

Video
ID : 2064 (0x810)
Menu ID : 100 (0x64)
Format : MPEG Video
Format_Commercial_IfAny : HDV 1080i
Format version : Version 2
Format profile : Main@High 1440
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=15
Codec ID : 2
Bit rate mode : Constant
Bit rate : 25.0 Mbps
Width : 1 440 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.536

and thinking that almost all the time the camera will shoot in natural and good light-so the footage will look OK-what is the best: to stay interlaced and encode to x264(or MainConcept h264 AVC Broadcast) at 8-12 Mbps(not sure if 12 is not a waste of space) or to go progressive(720p) also encoded in x264 or MC-264avc at 6-8Mbps?
For the second choice which settings for fast encoding speed?And keep 59.94 or to make a pulldown to 23,97?
My script looks now (obvious with the help of some people from this forum):


SetMemoryMax(900)
SetMTMode(5,6)
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
MPEG2Source("C:\test5min.d2v")
SetMTMode(2,6)
AssumeTFF()
ConvertToYV12(interlaced=true)
Import("C:\Program Files\AviSynth 2.5\plugins\QTGMC3.05.avsi")
spline36resize(1280,720)
QTGMC( Preset="Fast", EdiThreads=4 )


The CPU is AMD x6 1055T@3.3Ghz with 4GB DDR3 1366 and x86 OS

Thanks

[-Vit-]

Here's a revised version of QTGMC (v3.10) which reverts to the approach of v2.x. This will call far fewer filter constructors, using less memory and maybe prevent the crashes some people have had. If you couldn't run the recent versions, please give this one a quick test and report back. I haven't updated the OP yet in case this doesn't help. I tested this multi-threaded in VirtualDub (1.9.10) on some 1920x1080x60i material at preset "Slow" - it was fine:

QTGMC v3.10 (http://www.mediafire.com/download.php?4rgxf8s2iermiii)

____

sadie: I've never seen smearing like that out of QTGMC. Might it be x264? That can cause smearing, especially given that it's a fairly complex scene and you said you were going down to CRF 26? And it's strange that it is not consistently reproducible. These are deterministic algorithms, there isn't scope for variation. x264 does have a non-deterministic multi-threaded mode (the order of the threading calls is unpredictable and they get some tiny speed advantages by not worrying about that), but I don't think that mode is a default.

However, x264 is getting in the way with these examples. I always encode lossless 1st pass, then x264 the result. You should try to reproduce the error in a lossless format. Better still you should post that source snippet, so I can try to reproduce the issue.

____

marcopolo80: That seems like a decent start, but you've made a mistake with the resizing - you shouldn't vertically resize before the deinterlacing. The last part of the script should be this:

#...
spline36resize(1280,1080)
QTGMC( Preset="Fast", EdiThreads=4 )
spline36resize(1280,720)

You should tweak the threading settings to get best speed. About your other questions - there is no "best" choice, you must try each of your options and decide for yourself.

[marcopolo80]

Thanks,I'll try those settings.

[yup]

-Vit-!
Amazing!!!
Now my HD source work SetMTMode(2,4) and placebo preset without crash (before work only SetMTMode(2,2)). I am also note speedup 20...40%.
Waiting from Stephen R. Savage YUY2 release.
Good work.

[-Vit-]

Thanks yup. I'll take that as confirmation that I've at least fixed something. I've updated the OP to v3.10

Avisynth only calls what it needs when frame-serving, but it initializes everything that isn't explicitly guarded with a condition. QTGMC contains a huge number of filters, many of which are not used unless you choose a particular setting. However, almost all of them were being initialized, which must have been using a great deal of memory - it was hard to tell because the avisynth cache uses a huge amount of memory anyway. Other scripters with conditional / optional processing should note the example above (http://forum.doom9.org/showthread.php?p=1477993#post1477993).

[@MeGui]

In My case, calling "mt_masktools-26.dll" in script, did the trick...

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools-26.dll")
SetMemoryMax(1024)
SetMTMode(5,8)
DirectShowSource("C:\Documents and Settings\XyZ\Desktop\Svadba2.avi")
SetMTMode(2)
ConvertToYV12(interlaced=true)
Import("C:\Program Files\AviSynth 2.5\plugins\QTGMC3.10.avsi")
spline36resize(720,576)
QTGMC( Preset="Slow", EdiThreads=8 )
spline36resize(720,432)


I'm getting 34.10 fps with "Slow" preset on i7's

Tnx Vit again :))

p.s. Vit, this script, is it correct for 720x576 ( DV-PAL-interlaced 25.000)-->720x432?