Trying To Get QTGMC() To Work

[ZenMystic]

I totally uninstalled then reinstalled and updated to the latest versions of AviSynth and MeGUI. I am running the 32bit versions.

AviSynth 2.60 Build Feb20 2015
MeGUI 2525

ok so... I went here http://forum.doom9.org/showthread.php?t=156028

And downloaded plugin pack using the updated Avisynth 2.6 interface

I then put the Avisynth 32-bit Plugins in C:\Program Files (x86)\AviSynth 2.5\plugins and put the 32-bit System dlls in the Windows\SysWoW64 folder because I am running windows 7 Pro 64

I also tried updating AviSynth.dll from here http://forum.doom9

But I get this error AviSynth access violation mt_masktools-26.dl
If I use AviSynth mt_masktools-25.dl I get a access violation RemoveGrainSSE2.dll

Can anyone help me?

[Groucho2004]

Try the plugins I linked to here (http://forum.doom9.org/showthread.php?p=1733741#post1733741).

[ZenMystic]

No that didn't work either.... could someone help me setup and use GTGMC() please

I would really appreciate this been at it for 3 days now to get it to work.

[Reel.Deel]

No that didn't work either....

That doesn't tell us anything. If you want help you have to be more descriptive. Any error message(s)? Just guessing I would say you're probably missing the MSVC runtimes (very common problem), download and install vcredist_x86.exe (http://www.microsoft.com/en-us/download/details.aspx?id=30679). Also make sure you're using the 32-bit version of the plugins and delete all of the plugins from the "QTGMC plugins package using the updated AviSynth 2.6 interface", those plugins are all incompatible with AviSynth 2.6.

[ZenMystic]

ok so I installed vcredist_x86.exe and removed the plugins from the folder. It was getting to be a lot in there from trying this or that.

So I have clean installs of:
AviSynth 2.60 Build Feb20 2015
MeGUI 2525
And I'm ready to go with what is next.

Can someone tell me what dlls I need to put in there please? And possibly post a script for testing purposes.

Also it is better to have MT ones because they use my dual core yes?

This is the first time I've ever had trouble trying to get a AviSynth script to work. I am now on like day 4/5 of trying to get this to work lol. Getting just a little frustrated but oh well. But I can't seem to let it go either.

[Reel.Deel]

QTGMC() with default settings requires only these core plugins: MaskTools2, MVTools, nnedi3, RgTools. Use the plugins that Groucho2004 linked to. For nnedi3 you can use the official nnedi3 (http://avisynth.nl/index.php/Nnedi3) or nnedi3 for AviSynth 2.6 (https://github.com/jpsdr/NNEDI3/releases). If you want to use other features like denoising then you'll need FFT3DFilter or dfttest, read the documentation (http://avisynth.nl/index.php/QTGMC#Requirements) for more info.

I see you're using AviSynth 2.60 Build Feb20 2015, wouldn't hurt to update to the latest version (http://sourceforge.net/projects/avisynth2/).

[foxyshadis]

Some of the plugins might need the other VCRedists (https://support.microsoft.com/en-us/kb/2977003). It's a good idea to get the 2008, 2010, 2012, 2013, and 2015 (https://www.microsoft.com/en-us/download/details.aspx?id=48145)! (Quite a pain.) I don't think anything made with 2005 is still floating around, but that's another. Each dll can potentially use a different version.

Oddly enough, I haven't seen anyone put together a single mega-installer on MSFN yet. That would be VERY helpful.

[ZenMystic]

ok well I finally got it all working!!! At last!!! I've never had to fight so hard to get a script to work. So thank you one and all!!.....

Anyway I just want to do a final check that I have done everything correctly....

I updated and downloaded the dll's I was asked to. Updated AviSynth... And the other VCRedists....

I also download GRunT.dll from here: http://forum.doom9.org/showthread.php?t=139337 for use with SRestore(), (took me a while to realise it was a avsi script)

I also had to swap out AviSynth.dll for the MT version http://forum.doom9.org/showthread.php?t=148782 It was slightly older than the AviSynth.dll already in there but not by much. And it cut down my encode time by 50%.

Here is my script:

# Set DAR in encoder to 16 : 9. The following line is for automatic signalling
global MeGUI_darx = 16
global MeGUI_dary = 9

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RgTools.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\GRunT.dll")

import("C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC-3.32.avsi")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\SRestore.avsi")

SetMemoryMax(2000)
SetMTMode(3, 8)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("Video.mkv", cachefile="Video.ffindex", fpsnum=30000, fpsden=1001, threads=1)
SetMTMode(2)
QTGMC(EdiThreads=2)
SRestore()
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\UnDot.dll")
Undot() # Minimal Noise

Now I should use QTGMC on interlaced video only right?
What about partial film/interlaced stuff?

Is my Resize in the right place? I know when you resize you have to be careful not to destroy the the fields in the video or something.

Is there anything else I should do?

Once again I appreciate the time and effort that was given to me. Thank You

[chainring]

Some of the plugins might need the other VCRedists (https://support.microsoft.com/en-us/kb/2977003). It's a good idea to get the 2008, 2010, 2012, 2013, and 2015 (https://www.microsoft.com/en-us/download/details.aspx?id=48145)! (Quite a pain.) I don't think anything made with 2005 is still floating around, but that's another. Each dll can potentially use a different version.

Oddly enough, I haven't seen anyone put together a single mega-installer on MSFN yet. That would be VERY helpful.

Here ya go.

http://www.wincert.net/forum/topic/9790-aio-microsoft-visual-bcfj-redistributable-x86x64/

[foxyshadis]

Here ya go.

http://www.wincert.net/forum/topic/9790-aio-microsoft-visual-bcfj-redistributable-x86x64/

Thanks! Ricktendo is always awesome. I'll put that in my bag of tricks.

[Groucho2004]

Thanks! Ricktendo is always awesome. I'll put that in my bag of tricks.
+1. Very handy.

[feisty2]

Some of the plugins might need the other VCRedists (https://support.microsoft.com/en-us/kb/2977003). It's a good idea to get the 2008, 2010, 2012, 2013, and 2015 (https://www.microsoft.com/en-us/download/details.aspx?id=48145)! (Quite a pain.) I don't think anything made with 2005 is still floating around, but that's another. Each dll can potentially use a different version.

Oddly enough, I haven't seen anyone put together a single mega-installer on MSFN yet. That would be VERY helpful.

guess you won't need the "msvcr" stuff if the program was compiled under "Release" mode?
then why would anyone actually want to build some already developed program with "Debug" mode (= msvcr will be required)?
"Debug" mode is only useful when the program is still under development, right?

[Groucho2004]

guess you won't need the "msvcr" stuff if the program was compiled under "Release" mode?
then why would anyone actually want to build some already developed program with "Debug" mode (= msvcr will be required)?
"Debug" mode is only useful when the program is still under development, right?
The need for the runtime DLLs has nothing to do with Release or Debug builds.
You need them when you use dynamic linking in your project, you don't need them if you link against static libraries.

[wonkey_monkey]

guess you won't need the "msvcr" stuff if the program was compiled under "Release" mode?

You do, by default, even under Release mode. It's the Runtime Library setting in Visual Studio that makes the difference. It defaults to Multi-threaded DLL (/MD) in Release mode, which means you'll require whichever MSVCR it was built against to be locally installed. Changing it to Multi-threaded (/MT) removes that requirement by incorporating whatever it needs, with the penalty of a larger output. I always build with /MT now, after numerous good-natured complaints.

At least, that's what I've come to believe over the years. I may be wrong about this.

[feisty2]

http://i.imgur.com/0nGXFKU.png
yeah, found it here, next time I'm compiling something, I'll make it /MT

[wonkey_monkey]

I would also recommend setting Enable Enhanced Instruction Set to SSE2. Practically everyone has it these days, and even if you don't directly code for it, the compiler might be able to use it to give your plugin a speed boost.

There may also be options there for AVX and AVX2, but those are much newer (2011 onwards), so older processors may not be able to run your compiled code.

You will need to set these options separately for x86/x64 and debug/release.

[Groucho2004]

For those who link their DLLs against a static CRT, I strongly recommend reading this article (https://msdn.microsoft.com/en-us/library/vstudio/abx4dbyh%28v=vs.110%29.aspx) on MSDN.
Pay close attention to this paragraph:
Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. For example, if you call _set_se_translator in an executable that loads the DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, but hardware exceptions generated by code in the main executable will be caught.
There are other caveats, I suggest using Google to learn about these.

[Groucho2004]

I would also recommend setting Enable Enhanced Instruction Set to SSE2.
I'd be careful with that as well, using arch:SSE or arch:SSE2 may reduce the accuracy of floating point operations. Here (https://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/) is a very good article on the subject. If you're impatient, scroll down to the section named "/arch:SSE/SSE2".

[NikosD]

I'd be careful with that as well, using arch:SSE or arch:SSE2 may reduce the accuracy of floating point operations. Here (https://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/) is a very good article on the subject. If you're impatient, scroll down to the section named "/arch:SSE/SSE2".
Speaking of MS VC compiler and optimizations , I would like to ask if MS VC 2013 compiler provides any kind of auto-vectorization or vectorization in general.

I remember compiling the FLOPS C code with double precision floating point arithmetic, using MS VC 2013 with SSE2, AVX and AVX2-FMA3 switches, but non of them produced any speedup, although after disassempling the SSE, AVX and FMA3 versions, the code was there for each instruction set.

So, it surely produces the instructions, but the final result was the same speed for all those executables on Haswell.

It seems that it uses optimizations for all those instruction sets, but not for executing vectored code of arithmetic operations, probably some other kind (memory, caches) of optimizations.

I'm not sure, I'm waiting for your feedback.

[wonkey_monkey]

I was under the impression that it was just that certain things could be done quicker using SSE instructions even on single operands. There's some data here (http://gruntthepeon.free.fr/ssemath/) that suggests, for example, that sin implemented in SSE is 5 times quicker than ye olde sinf. It's not clear whether that's for one operand or four at once, but either way it still implies a speed-up with a single operand.

Maybe the speedups aren't so good for double precision stuff?

[NikosD]

I reported the issue only for VC 2013 compiler.

Using Intel C compiler 2013 the speedup on the same code reached about x8 using FMA3

[feisty2]

x8!! I'll take it as I will never ever need to do the asm opt stuff on my own, ever, right?
Woohoo, sounds awesometastic to me!

[NikosD]

Actually the speedup from the original ancient compilation is x7.8 to x8.7 (!)

But this is not a real - world app, just a benchmark which fits inside L1 cache and is mainly arithmetic (almost no branches and low memory operations)

Indeed the Intel compiler does an excellent job but I have to correct one statement.

The MS VC 2013 compiler using AVX2-FMA3 is about 45% to 60% faster than SSEx/AVX with the same compiler.

I'm 100% sure that I didn't manage to make VC vectorise the code (actually that's what I'm asking - if it can do it), but it seems that it can optimize the code for the FMA execution units and execute FMUL and FADD together.

The speedup of ICC 13.1 from AVX to FMA3 was 56% to 82% (!)