SEt's Avisynth 2.5.8 MT compiled for *X86_64*, Latest Build 4/16/2010

[VincAlastor]

I probably don't need a 64 bit OS to make the build. But I do need someone with 64-bit expertise to tell me how to make such builds. I have never made a 64-bit anything.

i hope there is an expert. don't be angry about me, i think you could understand me, that i wish a x64 version of your modern source filters :)

i'm not a programmer, but i'm a good tester :D

[Guest]

I'm not angry! I'll be happy to make a 64-bit build if someone is willing to educate me about it.

[JoshyD]

@neuron2
You can compile 64bit binaries without a 64bit operating system, you just can't test them without a 64bit computer/os :) The ease of porting the build will depend on how much it relies on assembly language, always considering pointers as the same length as an int, etc. If you want to try, I can find you some good reading material.

Also, isn't dg nv tools written in CUDA? I'm not super-familiar with compiling it, is it done via a custom NVIDIA compiler? If that's the case, and it only uses NVIDIA specific language references (I know CUDA is C like, or something) then it may be as easy as changing your compile target architecture to x64.

A little background info on how it's written, and I think I can get you going . . .

@Audionut
That error (the MT plugin is written in russian originally, I think?) usually happens when something goes wrong in the script you're trying to invoke. Syntax error, filter not loaded, something little is missing. That's really the only place in the code I see that error, so I don't know what to tell you. Something's throwing an exception in your chain.

@osgZach
Thread deadlock should be resolved by tonight. I'm pretty sure it's a result of me giving the compiler free reign to add parallelism where it *thinks* it is safe. I think I've mentioned this in an earlier post, compilers are stupid, I shouldn't have trusted it, but oh well. I can thread it all by hand eventually, but that's not my main concern. I'm working on some performance tweaks here and there that should make everyone smile.

[Guest]

If you want to try, I can find you some good reading material. Sure, please do. There is no assembler in the DLLs and just some basic stuff in DGIndexNV for chroma upsampling.

Also, isn't dg nv tools written in CUDA? No. It uses the CUVID API.

A little background info on how it's written, and I think I can get you going . . . See above.

[osgZach]

Joshy, cool will look forward to testing when it's released.

Also, just wanted to say, I know we all have problems with the build but don't let our whining control when you release updates or how often you work on it. I know how easy it is to get burned out on something you start out doing because you want to. I'd rather download an update a week later than a hastily put together crowd pleaser ;)

In other news.. I've gone back to using MT("filter") as I appear to have solved the overlap issue by cranking it up to 12.. Which I was initially afraid to do because I thought it would actually overlap the sections to the point where actual data started dissapearing.. It seems to work though, I will be comparing it against other encodes made without MT("filter")..

It is interesting to note, that I can actually use my PC for web browsing and other tasks when using MT("filter") - as opposed to SetMTMode which makes the entire thing slow down to a bog crawl. Even though performance is roughly the same (although MT("filter") seems a bit faster ).. Any reason why that is? And would it be reasonable to expert SetMTMode in the future to not bog down the PC completely even when using all cores?

[levi]

SetMTMode doesn't bog down my PC. if you are getting weird behavior, i suggest you look in to:

limit # of threads - SetMTMode(2,x) - x = threads
limit max memory - SetMaxMemory(512)
try regulator()
post your script

:)

[paulvdb]

Sure, please do. There is no assembler in the DLLs and just some basic stuff in DGIndexNV for chroma upsampling.
Only the DLLs have to be 64-bit because they have to be loaded by 64-bit avisynth. You can still use the 32-bit indexer. At least that's how squid80 did it with DGMPGDec.

[osgZach]

Levi, I will if I have problems in the future. But for now I'm content that its working the way I have it.

The only time SetMtMode didn't bog down the PC was when trying out the x32 builds w/MT. And performance was not really better than single threaded either for the most part, although I saw occassional spikes past 50 under task manager.. Maybe I just have a goofy install of Windows going on, or something like that..

But if its working under MT("filter") then that is OK for now.


re: DGindex/NV, The indexer itself runs fine as a 32bit app, its the decoder DLL's that have to be 64bit, and they will have no problems loading the index file as its just a basic text file after all.. Squid's x64 release is just the Dgdecode.dll compiled for x64.

[Hiritsuki]

I just waiting tnlmeans x64 ver.
and it's release I change use X86 MT to X64 MT

[ifb]

I have a 1080i MPEG2 source that I deinterlace and resize to 512x288.

Vertically resizing to anything less than 720 causes crashes. BilinearResize() did not crash, but every other resizer did.

Using the latest Intel build from the top post on an i7 920.


SetMemoryMax(512)
Global NewHeight = 288
Global NewWidth = 512
SetMTMode(5)

Vid = MPEG2Source("file.d2v")
Aud = wavSource("file.wav")
SetMtMode(2)
AudioDub(Vid,Aud)
Spline36Resize(NewWidth,NewHeight)

[osgZach]

It doesn't look like your initial SetMTMode call specified the number of threads, try (5,0). You might even be able to get away with Mode 2.. There seems to be conflicting opinions about whether it works properly under any mode less than 5.

Is your input clip progressive? You shouldn't be resizing before a deinterlace also, and I don't know if trying to resize an interlaced clip would mess up MT either ?

You could also try resizing before your Dub operation ?

[ifb]

It doesn't look like your initial SetMTMode call specified the number of threads, try (5,0).Doesn't change anything. I've never had to specify thread number, even with vanilla avisynth.
You might even be able to get away with Mode 2.. There seems to be conflicting opinions about whether it works properly under any mode less than 5.Not setting mode 5 before DGSource reduces speed dramatically, even when changing to mode 2 later in the script.
Is your input clip progressive? You shouldn't be resizing before a deinterlace also, and I don't know if trying to resize an interlaced clip would mess up MT either ?It's 1080i, like I said. I removed the deinterlacer for simplicity. I can resize horizontally all I want, just not vertically to a value less than 720.

Normally (32-bit) the script would be:

Spline36Resize(NewWidth,height,8,0,-8,0)
Yadif()
Spline36Resize(width,NewHeight,0,-4,0,-4)


Leaving SetMTMode() out completely, causes virtualdub to get green frames instead of crashing completely on open.

[osgZach]

Are you using the newest compile of Dgdecode? (1.5.8)

Don't know if it matters, but not all the iDCT modes work, could that be causing an issue?

That's about all I can think of really. I don't have any HD source files to play with.

[ifb]

Are you using the newest compile of Dgdecode? (1.5.8)Downloaded today.

Don't know if it matters, but not all the iDCT modes work, could that be causing an issue?No, because then it wouldn't decode anything (or the output would be trash).

It's very simple. Resize height<720 using lanczos, spline, or bicubic -> crashes virtualdub and avs2avi.

OS is Win2k8 Server 64-bit.

I should be thorough and try an older build (prior to the vertical resizer using SSSE3).

<edit>
The 3-1-2010 build works fine.

[JoshyD]

I think your resize problem is really my fault . . . I noticed I rolled back to an older version of the resample function source when releasing that build. If you could try my latest compile, I'd appreciate it. Let me know if it's still crashing so I know if I need to delve deeper into the matter.

@neuron2
This details the differences between x86 and x64. (http://www.x86-64.org/documentation/abi-0.99.pdf) The main thing to watch out for is any assembler that assumes a certain calling convention. In x64, instead of parameter passing on the stack, you get the first four "integer" (pointers, shorts, whatever) in rcx, rdx, r8, and r9. The first four floating point typed arguments are passed in xmm0-xmm3 (I think). There is shadow space created on the stack where you would normally find these variables, but don't go looking there for them. It's just garbage memory to start with, unless you explicitly store the parameter there for later use. Also, all variables on the stack are aligned to 64bits. So, even though int types should take 4 bytes on your stack, 8 are actually allocated. However, when reading these from memory, you can't read all 8 bytes, only the first 4 contain useful memory.;=============================================================================
;void mmx_merge_luma( unsigned int *src, unsigned int *luma, int pitch, int luma_pitch,int width, int height )
;=============================================================================
; parameter 1(src): rcx
; parameter 2(luma): rdx
; parameter 3(pitch): r8d
; parameter 4(luma_pitch): r9d
; parameter 5(width): rsp + 40
; parameter 6(height): rsp + 48

in this example, getting from memory would look like:
mov eax, DWORD [rsp+40]

You can't do this:
mov rax, QWORD [rsp+40]

Because bytes 44-47 are garbage. It's the little things you have to get used to.

There are some other oddities, like whenever an extended register is used, a REX prefix accompanies the opcode. If you want to use an extended register (r8-r15) as a counter, dec and inc always treat them as 64bit values, even when specifying:

dec r8d
or
inc r9d

You still get a 64 bit add, which is slower.

Volatile registers:
rax
rcx
rdx
r8
r9
r10
r11

Non volatiles:
rbx
rbp
rdi
rsi
r12
r13
r14
r15

XMM0-XMM5 are volatile, XMM6-XMM15 are non-volatile.

If your compiler supports 64bit binary compilation, then your shouldn't have a problem just taking the source and compiling it as is.

Watch out for MSVS's compiler, it takes away inline asm when compiling for x64.

[squid_80]

64-bit adds/subs aren't slower, that's the whole point of having a processor that uses 64-bit registers.

[Stephen R. Savage]

I can confirm that I experience "Avisynth: unknown exception" when resizing 1920x1080 to 704x396 with Spline36Resize, using the latest Intel build. 1920x1080 -> 1280x720 -> 704x396 works.

[JoshyD]

My bad on the inc, dec instructions, I thought I had read something in the Intel docs about them, it was actually that some forms of them aren't supported. I think the instruction is encoding may longer when using the extended registers, regardless of which portion of the register you want to inc or dec.

The INC and DEC instructions are supported in 64-bit mode. However, some forms of INC and DEC (the register operand being encoded using register extension field in the MOD R/M byte) are not encodable in 64-bit mode because the opcodes are treated as REX prefixes.

There's also something about register dependency breaking (the whole register renaming in an out of order core thing) if you modify all the flags with an ADD or SUB rather than just an INC or DEC, I don't remember exactly what it is.
Edit: found it, from intel's optimization guidelines
Assembly/Compiler Coding Rule 32. (M impact, H generality) INC and DEC instructions should be replaced with ADD or SUB instructions, because ADD and SUB overwrite all flags, whereas INC and DEC do not, therefore creating false dependencies on earlier instructions that set the flags.


I'll look into why the resize is throwing an error. What color space is it giving the error in? I can't seem to get the crash in any color space . . .

[yo4kazu]

64bit support so that you can do?

_GPU25.dll(source)
http://www.mediafire.com/?jdtmm2cjvrm

HLSLfile for HD48xx
http://www.mediafire.com/?jdtmm2cjvrm

original author:thejam79
GPU_001(binary&source)
http://www.avisynth.info/?plugin=attach&refer=%A5%A2%A1%BC%A5%AB%A5%A4%A5%D6&openfile=GPU_001.zip
custom author:gpu25clone
_GPU25(binary)
http://www.avisynth.info/?plugin=attach&refer=%A5%A2%A1%BC%A5%AB%A5%A4%A5%D6&openfile=_GPU25_Binary_Rev53.rar

include filter on GPU sharder
(GPU_001)BilinearResize,ColorYUY2,Convolution3d,IT,LanczosResize,TemporalSmoother,WNR
(_GPU25)2DClean,2DCleanFake,Wavelet,HardwareResize,Blur,Sharp,HFlip,VFlip

[turbojet]

JoshyD a few questions about the separate builds.

Does the amd build work on intel cpus? If so, is there a significant speedup of intel over the amd build on intel cpus? If not, any reason for separate builds? If so, do you want me to improve the install script to use amd dll for amd cpus and intel dll for intel cpus? If so, what will be the names of the 2 dll's?

Also I could make a self contained exe to install or use a typical installer but I'd have to inject new dll's every time, also typical installers are invasive in the registry. Maybe when the development slows down i'll look into it if you want.

[JoshyD]

@turbojet
The real reason for the difference in the dll's is one uses SSSE3 for the vertical resize functions, the other emulates it with SSE2 instructions. They differ by ~5 lines of code, literally. I just need to add the CPU flag checking, and do some renaming in the source. The AMD specific build will run every so slightly slower on Intel CPU's. The Intel build won't resize vertically on AMD CPU's. Integrating it all into a single DLL was going to be done after I finished tweaking the resize code. I'd hold off on creating a specific installer, soon they'll just be all in one package.

I agree with the installer, when things stabilize, perhaps a real installer would be a nice thing to have. Getting all the kinks worked out is keeping me busy in the meantime.

The latest build was compiled on the 20th, even though the file name suggests otherwise. Can anyone confirm it breaking a spline36resize from 1920x1080 --> 704x396?

[Hiritsuki]

If warpsharp release x64 is more well for me
I usually use warpsharp to do sharpen line.....

[JoshyD]

@Stephen
What's the info on the clip that's causing the error? I can only resize to 1920x1080 and then downsize that clip and it works fine for me, any chance you could post a few frames to work with?

[osgZach]

I have an awarpsharp x64, got it from squid's page. No idea what version it is tho

[Stephen R. Savage]

Edit: Apparently, the installer scripts don't work as expected when run via UAC (path issue). I was in fact testing with an old version (although the installer printed "Installation succeeded"). No resizing problems were found in the latest version.

If you do port aWarpSharp, could you port the modified ("aWarpSharp2") version by SEt? I know squid80 has a build of the old version that corrupts the edges of the frame or something. I'll also take this opportunity to re-iterate my request for AddGrainC and GradFun2DB.

[osgZach]

http://forum.doom9.org/showthread.php?t=147285

Here is the link for the version Stephen mentioned. It includes the CPP source code file, but no project file or anything. I had to right-click to select download for some reason, as it won't launch the link otherwise, and when I tried with a plugin I ended up with a corrupted 2k file.. Maybe its a Firefox thing, or googles just crap today.

[JoshyD]

@Stephen
AddGrainC and GradFun2DB are up on the main page. I started with the source found on the warp enterprises page. I was unsure if there were modded versions running about, so let me know if there are, and link me the source, and I'll see what I can do.

@osgZach
Thanks for doing the leg work, I'll see if I can't get that converted right away.

@turbojet
Any ideas on why the installer scripts aren't copying even under administrator privileges? I noticed the same thing happening, but the syntax looks sound. Your guess is probably better than mine . . .

[Adub]

Hey all, just installed Win 7 x64bit, and I am running some tests.

Right now, things are about 70% working.

First of all, I can't seem to get FFMS2 working. The dll is in my plugins64 folder, but it keeps telling me "no function named FFVideosource found". Has anyone else gotten ffms2 to work?

Here is my script:
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\ffms2.dll")
FFvideosource("00007.m2ts")

Am I doing something wrong?

In addition, I seem to be having troubles opening .m2ts files using Directshowsource but im still working on that.

[kemuri-_9]

Here is my script:

Am I doing something wrong?

this version requires using LoadCPlugin to load.
i specifically designed it to have something like

(LoadPlugin("ffms2.dll") == "Use LoadCPlugin") ? LoadCPlugin("ffms2.dll") : NOP()

work to load this version while still allowing the C++ version to take preference/not break when available (like on x86)

[Adub]

Ah, I see. Okay, I'm trying LoadCPlugin, and virtualdub appears to be creating the index file instead of erroring out on the first few seconds.

[JoshyD]

@Adub
Glad to see things are working out thus far, keep coming back with any questions that come up.

@Stephen and osgZach
aWarpSharp is ported, I did some preliminary testing, and it appears to be functionally correct. Would either of your two try and break it for me?/

[Hiritsuki]

thanks a lot JoshyD I'd come full x64 encode ^_^

[Stephen R. Savage]

@turbojet
Any ideas on why the installer scripts aren't copying even under administrator privileges? I noticed the same thing happening, but the syntax looks sound. Your guess is probably better than mine . . .

This is a Windows failure. When you invoke the script with "Run-As", the script executes in system32 instead of the directory the script is located in, so references to files in the current directory return FILE NOT FOUND.

The GradFun2DB version posted does not behave correctly. The following screenshots demonstrate a problem, illustrated by the use of thr=255.

32-bit version: http://img534.imageshack.us/img534/2003/gradfun2db32.png
64-bit version: http://img691.imageshack.us/img691/1294/gradfun2db64.png
unprocessed: http://img411.imageshack.us/img411/7892/gradfun2dborig.png

I applied an edge padding of +16px in all directions when I made the screenshots, but an unpadded image would produce the same result, leaving the 16 border pixels unprocessed.

AddGrainC and aWarpSharp appear to perform as expected.

On a totally unrelated note, dfttest is really awesome: http://img202.imageshack.us/img202/4701/dfttest.png

[JoshyD]

Ughh, GradFun2DB won't even build correctly unless you don't let the compiler optimize the code at all. Allowing the any more than a teeny bit of optimization produces a useless binary. I'll comb it over, perhaps I'll just post the debug DLL . . .

[turbojet]

v3 of the installer scripts (http://www.mediafire.com/?otmnzqwmzow)
- should fix access denied errors with UAC enabled by requiring admin privileges
- should fix running as admin by defining the script's actual path instead of working directory
- more robust check for windows 64 by checking cpu instead of wow6432node registry key (some installers that don't check for 64 bit add this registry key in 32 bit windows)
- added display of 64 bit plugins directory path in the install/uninstall

[Adub]

Has anyone gotten there Avisynth 64-bit to work with MeGUI? The reason I ask is that I'm finding out the hard way today that a number of my encoding programs don't actually support 64-bit at all.

[osgZach]

FYI, JoshyD,

I just had that thread deadlock problem happen to me on 32-Bit Avisynth/Vdub..
so maybe the issue isn't necesarrily with your port that is causing it.

All I was doing was loading an AVI source and using aWarpSharp2 on it, then cropping and resizing.

edit: Don't know if this will help identify where the problem is but I've gotten two thread deadlocks in a row now, I believe both occured on the very last frame of the file. Both times it was the 7th activated job in the queue. Hung up on frame 33264/33265. The one that happened last night I believe happened during the 10th active job, however.

I wonder if this may be a problem with UT codec... thoughts? I can't be the only one experiencing this.. in this particular case I'm not even using MT modes (not even installed). Only UT is multithreaded during the encode.

[JoshyD]

@turbojet
Thanks for the fast response on the install scripts, they'll definitely be appreciated in the next build. This should be soon . . . just finishing up some resize code at the moment.

I'm also messing around with EEDI2 a little more, turns out that mega calculation loop (EEDI2::calcDirections) can be picked apart so the compiler (and the processors branch predictor) understands it a little better. It's already three nested for loops, but I'm pretty sure it can be broken into three parts. This really simplifies branch conditions inside the loops, just need to make sure it's bit for bit exact with the original. The downside is a gigantic function gets even more gigantic.

@Adub
Are you familiar with getting MeGUI to use 64 bit x264? I can't find the guide for it offhand, I'll keep looking, but summarize the process in the meantime. I haven't done this myself, so, I'm making an educated guess for now, someone else may have better input.

Basically, when encoding with MeGUI, it calls x264.exe to do the video portion of the encode. All you need to do is change the x264.exe (usually at C:\Program Files (x86)\megui\tools\x264\x264.exe) to a program that pipes the output to x264_64.exe (usually renaming vfw4x264.exe or avs4x264.exe to x264.exe).

Now, using avisynth64, you can just rename x264_64.exe to x264.exe and have MeGUI use that.

The other issue is if you're going to be using its auto script generator, you'll need to change the avisynth plugins (usually at C:\Program Files (x86)\megui\tools\avisynth_plugin) to their 64bit counterparts. MeGUI hard codes the plugin loading at the beginning of it's scripts, so it always loads the version in its directory. Avisynth64 can't load 32bit plugins, so you can only use features that utilize the 64bit plugins ported thus far. Most of the functionality should be there.

I haven't tested this myself, maybe someone else can chime in with clearer ideas?


@osgZach
The thread deadlocking, is it repeatable, or does it just happen sporadically? If it's repeatable, it may be fixable. What version of avisynth32 caused the thread deadlock? SEt's 2.5.8 with SetMTMode or were you using MT.dll?

EDIT:
I can't be the only one experiencing this.. in this particular case I'm not even using MT modes (not even installed). Only UT is multithreaded during the encode.

It's probably some odd deadlock condition in the codec if that's the case. Personally, I've never experienced thread deadlocks with any of my builds that were publicly released, and normal avs2.5.8 can't deadlock, maybe ask the codec's author?

[Adub]

Okay, well it looks like the current author of MeGUI has stated (http://forum.doom9.org/showthread.php?p=1384999#post1384999) that he will add 64-bit support once all filters that MeGUI uses have been ported. Thankfully, we have already started to do just that.

From what I can tell from this screenshot of my megui plugins folder:
http://img87.imageshack.us/img87/7622/avisynthplugins.jpg (http://img87.imageshack.us/i/avisynthplugins.jpg/)

We only need Convolution3D, Fluxsmooth, an updated version of NicAudio, and TomsMoComp.

The VSFilterMod project has already created a 64-bit version of Vsfilter.

[osgZach]

I set the threads in UT codec to 1, and just encoded the rest of my files (23 to 37, 14 files) with no apparent issues.
I think maybe the problem is likely the codec, but I don't mind running it single threaded anyhow.. Oddly enough it has no "no multithreading" option, which kind of confused me at first. Has a checkbox to set threads to number of logical cpus, or if not used lets you input a number (1,2,3,4,5, etc) so I just stuck a 1 in there and in went fine.

Also, for reference you don't need to change MeGUI's plugin directory, not necesarrily anyway. You can use a custom Avisynth profile, with DLL loading calls to the plugins you want to use, and the filter call you want to use.
Kind of a compromise I guess, as I am betting you can't do quick-click on its resize and de-noiser options. But if you work in batches and use the same settings most of the time, it'll work too without having to replace all your filters. Just remember to use the correct Avisynth Profile during script generation.

[Adub]

Unfortunately, MeGUI appears to error out even when I create my own scripts.

[osgZach]

Create a bare bones AVS that loads a progressive AVI, or something like that, so you don't have to make any filter calls.

Then queue it for encoding. If its still errors out, make sure you properly replaced the x264.exe with the renamed 64-bit version. If its giving you some other error (other than unable to open file, which is the usual 32/64 incompatability problem) like unsupported flags or something you are probably using an outdated x64 build of x264.

So far, I get my x264_x64 EXE's from this site, and then I just use the command line with a batch file. It's not all that hard really, especially if you are using the profiles anyway.

[Adub]

Well, a simple "avisource("blah.avi")" errors out because it appears that megui is looking for a 32-bit codec, which would require a 32-bit install of ffdshow, which I'm a little wary to do, as I don't know how it will handle two versions of ffdshow installed on the same system.

[Emulgator]

I don't know how it will handle two versions of ffdshow installed on the same system.
I have 32-bit and 64-bit ffdshow on a Win7U64 here, it seems to work.
Not taking about MeGUI, I haven't tested in this configuration yet.
Only Mulder's Simple Launcher, VirtualDub64bit, a tiny bit of the x64Avisynth from this thread...
No speed gains over 32bit worth mentioning so far...

[levi]

Another bug report?

avisynth64_intel_3-19-10.rar will not LanczosResize to any resolution for me? (at least 2 - tried 512,384 & 1280,720). Reverting to previous version allows resize again.

[ifb]

The latest build was compiled on the 20th, even though the file name suggests otherwise. Can anyone confirm it breaking a spline36resize from 1920x1080 --> 704x396?
The Intel build labeled 3/19 fixed vertical resize for me.

[Andrey /MAG/]

Hello. I try to compare results of 32bit and 64bit builds of MVTools. I found that they are different. There are no motion interpolated frame in 64bit build results, but only blended frames. See linked archive (source, script and results) for details.
http://www.sendspace.com/file/4u8s0t

[Stephen R. Savage]

Andrey, I can confirm the problem with your settings, but I would just like to let you know that you can work around it by using the default settings.

[Andrey /MAG/]

Stephen, thank you. But I wonder why plugin MVTools 2.5.10 works another way after its "translating" into x64? I suggest the default settings must stay constants. And the result of plugin's work must be the same. If behavior of plugins is changed then version number must be changed too with attached change list. If it is a bug then bug needs to be fixed.
I can't use this plugin because of its strange (unexpected) results. In my opinion about MVTools 32bit results is good and 64bit results is bad. Why it happens? Is it a bug?

[osgZach]

I finally got around to installing FFDshowx64 so I could get my beloved HuffYV12 back. I need to eliminate UT Codec from the bug hunting process as its just too unreliable.

That being said, I am getting crashes still, at random, when opening a script. I can't remember if it was MaskTools or Mvtools but I'll try and produce another crash (shouldn't take long, opening and closing the same script...lol) and get a crash dump.

edit:

Crash dump: Unknown Exception (think that's different from my last dump)

VirtualDub crash report -- build 32706 (release-AMD64)
--------------------------------------

Disassembly:
08ed9e20: 0400 add al, 00h
08ed9e22: c0488bc8 ror byte ptr [eax-75h], 0c8h
08ed9e26: ff1504320100 call dword ptr [00013204]
08ed9e2c: 48 dec eax
08ed9e2d: 81c4e0050000 add esp, 000005e0
08ed9e33: 5b pop ebx
08ed9e34: c3 ret
08ed9e35: cc int 3
08ed9e36: cc int 3
08ed9e37: cc int 3
08ed9e38: 48 dec eax
08ed9e39: 895c2408 mov [esp+08h], ebx
08ed9e3d: 48 dec eax
08ed9e3e: 896c2410 mov [esp+10h], ebp
08ed9e42: 48 dec eax
08ed9e43: 89742418 mov [esp+18h], esi
08ed9e47: 57 push edi
08ed9e48: 48 dec eax
08ed9e49: 83ec30 sub esp, 30h
08ed9e4c: 48 dec eax
08ed9e4d: 8be9 mov ebp, ecx
08ed9e4f: 48 dec eax
08ed9e50: 8b0d5a280500 mov ecx, [0005285a]
08ed9e56: 41 inc ecx
08ed9e57: 8bd9 mov ebx, ecx
08ed9e59: 49 dec ecx
08ed9e5a: 8bf8 mov edi, eax
08ed9e5c: 48 dec eax
08ed9e5d: 8bf2 mov esi, edx
08ed9e5f: e8681e0000 call 108edbccc
08ed9e64: 48 dec eax
08ed9e65: 85c0 test eax, eax
08ed9e67: 741a jz 108ed9e83
08ed9e69: 4c dec esp
08ed9e6a: 8b542460 mov edx, [esp+60h]
08ed9e6e: 44 inc esp
08ed9e6f: 8bcb mov ecx, ebx
08ed9e71: 4c dec esp
08ed9e72: 8bc7 mov eax, edi
08ed9e74: 48 dec eax
08ed9e75: 8bd6 mov edx, esi
08ed9e77: 48 dec eax
08ed9e78: 8bcd mov ecx, ebp
08ed9e7a: 4c dec esp
08ed9e7b: 89542420 mov [esp+20h], edx
08ed9e7f: ffd0 call eax
08ed9e81: eb25 jmp 108ed9ea8
08ed9e83: b902000000 mov ecx, 00000002
08ed9e88: e8933e0000 call 108eddd20
08ed9e8d: 4c dec esp
08ed9e8e: 8b5c2460 mov ebx, [esp+60h]
08ed9e92: 44 inc esp
08ed9e93: 8bcb mov ecx, ebx
08ed9e95: 4c dec esp
08ed9e96: 8bc7 mov eax, edi
08ed9e98: 48 dec eax
08ed9e99: 8bd6 mov edx, esi
08ed9e9b: 48 dec eax
08ed9e9c: 8bcd mov ecx, ebp
08ed9e9e: 4c dec esp
08ed9e9f: 895c2420 mov [esp+20h], ebx
08ed9ea3: e868feffff call 108ed9d10
08ed9ea8: 48 dec eax <-- FAULT
08ed9ea9: 8b5c2440 mov ebx, [esp+40h]
08ed9ead: 48 dec eax
08ed9eae: 8b6c2448 mov ebp, [esp+48h]
08ed9eb2: 48 dec eax
08ed9eb3: 8b742450 mov esi, [esp+50h]
08ed9eb7: 48 dec eax
08ed9eb8: 83c430 add esp, 30h
08ed9ebb: 5f pop edi
08ed9ebc: c3 ret
08ed9ebd: cc int 3
08ed9ebe: cc int 3
08ed9ebf: cc int 3
08ed9ec0: 48 dec eax
08ed9ec1: 83ec38 sub esp, 38h
08ed9ec4: 48 dec eax
08ed9ec5: 8364242000 and dword ptr [esp+20h], 00h
08ed9eca: 45 inc ebp
08ed9ecb: 33c9 xor ecx, ecx
08ed9ecd: 45 inc ebp
08ed9ece: 33c0 xor eax, eax
08ed9ed0: 33d2 xor edx, edx
08ed9ed2: 33c9 xor ecx, ecx
08ed9ed4: e85fffffff call 108ed9e38
08ed9ed9: 48 dec eax
08ed9eda: 83c438 add esp, 38h
08ed9edd: c3 ret
08ed9ede: cc int 3
08ed9edf: cc int 3
08ed9ee0: 48 dec eax
08ed9ee1: 895c2410 mov [esp+10h], ebx
08ed9ee5: 57 push edi
08ed9ee6: 48 dec eax
08ed9ee7: 83ec60 sub esp, 60h
08ed9eea: 48 dec eax
08ed9eeb: 8bfa mov edi, edx
08ed9eed: 48 dec eax
08ed9eee: 8bd9 mov ebx, ecx
08ed9ef0: 48 dec eax
08ed9ef1: 8d4c2420 lea ecx, [esp+20h]
08ed9ef5: 48 dec eax
08ed9ef6: 8d1504a20200 lea edx, [0002a204]
08ed9efc: 41 inc ecx
08ed9efd: b840000000 mov eax, 00000040
08ed9f02: e869210000 call 108edc070
08ed9f07: 48 dec eax
08ed9f08: 8d542470 lea edx, [esp+70h]
08ed9f0c: 48 dec eax
08ed9f0d: 8bcf mov ecx, edi
08ed9f0f: 48 dec eax
08ed9f10: 895c2448 mov [esp+48h], ebx
08ed9f14: 48 dec eax
08ed9f15: 897c2450 mov [esp+50h], edi
08ed9f19: e850220100 call 108eec16e
08ed9f1e: 4c dec esp
08ed9f1f: 8b db 8bh

Built on Aegis on Thu Dec 24 19:58:44 2009 using compiler version 1400

Windows 6.1 (Windows Vista x64 build 7600) []

RAX = 1d50d090
RBX = 0
RCX = 1d50d090
RDX = 0
RSI = 0
RDI = 0
RBP = 0
R8 = 0
R9 = 0
R10 = 0
R11 = 1d50cff0
R12 = 1c0e6ac8
R13 = 0
R14 = 1c0e6ac8
R15 = 1d50d7c8
RSP = 1d50d570
RIP = 8ed9ea8
EFLAGS = 00000246


Crash reason: unknown exception 0xc0000417

Crash context:
An exception occurred in module 'mt_masktools26'.

Pointer dumps:

RAX 1d50d090: 02f6ab78 00000000 00000004 000002e0 00000170 00000170 02e40080 00000000
RCX 1d50d090: 02f6ab78 00000000 00000004 000002e0 00000170 00000170 02e40080 00000000
RSP 1d50d570: 0e291568 00000000 ed77ea04 00000000 00000048 00000000 02e40280 00000000
1d50d590: 00000000 00000000 00000030 00000000 00000000 00000000 08ed9ed9 00000000
1d50d5b0: 1c0e6ba8 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1d50d5d0: 00000000 00000000 1c0e6ba8 00000000 00000048 00000000 08e57969 00000000
R11 1d50cff0: c0000417 00000001 00000000 00000000 08ed9ea8 00000000 00000000 00000000
R12 1c0e6ac8: 08f46bc8 00000000 1c06ba20 00000000 00000000 00000000 00000000 00000000
R14 1c0e6ac8: 08f46bc8 00000000 1c06ba20 00000000 00000000 00000000 00000000 00000000
R15 1d50d7c8: 12659010 00000000 000002e0 000002d0 00000104 00000000 7bd1ce63 00000000

Thread call stack:
08ed9ea8: mt_masktools26!AvisynthPluginInit2 [08e00000+c7fc0+11ee8]
08ed9ed9: mt_masktools26!AvisynthPluginInit2 [08e00000+c7fc0+11f19]
08e57969: mt_masktools26!00057969
76d21c58: ntdll!RtlAllocateHeap [76cd0000+51b70+e8]
08e21b22: mt_masktools26!00021b22
08e42b39: mt_masktools26!00042b39
08e20736: mt_masktools26!00020736
7feef296b0f: avisynth!avs_at_exit [7feef0e0000+11c9c0+9a14f]
7feef0fcca1: avisynth!avs_release_video_frame [7feef0e0000+1b530+1771]
08e644e7: mt_masktools26!000644e7
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
04bf7b42: RemoveGrain!00007b42
76cea6d4: ntdll!TpCallbackMayRunLong [76cd0000+1a3f0+2e4]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
7feef1a8a29: avisynth!DllGetClassObject [7feef0e0000+25d80+a2ca9]
7feef1a7f39: avisynth!DllGetClassObject [7feef0e0000+25d80+a21b9]
76d229ac: ntdll!RtlRestoreLastWin32Error [76cd0000+52040+96c]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
76d02f65: ntdll!LdrLockLoaderLock [76cd0000+32850+715]
7feef19be8a: avisynth!DllGetClassObject [7feef0e0000+25d80+9610a]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
76d21c58: ntdll!RtlAllocateHeap [76cd0000+51b70+e8]
08e606b2: mt_masktools26!000606b2
76d229ac: ntdll!RtlRestoreLastWin32Error [76cd0000+52040+96c]
7feef293a43: avisynth!avs_at_exit [7feef0e0000+11c9c0+97083]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
7feef296b0f: avisynth!avs_at_exit [7feef0e0000+11c9c0+9a14f]
1b7650ed: mvtools2!000a50ed
7feef0f2a10: avisynth!avs_clip_get_error [7feef0e0000+10280+2790]
7feef0f2483: avisynth!avs_clip_get_error [7feef0e0000+10280+2203]
058bc0e5: EEDI2!0000c0e5
7feef0f2150: avisynth!avs_clip_get_error [7feef0e0000+10280+1ed0]
058bb289: EEDI2!0000b289
058c6fd9: EEDI2!00016fd9
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
1b6fc40b: mvtools2!0003c40b
76d21c58: ntdll!RtlAllocateHeap [76cd0000+51b70+e8]
7feef296b0f: avisynth!avs_at_exit [7feef0e0000+11c9c0+9a14f]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fcca1: avisynth!avs_release_video_frame [7feef0e0000+1b530+1771]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
7feef0fc22d: avisynth!avs_release_video_frame [7feef0e0000+1b530+cfd]
1b6dcd22: mvtools2!0001cd22
1b71982c: mvtools2!0005982c
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
7feef19be8a: avisynth!DllGetClassObject [7feef0e0000+25d80+9610a]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
76d26735: ntdll!RtlTimeFieldsToTime [76cd0000+55c60+ad5]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
76d27226: ntdll!RtlFindActivationContextSectionString [76cd0000+57050+1d6]
7feef19be8a: avisynth!DllGetClassObject [7feef0e0000+25d80+9610a]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
08e606b2: mt_masktools26!000606b2
76d27ea6: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [76cd0000+57a80+426]
76d27ea6: ntdll!RtlDosApplyFileIsolationRedirection_Ustr [76cd0000+57a80+426]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
08e643d2: mt_masktools26!000643d2
76d282ec: ntdll!LdrGetDllHandleEx [76cd0000+57f60+38c]
76d282ec: ntdll!LdrGetDllHandleEx [76cd0000+57f60+38c]
76d27773: ntdll!RtlFindCharInUnicodeString [76cd0000+57540+233]
76d27a5b: ntdll!RtlFindCharInUnicodeString [76cd0000+57540+51b]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
76d281b2: ntdll!LdrGetDllHandleEx [76cd0000+57f60+252]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
08e63b32: mt_masktools26!00063b32
76d2523c: ntdll!RtlEqualUnicodeString [76cd0000+55150+ec]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
7fefcf99506: KERNELBASE!IsDebuggerPresent [7fefcf90000+9310+1f6]
08e64822: mt_masktools26!00064822
76d26dd9: ntdll!LdrGetProcedureAddressEx [76cd0000+56b10+2c9]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
1b7197c9: mvtools2!000597c9
76d21c58: ntdll!RtlAllocateHeap [76cd0000+51b70+e8]
7fefea9130a: urlmon!0000130a
76d229ac: ntdll!RtlRestoreLastWin32Error [76cd0000+52040+96c]
7fefc4a1112: mswsock!00001112
76d283d1: ntdll!LdrGetProcedureAddress [76cd0000+583c0+11]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]
02a7164b: decomb!AvisynthPluginInit2 [02a50000+1000+2064b]
05027e8f: Repair!AvisynthPluginInit2 [05020000+5f50+1f3f]
08e643d2: mt_masktools26!000643d2
02ab1322: dgdecode!AvisynthPluginInit2 [02a90000+1e940+29e2]
76cf4e42: ntdll!RtlProcessFlsData [76cd0000+24920+522]
76d2c8d7: ntdll!LdrGetProcedureAddress [76cd0000+583c0+4517]
76d2c8f4: ntdll!LdrGetProcedureAddress [76cd0000+583c0+4534]
7feef0fca7e: avisynth!avs_release_video_frame [7feef0e0000+1b530+154e]
76d03194: ntdll!LdrInitializeThunk [76cd0000+33080+114]
7feef0fc1bb: avisynth!avs_release_video_frame [7feef0e0000+1b530+c8b]

-- End of report