QTGMC Deinterlacing Script (v3.32)

[-Vit-]

Overdrive80: No, I haven't changed anything that should affect the field parity. I also tested your clip on v3.20 and I needed the ComplementParity() line in that version too. Sometimes the source filters get the field parity wrong, I've seen it several times before.

johnmeyer: See post 430 above for the settings to restore "Very Fast" in v3.25 to v3.20 behavior and speed. That might help for your "Very Fast" setting. I am nearly finished on some optimizations for all the faster settings, so I'm not going to worry about the speed issue just now.

Regarding crashes, the 'mvtools2' note in the error message may or may not be indicative. Try adding the setting "SafeMode=true" to your QTGMC line (it will be slower). If that fixes it then MVTools is really to blame. I can reproduce errors with MVTools, so I will debug it at some point. However, often multithreading or memory bugs due to AviSynth itself occur whilst running the plugin modules, so the problem actually might be with AviSynth. Let's hope it's a memory issue, because they're easier to fix. Absolute priority when running HD multithreaded is to render to a lossless intermediate file - don't try to use x264 at the same time as HD QTGMC. For MeGUI that means you must select "Add Pre-rendering Job". Setting EdiThreads=1 might help with memory too.

If you're crashes are problems with avisynth multithreading then try using different versions of MT avisynth. Find them linked on the AviSynth Wiki main page

[Overdrive80]

@Vit. I translate QTGMC doc to spanish, I hope that dont disturb you.

http://www.megaupload.com/?d=3XKOAFTN

[johnmeyer]

Originally Posted by -Vit-

Regarding crashes, the 'mvtools2' note in the error message may or may not be indicative. Try adding the setting "SafeMode=true" to your QTGMC line (it will be slower). If that fixes it then MVTools is really to blame.

I tried all four permutations of new/old script and Faster/Very Fast with "SafeMode=true" added to my QTGMC line.

With the old (v.20) QTGMC script, I was able to get my 1,000 frame test video to run through the video analysis pass without crashing, although the fps indicator started to fluctuate at about the 900 frame mark, which is usually a sign of impending crash. Thus, it might still crash if fed a longer test video. With the new (v25) QTGMC script and the more stable Very Fast setting, I was able to get almost to the end of the analysis pass before the script crashed, whereas without the SafeMode statement, it crashed almost immediately.

Hope that helps.

[johnmeyer]

Quick addendum (I didn't want to further edit my previous post):

I kept trying different things with my four permutations (described above) and found that I got more stability with both versions of the script if I changed EdiThreads=0 to EdiThreads=1. I still got crashes with the new script but they happened after a larger number of frames had been processed. So, following the guidelines in the QTGMC doc, I played around with the MT settings. SetMemoryMax didn't make much difference, but increasing the number of cores from 4 to 8 (my computer is a 8-core i7), allowed me to get all the way through my 1,000 frame test video with the "toughest" combination of the new v25 script and the "Faster" QTGMC setting. I haven't tried this on a really long video so I don't know if it is totally stable. Also, I did these most recent tests without the SafeMode statement.

Again, I hope this helps.

[edit] I just re-ran the script using the newest v25 script with these settings, but using Very Fast. It crashed. Bummer. So, these settings let me get through the test script with the settings that previously crashed, but they cause crashes on the settings that previously worked. I tried about half a dozen settings for the "Very Fast" setting, and was unable to get ANY that would work with the new script, even if I completely disabled all multi-threading.

So, I guess I haven't yet found settings that work for more than a few settings. It's still very "touchy."

[-Vit-]

Overdrive80: Thanks very much for that, I'm sure it will be appreciated. [Edit: I couldn't download it before, but now I have it. I will link to it on the first post.]

johnmeyer: There are two things here. Firstly there is certainly a problem with QTGMC<->MVTools on faster presets, which sometimes causes crashes before even a single frame is processed. I will look at that. But I don't think that's all that you're experiencing. Almost everyone who does multi-threading with complex scripts finds that avisynth will randomly crash with particular settings/scripts/hardware etc. The reason is that there are bugs with the multi-threading in avisynth. Sadly fixing those bugs would involve considerable effort, especially for those of us who aren't familiar with the avisynth code base.

I have had numerous detailed descriptions of problems, and they all follow the same pattern: encoding crashes after X-thousand frames; tweaking settings makes things slightly better, or slightly worse; problem is more pronounced with complex settings or HD material. But despite the similarity, there is no one solution. The first thing you need to try is different MT versions of AviSynth. For example, I can barely get a few hundred frames out with the standard 2.57MT, I only get limited stability with SEt's 2.58MT, but I have encoded tens of millions of frames with SEt's 2.6MT. For others it's the same story but a different version that works...

Edit: BTW, EdiThreads=0 means use 1 thread per logical core. So on your system it means EdiThreads=8. That's why setting it to 1 is more stable. Also it can help to use SetMemoryMax at a lower value than you might expect. I sometimes use 400 for HD material...

[johnmeyer]

-Vit-,

Yes, I agree with what you are saying about the less-than-robust behavior of the MT versions of AVISynth. Fortunately I think I have now managed to tweak things so that I have a stable workflow now.

One thing I didn't realize is that there are competing MT versions of AVISynth. When I do a version call, I get: "AVISynth 2.58 tsp version 5(mod seraphy), build: Aug 16, 2009 ..." I'll see if I can find a version "2.6MT." I don't think I've seen that before.

[-Vit-]

Here are the various versions: Standard 2.57MT, SEt's 2.58MT or SEt's 2.6MT
Or if you've converted to a completely 64-bit workflow the x64-2.58MT

[SubJunk]

SET's 2.6 wins

[johnmeyer]

Thanks for the links. I tried set's 2.6, but apparently the direct support for reading RGB24 (at least from debugmode's frameserver) has been deleted. As soon as I try to open my script in VirtualDub, I get the message: "AviSource: Could not open video stream in any supported format." If I change the Debugmode Frameserver (which is how I serve out of Sony Vegas) from RGB24 to either RGB32 or YUY2, then I can open the script. RGB32 keeps the colorspace the same as my previous workflow, but cuts performance in half. Using YUY2 keeps performance the same, but introduces all sorts of color shift and levels issues. Nick Hope (who wrote the long tutorial on how to do this) has spent several months of his life working these things out, so I have no hope of trying to get the same levels. So, at least for the moment, I'm back to 2.5.8.

I like the idea, however, of having better stability with multi-threading (for ALL of my scripts), so I'll look into what else I can do here ...

[edit] I just did some more work ... if I use YUY2 out of the Debugmode frameserver, and strip all the colorspace corrections, I end up with the same levels. As for color space, all colors appear to be the same as those I got using Nick Hope's original workflow, except that pure red colors are truer to the original. With his workflow, it appears to me (now that I'm looking more critically) that there is a shift towards orange in the final render.

So, bottom line, I think I'll be able to use 2.6MT, and that all the changes you have suggested and that I've found on my own make this stable. I'm now getting over 15 fps doing video analysis in VirtualDub, and almost the same when rendering from MeGUI. All 8 cores are showing nearly 100%.

[Didée]

@ johnmeyer: Maybe I'm lacking imagination, but ... if you have to deinterlace a video, then why has it to come out of Vegas in the first place? I could more easily imagine the other way round: have some interlaced video, then deinterlace it with Avisynth/QTGMC, then do additional stuff in Vegas.
Basically this doesn't matter, of course. But since multithreaded QTGMC on Full-HD video is not a prime example of "stability" in the first place, I'm not sure if Vegas' frameserver does exactly help on the matter.

[johnmeyer]

Originally Posted by Didée

@ johnmeyer: ... if you have to deinterlace a video, then why has it to come out of Vegas in the first place? I could more easily imagine the other way round:

Didée,

For many situations, what you propose may make more sense. However, there are many cases where deinterlacing first does not make sense. For instance, I often need to produce several versions of the same video: one down-res'd to DVD; one for Blu-Ray; one for upload the web; and one to be archived in the original HDV or AVCHD format. So, in some cases I want to preserve interlacing, and other cases do not. Thus, for this workflow it makes more sense to maintain interlacing until the last step. Also, it has always been my mantra: don't deinterlace unless you absolutely must do this. Deinterlacing always degrades the video, both temporally and spatially, and therefore I believe it is always best to only take this step when sending the video to an unknown client (web browsers) where I cannot be certain that the display can either show the interlaced video natively, or can do deinterlacing on its own.

[aegisofrime]

Funny, johnmeyer, after I met Q/TGMC I always deinterlace before doing anything. Yup, it's that good to me.

Of course it would be best if your camera capture in 60p in the first place.

[johnmeyer]

Of course it would be best if your camera capture in 60p in the first place.

It's hard to argue against 60p.

[Didée]

Well, I knew nothing about your workflow, and therefore I didn't mean to critizise it. - I simply was wondering if the mere fact of frameserving from Vegas could increase the overall instability. I'm not even sure about the memory model - but if no piping happens and Vegas' frameserver shares the same 2 GB memory block with Avisynth and its host application, then I could very well imagine that a successful start-to-end encoding of a FullHD source is nothing but a dicegame.

Just to serve the curiosity, you might try to save Vegas' output to a losslessly compressed AVI, and use QTGMC on that AVI. Obviously you don't want to do that for your everyday's workflow. However, lets assume you undertake this experiment ... and find out that the notorious crashes disappear, and all full-length processings/encodings all of a sudden finish successful. What is then?

Also, fact is that with interlaced video, all operations with a "spatial" filtering aspect have to be done in a suboptimal way. In particular for change of resolution, but also for denoising, or blur/sharpen filters, it will be better to have QTGMC at the start of the chain, not at the end.
"Degrading by deinterlacing" is a valid point. However, "degrading because of NOT deinterlacing" is also a valid point. It's like it always is: "it depends".

[johnmeyer]

Didée,

Rendering first to uncompressed is a great idea for troubleshooting. I'll do that. The only issue I have ever had with this workflow is field reversal, and I think that was only with PAL sources.

And you may be correct about the DebubMode Frameserver, although I have no way of knowing about its internals. I've used it almost everyday for eight years in a variety of workflows, and not had problems, but I've only been using it with the multi-threaded version of AVISynth for about eighteen months, and I have definitely seen some issues. Until now, I never thought it could be part of the problem.

[-Vit-]

I've posted the latest version v3.30 in the first post.

This version includes some speed-ups and bug fixes:

# v3.30
# - Added ChromaMotion setting - can ignore chroma when analyzing motion (a speed-up with few ill-effects)
# - Added ChromaEdi setting - allow faster interpolation for chroma than luma (mainly useful for EEDI2/3)
# - New fast pre-filter (SrchClipPP) mode 1, previous modes 1 & 2 are now modes 2 & 3. Presets all updated with new modes.
# - EdiMode "TDIYadif" changed to "RepYadif" = Yadif+Repair giving less artefacts & more speed. Is default mode for "Ultra Fast"
# - Preset is now the first setting, allowing a simpler form: QuickTGMC( "Slow" ). Old TGMC style will no longer work
# - Workaround for padding bug in MVTools that crashed faster modes. Removes need for SafeMode setting, which has been removed

Speed-ups
Setting ChromaMotion=false makes QTGMC ignore chroma when analyzing motion. This provides a nice speed-up, and for the vast majority of the time the motion analysis comes out the same. [Edited:] There can be situations where moving items differ by color, but not by luma and in such a case the motion analysis could have used the chroma. I've seen this effect with a rapidly moving brightly colored object passing in in front of a plainly colored complex background: there was a tiny bit more ghosting with this speed-up enabled. This speed-up is used by default on all Presets "Slow" to "Ultra Fast". If you use "Slower" (default), "Very Slow" or "Placebo", set ChromaMotion=false to use this optimization

From a suggestion by Didée earlier, you can now select a different interpolation path for chroma. The EdiMode setting determines the main interpolation (NNEDI3 at various speed levels by default). Set ChromaEdi to use a different interpolation for Chroma, choose from "Bob", "Yadif" or "NNEDI3" (it uses the highest speed NNEDI3 settings). The idea is that it might be faster to process the chroma with a simpler interpolator and you might not notice the difference. However, it turns out that the default interpolator, NNEDI3 is already very efficient. By all means try this setting, but I found it was only a speed improvement if using an EEDIx variant as the main interpolator, e.g. QTGMC( EdiMode="EEDI3", ChromaEdi="Bob" )

I've added a simpler pre-filter mode for the fastest modes ("Super Fast", "Ultra Fast"). These presets were not pre-filtering before so this provides a quality improvement. Yet with the other changes above I still get an overall speed-up on these settings.

All presets from "Slow" and quicker are now faster on my machine and setting ChromaMotion=false can optionally speed up the slower settings. I would be interested to hear about other peoples speed experiences.

Other
I've worked around a bug in MVTools that was causing crashes in the faster modes ("Very Fast", "Super Fast", "Ultra Fast"). If you had crashes in these fast modes but not the slower ones, then you may find this version fixes that. This means the SafeMode setting has been removed.

You can now call QTGMC without writing "Preset=". Like this:
QTGMC( "Faster" )
You must put your preset first if you use other settings though:
QTGMC( "Slow", Sharpness=1.2 )
You can no longer use the old TGMC format for settings (e.g. QTGMC( 2,1,1, 4,0,4 ) )

[SubJunk]

Very nice

[nhope]

Preset tables updated for 3.30:

Compared to "faster"
Compared to "medium"

I can hardly keep up!

[nhope]

Can I please have clarification on which of the dll's from RemoveGrain-1.0.rar are now required? I have so far just had RemoveGrainSSE2.dll, Repair.dll and RSharpen.dll in my AviSynth plugins folder, but I'm trying YUY2 and it's throwing an error "No function named Interleaved2Planar". Is Interleaved2Planar a separate download or is it in the RemoveGrain package?

[nhope]

OK so I found SSETools (which provides the Interleaved2Planar function) in the older version of RemoveGrain. I am ignorant about SSE2/SSE3 etc., but reading this makes me think that the majority of users should be using the SSE3 version of the filters, right?

Anyway, with SSE3Tools.dll in place, the error has now jumped forward to line 394, "mt_lutxy: unsupported colorspace. masktools only support planar YUV colorspaces (YV12, YV16, YV24)".