QTGMC Deinterlacing Script (v3.32)

[simcut]

Hi guys, quick question, with solely interlaced footage, in my avisynth script, do I need to add AssumeTFF() or AssumeBFF() depending on what DGIndex detects as the field order, or does it not matter at all, does QTGMC detect the field order anyway so I dont need those commands in, or do I have to have them in.

Currently I have an avisynth script each set up, one for TFF and another for BFF.

Thanks

[Reel.Deel]

I only add AssumeTFF/BFF when the sequence is clearly out of order.

[LigH]

QTGMC will rely on the field order AviSynth assumes after loading the source clip.

Not all source filters are able to determine the field order correctly (e.g. AviSource will probably assume BFF because the AVI container does not flag it, each VfW codec may have its own default, and BFF is the most common default for DV in AVI); sometimes even the encoding studio flagged the material wrong. In general, better be safe than sorry (to have wasted hours due to QTGMC creating motion "holes" because the assumed order was wrong).

Furthermore, never use QTGMC if there is no regular interlacing (e.g. don't use it on Telecine with 3:2 or worse pulldowns, or even on norm conversion results with blending).

[Boulder]

Furthermore, never use QTGMC if there is no regular interlacing (e.g. don't use it on Telecine with 3:2 or worse pulldowns, or even on norm conversion results with blending).Out of interest, what is a good way to bob when redoing blended crap? I've been using QTGMC since it provides good quality even with non-purely interlaced material. Maybe it's just some of the post-processing stuff there that works well, I don't know.

[Sharc]

Out of interest, what is a good way to bob when redoing blended crap? I've been using QTGMC since it provides good quality even with non-purely interlaced material. Maybe it's just some of the post-processing stuff there that works well, I don't know.
Blended crap = blended fields or blended frames?
Dependiong on the root cause for the blending srestore() often helps. It might be a bit tricky (trial and error) to find the original (progressive) framerate if it is not compliant with one of the common (standard) rates.
Blended fields are more difficult or hopeless to fix, I think ....

[Boulder]

Oh, I meant preprocessing (=bobbing) the clip to feed to SRestore. SRestore itself works quite well in most cases if the pattern is constant.

[Sharc]

I normally use tdeint(mode=1) as a bobber,
or QTGMC(input type=0)
followed by srestore(omode="pp3"), possibly followed by
tdecimate() for removing double-blended fields.

You may already have tried this though ....

[DJ-1]

Hi, if I want a good analysis of source material I need to have trimmed my source from time to time. I usually use dvd shrink & use its cut feature but have read about programs not doing 'clean-cuts'.
Can someone recommend a 'clean-cutting' cutter?, thanks.

[LigH]

For MPEG2 sources like on DVD Video: Cuttermaran or MPEG2Schnitt. They will be able to cut GOP-wise, or even frame-accurate with smart re-encoding if you use one of the MPEG2 encoder "provider" modules (e.g. for HC).

[Music Fan]

Dvd-Shrink cuts correctly on I-frames because it can not re-encode (no smart rendering).

[Music Fan]

I normally use tdeint(mode=1) as a bobber,
or QTGMC(input type=0)
followed by srestore(omode="pp3"), possibly followed by
tdecimate() for removing double-blended fields.
What does "double-blended fields" mean ?
Does your script work with blended fields from interlaced videos (resized without de-interlacing) ?

[Sharc]

What does "double-blended fields" mean ?
Both fields of a frame are blended.
Does your script work with blended fields from interlaced videos (resized without de-interlacing) ?
I don't know, but I doubt. You would have to try and see whether you get some improvement. There are probably better scripts for that purpose. Resizing of interlaced content without prior deinterlacing is bad.
Perhaps someone else could chime in ....

[simcut]

QTGMC will rely on the field order AviSynth assumes after loading the source clip.

Not all source filters are able to determine the field order correctly (e.g. AviSource will probably assume BFF because the AVI container does not flag it, each VfW codec may have its own default, and BFF is the most common default for DV in AVI); sometimes even the encoding studio flagged the material wrong. In general, better be safe than sorry (to have wasted hours due to QTGMC creating motion "holes" because the assumed order was wrong).

Furthermore, never use QTGMC if there is no regular interlacing (e.g. don't use it on Telecine with 3:2 or worse pulldowns, or even on norm conversion results with blending).

Thank you for your advice man, much appreciated! :)

[hello_hello]

Would it be normal for QTGMC to be slower when working with non-mod16 video than if it's mod16?

I've been re-encoding some old video which is mostly 720x576 and running QTGMC in progressive mode to clean it up a little.
QTGMC(InputType=1, Ezdenoise=1)

I noticed every so often one of the encodes would take much longer. A little investigating seems to indicate it's due to a mod4 width. If I resize to mod16 in the script before QTGMC the speed goes back to normal, but that's not ideal as I'm also resizing after QTGMC.

It's not the end of the world and something I probably only noticed because the old dual-core I'm using is pretty slow anyway. When the resolution is 720x576 it only manages about 5.5fps, but CPU usage sits on 90%-100%. When the width is mod4 (ie 716x576) it drops to about 2.8fps and CPU usage hovers around 70%. There's a couple of encodes which I think ran even slower and they may have also had a mod4 height. I'd need to go back and do some more testing to confirm that.

I've tried QTGMC 3.32 and 3.33. I've checked to see whether I'm still using the QTGMC recommended versions of the various plugins and went back to the recommended versions where I wasn't but that didn't seem to make any difference. Avisynth 2.6.0.4, Windows XP.

Thanks.

[Boulder]

It could be memory alignment playing tricks on you (see Crop in Avisynth's documentation). You could try using Crop with the align=true option to get around it. Or Crop(0,0,-0,-0,true) if you've already cropped the video elsewhere.

[hello_hello]

Thanks Boulder.

I ran a test with a source video with a resolution of 716x576.

With this script it runs at about 2.8fps

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
crop(0,0,-0,-0,true)
QTGMC(InputType=1, Ezdenoise=1)
crop(4, 4, -4, -6)
Spline36Resize(656,480)

With this script it runs at 5.1fps

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
Spline36Resize(720,576)
QTGMC(InputType=1, Ezdenoise=1)
crop(4, 4, -4, -6)
Spline36Resize(656,480)

I even tried a second PC (quadcore). Being slow and running in single threaded mode, I'd normally run two QTGMC encodes at the same time. When I do, the encode of the video with a mod16 resolution runs a fair bit faster (close to 2x) than the one with the mod4 resolution.
I've tested without fpsnum=25, fpsden=1 and threads=1, but they don't seem to be causing it. QTGMC's Ezdenoise doesn't seem to be the culprit either.

[LigH]

Uh, scaling twice... I may rather have added a border and cropped as much more.

[asarian]

Thanks Boulder.

I ran a test with a source video with a resolution of 716x576.

With this script it runs at about 2.8fps

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
crop(0,0,-0,-0,true)
QTGMC(InputType=1, Ezdenoise=1)
crop(4, 4, -4, -6)
Spline36Resize(656,480)

With this script it runs at 5.1fps

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
Spline36Resize(720,576)
QTGMC(InputType=1, Ezdenoise=1)
crop(4, 4, -4, -6)
Spline36Resize(656,480)

I even tried a second PC (quadcore). Being slow and running in single threaded mode, I'd normally run two QTGMC encodes at the same time. When I do, the encode of the video with a mod16 resolution runs a fair bit faster (close to 2x) than the one with the mod4 resolution.
I've tested without fpsnum=25, fpsden=1 and threads=1, but they don't seem to be causing it. QTGMC's Ezdenoise doesn't seem to be the culprit either.

Instead of Spline36Resize(720,576), why not just AddBorders (4, 0, 0, 0) or something? The way you do it now, you're losing data.

Several QTGMC options even require mod16; so, always best to pad your source up to mod16 to begin with, I'd say.

[hello_hello]

In the end, I've used this script to solve the slowdown problem, while wondering why I didn't just think of it in the first place......

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
AddBorders(4,0,0,0)
QTGMC(InputType=1, Ezdenoise=1)
crop(8, 4, -4, -6)
Spline36Resize(656,480)

I use QTGMC for noise reduction quite a bit and I've not paid much attention to the source video dimensions in the past. Next time I'll try something similar if the source isn't mod16 to test whether the speed difference is normal.

Edit: I found the solution while you guys were suggesting it too, but I didn't see your posts until I submitted this one.
Thanks!

[-Vit-]

Kudos to the VapourSynth guys for getting QTGMC native. Wonder how well it works.

Just passing by to say hello - happy to see the script still being used. My avisynth development fell by the wayside when other things came up. Today I needed to do some video processing for first time in a long time. I found I didn't even have a working avisynth setup, lol. I seem to have lost the latest QTGMC version I had been working on. Probably for the best, it was getting even more complex...

[Reel.Deel]

-Vit-, nice to see you around. Don't be a stranger :)

[-Vit-]

Thanks. I posted a little present (http://forum.doom9.org/showthread.php?t=171346), but I don't do much video work these days so...

[jriker1]

I have some VHS captures and trying to use QTGMC to deinterlace. There have been some other posts here about this issue, but the resolution is always the poster not realizing they didn't fix the problem but changed the colorspace.

I have some YUY2 footage. AVISynth script works fine in Windows XP 32-bit. But on my Windows 7 box 64-bit no joy. Note using AVISynth 2.5.8 32-bit on both and both "work", just not with YUY2 colorspace. If I use a DV footage with YV12 goes thru fine as it's skipping the problem routine. This is where most people end their struggle by adding ConverttoYV12 into their script and thinking the problem was fixed.

I have tried a bunch of DLL changes but rather than get into them all will look for advice on thoughts how to get things working. I keep getting "There is no function named "Interleaved2Planar" ....QTGMC-3.22.avsi, line 350.

So I have


Windows 7 64-bit
AVISynth 2.5.8 32-bit
Appropriate files in the WOW64 folder
Rest files installed as described in the original install packet
mt_masktools-25.dll is in the plugin folder.
Per the first page I already have Visual Studio Redistributable 2010 (newer than linked on main page) installed.


Any thoughts how to get this working? Or a minimum copy of someone's plugin folder with a similar setup that is working?

Thanks.

JR

[Reel.Deel]

I keep getting "There is no function named "Interleaved2Planar"

You need the SSE Tools plugin from the Remove Grain v0.9 package (http://avisynth.nl/index.php/RemoveGrain_v0.9).

[jriker1]

You need the SSE Tools plugin from the Remove Grain v0.9 package (http://avisynth.nl/index.php/RemoveGrain_v0.9).

So to confirm, I need SSETools.dll and not SSE2Tools or SSE3Tools? Right now I have SSE2Tools.dll in the plugin folder which believe came from the original QTGMC install pack.

Thanks.

JR

[StainlessS]

SSE2Tools should be just fine, just a faster version than SSETools and which should be OK on your machine.
I have heard rumblings that SSE3Tools has problems but cannot confirm, I am happy to use SSE2Tools
even though my machine is SSE3 compatible.

EDIT:
SSETools is minimum Pentium III, SSE2Tools min P4.

[jriker1]

Thanks. One question. Should you be able to do a LoadPlugin on the SSE2Tools.dll file? I tried it for good measure and it says "AVISynth open failure: LoadPlugin unable to load ....SSE2Tools.dll"

EDIT: I tried replacing the SSE2Tools.dll with the one from 0.9 assuming it wasn't the same to begin with and same error. Here are the plugins in my folder. Most don't have version information imbedded otherwise would pull all that:

AddGrainC.dll
AviSynthPluginsDir.avsi
aWarpSharp.dll
colors_rgb.avsi
\ConditionalSmoothBob
ConditionalSmoothBob.avsi
DenoiseSharpen.dll
DePan.dll
DePanEstimate.dll
dfttest.dll
DGDecode.dll
DGIndex.exe
DGIndex.ini
DGPulldown.exe
DirectShowSource.dll
\dv2film
dv2film.avsi
dv2film.txt
EEDI2.dll
eedi3.dll
ffavisynth.avsi
ffavisynth.dll
FFT3DFilter.dll
GetSystemEnv.dll
GetSystemEnv.html
hd2sd.avsi
hd2sd.txt
\hd2sd_sd2hd
masktools2-25.dll
MT.dll
mt_masktools-25.dll
mvtools2.dll
NicAudio.dll
nnedi.dll
nnedi2.dll
nnedi3.dll
QTGMC-3.32.avsi
RemoveDirt.dll
RemoveDirtMC.avs
RemoveDirtS.dll
RemoveDirtSSE2.dll
RemoveGrain.cpp
RemoveGrain.dll
RemoveGrain.htm
RemoveGrainS.dll
RemoveGrainSSE2.dll
RemoveGrainSSE3.dll
Repair.dll
RepairS.dll
RepairSSE2.dll
RepairSSE3.dll
RSharpen.dll
RSharpenS.dll
RSharpenSSE2.dll
RSharpenSSE3.dll
sd2hd.avsi
sd2hd.txt
Srestore.avsi
SSE2Tools.dll
TCPDeliver.dll
TDeint.dll
TIVTC.dll
VerticalCleanerSSE2.dll
Where_to_put_these.txt
yadif.dll


JR

[Music Fan]

Try to remove the 3 ...SSE3.dll

[StainlessS]

SSE2Tools.exe requires MSVCR71.dll, see a bit about it here: (from Visual Studio toolkit 2003 / VS DotNet 2003 [I think])

http://forum.doom9.org/showthread.php?p=1696600&highlight=MSVCR71.dll#post1696600

and here:
http://forum.doom9.org/showthread.php?p=1620387#post1620387

or here:
https://www.google.co.uk/?gws_rd=cr&ei=ZE7PUrCTJMrStAa9p4CoAg#q=msvcr71.dll+microsoft

[johnmeyer]

Why do you want to deinterlace? Remember, deinterlacing always reduces the quality of the video.

Always.

When you re-size the video, you must first deinterlace, so there are times when it must be done. However, if you are simply making a DVD from your VHS tapes, I would recommend against doing any deinterlacing.

[LigH]

You may have too many competing DLLs (providing functions with the same name) in your plugin folder where AviSynth tries to load automatically from. Especially regarding R*SSE*.dll, I would strongly recommend not to have SSE, SSE2 and SSE3 variants of the same in this directory, but only one kind of each (e.g. only SSE2 of them all).

And StainlessS may be correct, there are many Microsoft Visual C++ Runtime versions out there (2003..2013) you may have to install once for all applications and DLLs which may need any of them.

[StainlessS]

DGIndex.exe # Should not really be here
DGIndex.ini # ditto
DGPulldown.exe # ditto
RemoveGrain.cpp # ditto
RemoveGrain.htm # ditto

RemoveDirt.dll # Only one of these (SSE2 or SSE3 OR 'S' version meaning 'Static' does not require CPP runtimes)
RemoveDirtS.dll
RemoveDirtSSE2.dll

RemoveGrain.dll # Only one of these (SSE2 or SSE3 OR 'S' version meaning 'Static' does not require CPP runtimes)
RemoveGrainS.dll
RemoveGrainSSE2.dll
RemoveGrainSSE3.dll

Repair.dll # Only one of these (SSE2 or SSE3 OR 'S' version meaning 'Static' does not require CPP runtimes)
RepairS.dll
RepairSSE2.dll
RepairSSE3.dll

RSharpen.dll # Only one of these (SSE2 or SSE3 OR 'S' version meaning 'Static' does not require CPP runtimes)
RSharpenS.dll
RSharpenSSE2.dll
RSharpenSSE3.dll


EDIT:
The 'S' versions are a lot easier as require no runtime but are usually bigger as they include the C libraries instead of loading a dll.

And a Ligh say above, you cannot just install latest version of the runtimes, the avisynth dll's are tied to a particular CPP runtime,
and so you may need to install, from VS 2005, 2008, 2010, 2012, 2013, and 2014, depends what you require,
as I said, the 'S' versions are easier.

And you do not need to LoadPlugin for most dll's if they are in your plugins directory. (although some people like to LoadPlugin for
everything, I have about 270 plugs in my dir at times but not at present).

[Reel.Deel]

Should you be able to do a LoadPlugin on the SSE2Tools.dll file? I tried it for good measure and it says "AVISynth open failure: LoadPlugin unable to load ....SSE2Tools.dll"


It sounds like like you're missing the MSVCR71.DLL runtime dependency. Download it here: msvcr7071msvcp7071.rar (https://web.archive.org/web/20070706223430/http://home.arcor.de/dhanselmann/_stuff/msvcr7071msvcp7071.rar) and add to your system directory (SysWOW64 on Windows 7); you can also add MSVCR71.DLL to the AviSynth plugin folder, I don't know if this is considered kosher but it does work (I sometimes use it this method for testing).

Edit: too slow, StainlessS beat me to it...

[jriker1]

Why do you want to deinterlace? Remember, deinterlacing always reduces the quality of the video.

Always.

When you re-size the video, you must first deinterlace, so there are times when it must be done. However, if you are simply making a DVD from your VHS tapes, I would recommend against doing any deinterlacing.

Hi JohnMeyer. I am not creating DVD's. They will end up being some form of media file on my media server so will be MKV or MP4 or WMV or something and played on a plasma or LCD display so figure deinterlacing is the right choice.

Removing the SSE3 files didn't help. Whether they should be there is another story. I'll cleanup per your recommendation StainLessS

However BINGO!!! Adding the MSVCR71.dll did it in the SysWOW64 folder. Thank you StainlessS and Reel.Deel.

[jriker1]

Now for the next problem to research. VirtualDub hit with out-of-bounds memory access (access violation) occurred in module 'lagarith'...reading address 076A4000.

Think I saw that before and switched to HuffyUV but since HuffyUV is no longer updated and never had a real installer for Windows 7 always found it less usable overall in my various tools.

JR

[Boulder]

Why not install ffdshow and use ffv1 in VDub, it's a very efficient lossless codec.

[Music Fan]

They will end up being some form of media file on my media server so will be MKV or MP4 or WMV or something and played on a plasma or LCD display so figure deinterlacing is the right choice.
You media server should be able to play interlaced videos.
Anywyay, if you need to de-interlace, 50p or 60p is better than 25p or 30p, it keeps the fluidity.

When you re-size the video, you must first deinterlace
I found a script that can resize interlaced videos without having to de-interlace and there is no field blending, JDL_InterlacedResize ;
http://www.avisynth.nl/users/stickboy/
It needs jdl-interlace.avsi and jdl-util.avsi.

I also use JDL_UnfoldFieldsVertical to separate fields and gather them one above the other to create a progressive video, which allows to use all filters only working on progressive videos. After filtering, put JDL_FoldFieldsVertical to re-interlace the video.
The option flip=true reverse the bottom field to make the 2 fields touching themselves by their bottom side, this may help spatial filters.

That saves a lot of time and quality when de-interlacing is not absolutely needed.

[johnmeyer]

I found a script that can resize interlaced videos without having to de-interlace and there is no field blending, JDL_InterlacedResize.Yes, you are correct: you can separatefields (or bob), resize, and then weave, and thereby avoid deinterlacing. This is faster than deinterlacing, but still avoids creating those horrible artifacts which result from resizing interlaced material using both fields at once.

However, there is no free lunch: while this does eliminate deinterlacing artifacts, resizing done this way is not as accurate because spatial information from the even fields is not used when deciding where to put each pixel for the odd fields (and vice versa). Each method has its advantages.

As always, there is no best choice ...

[Boulder]

If you need to deinterlace either by bobbing or discarding a field, QTGMC is definitely the way to go. The minor details look much better (provided that you don't cheat by choosing a too light a preset). The shutterblur option is very good IMO, even a clip with a discarded field looks very smooth in motion.

Personally I tend to bob-deinterlace to 50p or 60p with QTGMC because none of my playback devices come even close when quality is the main concern.

[hello_hello]

Why do you want to deinterlace? Remember, deinterlacing always reduces the quality of the video.

Always.

What particular video playing setup today is likely to display interlaced video without de-interlacing it?

Personally, I think QTGMC de-interlacing tends to improve the quality. At least compared to any other de-interlacing method, whether it be when encoding or on playback.

[jriker1]

I've had other problems with Lagarith before so may be misinterpreting this, however if I take a YV12 clip, and a YUY2 clip, and run them thru an AVISynth script (separately obviously), same script, just the YUY2 clip is AVI so using AVISource and the YV12 clip is MPG so using MPEG2Source, the YV12 one runs thru QTGMC every time, the YUY2 one keeps crashing even using half my cores as part of the SetMTMode command.

JR

[jriker1]

One curious thing I was wondering. If you are using AVISynth MT and encoding thru VirtualDub should you be checking the multithreading support in Lagarith or does that confuse things? Wasn't sure if AVISynth managed all the multithreading and Lagarith should be left unchecked. Would imagine not else I wouldn't be able to make it thru an hour and a half of encoding a file in YV12 colorspace in the first place.

JR

[jriker1]

Why not install ffdshow and use ffv1 in VDub, it's a very efficient lossless codec.

I'm not a big fan of installing ffdshow on my encoding box (minimal installs there), as it always seemed to want to take over a lot of stuff. Is there a way to install ffv1 by itself without the full ffdshow?

Getting annoyed right now as I'm running a deinterlace job and it's going to take one day thirteen hours without multi-threading support but with was going to be nine hours. Could switch to HuffyUV but my main system doesn't see it in VirtualDub for some reason.

Thanks.

JR

[foxyshadis]

Skip Lagarith in favor of UT video, or MagicYUV. Too many bugs in Lagarith if you use anything but YV12, it's slow, and the compression isn't that much better than UT or MagicYUV. ffv1 on the other hand is smaller and slower. The trade-off's up to you though. To get ffv1, install latest ffdshow (http://sourceforge.net/projects/ffdshow-tryout/files/latest/download?source=files) and select only the VFW part, not the DirectShow stuff. (DirectShow will still get extracted, but won't actually be functional.)

You should probably replace RemoveGrain everything with RGTools (http://avisynth.nl/index.php/RgTools). That fixes all of kassandro's SSE bugs, and it's faster, to boot.

[LigH]

Download it here:

In general, I would discourage people from downloading DLLs from any arbitrary archive.

The problem here is: MSVC?71.DLL are part of Microsoft Visual C++ .NET 2003 with the Microsoft .NET Framework 1.1. Windows 7/8 won't support .NET 1.1 anymore, it won't install. There is no Redistributable for these DLLs only. So in this case ... well ... downloading them or copying them from another PC may be your only options. Meh.

KB326922 (http://support2.microsoft.com/kb/326922/)
__

P.S.: Thank you for linking the RgTools, that was new to me, interesting project. If it is compatible enough for QTGMC, it will probably be useful for many people who prefer an up-to-date AviSynth.

[Music Fan]

Skip Lagarith in favor of UT video, or MagicYUV. Too many bugs in Lagarith if you use anything but YV12, it's slow, and the compression isn't that much better than UT or MagicYUV. ffv1 on the other hand is smaller and slower.
Slower and not as easy to use as Lagarith, I never had problem with Lagarith (yuy2, yv12, rgb) which is for me the best lossless codec. I don't really see the utility to use UT video or anything else.

[jriker1]

Skip Lagarith in favor of UT video, or MagicYUV. Too many bugs in Lagarith if you use anything but YV12, it's slow, and the compression isn't that much better than UT or MagicYUV. ffv1 on the other hand is smaller and slower. The trade-off's up to you though. To get ffv1, install latest ffdshow (http://sourceforge.net/projects/ffdshow-tryout/files/latest/download?source=files) and select only the VFW part, not the DirectShow stuff. (DirectShow will still get extracted, but won't actually be functional.)

You should probably replace RemoveGrain everything with RGTools (http://avisynth.nl/index.php/RgTools). That fixes all of kassandro's SSE bugs, and it's faster, to boot.

Thanks for the thoughts I was just looking at UT and MagicYUV. Compression isn't critical for me, just that it maintains its colorspace and is lossless. This is an intermediate file and have loads of space. With MagicYUV it has a checkbox for interlaced. Do I actually have to check and uncheck this if the footage is interlaced or not each time? Assume I would leave unchecked considering the output is progressive deinterlaced footage that im working on now

EDIT: Will updating to RGTools help if with QTGMC I'm doing QTGMC(preset="Very Slow"). Still good to know and update of course.

Guess MagicYUV didn't help five minutes in crashed with a best guess at the cause KERNELBASE. Any vslue in trying the latest 2.6 of Avisynth and the 64-bit version?
JR

[foxyshadis]

thanks for the thoughts I was just looking at UT and MagicYUV. Compression isn't critical for me, just that it maintains its colorspace and is lossless. This is an intermediate file and have loads of space. with MagicYUV it has a checkbox for interlaced. do I actually have to check and hncheck this if the footage is interlaced or not each time? assume I would leave unchecked considering the output is progressive deinterlaced footage that im working on now

JR

Only if you do a mode conversion from RGB or YUY2 to 4:2:0 (YV12) or vice versa, where it matters how you convert the chroma. Otherwise, I think it only changes the compression % slightly.

[-Vit-]

As I've been away, could someone update me on all the filter updates that have affected QTGMC recently? I noticed that masktools-2.6 doesn't work anymore. And now there is this RGTools. Anything else?

It would be nice to update the first post to be correct for current usage.

[jriker1]

I tried dropping RgTools.dll in my plugin directory. Caused the script to fail. I've also updated to latest 2.6MT.

Avisynth: access violation at 0x00000000 in virtualdub.exe
attempting to read from 0x000000000
QTGMC-3.22.avsi line 756
QTGMC-3.22.avsi line 781
QTGMC-3.22.avsi line 386

No documentation if this replaces other plugins what to physically remove if they are installed. If this is the problem. I tried removing RemoveGrainSSE2.DLL but didn't help.

Also ran into some other issues.

SEt's latest Avisynth 2.6MT doesn't work with the latest plugins. Got all kinds of access violations. Read a post that said the latest doesn't work. Had to go back to a prior version and problems went away.

mt_masktools-26.dll recommended for 2.6 doesn't work as -Vit- heard. Get colorspace errors and had to go back to 25.

JR