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

[JoshyD]

Edit: Quicklinks Updated 4/26/2010

Featured Release 4/16/2010
+ Resize artifacting fixed
+ Horizontal resize code re-written to use SSE registers
+ Worth noting, often used functions Temporal Soften, Merge, etc have been tweaked for a decent speed gain
+ Bug found, fixed in memory copy routine, again
+ Universal binary, no longer need to distinguish between AMD and Intel builds
+ Optimized BitBlt memory copy Routine
+ Started implementation of SSE3/4 specific instructions when supported processor is detected
+ Removed most code paths intended to support CPU's without mmx/iSSE
+ Resize functions reworked to take advantage of extra registers available when processor is in 64bit mode
Avisynth64 binary and installer (http://avisynth64.googlecode.com/files/avisynth64_4-16-10.rar) built on 4/16/2010

Many of the plugins have been optimized and recompiled, please get the latest and greatest versions with this release.

Service update on 3/19/2010
+ Minor fixes to allow better usage of MT modes
+ Tweaks to code for small performance increases all around
+ Fixed resize bug
Use this build for Intel processors (http://avisynth64.googlecode.com/files/avisynth64_intel_3-19-10.rar)
Use this build for AMD processors (http://avisynth64.googlecode.com/files/avisynth64_amd_3-19-10.rar)

Version from 3/15/2010:
64 bit Avisynth 2.5.8 w/multithreading (http://www.mediafire.com/?mzh2zxmx1nw)

------------------------------------------------
Plugins (Alphabetically, for now)
------------------------------------------------

New on 3/21/2010
AddGrainC x64 (http://www.mediafire.com/?imj5nkwdkj1)

Built on 3/14/2010
AutoCrop x64 (http://www.mediafire.com/?mzddfmjjdyx)

New on 3/21/2010
aWarpSharp x64 (http://www.mediafire.com/?mjmfnuwf2ky)
This version is based on SEt's original rewrite found in this thread (http://forum.doom9.org/showthread.php?t=147285)

Built on 3/20/2010
Color Matrix x64 (http://www.mediafire.com/?ztjwmywqmm4)

New on 3/13/2010
DFTTest x64 (http://www.mediafire.com/?oemygnmkrji)-->needs the included libfftw3f-3.dll to be in your system32 directory

Built on 3/19/2010
DgDecode 1.5.8 x64 (http://www.mediafire.com/?c0wmemj5jam)
Note: Is missing some IDCT modes, will get them back ASAP

Built on 4/10/2010
EEDI2 x64 (http://www.mediafire.com/?znmyzdo2ize)
+ Vectorized main loop
+ Further restructured main loop to minimize branching, processor dependent speed increase

FeildHints x64 (http://www.mediafire.com/?ynkidzz4joz)

Built on 3/12/2010
FFT3DFilter (http://www.mediafire.com/?2ymcyfuzzzw)-->needs the included libfftw3f-3.dll to be in your system32 directory

Built on 3/15/2010
FFT3DGPU x64 (http://www.mediafire.com/?2chnt1jkwwm)
note:The hlsl (shader program) file is edited from the original to adhere to pixel shader 3.0 syntax rules. Please make sure to place the correct file in the same directory as the 64bit plugin.

New on 3/13/2010
kemuri-_9's FFMS2 (The Fabulous FM Source 2) (http://kemuri9.net/dev/avs/ffms2/x64/ffms2.dll)
Big thanks to kemuri-_9 for the build

Built on 3/29/2010
GradFun2DB x64 (http://www.mediafire.com/?w0trndmni3j)

Built on 4/08/2010
hqdn3d x64 (http://www.mediafire.com/?gyvmmzx0v4z)

Built on 3/14/2010
LeakKernelDeint x64 (http://www.mediafire.com/?tqmjdnjdnum)

Built on of 3/12/2010
MaskTools 2.0a41 (http://manao4.free.fr/masktools-v2.0a41.zip)
+ Now straight from the source, Manao

Built on 3/31/2010
MVTools2 x64 (http://www.mediafire.com/?2yjmze2ommz)
+ Continued conversion and updating of assembly functions
+ Removal of some code intended to support processors without mmx/iSSE
+ Converted often used assembly functions to SSE2 instead of mmx/iSSE
+ Updated to latest shared function library from x264
+ Healthy 20%+ speed increase over x86 version in most cases

New on 3/14/2010
TDeint x64 (http://www.mediafire.com/?kmcztm1xzjm)
This is basically the same as squid80's build, main differences being newer avisynth.h and newer compiler

TelecideHints x64 (http://www.mediafire.com/?wnemmzntgnh)

Built on 3/13/2010:
TIVTC x64 (http://www.mediafire.com/?i2qtli1mxik)


New on 3/20/2010
TNLMeans_x64 v1.0.3 (http://www.mediafire.com/?y4e3zd2zodd)

New on 3/20/2010
TTempSmooth x64 v0.9.4 (http://www.mediafire.com/?zv0jm3mtmzf)

RemoveGrain x64 (http://www.mediafire.com/?qjmyjt52miz)

Repair x64 (http://www.mediafire.com/?q00r32yegnh)

VerticalCleaner x64 (http://www.mediafire.com/?mjctqyjnoxh)

Visit Squid80's homepage for more x64 plugins (http://members.optusnet.com.au/squid_80/)

Benchmarking Suggestions

Here is a 64bit avs2avi for benchmarking (http://www.mediafire.com/?yykmkawa40j).
You can run it against the original (http://moitah.net/)

To simply run the script through Avisynth, execute the following at a command prompt:
avs2avi64.exe <path:\script.avs> -o n

A dialog box will pop up asking what to do for compression. Choose no recompression (or whatever similar option your os gives you) and the script will run without saving an output.

The same should be done with avs2avi.exe.

This will take two factors out of the speed equation: 64bit vs 32bit compressors and hard disk write speed. The final fps report from both runs will allow a fairly apples to apples comparison of the two builds.

Source Code
For those who are interested: The source is now hosted over at google code, I'll keep it as up to date as I can (http://code.google.com/p/avisynth64/)
The source is constantly in flux.

This wiki page (http://code.google.com/p/avisynth64/wiki/PluginLinks) has all of the plugins linked as well.

The source to any of the plugins I have personally modified is available upon request. Please message me if interested.

[Chikuzen]

Hi, JoshyD

I tried to test it with my Q9450 and 64bit windows7, but some DLLs seems to be insufficient.
where can i get libiomp5md.dll ?

[JoshyD]

Hmm, it appears that even when linking all your libs statically, intel's compiler still links the openmp libs dynamically, I'll get a rebuild up ASAP. From the ICC forums:

"The 11.0 Windows compilers (both C++ and Fortran) have decoupled /MT from having any effect on which OpenMP runtime (static or dynamic) gets linked. In fact, all of /MT[d], /MD[d], and /ML[d] (latter VS2003 only) now only effect which MS C runtime is linked.
We made this change because we want dynamic to be the default when linking the OpenMP RTL. The use of static OpenMP libraries is not recommended, because they might cause multiple libraries to be linked in an application. The condition is not supported and could lead to unpredictable results. It can also cause Thread Checker false positives and other problems with the Intel Threading tools.
If you want to link against the static OpenMP RTL, you must add /Qopenmp-link:static, which is a new switch for 11.0. So to produce a purely static executable, compile/link with /MT /Qopenmp-link:static
Patrick Kennedy
Intel Compiler Lab"

I didn't build the project with OpenMP libs enabled, but did allow the compiler to auto-parallelize loops it found it could. Perhaps this is the issue.

[JoshyD]

There is support for SetMTMode and it's functions, but not MT("command") as of now. The whole MT function is contained in an entirely separate DLL loaded form your plugins dir automatically, or manually at the beginning of the script.

The RAR does contain a copy of direct show source for use with AVI synth. Any program that can open avs files AND is already a 64 bit executable should do the trick. VDub64 comes to mind, as well as media player classic home cinema 64. 64 bit builds of x264 that specifically have the ability to open avs files should work as well.

I have personally tested Virtual Dub 64, it has played back all of my little test cases I've had a chance to run without any complaint.

For some 64bit plugins that MAY work with this DLL please check out Squid80's prior work. (http://members.optusnet.com.au/squid_80/) He was the guy who ported Avisynth 2.5.5 to x64 a while back, without the nicety of having a compiler that supports inline asm.

Other than that, the the top two plugins that I want to see work with 64bit are MvTools2 and FFT3DFilter. I get a lot of mileage out of those two projects.

If there's enough interest generated I'm considering going back and optimizing all the ASM routines to take advantage of architectural changes that have occured over the past 5 or so years. Some of these assembly routines are long in the tooth, and could be better tuned for newer processors (I think).

Anyhow thanks for the post, and keep checking back for updates.

[Stephen R. Savage]

What I meant was, could you modify your avisynth64 release to use a separate directory for autoloading 64-bit plugins to avoid name-conflicts and similar issues? On an aside, having mvtools2 + MaskTools2 would allow a lot of script functions to work automatically.

[JoshyD]

What I meant was, could you modify your avisynth64 release to use a separate directory for autoloading 64-bit plugins to avoid name-conflicts and similar issues? On an aside, having mvtools2 + MaskTools2 would allow a lot of script functions to work automatically.

Sure, that's pretty easy. I can add throw that one on the to do list. I'm just a bit more focused on making sure others can run it at the moment.

[Stephen R. Savage]

Update: I copied avisynth.dll and devil.dll to system32 on a Windows 2008 R2 setup, after which I imported avisynth.reg. I created a test script with the code "BlankClip().ConvertToYV12()". It does not load in either VirtualDub64 or x264. Both crash upon exit. VirtualDub64 gives an error message "AVI Import Filter error: (Unknown) 80040154".

Faulting application name: Veedub64.exe, version: 1.9.8.0, time stamp: 0x4b343875
Faulting module name: avisynth.dll_unloaded, version: 0.0.0.0, time stamp: 0x4b7af14e
Exception code: 0xc0000005
Fault offset: 0x000007feee3b5408
Faulting process id: 0x62c
Faulting application start time: 0x01caaf7bdcc81b9e
Faulting application path: Veedub64.exe
Faulting module path: avisynth.dll

Edit: Processor is Core 2 T7250 "Merom".

[JoshyD]

Update: I copied avisynth.dll and devil.dll to system32 on a Windows 2008 R2 setup, after which I imported avisynth.reg. I created a test script with the code "BlankClip().ConvertToYV12()". It does not load in either VirtualDub64 or x264. Both crash upon exit. VirtualDub64 gives an error message "AVI Import Filter error: (Unknown) 80040154".



Edit: Processor is Core 2 T7250 "Merom".

This works for me, did you add the registry key that's included in the rar? When VDub throws that error, it usuaully means it can't find the right filter to decompress your stream.

I'm not sure which snapshot of the binary I compiled you may have grabbed, but along the way I realized I had the compile flags wrong. I was only generating code for a core I3/I5/I7. This caused my Penryn laptop to die when trying to load a clip. With the latest file up there, my Penryn executes no problem.

Just to be double safe, try this compilation of the avisynth binary:

It only has the SSE2 code path enabled (http://www.mediafire.com/?ykdjez2eomy)

If that doesn't work, we'll come up with a solution, I'm a bit hazy on how Windows associates registry keys with filter types. If anyone else has some pointers, that'd be great too.

[Stephen R. Savage]

The copy you just linked to depends on libiomp5md.dll, so I can't run it. Incidentally, my Merom CPU supports flags up to SSSE3, but not SSE4.1 like the higher-end Penryns. Perhaps you could use runtime CPU detection instead of requiring a specific instruction set compatibility?

Edit: Success! The build in the topic post of this now works. I guess it must have been silently updated.

Edit2: DirectShowSource and Spline36Resize work. However, scripts in my Avisynth32 plugins directory don't seem to be autoimported.

Edit3: TDeint64 built by Squid80 works fine. RemoveGrain64 by Kassandro does not (unknown exception).

Edit4: EEDI2_64 by Squid80 does not work. I believe this is because it is also statically linked to OpenMP, which according to a Google result on Intel's webpage, can cause conflicts.

Edit5: ConvertToRGB32 does not work. It always errors with the message "Rec.709 and PC Levels support require MMX and horizontal width a multiple of 4" regardless of settings/input.

[JoshyD]

EDIT:
You were right about EEDI2 using OpenMP and being dynamically linked to the libraries. I just recompiled the source with the OpenMP libraries statically linked:
EEDI2 64bit Multithreaded (http://www.mediafire.com/?mjomud5wnxd)

Also, where did you run across RemoveGrain64? I'd like a copy (and the source if possible) so I can figure out what exception it's throwing.

The only thing I can say for sure is that converting RGB error is hard coded in there for now, as there was a decent amount of assembly involved in converting the routine, and I just plain didn't feel like it. I'll get back around to it, put that on my todo as well.

I'll start checking into those other two plugins, I'm working on MVTools at the moment . . . that would be a huge win.

The other issue with the code paths was that I was basically telling ICC to target just my host CPU. When I tried to get it going on any other computer I realized my mistake. The current DLL for download has code paths for all EMT64 supporting Intel processors.

Once again, don't know if ICC cripples AMD chips or not . . .

[Chikuzen]

Hi, JoshyD
Thx for static build version. it seems to work at present without troubles.

I did some benchmarks. the results is here (http://en.pastebin.ca/1800425).

I think that faster 64bit decoder is necessary for me...

[Stephen R. Savage]

Kassandro posted his RemoveGrain64 on his own forum:

http://videoprocessing.11.forumer.com/viewtopic.php?p=700&sid=979b52936a673a92c52cd20f1c9425d0

Edit: Your rebuilt EEDI2() causes artifacts in chroma.
Edit2: Seems to be a pitch error. Doing a TurnLeft/TurnRight works around it.

[JoshyD]

Thanks for the benchmarcks! I don't think we're going to see any speed increases with 64bit code unless the assembly is re-worked to take advantage of more registers / less memory access.

Any resizers you run through there are really just using their old 32 bit counter part, essentially. The size of the pointers change, but the register usage at the CPU level is still the same, because it was specified explicitly. I'm going to continue work to see if I can't eek out some extra performance. I mainly want to see if I can't get some of the more demanding plugins a speed boost.


I'm not sure what's wrong with EEDI2, the source was straight compiled again.

[Stephen R. Savage]

Perhaps there was always the bug in the source code. Nevertheless, if you have experience in Avisynth plugin development, perhaps you could squash it for us? Please?

EEDI2 would normally not be anywhere near the top of my priorities, but without nnedi2, it's pretty much a necessary step to get TempGaussMC working on avs64 (the other steps being removegrain64, mvtools2_64, and masktools2_64).

[JoshyD]

Perhaps there was always the bug in the source code. Nevertheless, if you have experience in Avisynth plugin development, perhaps you could squash it for us? Please?

EEDI2 would normally not be anywhere near the top of my priorities, but without nnedi2, it's pretty much a necessary step to get TempGaussMC working on avs64 (the other steps being removegrain64, mvtools2_64, and masktools2_64).

Edit: EEDI2 bug squashed, I think
Try this out and let me know if it produces consistent results (http://www.mediafire.com/?oj2yhm0j2gn)


I DO have a somewhat working MVTools2. In so far as I have tested it, the "important" functions are working. A TON of the ASM has been re-coded to adhere to function calling specifications set forth by x64 c++. I did it by hand, meaning, there's probably a decent chance you'll crash it.

I also had to update the parts borrowed from other projects (xvid, x264, fftw), so those are a little "rough" at the moment.

My test cases mainly focused around motion vector generation and the degraining functions. Perhaps someone else will be able to fault it in other places, allowing me a chance to find and fix the bugs.

Here's the link to MVTools2 x64 (http://www.mediafire.com/?jf13dkynktj)

Personally, I see a significant performance increase (from ~20fps x86 to ~30fps x64, when using multi threading in both cases) when just writing out a raw stream. Try it out, and let me know where the problems are.

This is a little sample of what I've been using to mess around with the parameters. You can get it to go through a surprisingly large number of code paths just by varying the inputs to different degrain functions.

#MVTools x64
SetMTMode(2,4) #could be more, my system has four logical threads, but in certain instances more increase my encoding fps
LoadPlugin("D:\Development\mvtools2.dll")
AviSource("D:\testfile.avi")
ConvertToYV12(interlaced=true)


function MDegrain2i(clip source, int "overlap", int "dct", int "blksize", int "pel", int "search", int "searchparam")
{
overlap = default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct = default(dct,0) # use dct=1 for clip with light flicker
blksize = default(blksize, 8)
pel = default(pel, 2)
search = default(search, 4)
searchparam = default(searchparam, 3)

fields = source.SeparateFields() # separate by fields
super = fields.MSuper(chroma=true, pel=pel)

backward_vec2 = super.MAnalyse(blksize=blksize, isb = true, delta = 2, overlap=overlap, dct=dct, truemotion=true, temporal=true, pelsearch=pel, search=search, searchparam=searchparam)
forward_vec2 = super.MAnalyse(blksize=blksize, isb = false, delta = 2, overlap=overlap, dct=dct, truemotion=true, temporal=true, pelsearch=pel, search=search, searchparam=searchparam)

backward_vec4 = super.MAnalyse(blksize=blksize, isb = true, delta = 4, overlap=overlap, dct=dct, truemotion=true, temporal=true, pelsearch=pel, search=search, searchparam=searchparam)
forward_vec4 = super.MAnalyse(blksize=blksize, isb = false, delta = 4, overlap=overlap, dct=dct, truemotion=true, temporal=true, pelsearch=pel, search=search, searchparam=searchparam)

fields.MDegrain2(super, backward_vec2,forward_vec2,backward_vec4,forward_vec4, thSAD=500, thSCD1=500, thSCD2=130, plane=4)
Weave()
}

return MDegrain2i(last, overlap=4, blksize=8, pel=2)

Enjoy, and let me know any problems

[aegisofrime]

I do hope we can see TempGaussMC ported to 64 bit. That's one plugin that's slow but used a lot in the community. :)

Well, with MVTools and RemoveGrain done that's half the work over?

[Stephen R. Savage]

RemoveGrain is not very useful without its brother Repair, but the version you linked works. Also, what version did you compile? The EEDI2 build works and is consistent, though no longer multithreaded. Will all filters with internal multithreading be incompatible with this version of Avisynth?

Edit: Strange request, but could you build TelecideHints (http://www.sendspace.com/file/gzvkzy)and FieldHint (http://www.sendspace.com/file/h08eea)as well? They're pretty useful for anyone who uses Yatta, even if Yatta itself isn't 64-bit, and should be completely free of assembly code.

Edit2: Hmm, perhaps I should make a checklist of things that'd be cool in Avs64.

Edit3: VSFilter64 available here (https://code.google.com/p/vsfiltermod/downloads/list).

[Fizick]

JoshyD, you do big work!
I am intersted to see your TON of the ASM mvtools_64 source code lines ;)

[tedkunich]

JoshyD, you do big work!
I am intersted to see your TON of the ASM mvtools_64 source code lines ;)


Fizick, you do know that he is Jeremy Duncan in another persona, right?

From the user control panel, Jeremy's last activity was on Feb 5. JoshyD joins on Feb 5... Hmmmmm

[Stephen R. Savage]

I'm fairly certain that Jeremy Duncan would not be able to write any significant amount of code, much less port a large software project.

[tedkunich]

I'm fairly certain that Jeremy Duncan would not be able to write any significant amount of code, much less port a large software project.

Does seem a stretch, but it is extremely suspicious that this guy comes here out of the blue at the same time our resident 64bit pest disappears...

[JoshyD]

Does seem a stretch, but it is extremely suspicious that this guy comes here out of the blue at the same time our resident 64bit pest disappears...

I don't mean to be a pest about 64 bit binaries, I was just curious what improvements would be seen, if any. It was a nice chance to learn assembly, re-learn signal filtering, and all that good stuff.

Besides, Jeremy Duncan could barely compile the original 32bit source . . .

[kemuri-_9]

my question this entire time of the thread is:
why are you patching a patched version of avisynth rather than the official version like the avs 2.6 cvs branch which has already had the multithreading features committed to it.

[Stephen R. Savage]

Actually, that is a good point. JoshyD, how about a 64-bit Avs 2.6? :D

[Fizick]

Strange personality discussion.... I am simply waiting the source code and project files of MVTools2_x64 (GPL).
Are 32bit and 64 bit asm code generalized?

[JoshyD]

my question this entire time of the thread is:
why are you patching a patched version of avisynth rather than the official version like the avs 2.6 cvs branch which has already had the multithreading features committed to it.

Well, I started with SEt's build because he had already gone through and shored up a lot of the problems with for loop variable scope. The more well behaved your code is to start, better it should compile.

It was my understanding that the 2.6 branch was still in alpha status. There's a fair amount of new functionality for new colorspaces that I didn't want to go messing with if they weren't done.

The 2.6 branch also makes more use of Softwire to dynamically generate assembly code. In the end, I honestly didn't want to deal with working around Softwire more than was necessary. Softwire is a bit long in the tooth to begin with, and the original developer took that project and it's now Swift Shader (http://www.transgaming.com/business/swiftshader/) with a somewhat different focus, and closed source.

I took what seemed "stable" at the time, and just started working around there. There's no reason I couldn't merge these changes into the 2.6 alpha, I just wanted to be sure I was starting from a stable base.

That being said, anyone care to clue me in on the status of 2.6 as of now? I don't want to step on anyone's toes, I just wanted to poke around the source in my spare time. If there's enough new/stable code in there, I could definitely focus some time/effort in getting that code to target x64.

It seems that the work being done going forward is focused on other areas more important than an x64 code base. This whole thing is a bit of an experiment / sideshow. I thought it was interesting enough to share, hence it's posting here.

I know the eventual goal is to get Avisynth working cross platform, as well. A targeted win64 release would also be useless in the long run, if that's where the project is going.

Side note/tangent:
The inference about cross platform support for Avisynth can really be seen by looking at the MaskTools code base. I'm pretty sure the documentation for it explicitly states that it was written with the intent of eventually being cross compiled. The assembly functions for it are ALL contained in ASM files, and there's a lot of them. The layout is really quite elegant, I like it quite a bit.

[JoshyD]

Strange personality discussion.... I am simply waiting the source code and project files of MVTools2_x64 (GPL).
Are 32bit and 64 bit asm code generalized?

The source is finally up, sorry for the delay (http://www.mediafire.com/?yuzzwy3m1y1)

Unfortunately, they're not generalized as a whole. I did the inline assembler generally using just #ifdef's and then grabbed the latest x264 asm functions that the project uses, which are generalized. The actual asm for functions contained in files like bilinear.asm just got overwritten. It's trivial to swap the file for the original, and re-compile. It's just not exactly elegant.

The functions should have been generalized, but I was just working fast, kind of without putting a ton of thought into the process. I've been learning as I go, and it seems I always find an example of a sleeker solution after working through the first ugly one that popped into my head.

The main differences are in function calling, and register usage. You can get by with a lot less push/popping in 64bit land. Stack allocation between function calls changes as well. As a rule, all arguments are aligned at 8 byte boundaries. Arguments that are passed to the functions via registers still get shadow space on the stack, so your 5th integer argument will be at [rsp+40], if you didn't push any registers on the stack in the first place.

I wanted to ask some specific questions about the filtering and code copying functions. Was there a reason that they're often limited to the mmx registers? Things like the Horizontal Weiner filter are bothering me, because depending on your byte window, you're going to get different results from it, or it would seem that way. Right now, it has a 4 byte "window" to filter around. My understanding of a weiner filter is that it's adaptive, so changing its discrete window would change the filter's output altogether.

It's possible to look at 8 byte chunks using the XMM registers (unpacking to words for arithmetic (128bits total), repacking) but I'm unsure on the effect on overall image quality. Thoughts?

Finally, a lot of the mmx functions don't take advantage of the fact that we have a ton of XMM registers floating around that can also be used in mmx arithmetic. XMM0-XMM5 are all volatile across calls which could prevent some mmx registers from being shuffled around, etc.

When writing assembler, I'm not sure how the CPU's register files are architected to interact with each other. As in, if there's a pentalty associated with transferring a qword from an XMM register to an MMX reg, and vice versa.

I'm actually a VLSI designer (very large scale integration) (http://en.wikipedia.org/wiki/Very-large-scale_integration) by education, so thinking on the machine level is interesting and thought provoking. I don't know enough about the design of the x86 cores of late to generalize performance impact of various code paths. Is there any way other than running a battery of tests to analyze the clock cycles it takes for an instruction to retire?

I'm going to search around for the answers, but I thought I'd ask anyhow. Sometimes that's the fastest and most concise way to find the info you're after.

[JoshyD]

RemoveGrain is not very useful without its brother Repair, but the version you linked works. Also, what version did you compile? The EEDI2 build works and is consistent, though no longer multithreaded. Will all filters with internal multithreading be incompatible with this version of Avisynth?

Edit: Strange request, but could you build TelecideHints (http://www.sendspace.com/file/gzvkzy)and FieldHint (http://www.sendspace.com/file/h08eea)as well? They're pretty useful for anyone who uses Yatta, even if Yatta itself isn't 64-bit, and should be completely free of assembly code.

Fixed:
Here is the repair function to try out. (http://www.mediafire.com/?q00r32yegnh)

I removed threading form EEDI2 because Avisynth can handle threads internally for its filters. When all these little binaries link to each other, there should be some arbiter of thread creation. At least that's what seems logical at the time of writing. If you tell Avisynth work with 4 threads, and then it takes one of those threads and instantiates a filter who goes off and spawns 4 more threads, it would seem that the situation would get messy after a bit. There would possibly be a lot of context switching going on, which would degrade performance overall.

Also, any filterd compiled to statically link to the OpenMP libraries cannot be instantiated alongside any other filter also statically linked to those libs, because this will cause openmp.lib to be initialized more than once. Apparently, this can degrade performance, at least according to the error that occurs upon crash. The plugins can be compiled to ignore this, but in the short term, I was trying to save people some trouble shooting head aches.

As for the other two plugins you requested, I'll see what I can do. If Avisynth 2.6 can withstand a 64 bit port somewhat seamlessly, I'm going to focus my attention there first.

[Stephen R. Savage]

I get the error "LoadPlugin: unable to load 'Repair.dll'". Thank you for clarifying on the OpenMP issue. Again, I would like to ask what version of RemoveGrain/Repair your versions are based off. I ask this because there are two versions in "common" use.

Edit: ConvertToYUY2(interlaced=true) crashes your Avisynth64 build with SetMTMode(2) and causes an exception without SetMTMode.

Edit2: http://img43.imageshack.us/img43/50/avisynth64.png I'm liking the direction this project is going in. With masktools2 built, I can upgrade from "crude mvbob" (no error checking) to proper mvbob. Hopefully we can get some other volunteers to build plugins, so JoshyD doesn't have to do all the work.

[JoshyD]

Edit: ConvertToYUY2(interlaced=true) crashes your Avisynth64 build with SetMTMode(2) and causes an exception without SetMTMode.


Which color mode are you coming from when the crash occurs? I can't seem to get mine to crash . . . I have actually re-written some of the color conversion since the original dll was posted.

Try this one instead (http://www.mediafire.com/?hnbymmnyxky)

If that's a no go, maybe a sample clip is in order?

You are quite correct about the repair I uploaded being completely incorrect. I'm not quite sure where that dll even came from, the final build is ~3x its size. As for the version, it says "1.0" at the top of the main source file, I started with the original attempted RemoveGrain64. There were some glaring oversights in it (not sign extending 32bit integers when using them to compute 64bit addresses) that needed to be corrected, but otherwise, everything looks quite similar to the version available from the author's website.

That being said, I think the post that RemoveGrain64 came from was made ~a week after the last version of RemoveGrain and Repair were released.

I also built the two plugins you asked about, they're linked in the first post.

[tedkunich]

I don't mean to be a pest about 64 bit binaries, I was just curious what improvements would be seen, if any. It was a nice chance to learn assembly, re-learn signal filtering, and all that good stuff.

Besides, Jeremy Duncan could barely compile the original 32bit source . . .


My apologies sir... The subject matter and timing were just a too coincidental... :)

[Stephen R. Savage]

You forgot to statically link OpenMP again. I was converting to YUY2 from interlaced YV12 (generated by SeparateFields().SelectEvery(4,0,3).Weave()) on a 640x480 format frame.

Edit: I googled for a copy of libiomp5md.dll and copied it to system32. I hope that's legal. Anyway, YUY2 conversion no longer crashes with the updated version. The new Repair version also works. Thanks for clarifying the version number involved. TelecideHints and FieldHint work as expected.

Edit2: For the record, Decomb64 by Squid80 works as expected (even with MT). TIVTC would be nice though.

Edit3: My remaining (major) wishlist, in descending order of priority:

mt_masktools
TIVTC
nnedi2 (yeah right)
GradFun2DB
dfttest

I suspect most of these will be a pain to port, possibly with the exception of GradFun2DB and mt_masktools. Getting a full stable avisynth.dll is of course top priority though.

Edit4: I believe the RemoveGrain/Repair version is the "pre-release" then. Confusingly, there is a "1.0 pre-release" and a "pre-release".

[JoshyD]

OpenMP is open, so copying it to your system should be a ok, it's actually better than statically linking to the library, as it will allow the usage of multiple plugins that were compiled with parallel directives to be isntantiated concurrently.

Is there a major difference between the RemoveGrain and Repair versions?

Which version of mt_masktools are you looking for? I think 1.5.8 was the last build before 2.0 alphas started rolling out. I can port 1.5.8 very quickly, 2.0 will take a bit longer.

[Stephen R. Savage]

Latest v2.0 alpha (2.0a36). 1.5 stable isn't really used anymore. I think there was some rearrangement of the modes to Repair between the two versions, but I couldn't really tell you the difference to be honest. I think Didee mentioned something about it though.

Edit: You haven't answered this yet. How does the current build handle script/plugin autoloading? Is it simply disabled?

[patul]

My apologies sir... The subject matter and timing were just a too coincidental... :)

Coincidental, (not to mention a word in *_iSSE.asm files :p ).

[JoshyD]

Latest v2.0 alpha (2.0a36). 1.5 stable isn't really used anymore. I think there was some rearrangement of the modes to Repair between the two versions, but I couldn't really tell you the difference to be honest. I think Didee mentioned something about it though.

Edit: You haven't answered this yet. How does the current build handle script/plugin autoloading? Is it simply disabled?

To be honest, I haven't even looked into the autoloading. The code is all there, in tact. It may be looking in Program Files instead of Program Files (x86) or something. I'll see if I can't get a straight answer on that. In the mean time, have fun with masktools 2.0a x64. (http://www.mediafire.com/?jc0zh3gcmwg) It's a very rough build, stress it out and let me know how it treats you.

[Stephen R. Savage]

mt_edge crashes when using the built-in kernels. A custom kernel seems to work fine.

TempGaussMC(edimode="EEDI2") also raises an exception, but I can't seem to trace it to a specific line.

[JoshyD]

Can you post a few of the scripts you're using to test it? I don't have a lot pre-written myself, nor a lot of good material to test with, help on either would be greatly appreciated.

[Stephen R. Savage]

DirectShowSource("file.avi")
mt_edge(param) # param = "sobert" or "roberts" or "laplace"

causes an instant crash.

I have traced the TGMC exception down to a line unrelated to masktools. It occurs due to TemporalSoften at the line "temporalsoften(2,255,255,28,2)".

The following mt_masktools-based scripts seem to work:

AntiAliasing (custom version)
DeHalo_alpha
FastLineDarken
LimitedSharpenFaster
SRestore (except double blend modes, depends on Average.dll)

This means that so far the following operations are already enabled in Avisynth64:

Motion-adaptive deinterlacing (TDeint, EEDI2)
Crude Inverse Telecine (TDeint + Decimate)
Deblending (mt_masktools)
Sharpening (mt_masktools)
Denoising (MVTools2)

[JoshyD]

That was embarrassing . . . it was a simple typo in the source on my part. Link is updated with version that should work correctly. Let me know of any more problems.

[Stephen R. Savage]

Thanks. mt_edge defaults work now, and every example usage of masktools I have seems to perform as expected. Please look into fixing the temporalsoften bug, as temporalsoften is (ab)used fairly often in scripts.

[JoshyD]

Alright, I think I've got that temporal soften bug squashed, test it and let me know if there are any issues

I have TempGaussMC running . . . I'm showing some significant speed differences, anyone care to try there hand at it? I've got a four core machine, and telling AviSynth to use ~8 threads seems to be the sweet spot for processor utilization for me.

[aegisofrime]

Alright, I think I've got that temporal soften bug squashed, test it and let me know if there are any issues

I have TempGaussMC running . . . I'm showing some significant speed differences, anyone care to try there hand at it? I've got a four core machine, and telling AviSynth to use ~8 threads seems to be the sweet spot for processor utilization for me.

I want to try it! What are the files that's needed? I'm clueless about running 64-bit Avisynth.

JoshyD I take it you have a Core i7 machine? I wanna see what my Phenom II 955 gets.

[Stephen R. Savage]

I can confirm that TGMC/EEDI2 works now.

@aegis: You want avs64, eedi2_64, mvtools2_64, mt_masktools64, removegrain64, and repair64.

Things left to do:
1) Port changes to avs 2.6
2) Implement RGB code
3) Port more plugins
4) Clean up code

[JoshyD]

I can confirm that TGMC/EEDI2 works now.

@aegis: You want avs64, eedi2_64, mvtools2_64, mt_masktools64, removegrain64, and repair64.

Things left to do:
1) Port changes to avs 2.6
2) Implement RGB code
3) Port more plugins
4) Clean up code

@aegis
Stephen's spot on about what to get, the directions for installation of the 64bit dll are pretty straight forward, and contained in the readme that accompanies the archive containing Avisynth64. Any headaches you encounter, come back and we'll (myself and whoever else cares to pitch in(I bet Stephen wouldn't mind)) will be as helpful as possible.

@Stephen
Your list of todo's is quite well put. I wanted to ask you if you saw any speed improvement under the 64bit environment. I went from encoding ~10fps on a 720x480 interlaced dv source to ~20fps. I feel like that's too big of a leap and I may have screwed something up along the line. If your numbers are anything similar, I can rest a little easier.




Code clean up is a big concern . . . it's kind of a mess in there, especially the hack and slash that was done to get the inline assembler in Avisynth to compile. I would really like to rip the assembly out to standalone ASM files and optimize it specifically for x64 to truly take advantage of the extra registers all around. I think there's some extra performance to eek out if that can be done. Any current inline ASM doesn't use the extra registers at our disposal. In addition, a lot of it uses the mmx register set, when we could easily use the SSE registers, which are twice as large and twice as numerous (8 64 bit mmx registers vs 16 128bit xmm (SSE) registers).

Some of the existing code can be directly dropped in to what's in Avisynth 2.6, while other portions of the project have gone to Softwire for dynamic assembly generation. That's just a pain to deal with, I would have rather seen assembly generated dynamically via macros and such as Masktools did. This would mean generating every function needed before runtime, leading to possibly larger code, but removes the dependence on Softwire, which is no longer officially maintained.

Seriously, I'm really impressed with the way the Masktools authors implemented their assembly routines. It obscures a lot of the function generation via a TON of macros, but with some architecture specific aliasing of registers/variables, the codebase can be compiled for both x86 and x64 without too much of a headache. That's almost the state I have it in now, an hour of coding and the source would compile for either architecture. It's also compiler agnostic (for the most part, there were some pieces of C++ that ICC and GCC don't agree with, which were coded around in my release-->most compilers like their function templates outside of *.cpp source files). If any Masktools authors care, I can give you the source I made, and point you to where the more strict compilers complain.

The RGB code should be back in the main DLL without too much work, I think I've almost got it taken care of, hopefully we'll see it back by the end of the week. It just wasn't on the top of my priority list, I wanted to get TempGaussMC up and going before anything else.

The script produces awesome results for restoring my old home movies, but was painfully slow when comparing it to a quick noise removal / deinterlace with some of the other plugins (namely a quick run through FFT3DFilter and MVDegrain coupled with yadifmod/nnedi2). The x64 results appear visually identical, so I don't think there are any steps accidentally skipped in the x64 code path. I'm racking my brain for differences outside of arhcitecture, but can't think of any as of yet.

That being said, working with the same samples, I can literally encode almost twice as fast when working under a pure 64bit environment. This makes re-encoding 24 hours of raw dv video (thank you HDD's in the TB+ range) seem like a practical batch job.

I've grabbed the 2.6 branch from the CVS periodically, and it's not stable for me in x86 land as of yet. The code compiles, and starts to serve the video stream, but output will just drop to zero a few hundred frames into an AVI encode. When the project matures to a point that the authors feel comfortable calling it a beta release, I want to go to work. A lot of the code can just be "dropped in" while I'd like to create a more elegant solution to replace Softwire generated assembly. This would make the whole package a bit more future proof. We're going to see x64 stick around for a while, it makes sense to start to use the features it offers. I personally have 4 x64 machines floating around, while clinging to an old x86 P4 (northwood 2.6ghz) that I use to mess around with various linux distros.

Final note: Both GCC and ICC support iterative compile-->runtime profiling of code-->profile based optimization. None of that has been done for any of these releases. When it's all a bit more stable, I'd like to allow some time for this. The guys at doom10 recommend this approach when doing your own x264 compiles. (http://doom10.org/index.php?topic=26.0)

[kemuri-_9]

Final note: Both GCC and ICC support iterative compile-->runtime profiling of code-->profile based optimization. None of that has been done for any of these releases. When it's all a bit more stable, I'd like to allow some time for this. The guys at doom10 recommend this approach when doing your own x264 compiles. (http://doom10.org/index.php?topic=26.0)

this seems like you're trying to imply that MSVC does not have a profiling and optimization feature like ICL/ICC/GCC,
which is untrue as MSVC does have PGO (Profile Guided Optimization)...
i only recall the feature only being in the professional/team versions and not the express/free ones though.

x264 is easier to profile as it's an executable, so you only need to provide a file to work with and it can profile.

avisynth profiling would be more complex as you need to supply both a script and a program to profile avisynth with...
not to mention going through all the code paths would also be a pain.

[Stephen R. Savage]

I think a key problem is a lack of ways to benchmark AVS64. I use avs2avi for standard AVS, but there is no analogue for AVS64. For example, if you benchmark against x264, the results are skewed by the 64-bit advantage for x264. If you normalize by using avs2yuv for the 32-bit Avisynth, you still have to factor in the speedup by cutting out the piping overhead.

That said, here are some benchmarks. All results were taken using x264 64-bit in q=51, preset=ultrafast. 32-bit AVS was fed using avs2yuv, which should have negligible performance cost when single-threading.

Edit: Performance benchmarks have been redone using avs2avi.

TempGaussMC/EEDI2
32-bit: 2.83 fps
64-bit: 3.01 fps

MDeGrain3
32-bit: 6.20 fps
64-bit: 6.90 fps

AAA (mt_masktools, EEDI2)
32-bit: 1.92 fps
64-bit: 0.63 fps (SetMTMode: 1.94 fps)

Didee's Edge Mask
32-bit: 80.16 fps
64-bit: 89.02 fps

EEDI2 Resize2x
32-bit: 5.59 fps
64-bit: 5.67 fps

None of these cases came out bit-exact. I am a bit confused as to why AAA() comes out so much slower when all the components are faster.

Edit: I have traced the AAA slowdown to the following code fragment:

input = DirectShowSource("640x480p30.xvid.avi")

ox = width(input)
oy = height(input)

aa = TurnRight(input).EEDI2(field=1).TurnLeft().EEDI2(field=1)

edge = mt_logic(mt_edge(aa, "5 10 5 0 0 0 -5 -10 -5 4", 0, 255, 0, 255),
\ mt_edge(aa, "5 0 -5 10 0 -10 5 0 -5 4", 0, 255, 0, 255), "max").Greyscale().
\ Levels(0, 0.8, 128, 0, 255, false).Spline36Resize(ox, oy, -0.5, -0.5, 2 * ox, 2 * oy)
ds = Spline36Resize(aa, ox, oy, -0.5, -0.5, 2 * ox, 2 * oy)
maskmerge = mt_merge(input, ds, edge, U=1, V=1)
MergeChroma(ds)

I think it is a cache-related bug, because none of the individual pieces is slower.

[JoshyD]

this seems like you're trying to imply that MSVC does not have a profiling and optimization feature like ICL/ICC/GCC,
which is untrue as MSVC does have PGO (Profile Guided Optimization)...
i only recall the feature only being in the professional/team versions and not the express/free ones though.

x264 is easier to profile as it's an executable, so you only need to provide a file to work with and it can profile.

avisynth profiling would be more complex as you need to supply both a script and a program to profile avisynth with...
not to mention going through all the code paths would also be a pain.

Oh, I know that MSVC does profile, but GCC and ICC are just "better" compilers. If anything, at least give GCC credit for being free, cross platform, having auto parallelization and auto vectorization, and always being up to date. That's a lot for a community driven project. It constantly produces code similar in quality to the much more expensive and commercially developed ICC, and VS2008's compiler is pretty dated, I believe. It will still compile some really questionable coding practices without as much as a warning. I haven't looked at the release candidate for 2010 yet though.

Note:
Compilers are stupid, I've written them in the past. Consider them akin to something like google's translator. The more straightforward you are with the language, the easier it is for a compiler to understand. Hence, I don't like VS2008's lax rules for C++ syntax. Assembly is pretty much as straight forward as it comes, but inlining it into C++ functions is generally a bad idea. You tell the compiler "make me some machine code from this high level language" and you give it machine code wrapped in high level language? Why translate the same sentence twice??

And that ends my rant . . . sorry, back to DLL optimization.

A dll is essentially an executable as well, it just can be dynamically tagged on to whatever program needs it at the time. It contains a set of functions that are then made available to the process that utilizes it. As avisynth is a frame server, it has one purpose, to provide video and audio to the calling program. The entry point into avisynth's dll and subsequent function calls internally shouldn't depend on the program.

The drawback to dll profiling is that you can only profile functions in Avisynth that are called internally by Avisynth. The compiler doesn't know what the external program is doing to the registers, memory, etc, so no profile can be created for any externally called functions. Things like internal filters will behave the same each time they are called, because external programs cannot call something like a resize function directly. It is my understanding that useful profiles can be generated for these. The machine state is going to be known prior to each internal function call.

It would DEFINITELY be painful to try and get every code path to execute on avisynth, while also also providing a number of test videos to stress them.

Just feeding working scripts with strings of useful functions (pseudo-random perl avs generation anyone?) into x264 repeatedly at the command line would hit a lot of the code paths. Random test vector generation has been useful for me in the past, it may fail miserably here, but if I get the time I may try it out. Hey, it's my own time to waste, I'm not suggesting anyone even think about it.

[JoshyD]

I think it is a cache-related bug, because none of the individual pieces is slower.

Time to go bug hunting!

Just converted and restored RGB functionality, it's up and in the latest release on the front page.

[kemuri-_9]

I think a key problem is a lack of ways to benchmark AVS64. I use avs2avi for standard AVS, but there is no analogue for AVS64. For example, if you benchmark against x264, the results are skewed by the 64-bit advantage for x264. If you normalize by using avs2yuv for the 32-bit Avisynth, you still have to factor in the speedup by cutting out the piping overhead.

A) compile avs2yuv for 64bit
B) use vdub, it has x86 and x64 versions and both work with the corresponding avisynth directly.

---

I would be in agreement on extracting out the inline asm to separate files, utilizing x264's asm abstraction layer as indicated in
http://x264dev.multimedia.cx/?p=191
would likely make things much easier.

[Stephen R. Savage]

Time to go bug hunting!

Just converted and restored RGB functionality, it's up and in the latest release on the front page.

ConvertToRGB seems to work fine, as does ConvertToYV12. Is it a problem that your ported filters are not bit-exact to the originals?

Also, perhaps you could recompile avs2avi (http://moitah.net/download/latest/AVS2AVI.zip), avs2yuv (http://akuvian.org/src/avisynth/avs2yuv/), and wavi (http://sourceforge.net/projects/wavi-avi2wav/files/)against the 64-bit Avisynth. These should be trivial to build. In particular, avs2avi is useful for benchmarking because it has a null output mode and reports the average FPS.

[JoshyD]

@kemuri-_9

I like the way that x264 has done their asm coding, a lot. MvTools2 uses some portions of x264, and the fact that they have a nice and easy abstraction layer made porting those parts of the code seamless.

@Stephen
The issue with the AAA script you wrote is DEFINITELY cache related. Try SetMTMode(1,1) and it magically goes the speed it should when single threaded. It's ever so slightly faster in x64 mode, when you add threading to the mix, there are definite speed gains to be had. I have no idea why the normal caching mechanism is fussy, I didn't re-write any of that code.

I've been using VDub for benchmarking, but can do a quick recompile of those tools in a bit. I just write out raw streams taking any compressor out of the mix.

As for the subtle pixel differences, they're quite odd, and I can't explain them as of yet.

If comparing with ImageMagick (http://www.imagemagick.org/script/index.php), the average error of 24 bit bitmap captures for each channel is ~0.005%. I'm going to see if I can find what's causing the difference, there may be some rounding differences when working with 64bit integers that are playing a role. I'm going to fine tooth comb the code and see what I can see.

Edit: I just remembered that in the normal version of avisynth goes through Softwire for (I think) any planar to non-planar conversion, it very well could be that's where the difference lies.

[Stephen R. Savage]

I can confirm that SetMTMode(1, 1) brings performance back to about the same levels. I hope that the bug behind this can be squashed.

If you say that the image errors are trivial, then I will take your word for it.

Edit: Didee's new TGMC requires VerticalCleaner (http://home.arcor.de/kassandro/prerelease/VerticalCleaner.rar) by kassandro. Ain't the hamster wheel of upgrades fun?

[JoshyD]

A rough Vertical Cleaner is up on the first page, it's just the C-Code compiled, but ICC should be doing some of the SSE optimizations for us. TempGaussMC Beta 2 is at least as fast in most cases with this version of the plugin, sometimes still faster. This little filter is far from the limiting factor of the overall script . . .

Edit: The C version is faster than the ASM, odd huh?

[Stephen R. Savage]

Bravo, it works. It's a shame that you're the only one working on Avs64. Is there anything that those of us who can't write significant amounts of code can do?

[turbojet]

I see directshowsource source in the sources package but any chance of including directshowsource.dll in the binary package?

I've never been able to get squid80's directshowsource.dll working, keeps giving no function errors.

Also if you ever plan on an x64 build of 2.60 I look forward to it considering a resize only script is about 10% faster with 2.60 over 2.58 and about 15% faster then 2.58 MT.

[Stephen R. Savage]

DSS was included in one of the earlier copies of the Avs64 build posted here. It seems JoshyD has forgotten to include it in the latest one, so I have uploaded it here: http://www.sendspace.com/file/tm7pcf

[turbojet]

Thanks for the upload but unfortunately that doesn't work either. I tried both loadplugin and auto load from plugins directory and this is the result:

avs [error]: Script error: there is no function named "directshowsource"

avisource worked in avisynth64 and graphstudio64 handles the input files correctly.

Has anyone been able to use directshowsource?

[Stephen R. Savage]

DSS64 works fine for me, and I used it in all my performance tests above.

[JoshyD]

Whoops, sorry guys, updating the archive with direct show source, and it definitely is working for me. Don't know what other idiosyncrasies would be giving you grief when loading the plugin.

@Stephen:
I compiled a 64bit avs2avi for benchmarking and such, works fine for me, hope it does for you as well.

[turbojet]

I was able to get directshowsource working. Loadplugin was pointing to a 32 bit dll.

Also I made an batch installer (http://www.mediafire.com/?zgnyfxizmim) that checks for x64 os, checks if avisynth x86 is installed, copies files to the avisynth plugins directory, and enters the registry entries. It's kind of a rough installer but it only takes one click and gets the job done. Feel free to edit at your will and/or include it with the binaries if you want.

It's ok to use avisynth x86 plugins directory for x64 dll autoloading but they need to be named different from x86 dll's to allow x86 dll's to load.

[Stephen R. Savage]

@JoshyD: Thank you. I have updated the benchmarks to reflect the more accurate avs2avi methodology. avs2avi allows the accurate measurement of even very fast filters.

@turbojet: Good job figuring out the autoload thing. I thought it would be something like that.

[JoshyD]

@Turbojet: Thanks for the nifty little script, I'll go ahead and stick it in the archive with future updates of Avisynth64.

@Stephen: How many threads were you allowing during those benchmarks? I'm guessing you just ran it through the normal cache, so just double checking.

Also, are there any other little pieces of code that you'd like to see work with the project? I took a look at TIVTC, and it's a bit of a beast to convert, are there any other day to day plugins that would be beneficial?

I'm thinking I might optimize some of those hot spots where a single thread gets "stuck". I think there's some speed gains hidden in removing the core program's reliance on the mmx register set. All 64 bit processors have 16 XMM registers, 6 of which are volatile across function calls, meaning we can do whatever we want with them.

The BitBlt Functions (http://en.wikipedia.org/wiki/Bit_blit) move data in 64bit chunks when we could be doing it in 128bit chunks.

I at least want to get the memory copy functions using the XMM registers instead of the MMX ones.

[Stephen R. Savage]

All tests were strictly single-threaded. Neither MT() nor SetMTMode() were used, and only single-threaded filters were used.

If you can't get TIVTC, then perhaps:

Stuff I use frequently (descending order of priority):

DGDecode
GradFun2DB
dfttest
AddGrainC
ColorMatrix
FFmpegSource2
aWarpSharp (SEt version)
Vinverse (DLL version, but has working script equivalent)


Stuff I have but don't really use much (unsorted):

Average
BiFrost
ChromaShift
DeGrainMedian
Gavino's Runtime and Script extensions
RawSource
SSIQ (YV12 mod)
TComb
TTempSmooth


Stuff I use that is closed source:

nnedi/nnedi2 :(
Checkmate (needs to be reimplemented anyway)
DSS2 (dead)

[Adub]

Is it possible to run 32bit plugins with 64 bit Avisynth? Or will all plugins require a rewrite to work correctly with 64bit Avisynth?

[kemuri-_9]

Is it possible to run 32bit plugins with 64 bit Avisynth? Or will all plugins require a rewrite to work correctly with 64bit Avisynth?

x86 and x86_64 code is not allowed to intermix by the operating system.
if the plugin uses inline asm then it'll need to be rewritten...
(seeing at how most plugins inline asm instead of using an asm compiler like yasm/nasm)

if it only uses C/C++, then it can (most generally) just simply recompiled for x86_64
(this depends on how assumptive they are of things and used code that breaks when the sizeof some of the basic variable types change).

if you want to have avisynth x86 and x86_64 intermix, the available option is to use TCPDeliver to deliver frames over socket connections between them.

[Stephen R. Savage]

By the way, I am reporting that the version of FFT3DFilter on the first post of this thread does not work. It returns "could not load plugin fft3dfilter.dll". I have tried with fftw3.dll in system32, the application directory, and in another global/path directory.

Also, instead of making FFT3DFilter link against fftw3.dll, why not use the default name libfftw3f-3.dll, so that the DLL can be shared with dfttest (if you ever port it).

[JoshyD]

Also, instead of making FFT3DFilter link against fftw3.dll, why not use the default name libfftw3f-3.dll, so that the DLL can be shared with dfttest (if you ever port it).

Because I was being lazy . . . I'll change the library name to the original. I was wondering if maybe I included the wrong version of the fftw3.dll with the rar? I can't check that right now, but if you have a free second, try grabbing the original package here (ftp://ftp.fftw.org/pub/fftw/fftw-3.2.2-dll64.zip), and renaming the dll?

I had it up and running on my system . . . I'll get back to my development machine and check it out.

Also, in other fun news, I've ported the vertical resizers to use SSE registers instead of mmx, and taken it out of inline assembly. I'm almost done removing the default inline assembly horizontal routines to their own assembly functions.

You'd be surprised how much speed you can gain by just not using inline assembler and going with straight up assembly instead.

After that's all done, I think the slowest internal Avisynth function will be bitblt, and then it's on to the plugins for more optimizations.

[JoshyD]

Is it possible to run 32bit plugins with 64 bit Avisynth? Or will all plugins require a rewrite to work correctly with 64bit Avisynth?

The response you got earlier is quite correct, but I was wondering which plugin in particular you were interested in?

[Stephen R. Savage]

JoshyD, the MD5 of my fftw3.dll matches the one from the main page (Win64 version, of course).

Also, I believe the resizer functions were optimized for SSE2 in the 2.6 branch. Hopefully your optimizations won't be for nothing and can be generalized to the CVS version.

[squid_80]

Softwire was alive a few years ago, when 64-bit support was added: http://cvs.gna.org/cvsweb/softwire/?cvsroot=softwire

For benchmarking, that is what the "play" command of avsutil is for.

[JoshyD]

@Stephen

The optimizations shouldn't be all lost. The only difference is that mine aren't dynamically generated like they are in the new branch. Currently, I'm implementing them with function pointers to different resizers depending on the FIR filter size which is dependent on the filter. For example Lanczos4Resize has a FIR filter size of 8, it's possible to generate larger FIR filters, but those are rare. I'm still kicking around ideas on how to best handle these cases.

The trade here is that the actual code is larger, but since it's generated at compile time, there's no one time cost of function generation during filter instantiation. Will it really make a difference? Not really sure right now.

To give an idea of the difference in execution, I do something along these lines:

switch (plane)
{
case 2: // take V plane
cur = resampling_patternUV;
fir_filter_size = *cur++;
src_pitch = src->GetPitch(PLANAR_V);
dst_pitch = dst->GetPitch(PLANAR_V);
xloops = ((src->GetRowSize(PLANAR_V_ALIGNED)+15) / 16)*16; // Round to multiple of 16
dstp = dst->GetWritePtr(PLANAR_V);
srcp = src->GetReadPtr(PLANAR_V);
y = dst->GetHeight(PLANAR_V);
yOfs2 = this->yOfsUV;
(((INT_PTR)srcp&15) || (src_pitch &15)) ? ua_proc_uvplane(srcp, dstp, src_pitch, dst_pitch, y, xloops, yOfs2, cur)
:a_proc_uvplane(srcp, dstp, src_pitch, dst_pitch, y, xloops, yOfs2, cur);
break;

case 1: // U Plane
cur = resampling_patternUV;
fir_filter_size = *cur++;
dstp = dst->GetWritePtr(PLANAR_U);
srcp = src->GetReadPtr(PLANAR_U);
y = dst->GetHeight(PLANAR_U);
src_pitch = src->GetPitch(PLANAR_U);
dst_pitch = dst->GetPitch(PLANAR_U);
xloops = ((src->GetRowSize(PLANAR_U_ALIGNED)+15) / 16)*16; // Round to multiple of 16
yOfs2 = this->yOfsUV;
plane--; // skip case 0
(((INT_PTR)srcp&15) || (src_pitch &15)) ? ua_proc_uvplane(srcp, dstp, src_pitch, dst_pitch, y, xloops, yOfs2, cur)
:a_proc_uvplane(srcp, dstp, src_pitch, dst_pitch, y, xloops, yOfs2, cur);
break;

case 3: // Y plane for planar
break;

case 0: // Default for interleaved
(((INT_PTR)srcp&15) || (src_pitch &15)) ? ua_proc_yplane(srcp, dstp, src_pitch, dst_pitch, y, xloops, yOfs2, cur)
:a_proc_yplane(srcp, dstp, src_pitch, dst_pitch, y, xloops, yOfs2, cur);
break;

default:

break;
}

The 2.6 branch does something along these lines:

switch (plane) {
case 2: // take V plane
src_pitch = src->GetPitch(PLANAR_V);
dst_pitch = dst->GetPitch(PLANAR_V);
dstp = dst->GetWritePtr(PLANAR_V);
srcp = src->GetReadPtr(PLANAR_V);
y = dst->GetHeight(PLANAR_V);
yOfs2 = this->yOfsUV;
(((int)srcp&15) || (src_pitch &15)) ? assemblerUV.Call() : assemblerUV_aligned.Call();
break;
case 1: // U Plane
dstp = dst->GetWritePtr(PLANAR_U);
srcp = src->GetReadPtr(PLANAR_U);
y = dst->GetHeight(PLANAR_U);
src_pitch = src->GetPitch(PLANAR_U);
dst_pitch = dst->GetPitch(PLANAR_U);
yOfs2 = this->yOfsUV;
plane--; // skip case 0
(((int)srcp&15) || (src_pitch &15)) ? assemblerUV.Call() : assemblerUV_aligned.Call();
break;
case 3: // Y plane for planar
case 0: // Default for interleaved
(((int)srcp&15) || (src_pitch &15)) ? assemblerY.Call() : assemblerY_aligned.Call();
break;
}

The real difference is in the function calling, the underlying code is really very similar. The references to assemblerY.call() or ua_proc_yplane(...vars...) execute very similar code as far as I can tell.

I checked my FFT3DFilter, and it works still. I think I may have been building it funny, I noticed some intel compiler specific include directories in my configuration, so I removed them, and rebuilt. Would you humor me and try this build? (http://www.mediafire.com/?zzz3dy0mdt2)

@squid_80
Softwire does indeed have 64bit support, but it's apparently lacking. The main team of Avisynth guys has been updating 32bit Softwire as they go, I've noticed. I guess I just feel more comfortable writing hard coded assembly than dealing with Softwire, which will probably come back and bite me later, we'll see.

I can see myself breaking down and starting to implement the same things with Softwire64, it wouldn't be much of a stretch.

[Stephen R. Savage]

Oh, figured it out:

Activation context generation failed for "FFT3DFILTER.DLL". Dependent Assembly Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

There is also a dependency on libmmd.dll and ieshims.dll.

Edit: It loads and works fine after I installed the MSVC 2008 SP1 runtimes and a googled copy of libmmd.dll. Hopefully you can resolve the dependencies on your end as well (static linking?).

[Adub]

The response you got earlier is quite correct, but I was wondering which plugin in particular you were interested in?

Well, I have been considering installing Windows 7 x64 bit for some time as the website I run (Adubvideo (http://adubvideo.net) gives a number of tutorials, and on some of these my readers have been having issues when running BD Rebuilder on Windows 7.

Since I'm a bleeding edge kind of guy, I though, let's go 64bit! But I wanted to be sure that I could still get the most out of my current encoding chains.

I currently don't have a particular filter in mind, but then I haven't gone through all of my plugins to check which ones are compatible and not. Judging as more and more support is being added for 64 bit, I'll think I will go ahead and make the switch in the next few weeks.

I'll be back with plugin suggestions soon after that, I'm sure! ;)

And thank you so much for your hard work! It is greatly appreciated right now with the big switch to 64 bit operating systems and processors.

[JoshyD]

Yeah, statically linking would be pretty helpful, somehow I missed that one when setting my build options. It's fixed now, I think we're good to go

[JoshyD]

New build is up on the main page, please download it and let me know if I've missed any oddities in my test cases.

Changes are listed on the front page, there's some nice speed gains to be had in the main dll. Running single threaded TempGaussMC beta2 through avs2avi with a null output and using an old home movie recorded in DVSD (720x480, 29.97fps, interlaced, bff) as the source:

Avisynth32: 5.05fps
Avisynth64: 6.09fps

Hooray, a whole extra frame every second! It may not seem like much, but for a long encode (each run took ~40mins, give or take depending on the version used), an extra frame every second, can shave a significant amount off your total encode time.

Add some good ol' SetMTMode(2) into the mix, and you've got a larger gap (same test):

Avisynth32: 13.79fps
Avisynth64: 17.66fps

Still not setting any speed records, but with a slow script (that produces great results) I'll take my speed gains, however minor they may be. Script dependent, I'd say speed increases are in the 15% to 20% range on average.

[Stephen R. Savage]

Quick tests:

Decode 640x480 Xvid (MS MPEG-4 Decoder, 500 frames)
32-bit: 113.27 fps
64-bit: 118.20 fps
Relative Speed: 104.4%

Spline36Resize 16x Enlarge (500 frames)
32-bit: 18.06 fps
64-bit: 31.61 fps
Relative Speed: 175.0%

TempGaussMC beta 2 (EEDI2, 100 fields)
32-bit: 3.42 fps
64-bit: 3.72 fps
Relative Speed: 108.9%

MDeGrain3 (200 frames)
32-bit: 5.96 fps
64-bit: 6.54 fps
Relative Speed: 109.7%

AAA (100 frames)
32-bit: 2.17 fps
64-bit: 2.20 fps (MTMode = 1)
Relative Speed: 101.3%

All tests were run three times and averaged. I am not seeing the performance increases in TGMC that you are, JoshyD. However, resize performance is definitely up! The caching bug related to AAA is still not fixed. I suspect this bug is sapping performance out of other scripted filters (read: TGMC) as well. Note that the SetMTMode hack is suboptimal, as it costs performance when the caching bug is not in play (e.g. a simple source+resize script).

[turbojet]

Thanks for the new version however it crashes on Athlon II. Here's the windows error codes.

Problem signature:
Problem Event Name: APPCRASH
Application Name: x264_x64.exe
Application Version: 0.0.0.0
Application Timestamp: 4b8c1206
Fault Module Name: avisynth.DLL
Fault Module Version: 2.5.8.5
Fault Module Timestamp: 4b9681a6
Exception Code: c0000005
Exception Offset: 0000000000005528
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 9eab
Additional Information 2: 9eabb149e34b0e02564736c484278831
Additional Information 3: 6bcd
Additional Information 4: 6bcdaf28393e1989487185c90748dcec

I noticed the new dll is 4 MB while the older one that works is 800 KB.

Also since all 64 bit filters I could find are named identical to the 32 bit counterpart I changed the install script to use plugins64 directory. You can grab it here (http://www.mediafire.com/?zgnyfxizmim)

Another thing is as far as I know there's only one haali media splitter build that's x64 and handles vc-1 and it's very difficult to find but I uploaded it here (http://www.mediafire.com/?yy5nimzdwed). Up to you if you want to post it in the original post in case people aren't able to use HMS x64 or report issues with VC-1 (from the latest official release).

Lastly about filters I heavily use TIVTC so it's unfortunate that's not easy to convert. The other ones I use every once in awhile are:
Decomb v4 (http://neuron2.net/decomb/decomb410b4.zip) (more effective ivtc then v5 but nowhere near tivtc, squid's is v5 only)
LeakKernelDeint (http://avisynth.org/warpenterprises/files/leakkerneldeint_25_dll_20050118.zip) (fast, simple, sharp deinterlacer)
RePAL (http://avisynth.org/warpenterprises/files/repal_25_dll_20030523.zip) (very effective for handling pal sources that were blended for ntsc dvds)

[JoshyD]

@Stephen: Let TGMC (and all the filters, really) have a few thousand frames to work with, 100 doesn't give the caching mechanisms in Avisynth (nor the computer as a whole) time to get filled and ready to go. All that data has to be pulled in closer and closer to the processor before any computationally intensive algorithms can really shine. If they don't have the needed data close at hand, you're going to be memory latency limited rather than compute limited. I've been running tests with TGMC and my own personal builds to collect usage data in the program. That being said, using a larger sample can sometimes accentuate the differences between the two versions. For example, a 2002 frame sample produces slightly more differences than if I just let it run though the first few hundred frames.

Avisynth 32: 5.54fps
Avisynth 64: 6.60fps
Relative increase: 119%

The caching bug is annoying, can post the exact script and file for AAA that you're working with?

@turbojet: That's a memory access error, can you post the script that you were running when that occurred? A short sample of the clip you were using would be useful as well, I need to get pitch, height, width, etc info from it. I haven't coded any instructions that are incompatible with your processor, however, I may very well have mucked up my memory alignment access requests. I think it probably occurred in the horizontal resize function, but can't be certain.

The DLL linked here is ridiculous in size because of the compiler that generated it, and the options I allowed. Intel's C++ compiler will generate a specific code path for every Intel processor p4 and newer. At runtime, the code CPUID's your processor, and if you're lucky enough to have the your VendorID = 'GenuineIntel' you'll get a special set of the code optimized for your particular processor and its idiosyncrasies. Therefore, extra code for those processors, in addition to some statically linked code from OpenMP, balloon the size of the DLL.

Don't worry about AMD processors though, the base code path is for any processor that has SSE3 or newer. While Intel's compiler won't auto-vectorize using SSE4 instructions for AMD processors, it will still give them the benefit of data operations that can be performed with SSE3 and any older set of SIMD instructions.

[turbojet]

Source is a 1920x1080 m2ts, script is: DirectShowsource().AssumeFPS(24000,1001).LanczosResize(1280,720)

It's definitely an issue with resize, if I don't resize it works without crashing. I tried bilinear, point, bicubic resize and all crashed.

[JoshyD]

@turbojet

Would you try the latest release on the first page to see if that cleared up any of the problems?

If that doesn't, would you try the following two procedures:
1. Only resize on the the vertical axis
2. Only resize on the horizontal axis

Hopefully, only one of those will crash the program, if at all.

I'm guessing DirectShowSource is giving you a yv12 stream?

[turbojet]

With same 1920x1080 source
LanczosResize(1280,720) - crash
LanczosResize(1920,720) - crash
LanczosResize(1280,1080) - works

yes yv12

[JoshyD]

@turbojet
I can't seem to recreate the crash. I specifically wrote the vertical resize functions to check for memory alignment before executing. I hope this isn't processor specific, that would be a bummer. Checking for instruction support, your Athlon II should have all the goods to do the resize correctly. Any chance you could snip a few frames (100?) of the source and post it somewhere so I can investigate further?

@Stephen
That cache bug is annoying . . . but interesting. It seems that it also exists in SEt's 32bit build of avisynth 2.5.8 as well, perhaps something got all strange when the MT mode was hacked to be supported?

[turbojet]

Every source crashes instantly with horizontal resize so a source I don't think would help and I'm afraid it's a cpu instruction issue. Some things that might help is x264 doesn't use SSE3 on this cpu, this is what it uses: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT. Also a few months ago I was testing icc x264 builds and found some that worked and some that didn't. I believe the ones that didn't use -QaxSSE3 during the compile but I'm not 100% on that.

[kemuri-_9]

Every source crashes instantly with horizontal resize so a source I don't think would help and I'm afraid it's a cpu instruction issue. Some things that might help is x264 doesn't use SSE3 on this cpu, this is what it uses: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT. Also a few months ago I was testing icc x264 builds and found some that worked and some that didn't. I believe the ones that didn't use -QaxSSE3 during the compile but I'm not 100% on that.

what cpu do you have again (codename preferred)?

SSE3 is barely used in x264, the majority of the SSE3 related asm actually uses SSSE3.
that being said, x264 does have some SSE3 asm but it only uses these for CPUs that flag Cacheline64, which is only on intel processors.

tl;dr
AMD processors never see SSE3 getting used in x264 even if they have it.

[Stephen R. Savage]

@turbojet
I can't seem to recreate the crash. I specifically wrote the vertical resize functions to check for memory alignment before executing. I hope this isn't processor specific, that would be a bummer. Checking for instruction support, your Athlon II should have all the goods to do the resize correctly. Any chance you could snip a few frames (100?) of the source and post it somewhere so I can investigate further?

@Stephen
That cache bug is annoying . . . but interesting. It seems that it also exists in SEt's 32bit build of avisynth 2.5.8 as well, perhaps something got all strange when the MT mode was hacked to be supported?

Here is AAA.avsi in full:

function AAA(clip input, int "type", bool "mask", bool "chroma")
{
ox = width(input)
oy = height(input)

type = default(type, 1)
mask = default(mask, true)
chroma = default(chroma, false)

gscale = chroma ? input : Greyscale(input)

aa = type >= 2 ? nnedi2_rpow2(gscale, rfactor=2) :
\ type == 1 ? TurnRight(gscale).EEDI2(field=1).TurnLeft().EEDI2(field=1) :
\ PointResize(gscale, ox * 2, oy * 2).TurnRight().SangNom().TurnLeft().SangNom()

edge = mt_didee(aa).Spline36Resize(ox, oy, -0.5, -0.5, 2 * ox, 2 * oy)
ds = Spline36Resize(aa, ox, oy, -0.5, -0.5, 2 * ox, 2 * oy)
maskmerge = mask ? mt_merge(input, ds, edge, U=1, V=1) : ds

return chroma ? MergeChroma(maskmerge, ds) : MergeChroma(maskmerge, input)
}

function mt_didee(clip input)
{
mask = mt_logic(mt_edge(input, "5 10 5 0 0 0 -5 -10 -5 4", 0, 255, 0, 255),
\ mt_edge(input, "5 0 -5 10 0 -10 5 0 -5 4", 0, 255, 0, 255), "max").Greyscale().
\ Levels(0, 0.8, 128, 0, 255, false)
return mask
}
I just call it as
DirectShowSource("source.avi")
AAA()
adding "chroma=true" makes the cache bug even worse. I don't use MT myself, so this cache bug is quite a bummer. Hope you can find it, even if it's not a bug in your own code. Perhaps it will even turn out to be an intractable design flaw (argh).

Also, many older AMDs do not support SSE3, but only up to SSE2 (slowly).

[Wilbert]

Also, many older AMDs do not support SSE3, but only up to SSE2 (slowly).
My old Athlon XP doesn't support SSE2, but only iSSE (or perhaps SSE dunno).

[Stephen R. Savage]

According to Wikipedia, the oldest AMD64 CPU (Opteron, 130nm) supports SSE2. However, turbojet's Athlon II appears to support SSE3, so who knows...

[JoshyD]

@Stephen
You're quite correct, which is why I was confused. I don't think his processor agrees with loading the values of some of the arithmetic functions straight from memory. For now, I'm going to band-aid the code paths to use MMX if a non-compatible CPU turns up. I had totally forgotten that the Athlon64's only supported SSE2. I was happily thinking that many of the feature checking before function execution were going to go away because x64 processors generally have the latest and greatest when it comes to SIMD instructions. Looks like that's not the case. I've got an old Athlon64 I rarely use, so I guess I'll be turning it on to run test vectors before any future code gets loose.

It's weird because he can use the horizontal resize functions which make heavy usage of 128bit memory transfers to set up their workspaces. SSE2 doesn't have official listings for movdqa or movdqu instructions, but those are most certainly used when resizing YV12 or YUY2 horizontally.

The cache issue remains open, and I'm able to perfectly recreate it using any source. Looking intensively over a diff with the core Avisynth files hasn't turned up anything of interest yet. This test case seems to be the only one that really highlights the problem. Running other filters, internal and external, with and without a SetMTMode command doesn't give such a stark contrast in performance. I'm wondering a) why this filter combination is a showstopper and b) what script environment variables aren't set unless you allow a MT mode to be set. The largest difference I could find is:if ((env->GetMTMode(false) > 0) && (env->GetMTMode(false) < 5)) {
filter_graph = new CacheMT1(new Distributor(filter_graph, env), env);
}
else {
filter_graph = Cache::Create_Cache(AVSValue(filter_graph), 0, env).AsClip();
}

This occurs on script instantiation. I'll keep looking. On a sidenote, building and using the current 2.6 allows MT mode to be set, but the performance is abysmal. All non-MT functionality is perfect though.

@kemuri-_9
Thanks for the heads up on the x264 methodology of choosing instructions based on cacheline size. This makes me wonder if turbojet's CPU will return "true" when asked if it supports SSE3. If that's the case, then I'll have to add in code (yank it from the x264 cpuid functions) that checks for cache line size, and goes about its business appropriately.

Looking at the 2.6 CVS, it dynamically assembles almost identical code to what I have written for the vertical resizers. It does so based upon a check for SSE3 and SSSE3. If it's the case that Athlon II's and their brethren say they have SSE3, but fail when executing these SSE ops, the main code branch may hit a similar snag.

@turbojet:
Would you mind running CPU-z (http://www.cpuid.com/download/cpuz/cpuz_153.zip) and telling me what feature flags your CPU reports? If it says SSE3, then dang, more code to write.


EDIT:

Caching bug squashed. Turns out, EEDI2 identifies itself as never wanting a cache, so when your script asks for a frame generated by EEDI2, it goes all the way back and generates it again.
if (h_policy == CACHE_NOTHING) { // don't want a cache. Typically filters that only ever seek forward.
__asm mov rbx,rbx // Hack! prevent compiler from trusting ebx contents across call
return childGetFrame(n, env);
}

That childGetFrame executes more times than needed when your AAA script is run. This is the cause of the huge slowdown. Can anyone think of an instance where we would universally never want to save the previously generated frames? Check the main page for an update, this also *tries* to address the problems with older processors, but I don't think it's all the way yet.

[turbojet]

It's an athlon II 620. CPU Instructions are: MMX(+) 3DNow(+) SSE(1,2,3,4A) x86-x64, AMD-V which I'm pretty sure is identical to Phenom II. At least linux /proc/sys/cpu has identical flags.

Avisynth 2.6 Alpha 2 works fine here and if a dropback is needed wouldn't it be better to drop back to SSE(2) instead? IIRC that's all the further 2.6 branch goes to and it's a significant speedup

[Stephen R. Savage]

Updated results for AAA (200 frames):

32-bit: 1.85 fps
64-bit: 1.90 fps
Relative Performance: 102.7%

A bit disappointing, since I recalled EEDI2 being 10% faster and masktools2 similarly faster. How did you fix the caching bug? Did you enforce a cache for all filters? How does the original Avisynth code handle this?

Also, here's to hoping that you manage to get TIVTC ported one day, as it's one of the Greatest Filters Of All Time™.

[JoshyD]

@Stephen
The quick fix was to just *allow* a filter to be cached. EEDI2 was requesting not to be cached at all for some reason or another. Before, if the policy was not not cache a filter, it would go to the filter's get frame function, and return that, and no cache related code would be executed. By disallowing the insta-return and allowing it to also check / insert the frame into the cache, AAA starts finding the frames EEDI2 previously generated, and uses those, rather than making EEDI2 do the work all over again.

I'm not sure what the difference is between SEt's build and the standard build that creates the slowdown. The MTModes are hacked in to the main program, so there's some incongruities in the code. I think the internal caching mechanism is being polished little by little for 2.6, so this will be cleared up in the end. For now, the fix uses a little extra memory in certain corner cases. In general, a cache irregardless of whether or not the filter was written to only seek forward isn't a bad idea. You can write a script to access the source in any pattern you like really. If the accesses repeat, the script will be faster.

Also, a comment on the speed differences in AAA, over 3 runs of 250 frames, I have:
32-bit: 3.28fps
64-bit: 3.69fps
Relative performance: 112.5%

Did you grab the latest build of EEDI2? It used to use the same code for memory copying as Avisynth, which I wrote to work on processors with 128bit registers, instead of 64. The memory copy alone adds a little speed bump.

TIVTC is a beast because of the hodge podge of code it consists of. It also intermingles inline asm with compiler intrinsics as a means of using the XMM registers in some cases. It can get a little ugly. If I can figure out what's causing turbojet's crash, I'll re-examine TIVTC.

@turbojet:
The latest grab of the 2.6CVS has vertical resize code that checks for SSE3 support and then uses the same combination of instructions I do. I wish I had a similar machine to test on, so I could trace during run time. When I said fall back to MMX, I meant the mmx registers. They're half the size of the SSE registers, but technically, iSSE instructions use them. I'd drop back to that code in the case of an incompatible processor. The conundrum is why is your SSE1-4A supporting processor balking at the code? I also wonder what x264 is using to red flag your CPU to restrict it to SSE2, perhaps the vendor ID?

Do the older versions of the DLL let you resize? I hadn't changed ANY of the resize code at that point. I guess that's a good sanity check point. Try this one (http://www.mediafire.com/?cnzdxvzkw0m) or the fail safe is this build of the source. (http://www.mediafire.com/?ykdjez2eomy) If that doesn't work, there's something deeper behind the problem.

Has anyone been able to get this to run correctly on AMD cpu's?

[kemuri-_9]

I also wonder what x264 is using to red flag your CPU to restrict it to SSE2, perhaps the vendor ID?

look at common/cpu.c (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/cpu.c;hb=HEAD) and common/x86/cpu-a.asm (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/x86/cpu-a.asm;hb=HEAD)

[osgZach]

Does anyone have 32 vs 64 bit performance numbers for TempGaussMC_beta2 ? (assuming it runs.. Stephen mentioned TGMC but not which version he's using, I don't think)

[Stephen R. Savage]

@JoshyD: I'm using the copy of EEDI2 from the first page, which is dated to 2/19/2010. If there is another version, I am not aware of it.

[osgZach]

I was referring more to the AVS(i) script itself. But I'm guessing we're talking about the same thing really.

Either way. I average about 2fps give or take some fractional ups and downs. Takes about 4h:45m to do a 22m:48s clip

Core 2 Duo @ 3.2ghz

What kind of fps do you see on your machine?

And while I have your attention.. any way to get it entered either into the Fieldhint(blah..()) or replace that line entirely, during Yatta AVS generation ?

Sucks to have to manually swap it out on 50 different project files on average :p
But I suppose nothing a find/replace script can't fix. Still learning bits and pieces about YATTA, but since writing my Find30fps tool it's been so much less trouble.

[JoshyD]

Temp Gauss Beta 2 were the runs Stephen and I were performing, single threaded, for me enjoys a healthy ~20% speed increase, multiple threads speeds up the process by a larger margin. Here are some sample numbers for a 4000 frame run of a dvsd (720x480, 29.97 fps, interlaced bff) source through the script using avs2avi, no compression, outputting to null:

32bit Avisynth: 5.06fps
64bit Avisynth: 6.07fps
Relative speed: 119.96%

Threading the script with SetMTMode(2,8):
32bit Avisynth: 14.47fps
64bit Avisynth: 18.05fps
Relative speed: 124.74%

Tests were run with a Core i5-750 (4 cores, no HT) @ 3.71GHz. The eight thread creation request keeps all 4 cores constantly churning at 100%. Requesting less threads reduces total CPU utilization, with 4 threads giving ~50% total usage. Your performance will vary based upon your system setup, obviously.

The versions of Avisynth were both based on SEt's 2.5.8 build with multithreading enabled, for as much of an apples to apples comparison as possible.

Generally, it seems safe to assume ~15-20% performance increase, dependent upon which plugins you want to use.

Vertical Sharpen was ported specifically because of it's use in TGMC beta 2. The same goes for RemoveGrain and Repair. MaskTools2 and MVTools2 were ported because they're so darned useful. EEDI2 was ported to fill the void of a good 64bit deinterlacer.

The 32 bit versions of these plugins were compiled by myself, with some tweaks here and there as I went. I've been "rolling my own" versions of these for a while now, the 64bit port was an extension of this hobby.

[osgZach]

Thanks for your response.

Those are certainly some nice numbers. I wasn't even aware you could run it multi-threaded either. Frankly the setup process for MT related stuff scared me way, was afraid I would boink something :p
Right now I only exclusively use TempGaussMC_beta2, the only other filter being TDecimate, and any other stuff YATTA deems necesarry in the generated AVS. I am encoding to HuffYV12 and then filtering later. So hey maybe I'll get something like 5 or 6 fps ? LOL :p


Perhaps I will go back to the initial post and see if I can follow the steps to do all of this..

Although as far as MT goes.. I only have 2 cores, so I wouldn't expect huge numbers like you got (but really impressive), but I think the x64 single threaded boost might be pretty big as well.

Is there a chance this will all be available vial a one-click installer at some point?

[Adub]

So, are we currently not able to use TIVTC and most of Tritical's plugins with the 64 bit version of Avisynth? Or is that just because they haven't been converted yet?

If so, I request that we convert as many of Tritical's plugins as possible. Specifically TIVTC and Colormatrix, as I think that those are some of the most often used plugins.

[osgZach]

@ Adub

@Stephen


TIVTC is a beast because of the hodge podge of code it consists of. It also intermingles inline asm with compiler intrinsics as a means of using the XMM registers in some cases. It can get a little ugly. If I can figure out what's causing turbojet's crash, I'll re-examine TIVTC.


:(

Hopefully something will happen in the future though. This is a great project, I've been waiting for a long time.. So it is great to see the progress we have already.

I wish I had the skills to contribute.. I barely know what little Python I use as it is...

[osgZach]

Also it would be really nice if we could get an updated DGDecode DLL based on 1.5.8

I've gone and gotten DGIndex 1.4.6 in the meantime, and I'm hoping there is going to be no major differences in the results? Though I'm guessing I should recollect my YATTA metrics just to make sure..

[JoshyD]

Thanks for your response.

Those are certainly some nice numbers. I wasn't even aware you could run it multi-threaded either. Frankly the setup process for MT related stuff scared me way, was afraid I would boink something :p
Right now I only exclusively use TempGaussMC_beta2, the only other filter being TDecimate, and any other stuff YATTA deems necesarry in the generated AVS. I am encoding to HuffYV12 and then filtering later. So hey maybe I'll get something like 5 or 6 fps ? LOL :p


Perhaps I will go back to the initial post and see if I can follow the steps to do all of this..

Although as far as MT goes.. I only have 2 cores, so I wouldn't expect huge numbers like you got (but really impressive), but I think the x64 single threaded boost might be pretty big as well.

Is there a chance this will all be available vial a one-click installer at some point?

There is a one click installer included in the package, it was written by another user, turbojet. You just extract the files to any directory, and run it.

It needs to be run as administrator, and should copy all the needed info to run 64 bit mode.

Any hiccups, come back, and definitely ask. I really appreciate user feedback, it helps me understand where I can make the project more user friendly, and what makes people decide not to try it.

If that doesn't work, try this as a fallback:
Essentially, you need to put Devil.dll and avisynth.dll in your system32 directory. All other plugins can be loaded in your script or placed in <Avisynthdir>\plugins, or I think the installer changes it so that 64bit plugins go in <Avisynthdir>\plugins64.

There should be two system directories under <drive>:\Windows, one for SysWOW64, and one for system32. System32 is a misnomer, as this is where all 64bit binaries are stored. SysWOW64 stands for system windows on windows 64, and is meant to keep 32bit binaries separate from your 64bit ones. SysWOW64 is where your current avisynth.dll lives.

Other notes, SetMTMode is really worth getting to know a little better. If you have two cores, why not use them? I'll be happy to help you get started, just send a quick message if interested.

[osgZach]

I'd definitely like to learn how to use SetMTMode.. I think there are some threads around here I might be able to read to get a handle on it, too. But I'll try not to ask anything -too- stupid if it comes down to needing help.

A quick example with TGMC would be best, as that's all I really need at this point.

I did use the batch install script. It worked for the most part. Was it supposed to make a "C:\Program 2.5\plugin64" directory though? I am stuck with it now, and it will only autoload plugins from that directory. It's a minor issue at this point though, I probably goofed on setup procedure/steps.

My only remaining problem is.. I need Decimate or TDecimate , to do my IVTC. I did have to hack around the AVS that YATTA generated, to get things working (until I discovered only that aforemention directory was the one needed for auto-loading) so far I get it opened to the point where it whined about no TDecimate :p

I'm guessing there is no x64 Tdecimate as its part of TIVTC package =\

Is there a Decomb 64-bit package? Otherwise I'm kind of... meh now. can't proceed any further until I figure out a solution. Hoping the answer is in front of my face, lol....:(

[JoshyD]

So, are we currently not able to use TIVTC and most of Tritical's plugins with the 64 bit version of Avisynth? Or is that just because they haven't been converted yet?

If so, I request that we convert as many of Tritical's plugins as possible. Specifically TIVTC and Colormatrix, as I think that those are some of the most often used plugins.

TIVTC is going to be an undertaking, but it's been so largely requested, it seems that I may have to suck it up and do it.

ColorMatrix looks easier, I may do that one today . . .

[JoshyD]

Ta-da! Decomb64 (http://members.optusnet.com.au/squid_80/Decomb.zip) This was built by squid_80 way back when. If it doesn't give you the desired results, I'll look into building a version myself. For more quick existing ports check his page out. (http://members.optusnet.com.au/squid_80/)

There isn't a TDecimate that I'm aware of, but, TIVTC is getting ported one way or another, dammit.

[Stephen R. Savage]

I believe the poster who mentioned Decomb wanted the v4 release, not the v5 built by Squid80 (which does work fine). However, I think porting TIVTC would make his point moot.

[osgZach]

Actually Stephen, up until now, I have always used Decomb V5, but will switch over to TFM/TDec when they are finally ported to x64.

However, since I only need the Decimate function (at least I can still index with TIVTC in 32-bit) and not Telecide or anything else, I think this will work for me.

Pretty much going to be going TFM/TDec in the foreseeable future. Works for my needs from what I can tell.

I did start an AVI (Lagarith since I don't have ffdshowx64 installed) I saw a slight improvement but really not much.. I don't seem to dip into the 1.x FPS range anymore, and on average its about 2.5fps or so. But I am hoping once I get MT figured out, I will see a better performance boost.

In either case, instead of just hitting every frame with TGMC, I can just set my TFM values really low to pick up all visible combing until I'm satisfied. That'll give me a good performance boost. ON default values, earlier today I did a test and it only took 30m to do the encode to HuffYV12. So almost real-time results which is not bad.

I'm probably abusing TGMC anyway, but it gives such good quality whether the frame is actually combed or not, I figure why not just wipe it all out in one fell swoop :p

If I could figure out that fuzzy math behind VFR trimming + timecodes frame-range calculations, and actually manage to write it in code, I wouldn't even need YATTA for TFM stats... ah well, its a great program regardless. And so is Avisynth x64 (I hope!)


UPDATE

Nice! SetMTMode(2,0) gets me between 3 - 4 fps now instead of 2 on average. It goes up and down. Bit of a boost tho :) I've even seen it go up to 5fps for a few seconds.

[osgZach]

OK that's not good.... It just threw an Access Violation. It was somewhere around 80 - 90% done with the encode I think.

Running SetMTMode(2,0) outputting to Lagarith, YV12, Multithreaded, and at the time of the crash it had 749MB of memory allocated in the processes tab.


Crash context:
An out-of-bounds memory access (access violation) occurred in module 'Veedub64'...

...writing address 0000000000000000.


Crash dump included below.


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

Disassembly:
7fef045b100: 49 dec ecx
7fef045b101: 03d3 add edx, ebx
7fef045b103: 49 dec ecx
7fef045b104: 03c8 add ecx, eax
7fef045b106: 49 dec ecx
7fef045b107: 03d0 add edx, eax
7fef045b109: 43 inc ebx
7fef045b10a: ff24c2 jmp dword ptr [edx+eax*8]
7fef045b10d: 666690 nop
7fef045b110: 48 dec eax
7fef045b111: 8d4940 lea ecx, [ecx+40h]
7fef045b114: 48 dec eax
7fef045b115: 8d5240 lea edx, [edx+40h]
7fef045b118: 4d dec ebp
7fef045b119: 8d40c0 lea eax, [eax-40h]
7fef045b11c: 0f db 0fh
7fef045b11d: 188280010000 sbb [edx+180], al
7fef045b123: f30f6f42c0 movdqu xmm0, [edx-40h]
7fef045b128: f30f6f4ad0 movdqu xmm1, [edx-30h]
7fef045b12d: 49 dec ecx
7fef045b12e: 83f840 cmp eax, 40h
7fef045b131: 660fe741c0 movntdq [ecx-40h], xmm0
7fef045b136: 660fe749d0 movntdq [ecx-30h], xmm1
7fef045b13b: f30f6f52e0 movdqu xmm2, [edx-20h]
7fef045b140: f30f6f5af0 movdqu xmm3, [edx-10h]
7fef045b145: 660fe751e0 movntdq [ecx-20h], xmm2
7fef045b14a: 660fe759f0 movntdq [ecx-10h], xmm3
7fef045b14f: 7dbf jge f045b110
7fef045b151: 4c dec esp
7fef045b152: 8d15b8010000 lea edx, [000001b8]
7fef045b158: 4d dec ebp
7fef045b159: 8bc8 mov ecx, eax
7fef045b15b: 49 dec ecx
7fef045b15c: c1e904 shr ecx, 04h
7fef045b15f: 49 dec ecx
7fef045b160: c1e104 shl ecx, 04h
7fef045b163: 49 dec ecx
7fef045b164: 03c9 add ecx, ecx
7fef045b166: 49 dec ecx
7fef045b167: 03d1 add edx, ecx
7fef045b169: 4d dec ebp
7fef045b16a: 2bc1 sub eax, ecx
7fef045b16c: 49 dec ecx
7fef045b16d: c1e904 shr ecx, 04h
7fef045b170: 0faef8 sfence
7fef045b173: 43 inc ebx
7fef045b174: ff24ca jmp dword ptr [edx+ecx*8]
7fef045b177: 66666690 nop
7fef045b17b: 66666690 nop
7fef045b17f: 90 nop
7fef045b180: 660f6f02 movdqa xmm0, [edx]
7fef045b184: 660f6f4a10 movdqa xmm1, [edx+10h]
7fef045b189: 660f7f01 movdqa [ecx], xmm0 <-- FAULT
7fef045b18d: 660f7f4910 movdqa [ecx+10h], xmm1
7fef045b192: 4d dec ebp
7fef045b193: 8d4080 lea eax, [eax-80h]
7fef045b196: 660f6f5220 movdqa xmm2, [edx+20h]
7fef045b19b: 660f6f5a30 movdqa xmm3, [edx+30h]
7fef045b1a0: 660f7f5120 movdqa [ecx+20h], xmm2
7fef045b1a5: 660f7f5930 movdqa [ecx+30h], xmm3
7fef045b1aa: 660f6f4240 movdqa xmm0, [edx+40h]
7fef045b1af: 660f6f4a50 movdqa xmm1, [edx+50h]
7fef045b1b4: 49 dec ecx
7fef045b1b5: 81f8a8000000 cmp eax, 000000a8
7fef045b1bb: 660f7f4140 movdqa [ecx+40h], xmm0
7fef045b1c0: 660f7f4950 movdqa [ecx+50h], xmm1
7fef045b1c5: 660f6f5260 movdqa xmm2, [edx+60h]
7fef045b1ca: 660f6f5a70 movdqa xmm3, [edx+70h]
7fef045b1cf: 48 dec eax
7fef045b1d0: 8d9280000000 lea edx, [edx+80]
7fef045b1d6: 660f7f5160 movdqa [ecx+60h], xmm2
7fef045b1db: 660f7f5970 movdqa [ecx+70h], xmm3
7fef045b1e0: 48 dec eax
7fef045b1e1: 8d8980000000 lea ecx, [ecx+80]
7fef045b1e7: 7d97 jge f045b180
7fef045b1e9: 4c dec esp
7fef045b1ea: 8d15d0ebffff lea edx, [ffffebd0]
7fef045b1f0: 49 dec ecx
7fef045b1f1: 03c8 add ecx, eax
7fef045b1f3: 49 dec ecx
7fef045b1f4: 03d0 add edx, eax
7fef045b1f6: 43 inc ebx
7fef045b1f7: ff24c2 jmp dword ptr [edx+eax*8]
7fef045b1fa: 666690 nop
7fef045b1fd: 666690 nop

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

Windows 6.1 (Windows Vista x64 build 7600) []

RAX = 0
RBX = 5c0
RCX = 0
RDX = 37e4aaf0
RSI = 2d0
RDI = 5c0
RBP = 7fef05e4d00
R8 = 2d0
R9 = 200000
R10 = 0
R11 = 7fef0459dc0
R12 = f0
R13 = 0
R14 = 0
R15 = 37e4aaf0
RSP = 252ab408
RIP = 7fef045b189
EFLAGS = 00010246


Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'Veedub64'...

...writing address 0000000000000000.

Pointer dumps:

RDX 37e4aaf0: 10101010 10101010 10101010 10101010 10101011 10101010 10111110 10111110
RSP 252ab408: f01fce6d 000007fe 252ab440 00000000 365d1f30 00000000 365d1f30 00000000
252ab428: f020bdb9 000007fe 37e4aaf0 00000000 00000000 00000000 00000000 00000000
252ab448: 00000001 00000000 37e4aaf0 00000000 00000000 00000000 000005c0 00000000
252ab468: 05211fca 00000000 051337bc 00000000 f020b357 000007fe 365d1f30 00000000
RBP 7fef05e4d00: f01fbf50 000007fe f0201bd0 000007fe f0201b80 000007fe f0201aa0 000007fe
7fef05e4d20: f02019f0 000007fe f0305820 000007fe f0200d80 000007fe f0200c80 000007fe
7fef05e4d40: f01ff170 000007fe f01feda0 000007fe f01fe8b0 000007fe f01fe6f0 000007fe
7fef05e4d60: f01fe620 000007fe f01fe5d0 000007fe f01fdf20 000007fe f01fcec0 000007fe
R9 00200000: 00000000 00000000 001c2ad0 00000000 00200050 00000000 001fffd0 00000000
R11 7fef0459dc0: f045a4b4 000007fe f045a58f 000007fe f045a672 000007fe f045a757 000007fe
R15 37e4aaf0: 10101010 10101010 10101010 10101010 10101011 10101010 10111110 10111110

Thread call stack:
7fef045b189: avisynth!avs_at_exit [7fef01f0000+115680+155b09]
7fef01fce6d: avisynth!0000ce6d
7fef020b357: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4897]
05211b3d: fieldhint!00001b3d
76d7aac8: ntdll!TpCallbackMayRunLong [76d60000+1a3f0+6d8]
1b70dd7d: mt_masktools26!0005dd7d
7fef0209ad4: avisynth!avs_release_video_frame [7fef01f0000+16ac0+3014]
7fef01fcae8: avisynth!0000cae8
7fef020b655: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4b95]
7fef01fcae8: avisynth!0000cae8
0516138f: telecidehints!0000138f
7fef0209ad4: avisynth!avs_release_video_frame [7fef01f0000+16ac0+3014]
7fef043c953: avisynth!avs_at_exit [7fef01f0000+115680+1372d3]
7fef01fcae8: avisynth!0000cae8
7fefcdb18aa: KERNELBASE!ResetEvent [7fefcdb0000+18a0+a]
7fef020b655: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4b95]
1b6d1b22: mt_masktools26!00021b22
7fefcdb10ac: KERNELBASE!WaitForSingleObjectEx [7fefcdb0000+1010+9c]
7fef025a559: avisynth!DllGetClassObject [7fef01f0000+20ec0+49699]
7fef01fce6d: avisynth!0000ce6d
7fef0209ad4: avisynth!avs_release_video_frame [7fef01f0000+16ac0+3014]
7fefcdb18aa: KERNELBASE!ResetEvent [7fefcdb0000+18a0+a]
7fef020b655: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4b95]
05193f70: decomb!AvisynthPluginInit2 [05190000+1000+2f70]
7fef01fc9cc: avisynth!0000c9cc
7fef01fcae8: avisynth!0000cae8
7fef0209ad4: avisynth!avs_release_video_frame [7fef01f0000+16ac0+3014]
7fef01fcae8: avisynth!0000cae8
7fefcdb134c: KERNELBASE!SetEvent [7fefcdb0000+1340+c]
7fef020b6e7: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4c27]
7fef025a559: avisynth!DllGetClassObject [7fef01f0000+20ec0+49699]
7fef01fcae8: avisynth!0000cae8
7fefcdb134c: KERNELBASE!SetEvent [7fefcdb0000+1340+c]
7fef020b6e7: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4c27]
051918e2: decomb!AvisynthPluginInit2 [05190000+1000+8e2]
7fef01fc9cc: avisynth!0000c9cc
76db1c58: ntdll!RtlAllocateHeap [76d60000+51b70+e8]
7fef020b6e7: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4c27]
051917b8: decomb!AvisynthPluginInit2 [05190000+1000+7b8]
7fef043fa1f: avisynth!avs_at_exit [7fef01f0000+115680+13a39f]
7fef0209ad4: avisynth!avs_release_video_frame [7fef01f0000+16ac0+3014]
7fef043c953: avisynth!avs_at_exit [7fef01f0000+115680+1372d3]
7fef01fcae8: avisynth!0000cae8
7fefcdb18aa: KERNELBASE!ResetEvent [7fefcdb0000+18a0+a]
7fef020b655: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4b95]
7fef01f7e22: avisynth!00007e22
7fef043fa1f: avisynth!avs_at_exit [7fef01f0000+115680+13a39f]
7fef0209ad4: avisynth!avs_release_video_frame [7fef01f0000+16ac0+3014]
7fef043c953: avisynth!avs_at_exit [7fef01f0000+115680+1372d3]
7fef01fcae8: avisynth!0000cae8
7fefcdb18aa: KERNELBASE!ResetEvent [7fefcdb0000+18a0+a]
7fef020b655: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4b95]
7fef025a559: avisynth!DllGetClassObject [7fef01f0000+20ec0+49699]
7fef043fa1f: avisynth!avs_at_exit [7fef01f0000+115680+13a39f]
7fef0209ad4: avisynth!avs_release_video_frame [7fef01f0000+16ac0+3014]
7fef043c953: avisynth!avs_at_exit [7fef01f0000+115680+1372d3]
7fef01fcae8: avisynth!0000cae8
7fefcdb18aa: KERNELBASE!ResetEvent [7fefcdb0000+18a0+a]
7fef020b655: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4b95]
7fef01fcae8: avisynth!0000cae8
7fef0259006: avisynth!DllGetClassObject [7fef01f0000+20ec0+48146]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef020b6e7: avisynth!avs_release_video_frame [7fef01f0000+16ac0+4c27]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]
7fef0258ff0: avisynth!DllGetClassObject [7fef01f0000+20ec0+48130]

-- End of report

[turbojet]

osgZach: You didn't make a mistake on using the installer, I did. I didn't account for more spaces in the path here's a fixed install script and an uninstall script (http://www.mediafire.com/?zthdjndw5wo). All you should have to do is run the fixed installer, move any plugins from C:\Program 2.5\plugins64 to the avisynth install directory and delete C:\Program 2.5.

JoshyD: Can you remove the old broken install script and include the fixed install script and uninstaller in the next package? Also Do you have any news on an 'amd fix'? If it helps any I can test a 2.6 cvs dll if you can compile it, currently I don't have the time or the patience to setup a compiling environment again.

I was the one that asked for Decomb v4, for more reliable field matching, deinterlacing results then v5 but TIVTC would definitely trump both of them if time permits it.

[osgZach]

Thanks for that fix. I'll download it in a bit and give it a whirl.

Also.. if anyone could give advice, or point to a thread where it is discussed.. I'm interested in either completely moving to a 64-bit encoding/playback path, or just looking for some general guidelines on how to set it up easily so that my 32/64 bit stuff can peacefully co-exist and I can keep track in a way so that I know what's what, when working in scripts / other programs. As of right now I'm new to this so obviously I've had to do some juggling around of files, etc with scripts errors for this or that reason. Mainly I am worried that I am gonna make my system barf, and kill my brain trying to keep track of both x32/x64. I have no experience manually installing or things like ffdshow, Haali, etc or fussing with registry entries, etc.. I use CCCP and I don't think they have a pure 64-bit version?



Of course going pure 64-bit I guess depends on whether that Vdub crash was just a random oddity, has to do with Vdub itself, or the x64 Avisynth /or one of the x64 filters..

Though considering my (lack of) knowledge, perhaps it would be safer/better for me to maybe try getting Avisynth x32 MT setup instead? that seemed to be where the bulk of my performance boost came from. Is it a relatively easy process like installing x64? (a couple files copied, etc). It was great fun playing around with for sure.. But I gotta have a stable setup so I can leave the PC on and encoding, and not come back hours later to some random crash that ironically happened just after I left the room :p

[turbojet]

As for setting up I'd suggest this haali media splitter (http://www.mediafire.com/?yy5nimzdwed) (only one I've found that has an x64 splitter and splits VC-1) and ffdshow64 (http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/64-bit%20builds/ffdshow_rev3305_20100304_clsid_x64.exe/download). This should decode just about everything as long as a decoder is set in ffdshow decoder configuration. If you use windows 7 Preferred filter tweaker (http://www.codecguide.com/windows7_preferred_filter_tweaker.htm) will help set the defualt decoder.

With avisynth store 32 bit plugins in plugins, 64 bit in plugins64. The same avs script can be used for both and what determines if it's 32 or 64 bit is what application opens the avs file.

[hajj_3]

this 64bit avisynth is looking promising :) Alot of progress has been made in such a short space of time. Anyone know if LeakKernelDeint is open source and if it has a 64bit version compiled?

[Guest]

this 64bit avisynth is looking promising :) Alot of progress has been made in such a short space of time. Anyone know if LeakKernelDeint is open source and if it has a 64bit version compiled? Source is here (scroll to bottom):

http://neuron2.net/kerneldeint/kerneldeint.html

[osgZach]

As for setting up I'd suggest this haali media splitter (http://www.mediafire.com/?yy5nimzdwed) (only one I've found that has an x64 splitter and splits VC-1) and ffdshow64 (http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/64-bit%20builds/ffdshow_rev3305_20100304_clsid_x64.exe/download). This should decode just about everything as long as a decoder is set in ffdshow decoder configuration. If you use windows 7 Preferred filter tweaker (http://www.codecguide.com/windows7_preferred_filter_tweaker.htm) will help set the defualt decoder.

With avisynth store 32 bit plugins in plugins, 64 bit in plugins64. The same avs script can be used for both and what determines if it's 32 or 64 bit is what application opens the avs file.

Thanks.. I'm currently trying to do some further testing to see if anything on my end is causing this Access Violation.

So far its codec independent that I can tell. Lagarith does it, no matter the settings. I also came across UT Lossless Codec (http://forum.doom9.org/showthread.php?p=1382276) which is YV12 and multithreaded, which makes it a great replacement for HuffYUV until I can get FFDshowx64 installed (hopefully w/out problems) and see if they have an x64 HuffYV12 or not.

But it still does it. It seems like its either Avisynth causing the crash, or one of the filters like MT (not sure if its "MT" or masktools) or something.

I am currently running the script without SetModeMT(2,0) to see if it throws another Access Violation or not.

[osgZach]

It's definitely a crash caused by SetMTMode(2,0)

Encode without this line completed successfully..

Are there other MT modes I can try?

[levi]

It's definitely a crash caused by SetMTMode(2,0)

Encode without this line completed successfully..

Are there other MT modes I can try?

The modes are described @ http://avisynth.org/mediawiki/MT

usually i do
SetMTMode(3,0)
...source(...)
SetMTMode(2,0)
...


JoshyD

not sure if you saw it, but Set did make 2.6 avisynth build as well - http://forum.doom9.org/showthread.php?t=148782

Requests: (since you are so kind to accept them) :)
I'd like to cast another vote for 64 bit TIVTC & leakkerneldeint (in that order)

Also, someone mentioned repal but linked to the older version, the newer version (outputs 25 fps) is found at http://forum.doom9.org/showthread.php?p=1092552#post1092552 however srestore (http://forum.doom9.org/showthread.php?t=95924) is much more likely to give positive results across a variety of sources so i would not put repal at the top of a priority list

I want to test this with MCTemporalDenoise (http://forum.doom9.org/showthread.php?t=139766) which is a slow script I like.

Thanks for your efforts! This is a very exciting development. :)

[JoshyD]

@osgZach
What script/filters were you trying to run when you experienced the crash? That looks like a memory copy routine followed by some function, and that function looks vaguely familiar. There are MT modes ranging from 1 to 5, depending on how the filter wants to access data, the modes offer varying amounts of "protection" from events occurring asynchronously. Masktools *should* be thread safe, but that I can dig further. From the callstack, it looks like something wasn't cleaning up after itself correctly, I bet it's an easy fix.

@turbojet
I don't have access to an AMD machine to test why this is failing. Did you try the really old SSE2 only build from some time ago I linked in a previous post? If that's still failing, I'm going to have to find someone with an AMD machine to let me debug with. I'll change the installer in the next update. I've found a few other bugs and remnants of code that shouldn't exist in the 64bit environment. These changes aren't resize related though, this one's really bothering me. I also have a new Masktools that needs to go up after some testing, and ColorMatrix to post as well. I can get 2.6's CVS built and up sometime tomorrow, and then it's the weekend :)

[osgZach]

Here is the AVS, with the SetMTMode line that makes it crash..
I left out the truck-load of Trim statements at the end, for obvious reasons, but the rest is intact.

Also.. SetMTMode other than 1 or 2, crashes immediately (and it points to masktools 2.6). 1 loads with corruption but obviously crashes when you try to do anything.


SetMTMode(2,0)
LoadPlugin("C:\yatta\plugins64\decomb.dll")
LoadPlugin("C:\yatta\plugins64\dgdecode.dll")
LoadPlugin("C:\yatta\plugins64\telecidehints.dll")
LoadPlugin("C:\yatta\plugins64\fieldhint.dll")


function Preset0(clip c) {
#Name: Default
c
return last
}

DGDecode_Mpeg2Source("L:\Ep 01\VTS_01_1.d2v")



FieldHint(ovr="L:\Ep 01\VTS_01_1.d2v.fh.txt")
TempGaussMC_beta2().SelectEven()

PresetClip0=Preset0()

PresetClip0.Trim(0,41023)



DClip = Decimate(cycle=5,quality=3,ovr="L:\Ep 01\VTS_01_1.d2v.dec.txt").assumefps(last.framerate)


Several variations on the line calling TGMC (I Believe with TelecideHints also) will still cause a crash as well. Although I forgot which specific variation it originally crashed under (was pretty tired yesterday when fiddling with this stuff).

It's kind of a bummer really. I don't really get much of a speed improvement at all that I can tell, with x64. Most of it seems to come from using SetMTMode. But I'm currently doing more testing as my understanding allows.

I did visit the avisynth page, and one thing that I really couldn't "follow" was the MTi() stuff listed before SetMTMode.. I've never seen anyone actually use that stuff in a script either, always just the SetMTMode.. is it of any use in this situation?

8:50am EST:
I'm currently trying without SetMTMode, using this line instead

MT("TempGaussMC_beta2().SelectEven()",threads=2)


If it works, it will have cut work time, solidly in half. (nearly 5 hours, down to around 2 and a half per file). Hopefully it won't crash or anything, but will report back around 11am (or before) or so if it has.

[aegisofrime]

I finally got around to trying your 64-bit plugins JoshyD. I would have done it far sooner, but was worried about breaking my 32-bit Avisynth.

On a 624x352 test clip with the following script


DirectShowSource("D:\Test\Test.avi")
tempgaussmc_beta2(1,1,0,0,0,0,edimode="--",SVthin=0.0,pelsearch=1)

64-bit TGMC yield 14.29 FPS. The 32-bit version yielded 12.99.

For 64-bit I used x264_64 CLI. For 32-bit I used Lord Mulder's x264 launcher, so that I could use 64-bit x264 and thus reduce the variables to purely 64-bit vs 32-bit TGMC.

The test platform is a Core 2 Duo P8700 notebook with 4GB DDR3 RAM running Windows 7 (64-bit of course!)

It might not seem much, but I believe on a more powerful rig and over the course of a full length DVD movie the difference can be quite significant. I will get around to testing it on my Phenom II 955 rig and see if Intel's compiler really do cripple AMD performance.

I did run into a problem though. I tried to run FFT3DGPU but ran into an error with a missing file d3dx9_42.dll. Downloading that file and placing it in both my SysWOW64 and System32 folders merely gave me an error loading FFT3DGPU.dll.

In any case, thanks for the great work JoshyD! It's amazing what you have done on your own.


8:50am EST:
I'm currently trying without SetMTMode, using this line instead


If it works, it will have cut work time, solidly in half. (nearly 5 hours, down to around 2 and a half per file). Hopefully it won't crash or anything, but will report back around 11am (or before) or so if it has.

I tried that before, at least on the 32-bit version. TGMC does not work with the MT() function. It messes up the picture. If it works for you I would like to know though!

[Stephen R. Savage]

@aegisofrime: You need the 64-bit version of the d3dx9_42.dll and the website you downloaded it from probably only offered the 32-bit version. Have you tried using the Microsoft DirectX updater/installer?

Also, note that you introduce a bias by using x264 to compare speeds because the 32/64 piping introduces overhead, which may in fact be equal to the 1.3 fps advantage you see (though probably not).

[aegisofrime]

@aegisofrime: You need the 64-bit version of the d3dx9_42.dll and the website you downloaded it from probably only offered the 32-bit version. Have you tried using the Microsoft DirectX updater/installer?

Also, note that you introduce a bias by using x264 to compare speeds because the 32/64 piping introduces overhead, which may in fact be equal to the 1.3 fps advantage you see (though probably not).

Thanks for the reply. I have not needed to use the DirectX updater for quite a long while, but I will give it a try soon.

With regards to my testing methology, that's possible, although when MeGUI introduced 64-bit x264 support most agreed that the speedups from 64-bit x264 outweighs any latency issues with piping.

I think the next best thing is to use Veedub64 to do a Lagarith lossless encode? Is that what "save as AVI" does? Because it's the first time I'm using that software...

[Stephen R. Savage]

Yes, "Save as AVI" in VirtualDub compresses the video using VfW. The problem here is that now you have to factor in the cost of 32-bit vs 64-bit encoders. That is why I recommend avs2avi.exe with null output for comparing speed, because it eliminates outside variables.

avs2avi test.avs NUL -c null -o n

[aegisofrime]

Ah, the line you provided gave me the error "There is no codec with FourCC "null"!"

Pardon the noobness, again it's my first time using Avs2Avi too!

[osgZach]

aegisofrime,

I don't know what to tell you but from what I can tell my encode has come out perfectly.

2 hours 9 minutes and 30 seconds (give or take). Averaging about 4.5fps across 33,328 frames. Using MT() versus SetMTMode(). The same encode under 32-bit with the same filter and no MT would take around 4h:45m.

This makes me want to start priciing Core 2 quads at Newegg, to replace my Core 2 Duo :D But I must persevere! Fermi will be out soon and I'm on an aging 8800GTS(g92) 512MB. Although after selling my old 19" Samsung and maybe the C2D I could make up most of the cost anyway.... hmmm.. decisions ;)

Were you doing any manipulation in your script? I know I read that MT will totally screw up if you try to resize Width or Height or something like that..

btw Joshy.. Spline64Resize does not work ?? I'll test it again but it was Avisynth throwing me errors last time I tried it.

Also for anyone interested.. UT Codec is pretty awesome from what I can tell. File comes out much smaller than HuffYUV/12 probably on par with what Lagarith could do, or a bit smaller?
Its pretty nice either way.


General
Complete name : G:\test1.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 3.88 GiB
Duration : 18mn 32s
Overall bit rate : 29.9 Mbps
Writing library : VirtualDub build 32706/release

Video
Format : ULY0
Codec ID : ULY0
Duration : 18mn 32s
Bit rate : 29.9 Mbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 1.500
Frame rate : 29.970 fps
Standard : NTSC
Bits/(Pixel*Frame) : 2.890
Stream size : 3.88 GiB (100%)

[aegisofrime]

It works? I will have to give it a go myself then. Although I seem to recall Didee saying it won't work either. Perhaps it's because I have SetMTMode(2,4) at the top of my script and a Distributor behind. That gives me around 13 FPS on a Lossless Rendering run with TGMC(2,1,1,"NNEDI2" on my Phenom II 955.

Them Core 2 Quads ain't bad but I would really consider a Core i5-750 at least... Although that will require a motherboard change... And I'm waiting for Fermi to replace my 4870 as well!

[osgZach]

Yeah there is a really nice Lynnfield i5 up there w/8MB cache and virtualization support (tho no hyperthreading, but still 4 cores).

The SetMTMode gave me problems so maybe that is why it messed up on yours too.. hmm. Although we have different issues so who knows.
Now we need some 64-bit filters for Dot Crawl, Rainbows, etc.. I don't know how to do any of that with the filters I've collected so far.. Which by the way really need to be distributed with their Readme's..

I also can't get FFT3D/3DGPU to work.. comaplains about fftw3.dll, but I dunno. Its in the plugins64, system32, syswow64.. should all be the same version too. Complains it can't load it though.. lol. Not that I use it that much.
Think I can make due without most of the other filters for now tho.. Death Note's DVD have horrible color banding or something that I just can't fix, even with the proper filters. They go away if you use Gradfun2db to add grain, but then when you try to denoise or sharpen up in any way, they come right back.. not that they dissapeared much to begin with.. LOL Sorry for off topic.

Gonna go track down some AA bits to try w/EEDI2 there were some good fast ones in a thread somewhere around here (maybe one of mine).

Keep up the good work JoshyD.

p.s what I meant by a one-click installer was starting blank with no Avisynth installed. But having a installer package that will explicitly install an x64 only version.. I assume its just modifying the current installer with the changed files or something?

[osgZach]

Hmm ok Aegis, maybe you were right.. I just noticed, on frames that appear to be scene changes and fades (or fades on scene changes or something like that, but definitely scene changes) there is a very thin black line going DEAD CENTER through the image. (across the width, not the height i.e divides into a "top half" and "bottom half")
I am guessing this is an MT and/or Bobbing artifact.. An Overlap problem? Can that be tweaked ? It doesn't happen on every single frame in sequence, it might disappear and reappear, but once the scene is established it appears to go away..

Would MTi be better in this case? Advice appreciated. Frankly I never noticed it during playback, even when looking for it. So it may not be a huge issue, but would be nice to fix.

Fixed: (hopefully)
Hmm.. overlap 4 seems to give the best results. Aegis, if your problem was similar try tacking that MT("filter()",threads=int,overlap=int)

[JoshyD]

@osgZach
I seem to remember DGDecode not liking SetMTMode for some reason. If you want to try the same script, do something like this

SetMtMode(5,0)
DG_decode(<path>\source)
SetMtMode(2)


Setting an MT mode before calling a source multithreads accesses to the source itself. In this case, setting mode 5 before the source will make it behave like a single threaded source, while all other filters after SetMTMode(2) will behave nicely.

The version of FFT3DGPU linked on the main post shouldn't need that dll, but the regular FFT3DFilter should have been packaged with the fast fourier transform library needed to run correctly. Turns out I packed the wrong DLL with the filter, my mistake. The package is updated, if you'd grab it and give it a a whirl, I'd much appreciate it.

The FFT3DGPU filter DOES need a different *.hlsl file to be in the same directory as the plugin. I re-wrote the shaders used to be compliant with newer DX9 syntax rules. The results are the same though, but FFT3DFilter produces overall higher quality results in my opinion. Special note for FFT3DGPU, if you want to use SetMTMode around it, put the script in SetMTMode(5) before using the filter, and change back when you're done calling it.

As for Spline64Resize, mine works correctly for the test clips I've thrown through it. All of the resize functions eventually hit the same code, perhaps there's some corner case that you are running into? What's the size (widthxheight) and color space of the clip that's causing the resize to complain? I guess, all the video information on the clip as well as what you were trying to size it to would be helpful.

Finally, with the masktools 2.6 crashing, I'm pretty sure I can get that fixed. There's a new rough build of it as of now. See if that helps, otherwise, I may be going back in and re-writing the belly of the thing. Masktools uses an assembly macro to process all function calls, the problem being that 64bit C++ calls are all fast calls, and the function calling/returning code in masktools assumes a __cdecl call, I think. It's a pretty integral part of the whole thing, so I went about modifying it as gingerly as I could.

Masktools and MVTools are two plugins I'd really like to go back and optimize further, but I want to get a working TIVTC out, and before that, I'd really like to figure out why turbojet's Athlon II bites the dust when resizing. I'd also like to re-write EEDI2 for some extra speed all around, but these are more long term goals.

@aegisofrime
You've got this running on a Phenom II?? turbojet's been having troubles with his Athlon II. If I can get confirmation that this release doesn't break AMD processors, I'd be a very happy dude.

I think the syntax you want to use for benchmarking with avs2avi is:avs2avi64.exe <path:\script.avs> -o n

Choose no compression from the little dialog that pops up and wait. This will just run your script/video through avisynth, without writing the results to disk. Compare final FPS reports, and judge speed improvements accordingly.

Now to clear a few things up on multithreading:

The differences between MT("function") and SetMTMode aren't very well documented. Quick explanation, SetMTMode creates multiple instances of the filters used and allows more than one frame to be worked on at once. The drawback here is, that in some cases two functions will be trying to modify the same "things", giving you that nasty access violation. The different modes of SetMTMode (1-5) are designed to safegaurd against this. Mode 5 essentially puts whatever filter you've called into single threaded mode. Mode 1 creates a free for all when it comes to memory access/modification, which I don't think is really ever going to work well. Special note on use of SetMTMode, the number of threads can only be set during the first call to the function. Any use of SetMTMode(x, threads) after the initial use will ignore the "threads" parameter.

MT(clip,"function",threads,overlap) splits your source into pieces based upon how many threads you specify. For instance, clip.MT("FFT3DFilter()", threads=2), divides the source into top and bottom halves, processes them each with a different thread, and laces the output back together. The split (you can choose whether to do it horizontally or vertically) limits your options for resizing, because it doesn't know how to re-stitch together frames that started at one size, and then ended up completely differently sized at the end.

The other problem with using MT("function") is that the two halves may present different complexities, and therefore have different processing times. Also, if using a filter that does overall motion compensation or something of that sort, you only get half the information. The overlap parameter helps to alleviate this problem by making sure that both portions of your clip share some boundary data. If anyone remembers 3D game SLI (literal scan line interleaving 3DFX Voodoo2 style) vs load balanced rendering based on scene complexity, The same ideas can be applied to SetMTMode and MT("function"). There's no universal solution, that's why nVidia/ATi have custom profiles for different games.

A note on MTi, this operates essentially the same as MT, instead giving the filter the hint that you are feeding it an interlaced source. The internal functionality of the filter uses this hint to produce "more correct" results. (I think it may just separate fields before it goes calling other functions, call the functions with only the even frames and only the odd frames, finally weaving the results together)

Total tangent: As for current processors, Core i5-750 all the way. Hyperthreading is overrated, it's there to ensure poorly written code can keep all the execution units available busy. Write good code, and this shouldn't happen. The i5-750 overclocks like nobody's business. I've got mine, using the diminutive stock cooler and at stock voltage, running just north of 3.7GHz, stock speed is 2.66GHz. I think it's an upgrade that will last a while. There's some nice new technologies on it, not to mention that it was designed with four cores in mind, giving all four cores a pooled (and large) level 3 cache on die. The Core2Quads are two Core2's on the same die, so each pair of cores share a cache, but need to talk via an external bus to figure out which core has what in their cache, and synchronize accordingly.

I'm a computer architecture nut. The assembly functions that crop up in the 64bit version of Avisynth were written after a fair deal of reading of the Intel processor white papers. It's an attempt to optimize the code based on it's actual execution, taking into account which x86 micro-ops fuse, how a branch predictor will handle looping functions, memory accesses, register renaming, reorder buffers, pipeline stalls and flushes, blah blah blah.

[osgZach]

Interesting. I know earlier today I -did- try playing around with a SetMTMode initially 5, and then 2 around the filter but that still seemed to mess up or not work, etc.. I will go back and revisit the idea again and make sure I did everything properly.. Also is it necesarry to have a SetMTMode at the very top of the script, always? Or can I just call it AFTER DGDecode ? In either case I'll see if I can think of something.

MTi is an interest solution, but I don't have a true interlaced source.. not in the sense that every frame is interlaced, if I understand correctly. Most of its just combs from Telecine.. would that matter?

I will try and get back to you on Spline64Resize, as I know I could not get it to work that I can remember.. Spline36 will though.. Although it does funny stuff if you tag it onto the end of an EEDI2 anti-aliasing line (turnleft, blah blah, turn right, etc).

This baby IS very tempting I agree.. (http://www.newegg.com/Product/Product.aspx?Item=N82E16819115215&cm_re=Core_i5-_-19-115-215-_-Product) I also like that it supports virtualization technology too as its fun to play around with.. I think I saw a decent bundle for <$400 but that would also mean buying new DDR3... meh.. Fermi first, I'm pretty happy @ 3.2Ghz just need a better GPU for the time being :D

Edit:

I've done this is my script thus far but the performance seem lacking... although it takes a while for it to stabilize and pickup (its only been 20m).. But I'm only average around 2.5 to 3.5fps with ETA @ 2:42m so far. Which is a 30m increase..


SetMTMode(5,0)
DGDecode_Mpeg2Source("L:\Ep 01\VTS_01_1.d2v")
SetMTMode(2)


FieldHint(ovr="L:\Ep 01\VTS_01_1.d2v.fh.txt")

#MT("TempGaussMC_beta2().SelectEven()",threads=2,overlap=4)

TempGaussMC_beta2().SelectEven()

PresetClip0=Preset0()

PresetClip0.Trim(0,41023)

DClip = Decimate(cycle=5,quality=3,ovr="L:\Ep 01\VTS_01_1.d2v.dec.txt").assumefps(last.framerate)

Above the MT are LoadPlugin calls, an of course I left out the billion or so Trim/ Dclip.Trim statements

Setting the MT at the top of the file did no good, so I'm not sure if that is necesarry (I thought I read that somewhere). It gives only single thread performance with a few spikes up to 80 - 100% usage here and there. Whereas the script I have going now never drops out of the 90's (and I know its not a good guage, but high usage at least tells you its working, when its above 50).

Hopefully I'm doing it properly now, though.. and hopefully it won't error out on me since DGDecode is no longer being threaded erroneously.

Still, MT("filter",threads,overlap) seems to be faster.. I know the overlap isn't perfectly curing it, but you have to blow it up to %200 to even see a small trace of the merge halves and its not even a uniform line.. I could potentially live with that, and hell it might even be my eyes deceiving me and just be other noise.

I don't think its the threading overhead from UT Codec either, as I've been using it in all my tests since the crashing stopped.

Hoping it will ease up and pan out to no more than 2h:30m when all is said and done though.. but it's inching its up way to the 3hr mark for ETA :(

[osgZach]

Access Violation... again, heh..

Is this starting to look like a Mask/MV Tools issue ?

[kemuri-_9]

What does your avs build look for as the entry point for C Plugins?
A) avs x86 looks for avisynth_c_plugin_init[@4]
B) squid_80's avs x64 build technically looks for avisynth_c_plugin_init_s[@4] (minus the part where it doesn't actually have LoadCPlugin enabled)

was wondering if you altered this to be like squid_80's build or if you left it as is and are looking for the same thing the x86 version looks for.....

relevant as I'll need to know what entry point i need to define for my avs64 branch of ffms2. (that uses the avs C plugin interface)

[osgZach]

Updated FFT3DFilter now works properly. :)

Also, I tried Setting the mode back to 5 again, after I set it to 2 for TGMC, thinking maybe it was something past that causing it to goof up.

But if I do that, it never goes multi-threaded.

Can you not have more than two SetMtMode declarations in a script?

[kemuri-_9]

you need the final MT mode to be 0 < mode < 5 for avisynth to call distributor() automatically.
otherwise you could try adding Distributor() to the end of your script yourself if you want it threaded.

[osgZach]

0 < mode < 5


Sorry but I don't quite understand how that should read.

[JoshyD]

@kemuri-_9

No alteration to the loading of c plugins on my part, SEt hacked c-plugins to identify themselves as cache, I think. Take a look at the source to see if it gels with what you were expecting. I don't know if anything is different off-hand, nor even if it loads C-plugins correctly, as I haven't had any to try. I'm not sure if this makes a difference at all, but under x64 all function calls are fastcalls. I'm betting you already knew that . . .

[aegisofrime]

@JoshyD : I'm sorry if I wasn't clear. I tried the 64-bit stuff on my C2D notebook as I was afraid to break any stuff on my Phenom II right which is my main encoding rig. Now that I have gained confidence with it I will be trying it on that rig soon. It's currently encoding something now... So I will report back when I have tried.

With regards to avs2avi64, I assume you are talking about plain avs2avi instead? Because Googling for avs2avi64 gives your post as the only result. :D In any case, I tried your syntax, and as there was no option for "No Compression" I chose full frames (uncompressed) which gave me a Valid Compressor not chosen error. Perhaps my version of avs2avi is outdated, I'm going to poke around to see if I can find a newer one.

EDIT: I need to learn to read instructions more carefully. I missed the link which you provided in your first post!

EDIT2: I HAVE RESULTS!

32-bit : 28.02 fps
64-bit : 34.18 fps

I'm quite pleased!

Yet another edit (because I don't want to double post): Has anyone tried the 64-bit version of DGDecode at squid80's site? It gives me an unable to load DGDecode error, even though I have placed the required libmmd.dll file in the system32 folder :(

[kemuri-_9]

Sorry but I don't quite understand how that should read.

modes that are >0 and <5 (1 through 4 inclusive)

No alteration to the loading of c plugins on my part, SEt hacked c-plugins to identify themselves as cache, I think. Take a look at the source to see if it gels with what you were expecting. I don't know if anything is different off-hand, nor even if it loads C-plugins correctly, as I haven't had any to try. I'm not sure if this makes a difference at all, but under x64 all function calls are fastcalls. I'm betting you already knew that . . .

trying to load my ffms2 x64 C plugin causes avisynth to crash at startup.

i wrote a C++ plugin to add LoadCPlugin/Load_Stdcall_Plugin functionality (to use originally with Squid_80's build since he didn't include these functions in his though the entire C plugin framework was there and functioning).
and loading my ffms2 C plugin via this plugin has no issues and it works as intended.

you seem to have simply ported over the stack corruption checking that's supposed to check for the plugin being stdcall (and following that convention)
which you had already pointed out that win x64 does not follow this convention so what's going on here?

[turbojet]

JoshyD: The SSE2 build works. I don't think SSE2 is what AviSynth 2.60 is using during resize judging by these results

2.58-x86: 51.51
2.60a2-x86: 57.77
+12%

3-1-10-x64: 49.25
SSE2-x64: 51.07
+3%

If you plan on suggesting the SSE2 build for AMD CPU's for now you might want to link libiomp5md.dll if you can, it's not an easy dll to find.

[Gavino]

The differences between MT("function") and SetMTMode aren't very well documented.
See http://avisynth.org/mediawiki/MT_support_page, especially section 2.

[osgZach]

Well I've done some testing.. I think SetMTMode 3 stopped the crashing (and it was occuring not because of DG_decode, but because of either Decimate, or Trim).

However any suitable combination of MT Modes aside from a flat out Mode 2 blanketing the entire script - has worse performance than using what I did before with
MT("function",threads,overlap), we're talking almost no improvement over not using MT at all, or possibly worse.

So I guess I'm stuck with that.. in all honest I think its pretty darn good.. And not anything you would notice at sizes 100% or smaller if in fact there are any leftover artifacts from the split-join. It's worth it from my perspective I guess, as it seems to run without problems and cuts the time in half at least.

[JoshyD]

JoshyD: The SSE2 build works. I don't think SSE2 is what AviSynth 2.60 is using during resize judging by these results

2.58-x86: 51.51
2.60a2-x86: 57.77
+12%

3-1-10-x64: 49.25
SSE2-x64: 51.07
+3%

If you plan on suggesting the SSE2 build for AMD CPU's for now you might want to link libiomp5md.dll if you can, it's not an easy dll to find.

It isn't . . . it uses the same opcodes my resizers use, which is why I'm at a loss as to why my resizers cause your computer to error.

Avisynth 2.6 uses SSE3 as long as the FIR filter size is below 8, which is a pretty decent cutoff. Resizers that need larger filter sizes are normally pretty rare. TGMC beta 2 goes up to size 9 for my test vectors.

Also, my compiler settings shouldn't allow your Athlon down any Intel code paths. The intel specific code paths, from what I can gather by reading icc vs gcc posts, are only executed when an intel family processor is detected. Any of Intel's "special" code should look at your AMD processor, read the vendor ID, and send it down a generic code path.

Also, aegisofrime seems to indicate that he has it running on his Phenom II x4 in the post above. kemuri-_9's system specs indicate he's running a Phenom II x4 as well, and he hasn't voiced any resize specific problems as of yet. Your Athlon II is a stripped down phenom II core, I believe. I'm a bit baffled.

I usually link Open-MP statically, that SSE2 only build is really old and I probably omitted the compiler flag for it. It has to be manually entered, because Open-MP, when used by multiple plugins, will error if they're all statically linked. For this reason, I haven't built any of the plugins with Open-MP directives. EEDI2 in particular enjoys a massive speed gain if you let it run with multiple threads.

you seem to have simply ported over the stack corruption checking that's supposed to check for the plugin being stdcall (and following that convention)
which you had already pointed out that win x64 does not follow this convention so what's going on here?

You are correct, I didn't touch any of these routines, they'll definitely need to be changed. I hadn't even thought about loading C plugins with this dll until you expressed interest in getting a 64bit port of FFMS2 working. I was updating on an "as needed" basis, it's just a lot of code to sift through, I can't get it all in one shot. I grabbed the FFMS2 source, are you building it with MinGW? There's a MSVS project in the svn checkout, but even with C99 support, I'm missing some headers, and wanted to be consistent with your build environment, for testing/debugging and such. A compiled x64 dll would let me run through my source to tie any loose ends up, if you could either a) just link an x64 dll or b) fill me in on how you're compiling, I'd greatly appreciate it, and can get the avisynth core changed ASAP.

[kemuri-_9]

Also, aegisofrime seems to indicate that he has it running on his Phenom II x4 in the post above. kemuri-_9's system specs indicate he's running a Phenom II x4 as well, and he hasn't voiced any resize specific problems as of yet. Your Athlon II is a stripped down phenom II core, I believe. I'm a bit baffled.


I've been mostly sitting on the sidelines on this and not actively testing so don't pull me into any arguments as proof of something!
(I only got the binary and started working with it for trying the ffms2 plugin just yesterday!)
I have 3 pcs consisting of PhenomII x4, Phenom x4, and athlon64 x2 all running on x64 versions of windows, so i can do testing from the AMD side of things if the need arises....
(as i usually do this for x264 as the other x264 devs mostly use Intel and/or linux)

You are correct, I didn't touch any of these routines, they'll definitely need to be changed. I hadn't even thought about loading C plugins with this dll until you expressed interest in getting a 64bit port of FFMS2 working. I was updating on an "as needed" basis, it's just a lot of code to sift through, I can't get it all in one shot. I grabbed the FFMS2 source, are you building it with MinGW? There's a MSVS project in the svn checkout, but even with C99 support, I'm missing some headers, and wanted to be consistent with your build environment, for testing/debugging and such. A compiled x64 dll would let me run through my source to tie any loose ends up, if you could either a) just link an x64 dll or b) fill me in on how you're compiling, I'd greatly appreciate it, and can get the avisynth core changed ASAP.

yes, I'm building with MinGW completely as per the reasoning of http://doom10.org/index.php?topic=25.msg1730#msg1730
ffms2.dll: x64 testing binary (http://kemuri9.net/dev/avs/ffms2/x64/ffms2.dll)
aforementioned LoadCPlugin plugin: x64 binary (http://kemuri9.net/dev/avs/LoadCPlugin/LoadCPlugin.dll) src (http://kemuri9.net/dev/avs/LoadCPlugin/LoadCPlugin.zip)

[JoshyD]

@kemuri-_9
Being the king of AMD PC's that you are, would you mind pulling a quick vertical resize test on any source to see if it's broken across the board for AMD users? If you could pull the latest binary (I uploaded a new one today), it'd be helpful to see if something funny is happening on the AMD side of things. You'll need it to properly test ffms2 anyway :).

Giving a quick look at your loadCplugin vs the current one that checks stack corruption, I decided to just drop your LoadCPlugin function in as a replacement. As a result, I've got your ffms2.dll loading and the few tests I've run (various sources with some post processing effects, etc) have it running, with some oddities. Running a debug build of avisynth through through MSVS's debugger points to some code in ffms2.dll that is making illegal memory accesses. However, frames come through and appear correctly when running a release build of avisynth. There are no memory access violations thrown.

The oddity is that the 1st frame (frame 0) comes through as garbage. Moving around the source a bit, and then coming back to frame 0 has the frame rendering correctly. I figured I'd let you look it over, it may be my avisynth not initializing your plugin correctly. As you've probably gathered, I'm not too familiar with the plugin loading code of avisynth. My main focus has been on optimizing the calculation and memory heavy routines, which aren't usually hanging out in the core code.

Oh, and in case you needed to see what I was building: a quick snapshot of my source. (http://www.mediafire.com/?ziyxmmm1mji) The C plugin routines still check for/specify fastcall and stdcall in places, but icc ignores these types when compiling 64bit. I thought it would be safe to leave them in if nothing was breaking as a result.

It is very cool to have ffms2 working somewhat correctly though, it can't be far off from having full blown functionality.

[kemuri-_9]

@kemuri-_9
Being the king of AMD PC's that you are, would you mind pulling a quick vertical resize test on any source to see if it's broken across the board for AMD users? If you could pull the latest binary (I uploaded a new one today), it'd be helpful to see if something funny is happening on the AMD side of things. You'll need it to properly test ffms2 anyway :).

har har, i have SWScale to resize with instead!
but yes, trying something like Lanczos4Resize(Width(last),Height(last)*2) is throwing
"Avisynth Unknown exceptions" exceptions here on my phenomII and athlon64 machines with this new build.

Giving a quick look at your loadCplugin vs the current one that checks stack corruption, I decided to just drop your LoadCPlugin function in as a replacement. As a result, I've got your ffms2.dll loading and the few tests I've run (various sources with some post processing effects, etc) have it running, with some oddities. Running a debug build of avisynth through through MSVS's debugger points to some code in ffms2.dll that is making illegal memory accesses. However, frames come through and appear correctly when running a release build of avisynth. There are no memory access violations thrown.

The oddity is that the 1st frame (frame 0) comes through as garbage. Moving around the source a bit, and then coming back to frame 0 has the frame rendering correctly. I figured I'd let you look it over, it may be my avisynth not initializing your plugin correctly. As you've probably gathered, I'm not too familiar with the plugin loading code of avisynth. My main focus has been on optimizing the calculation and memory heavy routines, which aren't usually hanging out in the core code.

I'm not experiencing either of these, though i can't manage to compile the source code you provided (I do have ICL 11.1.051) due to missing convert_a64.asm to make a debug build

[aegisofrime]

JoshyD, sorry for any confusion but the tests were on my Core 2 Duo machine, not my Phenom II machine. I do intend to test it on my Phenom II rig after my current encoding run is completed.

[JoshyD]

kemuri-_9
Whoops, I keep a CVS server running for my own code, forgot to add it to the tree. Here it is on it's own. (http://www.mediafire.com/?ntzygjnyiyy) Here's the source again, just to be on the safe side. (http://www.mediafire.com/?myogqtnmzno)

If you can point me to the code making AMD processors so unhappy, I'd really really appreciate it.

[turbojet]

Thanks levi for pointing to a newer RePAL version that outputs 25fps. About a year ago I had a blended pal->ntsc dvd that repal didn't handle all that well and tried SRestore to find worse results but maybe SRestore has improved since then. I agree repal should be low priority considering the low percentage of pal->ntsc sources.

Another filter that I've started to use lately is autocrop (http://forum.doom9.org/showthread.php?t=87602) which would be nice for avisynth64 and required for x264 input imo without it you need to depend on external programs to get crop values. Maybe something like --autocrop:width(none = no resize):resizer(lanczos default):mod(default 16) some examples with a 1920x1080 2.35:1 source:
--autocrop:1280 = lanczosresize(1280,544,0,132,0,-132)
--autocrop:1920 = --autocrop = crop(0,132,0,-132) (this should undercrop to mod set, since it's still higher quality then resizing)
if the source is 1920x1080 1.78:1 --autocrop:1920 = 1920x1080 with no crop/resize (mod8 input with no crop/resize would always be mod8 output, same for mod4/2?)
though something like --crop and --resize would be helpful in cases where autocrop doesn't work (which I haven't ran into yet). I really don't understand the need for --cli-filter prefix however.

Thanks JoshyD for tivtc I'll try it on some sources next week.

[Stephen R. Savage]

I just tried the new plugins, and I can say that all of them passed a quick test without issues. However, I do have a question regarding the "threads" parameter to some of these filters. Does the threads parameter get ignored on your Avs64 build, JoshyD?

Now if only we had nnedi2 :(

[JoshyD]

Nope, they'll thread themselves independently of the main avisynth dll. It's a bit of a balancing act that the user has to do to make all processors stay busy, while not choking them with too many threads. NNEDI2 would be nice, but I don't think we're going to see that anytime soon.

For now, I really want to figure out why AMD processors can't run the resizers in current binary . . . it's has to be something really simple that I'm missing.

[mavinashbabu]

Hi,


thread title says x86_64 so can i assume that it works on 32 bit versions of avisynth as well. can anyone confirm please.

Thanks,

[aegisofrime]

Hi,


thread title says x86_64 so can i assume that it works on 32 bit versions of avisynth as well. can anyone confirm please.

Thanks,

Nope, it doesn't. You can't mix 64-bit filters with 32-bit filters, AFAIK.

[osgZach]

I did a clean download last night and grabbed everything again. To make sure I had all the recent updates.

Did a test last night.. Took 2h:37m. And no crash. LEt's hope it stays that way :p

The problem did not appear to be source access either, I think it was something like Trim or Decimate.. I'm guessing trim. I set Mode 3 after TGMC



LoadPlugin("C:\yatta\plugins64\decomb.dll")
LoadPlugin("C:\yatta\plugins64\dgdecode.dll")
LoadPlugin("C:\yatta\plugins64\telecidehints.dll")
LoadPlugin("C:\yatta\plugins64\fieldhint.dll")


function Preset0(clip c) {
#Name: Default
c
return last
}
SetMTMode(2,0)
DGDecode_Mpeg2Source("L:\Ep 01\VTS_01_1.d2v")



FieldHint(ovr="L:\Ep 01\VTS_01_1.d2v.fh.txt")

#MT("TempGaussMC_beta2().SelectEven()",threads=2,overlap=4)
TempGaussMC_beta2().SelectEven()
SetMTMode(3)

PresetClip0=Preset0()

PresetClip0.Trim(0,41023)


DClip = Decimate(cycle=5,quality=3,ovr="L:\Ep 01\VTS_01_1.d2v.dec.txt").assumefps(last.framerate)

[squid_80]

Are you perhaps confusing SSSE3 instructions with SSE3? I think you'll find the pmulhrsw instructions are the issue.

[levi]

Xeon quad core E5530 2.40 ghz w/ turbo(hyperthreading)

x264(x86) + set avisynth 2.6(x86)
First Pass Output to null = 27.18

x264(x64) + JoshyD avisynth 3-13-10(x64)
First Pass Output to null = 29.54

I've seen an 8% speed improvement


SetMTmode(3,3)
mpeg2source("my.d2v")
SetMTmode(2,3)
tdeint()
crop(4,4,1916,1076)
LanczosResize(1280,720)

[JoshyD]

@Squid_80
You've got it. It's pshufb that throws the first error on my (really old) Athlon64. Then, those pmulrhrw's probably cause an issue as well. Reading some programming message boards, apparently pshufb has been giving AMD developers trouble. I'd guess the subtleties between SSE3 and SSSE3 do as well. Back to the drawing board for AMD people. Thanks for taking a look, being the only eyes looking over your source can drive a person a bit crazy.

@levi
Why only 3 threads? Are you accounting for x264 also taking up some cores? I think x264's defaults to creating 1.5x the amount of threads it detects your system can run. I was hoping for some more speed gains. Any chance on seeing some straight single threading tests on the same system? I want to re-build tdeint to see if I can't eek out some more performance as well.

@osgZach
It's great that there aren't any crashes anymore! I don't think trimming frames from a source should kill multithreading, but decimate has an unusual access pattern. I guess you can't win them all.

[osgZach]

Crap keyboard.. lost my post to ill-place Forward/Backward keys...

Anyway. Its technically 2 different sources being mixed in, so whatever the case the problem probably lies somewhere in there, with one or both of them.. I know Mode 3 was recommended for Trim at the very least.

Any chance of grabbing the latest DGindex/decode source (1.5.8) and seeing if it will compile for x64? I'd give it a shot but if it needed changes I'd be clueless about that stuff..

It would certainly make managing Yatta a lot easier (right now I have to setup two copies, using older x86 source to make projects, since the x64 DLL we have is only 1.4.6).
If anyone that has time could look into it for that matter, it'd be great.

[squid_80]

I just had a look on my HDD and it seems at some point I did make an x64 build of DGDecode 1.5.4: http://www.mediafire.com/?dl4fc2yyyzz

It seems to work but I have no idea if it's faster than the old build or if anything apart from the .d2v identifier was changed. Too bad the author has no regard for backwards compatibility.

[noee]

FWIW, just did a test with an SD MPEG2 source, encoding with x264, using the 3/13 AVISynth64:

AVS:
#LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\DGDecode.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\tivtc.dll")
SetMTmode(2,8)
Mpeg2Source("lotr.d2v")
#Insert Deinterlacer
tfm(last,d2v="lotr.d2v").tdecimate()
#Applying Resizing
LanczosResize(720,352,0,62,-0,-66)

x264 v1471
64: x264-64bit.exe --crf 20 --preset medium --threads auto --tune film --sar 32:27 --output "C:\Temp\lotr64.mkv" lotr64.avs
32: x264.exe --crf 20 --preset medium --threads auto --tune film --sar 32:27 --output "C:\Temp\lotr.mkv" lotr.avs

64bit chain: encoded 16356 frames, 79.40 fps, 1345.89 kb/s
32bit chain: encoded 16356 frames, 70.57 fps, 1345.89 kb/s

Using Athlon II (620) O/C'd to 3.5Ghz
Win7 Ult x64

[osgZach]

Thanks Squid, I suppose its better than nothing :D

I don't have any issues with using old versions, as long as nothing major has changed since then.. But when I open the D2V files from two different versions and they look different it kind of makes me nervous I'm not getting the best indexing of my source.

[JoshyD]

@noee
I'm guessing this means that you've gotten tivtc with working results? If so, that's great news. Those results seem about in line with expected. Somewhere between 10-20% faster when using x64 code.

@Squid80
You've got a DGDecode listed on your webpage along with source, but checking the version info indicates it's 1.4.6. Any chance you have the 1.5.6 source on hand and I could take a peek at it? Also, may I add that to the first post?

@kemuri-_9
Can I link your FFMS2.dll on the first post? I can move it over to mediafire if you don't want to waste bandwidth on hosting it locally.

@turbojet
Autocrop is built and working for me. Link is on the first post.

[osgZach]

@noee

@Squid80
You've got a DGDecode listed on your webpage along with source, but checking the version info indicates it's 1.4.6. Any chance you have the 1.5.6 source on hand and I could take a peek at it? Also, may I add that to the first post?





DGIndex/Decode/VFAPI sources are all available at Neuron2's web site. Which was why I was surprised there were no newer x64 compiles..

http://neuron2.net/dgmpgdec/dgmpgdec.html

Also some other things we may not have can probably be found here.

http://www.neuron2.net/mine.html

[levi]

@levi
Why only 3 threads? Are you accounting for x264 also taking up some cores? I think x264's defaults to creating 1.5x the amount of threads it detects your system can run. I was hoping for some more speed gains. Any chance on seeing some straight single threading tests on the same system? I want to re-build tdeint to see if I can't eek out some more performance as well.

3 MT threads plus letting x264 do what it wants usually gives me the best performance.

I tested single threaded as you requested - it gives same 7-8% increase.

tdeint is pretty slow. As was mentioned, leakkerneldeint is a much faster one. I would much rather see you give that one a go vs. trying to get further performance gains with tdeint.

@Squid80
thanks for dgdecode 1.5.4 x64

[noee]

I'm guessing this means that you've gotten tivtc with working results? If so, that's great news.

Yes, I've reviewed the results and it appears to be correct. I'll run a couple of more tests a little later today.

[kemuri-_9]

@kemuri-_9
Can I link your FFMS2.dll on the first post? I can move it over to mediafire if you don't want to waste bandwidth on hosting it locally.

sure, you can post it in the first post and leave it how it is on referencing my website (i'm totally not concerned about the bandwidth for the server it's on)
I'll generally be updating it as bug reports come in, so it would be helpful for me to update it directly.

[JoshyD]

tdeint is pretty slow. As was mentioned, leakkerneldeint is a much faster one. I would much rather see you give that one a go vs. trying to get further performance gains with tdeint.


Did a quick and dirty port of LeakKernelDeint, link is on the main page. Nice to have it for use in avisynth64, but it's hardly speed limited to begin with. This version should be at least as fast as the 32bit plugin.

[levi]

Another note, this build has the same flaw as Set's previous builds - If I turn hyper-threading off in the bios (therefore only using my 4 xeon cores) the same test (with your 64bit build) gives 31 fps - which is another 5% faster & completely counter-intuitive. It's a mystery that was never solved.

----------------------------------------------------------

much better performance with LeakKernelDeint port.

Xeon quad core E5530 2.40 ghz w/ no hyperthreading

x264(x86) w/ 5 threads + set avisynth 2.6(x86)
First Pass Output to null = 57.4

x264(x64) w/ 5 threads + JoshyD avisynth 3-13-10(x64)
First Pass Output to null = 63.5

I've seen an 10% speed improvement


SetMTmode(3,2)
mpeg2source("my.d2v")
SetMTmode(2,2)
ord = last.getparity() ? 1 : 0
LeakKernelDeint(ord,sharp=true)
crop(4,4,1916,1076)

LanczosResize(1280,720)

[JoshyD]

Alright, I've gotten a DgDecode 1.5.8 built and running correctly on my system. It will only decode with SSE2 or SKALSSE algorithms for now, I'll work on getting the others back. Link is on the main page. It's not exactly x64 optimized, but at least it's the latest build.

[squid_80]

I'm not sure where the source code for my 1.5.4 build is. I didn't even know I had it.

The problem with DGDecode (the reason why I didn't compile new versions for x64) is that to get maximum speed, I found I had to hand compile some source files with ICC and others with VS - that's why I said it's possible the 1.5.4 build is slower than the older 1.4.8. Run some benchmarks if you want to check the difference. Also the source code only comes as a .zip file, there is no CVS/SVN/Git that allows for easy merging of files so updating it is tiresome.

[levi]

FYI - CelticDruid has some 64 bit - multithreaded xvid builds @ http://esby.free.fr/CelticDruid/mirror/XviD/

1.2.0 CVS (http://esby.free.fr/CelticDruid/mirror/XviD/XviD64-setup.exe)

1.3.0 CVS (http://esby.free.fr/CelticDruid/mirror/XviD/XviD64-setup.exe.1)

[MuLTiTaSK]

http://www.xvidvideo.ru/xvid-video-codec/

[levi]

http://www.xvidvideo.ru/xvid-video-codec/

Sweet, :thanks:

JoshyD

Think I found a bug...

LanczosResize(576,320) causes crash on Veedub64 open. LanczosResize(1280,720) works fine :eek:

[aegisofrime]

Thanks for the DGDecode JoshyD! Now all we need is nnedi2 and my DVD deinterlacing toolchain is complete...

JoshyD: I finally got around to testing it on my Phenom II rig. Upon starting the script with x264 I get this error:

http://img123.imageshack.us/img123/2696/67910090.jpg

Here's my script if it matters:

loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\DirectShowSource.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\EEDI2.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\MT.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\mt_masktools25.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\mvtools2.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\RemoveGrain.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\Repair.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\FFT3dGPU.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\DGDecode.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\VerticalCleaner.dll")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\TempGaussMC_beta2.avsi")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\LimitedSharpenFaster.avs")

SetMTMode(2,4)
DGDecode_mpeg2source("D:\Raws\Test.d2v")
/*TempGaussMC_Alpha3(2, 1, 1, EdiMode="EEDI2")
crop( 0, 0, 0, -2)
Spline36Resize(720,480)

Distributor()

MT("LSFMod()")*/

As you can see, I have commented out everything but the source filter, to isolate the source of the error. It still persists with this.

[osgZach]

I'm not sure where the source code for my 1.5.4 build is. I didn't even know I had it.

The problem with DGDecode (the reason why I didn't compile new versions for x64) is that to get maximum speed, I found I had to hand compile some source files with ICC and others with VS - that's why I said it's possible the 1.5.4 build is slower than the older 1.4.8. Run some benchmarks if you want to check the difference. Also the source code only comes as a .zip file, there is no CVS/SVN/Git that allows for easy merging of files so updating it is tiresome.

I definitely noticed a big difference in speed after switching to the newer one.. I haven't tried the 1.5.8 compile yet (because I use reference for iDCT) but Squid's original older version is a hell of a lot faster..

The same script actually runs SLOWER than single threaded 1.5.8 in 32 bit.. I thought I broke something on my system when I started seeing the clock go up to 4... 5 hours. But I had to go to bed so I just let it run and when I woke up later and checked on it, it had frozen after hitting the 6,000 frame range.

Which was weird, the program was NOT hard locked or anything, the status window was just frozen.. nothing updating, etc.. But abord worked and the program was responding, etc..

Kind of makes me feel bad for bugging you guys for a more updated build now that I see its going to take a lot of manual hands on work to get it running decently. That plus I have to throw out 37 d2v's from 1.5.8 to go down to 1.4.6 based build, then had to throw those out to go to 1.5.6 or w/e the newer one he did was. heh.. Of course the real time-killer is redoing the metrics off of them in Yatta.. that takes a good 10 minutes or so for each one I think.. adds up to a few hours or something like that.

Looking at the readme for the one hosted on Squid's page it seems like it only does iDCT through SSE2 also ? It didn't complain so I figured all the modes were there, but was just curious HOW important a difference there is between the various iDCT modes.. I always use references cause I figured why not, its fast enough and is supposed to be the most "accurate".. But I really don't know what iDCT is about either, so.. just wondering.

Update
I've been giving the 1.5.8 compile a try and it looks pretty solid from what I can tell. It seems to have about the same performance as the previous 1.4.6 based compile by Squid80. The ETA is pretty stable below the 3 hour mark (goes up and down, currently 2h:35m) and I used SSE2 32-bit on the iDCT. This is the same script I posted back as working / non crashing under the 1.4.6 based version, so hopefully this one won't crash either. Averaging about 3.5fps according to rough math estimates ( (8500 frames / 40m) / 60s ) FPS meter runs anywhere between 2 to 5 fps.

Very good performance I think.

[JoshyD]

@levi
I think there you did find a bug, I've done a quick fix for it, one I should have done a while ago. Can you try the latest DLL from the first post and see if that still crashes out? If so, some clip info may be in order so I can fix it properly.

@aegisofrime
One or more of those plugins was compiled with open mp enabled, and then statically linked. The error basically means more than one binary in your chain tried to initialize the library, which is discouraged. I don't think x264 uses OpenMP, I know my avisynth does in places, but the latest plugins shouldn't. Hence, there shouldn't be any errors. I've been known to be a bit inconsistent on my compile environments, but I thought I killed off open mp support in all the latest builds. I'll double check this, but could you get the latest build of each plugin as well to see if it still errors?

The option is out there to require the OpenMP dll be in your system32 directory, and then not statically link to it when building. I just haven't done this to reduce the headaches of installing another version of avisynth.

I'm guessing it'll throw errors on the resizing still, but that remains to be seen. I'm still working on an SSE3 only version of vertical resize function.

@osgZach
What's the final speed verdict on the 1.5.8 compile? Is it slower than the 32bit build? If that's the case, bummer. Squid80 mentions hand compiling the sources with different compilers, and that sounds gross. I'd like to avoid this, but I want DgDecode working as fast or faster in the 64bit environment.



To everyone and anyone:
A general question to those in the know about OSS, is everything I'm doing legal under the GPLv2? I've been kicking around the idea of hosting the source code somewhere (SourceForge, Google Code) and wanted to make sure this was alright with a) the community at large and b) the license under which Avisynth was released under.

I've also been wanting to set up a (poorly done) website somewhere for documentation and filter linking that doesn't rely on the main page of this thread. Additionally, I'd like to create a "swiss army knife" archive of the most useful plugins for single click downloading. Also, I think a real installer would be useful to many people, especially those hesitant that 64bit Avisynth will break 32bit Avisynth functionality.

Feedback, as always, is much appreciated.

[Stephen R. Savage]

You are technically in violation of GPL, since you do not host the modified AMD64-compatible source code (for the plugins) or provide a written offer for it.

[osgZach]

I haven't done exclusive testing of 32 vs 64-bit. However my guesstimation is that currently it should be at least as fast or very close.

I only started seeing these 2-1/2 hour encode times once I began using MT anyway. Under x32 it was 4h:45m and looked to be around 3-1/2 or 4h under x64 single threaded.

I know that's not a kosher analysis but you'll just have to trust me that at the very least, I find 1.5.8_x64 to be well within acceptable performance. It pretty much matches previous 1.4.6_x64 times so I think that's as good an indicator as any.


As for GPL issues.. Avisynths source code is freely available right? I think other modded editions have been let loose here too as well. As long as you provide the source and credits, release under GPL with your own updates, I don't think there should be an issue? Just got to get it taken care of. Currently I don't think anyone cares that much about technicalities, as you seem to have good intentions here. Just got to make sure future releases in an "official" type way that you follow the GPL rules.

I'm sure experienced members like the various utility authors here can help you understand any GPL questions and make sure everything is in order.

If you need hosting, I may be willing to donate some space and a pretty web page for you, and if the bandwidth is only a couple GB a month that should be fine.. If bandwidth becomes an issue you could just make a project on Sourceforge and keep everything distributed under there? Link to it from the pretty web page ;)

[JoshyD]

@Stephen
A written offer on the downloads page will suffice in lieu of packing up all the sources immediately and getting them hosted somewhere? Packing the sources for ~15 plugins isn't hard either, it's just a matter of linking them all somewhere, preferably not muddying up the first post.
Side note: some of the source is just plain embarrassing to have others look over. When I started porting, I couldn't write assembly AT ALL. I understood most of it, but comparing my earlier coding "style" (style=non-existant) to the macros and such I have now, there's significant difference. The more recent code at least looks halfway competent.

@osgZach
I may have to take you up on the offer of a pretty webpage! My mediafire download stats have the binary being downloaded just north of 500 times since I posted the original about a month ago. Granted, those are not all unique downloads, but at least there's been some interest in the port. I wonder if interest will continue? I don't see anything preventing me from merging x64 changes into 2.6 once it sees the light of day, either. At any rate, I'd like to generate better documentation, an installer, you know, kind of round out the port a bit. One step at a time, for now, GPL compliance, because, hey, open source software is pretty awesome.

[osgZach]

Cool.. I will try to find some time within the next day or two, to do a fast and dirty mockup for a prospective site for you.

500 downloads isn't much as it is.. I don't think I've ever broken 50gb of usage in a single month, with my magazine and other randomly downloaded stuff I host sometimes. So I don't anticipate a huge problem.

[squid_80]

Back when I started avisynth64, Wilbert and IanB set up a branch for me to use in avisynth's CVS on sourceforge. Unfortunately I never got very far for various reasons (sorry!). But maybe they would let you take it over if you asked them.

[JoshyD]

Could anyone with an AMD processor test this version of avisynth64 (http://www.mediafire.com/?ynzzjzqzitj) and let me know if the vertical resize functionality is restored?

[turbojet]

Could anyone with an AMD processor test this version of avisynth64 (http://www.mediafire.com/?oyzmikdgxu1) and let me know if the vertical resize functionality is restored?

It works. 57.46 fps on that same source from last week so it's right up there with 2.6-x86 with very fast x264 settings when resizing to 1280x720. When slower settings are used x64 is 10-15% faster also true when not resizing and using very fast settings.

Thanks for autocrop and leakkerneldeint 99% of the time avisynth64 will be my choice the only exception being repal but maybe mvtools with newer srestore will work in those cases.

It looks like x64 is by far the more popular windows 7 version according to steam (http://arstechnica.com/microsoft/news/2010/02/windows-7-eclipses-vista-on-steam-64-bit-dominating-32-bit.ars) so hopefully x64 encoding is here to stay. A few years ago when squid_80 was working on avisynth64 xp x64 was and still is incompatible with many applications, vista was disliked by many. Also there wasn't many x64 encoding applications, virtualdub64 I think was just coming along, no x264_x64. So let's hope for a better turnout this time. 64 bit directshow filters I think were non-existent then as well, except maybe ffdshow64 which doesn't do much good without a 64 bit splitter. Windows 8 is rumored to not be available in x86 but then again windows 7 had the same rumor.

[osgZach]

FYI

I got that weird lockup problem again.. It happened on the 3rd job in the queue. This time I at least got a message out of it.. It said something along the lines of "Something appears to be stuck (thread deadlock) while trying to abort" and asked me if I just wanted to kill everything.

I'm assuming it's not Vdub itself since the program was otherwise responsive and interact-able.

[noee]

Could anyone with an AMD processor test this version of avisynth64 (http://www.mediafire.com/?oyzmikdgxu1) and let me know if the vertical resize functionality is restored?

No joy here. Athlon II x4 620.

I get choppy, stuttery playback. I'm resizing (cropping) a FullHD source, here's the .AVS:

SetMTMode(2,4)
#Source File
directshowsource("c:\output\Law Abiding Citizen.mkv",audio=false)
last = isRGB(last) ? ConvertToYV12(last) : last
last = isYUY2(last) ? ConvertToYV12(last) : last
#SetMTMode(2,8)
#Spline36Resize(1920,800,0,140,-0,-140)
Lanczos4Resize(1280,528,0,140,-0,-140)
#RemoveGrain(mode=2)
trim(0,7500)
distributor()

[turbojet]

I can confirm noee's issue and isolated it to SetMTMode(2). It appears the frames are delivered out of order and some frames break up. However it doesn't happen in every scene. Modes 5 and 6 are working okay. Modes 1,3,4 freeze x264 with mpeg2source or directshowsource only.

Also modes 2 and 6 have randomly rebooted my machine which is like noee's an athlon X4 620@3.5 ghz. This might be caused by avisynth64 but I wouldn't rule out the multiple runs of ffdshow64, coreavc2 or dgdecode.

I don't use setmtmode or mt unless I'm doing heavy filtering which is almost never so I don't know if the reboots and freezes of certain modes are typical. With a 'light' script like noee's you lose about 50% of the speed with setmtmode/mt.

LeakKernelDeint works as expected but about 3% slower than x86
DGDecode 1.58 works okay too but is 10-15% slower for me then x86, optimized for intel only?
TIVTC and autocrop works okay and roughly the same speed as x86

[noee]

With the "AMD only" version, I can't even get an encode to run without using SetMTMode(). If I comment it out in the above script, the encode just sits there doing nothing. Every now and then x264.exe will pop 1-2% CPU, but it just sits there for hours doing nothing.

[osgZach]

*scratches head*.. This is really starting to throw me for a loop.

Despite my previous success reports. It appears optimizations on Dgdecode 1.5.8 are indeed going to be needed. I restarted my queue this morning and came home to find the same file still encoding. It was around 4:45m for completion, as if it were running a non-MT x32 setup. Despite the previous encodes only taking the average 2:40m or so..

The next file in the queue started and I was seeing 4 - 5 hour completion ETA.. I played around with the MT settings in the script and I still could not get it to go higher than 2.5 ~ FPS range. I regrabbed DG Index 1.4.6, re-indexed the same file, redid the yatta project, and set the script to the exact same settings. It started off in the 3 hour range but now it has dropped to currently 2h:40m range.. The FPS does go up and down, but in general seems to stay in the 3 - 4fps range.

So currently, it seems Dgdecode 1.4.6 is still the best optimized version to use ? I really need more corroboration on this one though. Can anyone else verify a performance gap through comparing multiple sources? I am prediction when this encode finished, it will have only taken about 2:45m or less. Or very close.

Core 2 Duo 2.13Ghz @ 3.2Ghz
8GB DDR2
Windows 7 x64

[JoshyD]

@noee
Bizarre on the needing to set the MT mode to get it to run. That really shouldn't be happening. I'll look at the code a while, and see if anything pops out as just plain "wrong." Though, you don't need to call distributor at the end of the script. It's automatically called internally when using a valid MT mode. Also, placing that trim command directly after the source is created will stop the MT mode of avisynth from beginning to render frames outside your region of interest.

@osgZach
Thread deadlock = not good. I think it's time to remove some parallelism from my build and see if I can kill off the deadlock condition.

Overall, at least there's some resize functionality restored, still not to the point I'd like to see it though. I'll continue to wade through the code to see if I can get a flawless version of all the crucial functions that works for everyone.

In the meantime, could either of you try this updated AMD compatible binary (http://www.mediafire.com/?zlxnjjgntny) to see if it alleviates some of your cache and thread woes?

@squid80
Any chance you remember the problem sources when compiling 1.5.6? I'm willing to do it by hand, a nudge in the right direction would do be much appreciated.

[osgZach]

Might want to go off 1.4.6 as that seems to be the best one, and I think Squid said 1.5.6 would likely have performance issues. I would think it better to start with the modified source of the faster performing version?

But that's just my uninformed opinion.. I have to go back to VB 2008 for Dummies now :p

[JoshyD]

@osgZach
Funny thing is, I started with the 1.4.6 source and used WinMerge to selectively merge in changes from the 1.5.8 source that shouldn't have effected x64 compatibility. DgDecode 1.5.8 isn't optimimized for a specific architecture, we could be seeing performance loss because some of the inline asm remains hard coded for best use with 32bith processors. This means we don't get to use any extra registers available to us and there are some idiosyncrasies that arise when writing x64 assembler. Some instructions take longer to complete because of internal handling by the processor. The often used


inc regA
or
dec regA


should almost always be replaced with


add regA, 1
or
sub regA, 1


Somewhere in the Intel docs it mentions that the register dec or inc operates on automatically gets promoted to it's 64bit version, meaning a 64bit add vs a 32 bit add. These instructions usually crop up in loop counting. Inc and dec were designed to not change certain conditional flags for easier conditional branching. However, using add or sub is faster for 32bit operations, and breaks some contingency conditions (or something, can't remember the right word) allowing the processor to better predict what code to fetch and decode next.

Short story, a quick and dirty port can slow you down, a well thought out and carefully coded port can see nice speed gains.

To all:
If the crashing from SetMTMode and thread deadlocking becomes solved, and the vertical resizers for AMD processors work without issue, I'm going to change the horizontal resize code to use the same concepts as the vertical resize code. Horizontal resize speed, believe it or not, is the slowest part of Avisynth (internally, not counting filters which eat way more processing time) when running TGMC beta2, by a factor of 3 or so, which is pretty substantial. Here's hoping for some good news about the latest builds.

[osgZach]

Ah, cool.. I know nothing about ASM Language so you already know more than I do :p

That encode under 1.4.6_x64 just finished. 2h:30m for a 22m:48s video. I guess for now I'll have to stick with 1.4.6 and hope the speed holds up for other sources (4 down, 33 to go).

[levi]

@levi
I think there you did find a bug, I've done a quick fix for it, one I should have done a while ago. Can you try the latest DLL from the first post and see if that still crashes out? If so, some clip info may be in order so I can fix it properly.



avisynth64_3-15-10.rar fixes the issue. :thanks:

[noee]

Okay, that last "AMD" version worked with the resize in my script, but only when I removed the SetMTMode() call. It appears that when I use SetMTMode(), the frame corruption occurs. I've run two test so far with Spline36 and Lanczos without SetMTMode() and they are good.

[levi]

Any chance for a tomsmocomp (http://avisynth.org/warpenterprises/files/tomsmocomp_25_dll_20030629.zip) port?

[Audionut]

With the latest builds I get an error with

mt("TempGaussMC_beta2()",threads=4)

http://img189.imageshack.us/img189/438/95216591.png

Removing the threads=4 works but then its not multi-threaded.
I had this working on a older build.

setmtmode, doesn't have any speed increases for me.

[VincAlastor]

great job! thanks a lot!
would someone make a dg nv tools x64 version, please? ...neuron2 hasn't a 64 bit os. that were very nice. a debanding function like gradfunkmirror, too :)

[osgZach]

I hate computers. I can't get stable performance numbers. lol.. Somebody please shoot me.. I think I better stay away from SetMTMode() until a lot of this gets straightened out.. Especially the thread deadlocks - that hits randomly too.

I really don't want to use MT either.. can't solve the overlap misalignments :mad:

Plus the more time I spend screwing with this, the less time I have to get JoshyD's hosting set up.. ;)

[squid_80]

great job! thanks a lot!
would someone make a dg nv tools x64 version, please? ...neuron2 hasn't a 64 bit os.

That's a bit hard to do without the source code (although not super hard, given the format is documented).

[osgZach]

I don't think DGNv is open source anyway. It's a pay-for product.

Although if a coder he trusts were to ask, maybe he could work with them to produce 64-bit compiles?

[hajj_3]

yeah its a pay app, i can't see neuron giving anyone the code to make a 64bit version as its too risky. It would be nice though. He said he has no 64bit O.S and that if he had 1 he might create 64bit versions of it so if anyone is rich feel free to pay for a copy of win7 pro x64 for him.

[Guest]

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.

[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

[osgZach]

Script:


LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\decomb.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\dgdecode.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\telecidehints.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\fieldhint.dll")



function Preset0(clip c) {
#Name: Default
c
return last
}

DGDecode_Mpeg2Source("L:\D-Note\Ep 01\episode 01.d2v")



FieldHint(ovr="L:\D-Note\Ep 01\episode 01.d2v.fh.txt")


MT("""TempGaussMC_beta2().SelectEven()""",overlap=12,threads=2)


PresetClip0=Preset0()

PresetClip0.Trim(0,41023)



DClip = Decimate(cycle=5,quality=3,ovr="L:\D-Note\Ep 01\episode 01.d2v.dec.txt").assumefps(last.framerate)

##removed a bunch of Trim + Dclip.Trim statements from this line


aWarpSharp2(64,12,type=1)
Crop(0,4,-4,0)
Spline36Resize(720,480)

[Stephen R. Savage]

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?

Yes, it is most certainly a bug. Likely, some of the lesser-used functions were not correctly converted to 64-bit code, and they were overlooked because nobody was using them.

[osgZach]

Hmm wonder if I just made an important discovery..

I didn't have the newest mt_masktools sitting in my plugins64 directory, however I did have TWO different versions of mt_masktools, 2.5/2.6 I am wondering if a) I should have had two in the first place.. and

b) what the difference is between your newest released version simply titled "mt_masktools".

I deleted the older versioned ones, and stuck the singular "mt_masktools" in the plugins64 directory, so far no weird errors or anything. Hmm

[osgZach]

New access violation, this time it was decomb I think (never seen it show up before, but mvtools/masktools is decidedly absent from the dump).
This was a test using SetMTModes w/Huffyv12. I threw in TelecideHints as well to see how much faster I can increase encoding time (if TGMC'd frames and returned progressives from TFM do not look substantially different) , will try an MT.DLL variant with it next.

I suspect the decomb reference to be coming from TelecideHints (but am unsure) but wanted to make sure this wasn't an actual bug, although I believe TelecideHints probably just doesn't like Mode2
For reference this occured on: The new Intel Build, new "mt_masktools.dll", DGDecode 1.4.whatever,

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

Disassembly:
7feef541360: 83c120 add ecx, 20h
7feef541363: 49 dec ecx
7feef541364: 83f820 cmp eax, 20h
7feef541367: 7db7 jge ef541320
7feef541369: 4c dec esp
7feef54136a: 8d15c0ecffff lea edx, [ffffecc0]
7feef541370: 49 dec ecx
7feef541371: 03d3 add edx, ebx
7feef541373: 49 dec ecx
7feef541374: 03c8 add ecx, eax
7feef541376: 49 dec ecx
7feef541377: 03d0 add edx, eax
7feef541379: 43 inc ebx
7feef54137a: ff24c2 jmp dword ptr [edx+eax*8]
7feef54137d: 666690 nop
7feef541380: 48 dec eax
7feef541381: 8d4940 lea ecx, [ecx+40h]
7feef541384: 48 dec eax
7feef541385: 8d5240 lea edx, [edx+40h]
7feef541388: 4d dec ebp
7feef541389: 8d40c0 lea eax, [eax-40h]
7feef54138c: 0f db 0fh
7feef54138d: 188280010000 sbb [edx+180], al
7feef541393: f30f6f42c0 movdqu xmm0, [edx-40h]
7feef541398: f30f6f4ad0 movdqu xmm1, [edx-30h]
7feef54139d: 49 dec ecx
7feef54139e: 83f840 cmp eax, 40h
7feef5413a1: 660fe741c0 movntdq [ecx-40h], xmm0
7feef5413a6: 660fe749d0 movntdq [ecx-30h], xmm1
7feef5413ab: f30f6f52e0 movdqu xmm2, [edx-20h]
7feef5413b0: f30f6f5af0 movdqu xmm3, [edx-10h]
7feef5413b5: 660fe751e0 movntdq [ecx-20h], xmm2
7feef5413ba: 660fe759f0 movntdq [ecx-10h], xmm3
7feef5413bf: 7dbf jge ef541380
7feef5413c1: 4c dec esp
7feef5413c2: 8d15b8010000 lea edx, [000001b8]
7feef5413c8: 4d dec ebp
7feef5413c9: 8bc8 mov ecx, eax
7feef5413cb: 49 dec ecx
7feef5413cc: c1e904 shr ecx, 04h
7feef5413cf: 49 dec ecx
7feef5413d0: c1e104 shl ecx, 04h
7feef5413d3: 49 dec ecx
7feef5413d4: 03c9 add ecx, ecx
7feef5413d6: 49 dec ecx
7feef5413d7: 03d1 add edx, ecx
7feef5413d9: 4d dec ebp
7feef5413da: 2bc1 sub eax, ecx
7feef5413dc: 49 dec ecx
7feef5413dd: c1e904 shr ecx, 04h
7feef5413e0: 0faef8 sfence
7feef5413e3: 43 inc ebx
7feef5413e4: ff24ca jmp dword ptr [edx+ecx*8]
7feef5413e7: 66666690 nop
7feef5413eb: 66666690 nop
7feef5413ef: 90 nop
7feef5413f0: 660f6f02 movdqa xmm0, [edx]
7feef5413f4: 660f6f4a10 movdqa xmm1, [edx+10h]
7feef5413f9: 660f7f01 movdqa [ecx], xmm0 <-- FAULT
7feef5413fd: 660f7f4910 movdqa [ecx+10h], xmm1
7feef541402: 4d dec ebp
7feef541403: 8d4080 lea eax, [eax-80h]
7feef541406: 660f6f5220 movdqa xmm2, [edx+20h]
7feef54140b: 660f6f5a30 movdqa xmm3, [edx+30h]
7feef541410: 660f7f5120 movdqa [ecx+20h], xmm2
7feef541415: 660f7f5930 movdqa [ecx+30h], xmm3
7feef54141a: 660f6f4240 movdqa xmm0, [edx+40h]
7feef54141f: 660f6f4a50 movdqa xmm1, [edx+50h]
7feef541424: 49 dec ecx
7feef541425: 81f8a8000000 cmp eax, 000000a8
7feef54142b: 660f7f4140 movdqa [ecx+40h], xmm0
7feef541430: 660f7f4950 movdqa [ecx+50h], xmm1
7feef541435: 660f6f5260 movdqa xmm2, [edx+60h]
7feef54143a: 660f6f5a70 movdqa xmm3, [edx+70h]
7feef54143f: 48 dec eax
7feef541440: 8d9280000000 lea edx, [edx+80]
7feef541446: 660f7f5160 movdqa [ecx+60h], xmm2
7feef54144b: 660f7f5970 movdqa [ecx+70h], xmm3
7feef541450: 48 dec eax
7feef541451: 8d8980000000 lea ecx, [ecx+80]
7feef541457: 7d97 jge ef5413f0
7feef541459: 4c dec esp
7feef54145a: 8d15d0ebffff lea edx, [ffffebd0]

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

Windows 6.1 (Windows Vista x64 build 7600) []

RAX = 0
RBX = 5c0
RCX = 0
RDX = 22b97920
RSI = 2d0
RDI = 5c0
RBP = 7feef6217e0
R8 = 2d0
R9 = 200000
R10 = 0
R11 = 7feef540030
R12 = f0
R13 = 0
R14 = 0
R15 = 22b97920
RSP = 14a6c058
RIP = 7feef5413f9
EFLAGS = 00010246


Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'Veedub64'...

...writing address 0000000000000000.

Pointer dumps:

RDX 22b97920: 10111010 10100f10 10100f0f 10101111 0f0f1012 0f101110 0e0f1010 0f11100e
RSP 14a6c058: ef381a0d 000007fe ef621c60 000007fe 445c93e0 00000000 445c93e0 00000000
14a6c078: ef3907c9 000007fe 22b97920 00000000 00000000 00000000 00000000 00000000
14a6c098: 00000001 00000000 22b97920 00000000 00000000 00000000 000005c0 00000000
14a6c0b8: 03091fca 00000000 445c942c 00000000 ef38fd89 000007fe 445c93e0 00000000
RBP 7feef6217e0: ef380af0 000007fe ef3866f0 000007fe ef3866a0 000007fe ef3865c0 000007fe
7feef621800: ef386510 000007fe ef48cb60 000007fe ef3858a0 000007fe ef3857a0 000007fe
7feef621820: ef383ce0 000007fe ef383910 000007fe ef383420 000007fe ef383260 000007fe
7feef621840: ef383190 000007fe ef383140 000007fe ef382a90 000007fe ef381a60 000007fe
R9 00200000: 25048d48 00000010 082524ff 90000000 40171300 00000001 4016b540 00000001
R11 7feef540030: ef540724 000007fe ef5407ff 000007fe ef5408e2 000007fe ef5409c7 000007fe
R15 22b97920: 10111010 10100f10 10100f0f 10101111 0f0f1012 0f101110 0e0f1010 0f11100e

Thread call stack:
7feef5413f9: avisynth!avs_at_exit [7feef370000+11c9c0+b4a39]
7feef381a0d: avisynth!avs_clip_get_error [7feef370000+10280+178d]
7feef38fd89: avisynth!avs_release_video_frame [7feef370000+1b530+4859]
03091b3d: fieldhint!00001b3d
76ab56c0: kernel32!lstrcmpi [76ab0000+5680+40]
7feef3835a0: avisynth!avs_clip_get_error [7feef370000+10280+3320]
7feef38cf09: avisynth!avs_release_video_frame [7feef370000+1b530+19d9]
7feef39007e: avisynth!avs_release_video_frame [7feef370000+1b530+4b4e]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
02ba138f: telecidehints!0000138f
7feef38156c: avisynth!avs_clip_get_error [7feef370000+10280+12ec]
7feef38e504: avisynth!avs_release_video_frame [7feef370000+1b530+2fd4]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
7fefcf918aa: KERNELBASE!ResetEvent [7fefcf90000+18a0+a]
7feef39007e: avisynth!avs_release_video_frame [7feef370000+1b530+4b4e]
76d1d1a8: ntdll!CsrAllocateMessagePointer [76cd0000+4cf80+228]
7fefcf910ac: KERNELBASE!WaitForSingleObjectEx [7fefcf90000+1010+9c]
7feef3e21b9: avisynth!DllGetClassObject [7feef370000+25d80+4c439]
76d1d0a2: ntdll!CsrAllocateMessagePointer [76cd0000+4cf80+122]
7feef38e504: avisynth!avs_release_video_frame [7feef370000+1b530+2fd4]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
7fefcf918aa: KERNELBASE!ResetEvent [7fefcf90000+18a0+a]
7feef39007e: avisynth!avs_release_video_frame [7feef370000+1b530+4b4e]
02b63f70: decomb!AvisynthPluginInit2 [02b60000+1000+2f70]
7feef38156c: avisynth!avs_clip_get_error [7feef370000+10280+12ec]
7feef38fd89: avisynth!avs_release_video_frame [7feef370000+1b530+4859]
02b618e2: decomb!AvisynthPluginInit2 [02b60000+1000+8e2]
7feef3835a0: avisynth!avs_clip_get_error [7feef370000+10280+3320]
76d1d238: ntdll!CsrAllocateMessagePointer [76cd0000+4cf80+2b8]
7feef38156c: avisynth!avs_clip_get_error [7feef370000+10280+12ec]
7feef38cf81: avisynth!avs_release_video_frame [7feef370000+1b530+1a51]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
02b617b8: decomb!AvisynthPluginInit2 [02b60000+1000+7b8]
7feef38e504: avisynth!avs_release_video_frame [7feef370000+1b530+2fd4]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
7fefcf918aa: KERNELBASE!ResetEvent [7fefcf90000+18a0+a]
7feef39007e: avisynth!avs_release_video_frame [7feef370000+1b530+4b4e]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
7feef3de282: avisynth!DllGetClassObject [7feef370000+25d80+48502]
7feef38e504: avisynth!avs_release_video_frame [7feef370000+1b530+2fd4]
76d21c58: ntdll!RtlAllocateHeap [76cd0000+51b70+e8]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
7fefcf918aa: KERNELBASE!ResetEvent [7fefcf90000+18a0+a]
7feef39007e: avisynth!avs_release_video_frame [7feef370000+1b530+4b4e]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
7feef3e21b9: avisynth!DllGetClassObject [7feef370000+25d80+4c439]
7feef526b0f: avisynth!avs_at_exit [7feef370000+11c9c0+9a14f]
7feef38e504: avisynth!avs_release_video_frame [7feef370000+1b530+2fd4]
7feef523a43: avisynth!avs_at_exit [7feef370000+11c9c0+97083]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
7fefcf918aa: KERNELBASE!ResetEvent [7fefcf90000+18a0+a]
7feef39007e: avisynth!avs_release_video_frame [7feef370000+1b530+4b4e]
7feef381688: avisynth!avs_clip_get_error [7feef370000+10280+1408]
7feef3e0c66: avisynth!DllGetClassObject [7feef370000+25d80+4aee6]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]
7feef3e0c50: avisynth!DllGetClassObject [7feef370000+25d80+4aed0]

-- End of report




LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\decomb.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\dgdecode.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\telecidehints.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\fieldhint.dll")



function Preset0(clip c) {
#Name: Default
c
return last
}
SetMTMode(5,0)
DGDecode_Mpeg2Source("L:\D-Note\Ep 01\episode 01.d2v")



FieldHint(ovr="L:\D-Note\Ep 01\episode 01.d2v.fh.txt")



SetMTMode(2)
TelecideHints(TempGaussMC_beta2().SelectEven())

PresetClip0=Preset0()

PresetClip0.Trim(0,41023)



DClip = Decimate(cycle=5,quality=3,ovr="L:\D-Note\Ep 01\episode 01.d2v.dec.txt").assumefps(last.framerate)

#and obligatory omitted Trim + Dclip.Trim statements.

[JoshyD]

@osgZach

The difference between the two plugins is actually the version of avisynth.h that they were compiled with. My version latest version definitely go changed to use my version of avisynth.h, I think the previous versions were built using avisynth 2.6's pre-release header that was packaged with the binary/source. The titling of the plugin to just "mt_masktools.dll" was just for simplicity. The 32 bit versions of 25 and 26 are meant for use with avs2.5 or avs2.6. That's about it, I think the last compile that you downloaded is solid, but let me know any problems that may arise. Try to keep only a single version of the plugin in the auto-load directory, I can't remember how avisynth does it's loading, but it's something along the lines of the last one loaded with the function name will be used.

Your new crash doesn't look like any code I've written . . . at least lately or extensively. It looks like a memory copy, maybe it is related to SetMTMode, keep me updated on the crashing.

@Stephen
What exactly is the problem with MVTools? The one labeled "64" plays back smoothly for me, whereas the other version labeled "32" displays some strange motion from frame to frame. Running it on my machine gives the same results, so, should the end result shouldn't be displaying a blurring of two frames to create the new frame rate?

Edit: I think I found the problem, it should be an easy fix.

@levi
I can LanczosResize just fine . . . but can you you Lancsoz4Resize? If so, then that's quite the strange problem.

[osgZach]

For the time being I'll stick with MT("filter") but will do tests on new releases of Avisynthx64 and MV/Masktools x64 releases from time to time and provide crash dumps each new version if that's OK with you. I just don't want to end up littering the thread with crash dumps that may be the same and nothing related to your work.

Huffyv12 seems just as fast as UT was and adaptive tables keeps the size very competitive so I'm going back to that now that I have access to it again. Hopefully it will provide some stability to the process as well.. I'll probably go back and recompare DGDecode 1.5.8 performance again as well.. If you can find time to reimplement the iDCT's that would be great I guess, but for now I'm using SSE2 with no problems.

I haven't done extensive testing with TIVTC as it pretty much crashed on me, but I don't recall why. Hopefully new versions will come along in the future though, with some improvements. Haven't forgot about the web site either, I started experimenting with a layout so the URL didn't 404 all the time ;) but I haven't had the time to do a proper sit down session and really work at it.

Also I recommend anyone stay away from UT codec until AVIsynth x64 and most plugins are stable. I think there may be stability issues, but I can definitely confirm, much to my expensive chagrin, that it is not suitable for lossless workfiles based on VFR. If you go back and re-encoding with other postprocessing (in my case after a lengthy TGMC IVTC) your VFR file will get screwed up for some reason. I ended up with 37 files that even when muxed with timecodes did not play back properly and had huge frame skipping / jerky playback issues. Huffyuv/yv12 seem to be safe based on a quick test I did, however, so ffdshowx64 is imperative for those doing lossless intermediate files under a pure x64 encoding chain.

I got my version from http://x264.nl - not sure if its the latest but I've been skeptical to install the Tryouts site version as it seems to be in perpetual "beta" state, or the wording is just in a way that scares me off maybe.

[squid_80]

A word of warning, virtualdub's x64 disassembler has some bugs and the code might not be accurate (as demonstrated by the supposed fault on a dec instruction).

[AlekseiV]

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.Pretty sure a 32-bit ffdshow will only interact with 32-bit players/whatevers, just how x64 only interacts with x64. I have them both running without any noticeable problems.

[levi]

@levi
I can LanczosResize just fine . . . but can you you Lancsoz4Resize? If so, then that's quite the strange problem.

I removed everything avisynth related & re-installed. Now the issue is gone. :confused:


I have another oddity:

When encoding with the 64 bit xvid_encraw from http://members.optusnet.com.au/squid_80/ I get inaccurate FPS reported (it's reported correctly @ 12fps with the 32 bit version):


xvid_encraw64.exe -imin 2 -imax 4 -pmin 2 -pmax 7 -bmin 2 -bmax 10 -bvhq -vhqmode 4 -qtype 0 -progress 300 -stats -i "my.avs" -pass1 "my.xvid.stats" -bitrate 1004 -threads 1



Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 512 x 384, 23.976fps (24000/1001), starting from frame 0
xvid [info]: Number of frames to encode: 124472, Bitrate = 1004kbps
xvid [info]: xvidcore build version: xvid-1.2.2
xvid [info]: Bitstream version: 1.2.2
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
xvid [info]: Detected 4 cpus, using 1 threads.
124201 frames( 99%) encoded, 310.56 fps , Average Bitrate = 1200kbps
Tot: enctime(ms) =400343.00, length(bytes) = 777934630
Avg: enctime(ms) = 3.22, fps = 310.92, length(bytes) = 6249, psnr y = 0.00,
psnr u = 0.00, psnr v = 0.00
I frames: 632 frames, size = 26343/16649129, quants = 2 / 2.00 / 2
P frames: 43223 frames, size = 13059/564455603, quants = 2 / 2.00 / 2
B frames: 80617 frames, size = 2441/196829898, quants = 4 / 4.00 / 4



It gets worse with the one from http://www.xvidvideo.ru/xvid-video-codec/xvid-1-2-2-x86-x64-stable-release-vaq.html

The xvidvideo.ru version cannot even detect the avisynth input information at all. The reported FPS is also inaccurate.

Any ideas on how to get the FPS reporting properly?

[aegisofrime]

JoshyD, just want to provide feedback for my libmio5 *something* thingie. Downloading your AMD build fixed it somehow :) Thanks for the great work!

[squid_80]

The xvidvideo.ru version cannot even detect the avisynth input information at all. The reported FPS is also inaccurate.

Any ideas on how to get the FPS reporting properly?

It's an xvid_encraw issue, it only reports the time taken to encode the frame rather than including the processing time taken to fetch the input frame. It was fixed in my 32-bit build but the source code is buried in storage.
The avisynth information was also something extra that I added to my build and is not part of the code from xvid's cvs.

[levi]

I'm sure you would have offered if you really wanted too, but I'll go ahead & ask... any chance you could dig up that source? :)

[osgZach]

After some further comparisons between DGdecode 1.4.6 & 1.5.8 I'm seeing 1.5.8 as falling between 10 - 20 minutes slower (averaing 12m - 16m slower). Is that consistent with other peoples findings?
Seems stable and everything, so that's good to know. Will probably stick with it despite the minor slowdown. Not sure how that quantifies into FPS but I'm guessing some kind of fraction of an FPS.

[MuLTiTaSK]

testers needed -> Zathor x64 MeGUI build (bit.ly/9EpprX)

[Delerue]

I have just tested x64 versions of Avisynth and MVTools with XP x64 and both worked flawlessly. MVTools had a great performance boost. Thanks a lot, JoshyD.

[Stephen R. Savage]

Any luck with that GradFun2DB? It's the last plugin holding be back from using Avs64 as my main encoding platform.

[osgZach]

I haven't tested it with option calls, but I have invoked it without error just to see if it would load.

http://www.mediafire.com/?gogdnjtzinf

If you didn't notice it on the first page.

[turbojet]

I decided to make an install script for both amd/intel (http://www.mediafire.com/?mmo2dz3ozmx) since I'm now using it on both platforms and got sick and tired of keeping track of 2 dll's. Just thought I'd post it unless anyone else was in the same situation.

Edit: Also with resizing to anything I'm getting this error in x264 r1510:

x264 [warning]: non-strictly-monotonic pts at frame 1 (0 <= 0)
x264 [warning]: non-strictly-monotonic pts at frame 2 (0 <= 1)
x264 [warning]: non-strictly-monotonic pts at frame 3 (0 <= 2)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones

There is no error when not resizing or with avisynth 2.6 resizing.

[VincAlastor]

thanks a lot for gradfun2db x64!!! now i just have to wait for a x64 version of dg nv tools :-)
thank you guys for your hard work

[JoshyD]

@turbojet
I'm not really sure what that error means . . . I'm aware of monotonic functions in mathematics, but how this relates to x264 and video compression, I'm not really sure. I get the same error, I think I may have to pop over to doom10 and ask there, if you haven't already. I'll comb through the source and see if I can find what generates the error in the first place. With older builds of x264, no complaints, so this is must be a new error. Unfortunately, most of the code for the project currently is 64bit specific, so I can't build a 32bit version of my source to test against.

For me, the resulting video file is all sorts of bizarre as well. The frame rate doesn't appear to be written to the file correctly, the encoder does it's thing reporting the correct rate, the resulting file has the correct fps info, but playback is sporadic and looks like it's ~2x faster than what it should be. Older builds produce correct results.

I've got a test release that I want to get out today that should be platform agnostic, so you don't have to worry about managing two dll's. Sorry it took so long to finally get around to it.

@Stephen
As far as the GradFun2DB issues, I haven't gotten a chance to sort it out, but I'll take a look at it today.

Edit: Glaring code mistake on my part, fixed it up, and it now produces the same output as the 32bit version. Try it out and let me know if there are still any issues.

[Mr VacBob]

It means that input frame timestamps aren't strictly increasing (in monotonic order). This can be caused by, well, nearly any kind of bug in the x264 input module being used - in this case it looks like the input pts is always 0.

You can fix it with some combination of --force-cfr and --fps, but I forget how that works.

Speaking of x264, it would be nice if you adopted the ISC-license yasm system it uses for i386/x86-64/win64 asm, it's all portable and stuff.

[Stephen R. Savage]

Thanks for updating GradFun2DB. I hope that you can get the remaining IDCTs in DGDecode sorted out, but with this, I can finally start encoding in 64-bit.

Edit: I know this is really "asking the impossible," but could you think of any way to allow calling 32-bit plugins within a 64-bit Avisynth instance? It doesn't have to be efficient or even elegant. Even just internally spawning an Avs32 instance and copying frames from it would be acceptable. The reason I ask is that working without nnedi2 is just a massive drag.

I was thinking something like this hack would work, if not too many 32-bit plugins were used, and they were called infrequently:


Load32Plugin() opens a win32 DLL and scans it for Avs32 functions.
Whenever a function associated with a 32-bit DLL is called, export the script environment referenced by the call to shared memory. This would include clips and the value of variables.
An Avs32 instance is created in another process. This process loads a helper ImportFrom64() source that reads the variables exported by Avs64.
The 32-bit subprocess has the function ExportEnvironment() which somehow transfers variables and clips to shared memory.
Avs64 reads the data exported by Avs32 and updates the script environment.

Another idea:

Implement the function Eval32() that runs one command in an Avs32 environment and reads the value of "last" back. The last clip would be exported via shared memory, as well as any other clips and variables the user specifies.

Would the overhead from these suggestions be unacceptable?


I am thinking of one specific usage case for this:

You want to use TGMC with nnedi2. You posit that if the 32-to-64 memory transfer can occur fast enough, the performance benefits of using 64-bit mvtools outweigh the overhead of the memory copy.

I know that something similar is currently implemented with TCPSource/TCPDeliver (although it is not implemented in current Avs64), but it is not transparent to the script.

[kemuri-_9]

Edit: I know this is really "asking the impossible," but could you think of any way to allow calling 32-bit plugins within a 64-bit Avisynth instance? It doesn't have to be efficient or even elegant. Even just internally spawning an Avs32 instance and copying frames from it would be acceptable. The reason I ask is that working without nnedi2 is just a massive drag.

the best you'll get is TCPDeliver

[Stephen R. Savage]

the best you'll get is TCPDeliver

I know of TCPDeliver, but a fatal flaw is that you can not call it more than once, nor can you use it in combination with TCPSource to shuffle data. It also requires the user to manually load any external scripts.

[kemuri-_9]

I know of TCPDeliver, but a fatal flaw is that you can not call it more than once, nor can you use it in combination with TCPSource to shuffle data. It also requires the user to manually load any external scripts.

Script A (x64)
...
TCPDeliver


Script B (x86)
TCPSource
...
TCPDeliver


Script C (x64)
TCPSource
....

-> x264 x64

to do something like you're wanting this would be more reliable to be done as a plugin that spawns avs x86 a seperate process in some fashion to pipe data to and from it in some fashion.
by no means is this a small or clean task.

[turbojet]

@turbojet
I'm not really sure what that error means . . . I'm aware of monotonic functions in mathematics, but how this relates to x264 and video compression, I'm not really sure. I get the same error, I think I may have to pop over to doom10 and ask there, if you haven't already. I'll comb through the source and see if I can find what generates the error in the first place. With older builds of x264, no complaints, so this is must be a new error. Unfortunately, most of the code for the project currently is 64bit specific, so I can't build a 32bit version of my source to test against.

For me, the resulting video file is all sorts of bizarre as well. The frame rate doesn't appear to be written to the file correctly, the encoder does it's thing reporting the correct rate, the resulting file has the correct fps info, but playback is sporadic and looks like it's ~2x faster than what it should be. Older builds produce correct results.

After further investigation it wasn't just any resize that gives the warning. 1280x712, 640x360, 1920x720 didn't have the warning but these did: 1280x720, 1280x728, 1280x1080, 1280x960, 960x720. I tried the SSE dll you had amd users try a few weeks ago and I couldn't reproduce the warning. I'm not getting playback issues with MPC-HC with DXVA, ffdshow, or coreavc but I've only tried <10000 frame clips.

I've got a test release that I want to get out today that should be platform agnostic, so you don't have to worry about managing two dll's. Sorry it took so long to finally get around to it.

No rush, it only took me 5 minutes to add the 2 lines, so no harm.

Just out of curiosity was porting x86 to x64 avisynth tedious and/or difficult for someone who has never ported? I'm asking because I've been contemplating trying it out with 2.60 because I'd like to get back the performance lost in the MT hack. Official 2.58 build is about 8% faster then set's 2.58 MT build with my light scripts that include only crop, resize, ivtc, fast deinterlacing.

[squid_80]

I know this is really "asking the impossible," but could you think of any way to allow calling 32-bit plugins within a 64-bit Avisynth instance? It doesn't have to be efficient or even elegant. Even just internally spawning an Avs32 instance and copying frames from it would be acceptable. The reason I ask is that working without nnedi2 is just a massive drag.

I was thinking something like this hack would work, if not too many 32-bit plugins were used, and they were called infrequently:


Load32Plugin() opens a win32 DLL and scans it for Avs32 functions.
Whenever a function associated with a 32-bit DLL is called, export the script environment referenced by the call to shared memory. This would include clips and the value of variables.
An Avs32 instance is created in another process. This process loads a helper ImportFrom64() source that reads the variables exported by Avs64.
The 32-bit subprocess has the function ExportEnvironment() which somehow transfers variables and clips to shared memory.
Avs64 reads the data exported by Avs32 and updates the script environment.

Another idea:

Implement the function Eval32() that runs one command in an Avs32 environment and reads the value of "last" back. The last clip would be exported via shared memory, as well as any other clips and variables the user specifies.

Would the overhead from these suggestions be unacceptable?


I did attempt this, the overhead was minimal since the filters could blit frames directly into the shared memory regions. But the major issues were handling audio as well as video, and exporting multiple clips for input to a single proxy function.

[osgZach]

Personally I'm of the opinion audio support is not a necessity. There are a million ways to get your audio into the final clip. If supporting video only makes the last problem that much easier to handle, I say go for it. It's not the end of the world, right?

[JoshyD]

Just out of curiosity was porting x86 to x64 avisynth tedious and/or difficult for someone who has never ported? I'm asking because I've been contemplating trying it out with 2.60 because I'd like to get back the performance lost in the MT hack. Official 2.58 build is about 8% faster then set's 2.58 MT build with my light scripts that include only crop, resize, ivtc, fast deinterlacing.

Tedious, yes. Difficult, depends.

Tedious because the actual code base is quite large, and some parts of it have been hanging around for quite some time. For example, _control87() is used in one of the init functions for scripts. 64bit apps don't want you changing the fp state and such. Then, there's any parts of the code that rely on pointers being the same size as integers. This get's sticky at times. I remember missing a few instances when some assembly was indexing an array of pointers. They're not in 4 byte chunks anymore . . . that's an easy one to miss at first glance.

The resizing code actually lucks out that memory created local to a function will never have an address >32bits. The resize code stores address offsets in an array of integers, along with coefficients for the corresponding address. If the address were larger than an integer, it would have never worked out under x64.

The most difficult part for me was just learning assembly, and more specifically 64bit function calling and returning (where's my data and why did the calling function write 32bits of it, but allocate 64?). There's inline assembler littered throughout the source, and the resize functions use snazzy dynamically compiled assembly. To be competitive in this aspect, I statically generated most cases that would arise when dynamic code was going to be used. To ease in the static generation, you'll need to learn the ins and outs of writing macros and such to easily create x functions from one piece of code.

Then there are instances where you're going to have to pay special attention if a negative value is ever used. If you want to manipulate an address using a negative offset, you have to make sure to sign extend it first. There's a decent number of quirks that tripped me up on the first pass through.

Also, seriously, if you want to port the whole code base, set up some sort of version control. My first attempt was totally scrapped, then I set up a cvs server on my own machine, and it has since really cut down on the amount of time spent searching for the crazy little syntax change I forgot about.

A note on the inline assembler, you'll need Intel's compiler to even think about compiling the source without re-writing all the inline assembler in their own modules.

With some decent C++ background and some understanding of computer organization, it wouldn't be all too difficult to port the 2.6 code as well. I was actually considering doing this one of these days. The majority of the code has been merged into the head branch of the project, and I've been building it for a while. I'm going to hazard a guess that it's close to being stable. If you've got some free time, I've got a google code project setup finally, we could start a 2.6 branch there. If you prefer working on it on your own, the source is all there, and it's a decent starting point for converting 2.6. I guess just let me know.

[osgZach]

Teaming up is always nice I say. Delegate out the easy stuff to the n00b and then work on the hard stuff yourself, you'll be done in no-time ;)

Always nice to be working off stable code too.. So I'd say at least wait for an official release before releasing a x64 port to the public, though.

[squid_80]

The resizing code actually lucks out that memory created local to a function will never have an address >32bits. The resize code stores address offsets in an array of integers, along with coefficients for the corresponding address. If the address were larger than an integer, it would have never worked out under x64.


Please tell me you didn't leave the code like this. If you did, you're setting up an inevitable point of failure. Avisynth is a library and should not make *any* assumptions about the location of the stack.

[turbojet]

The porting sounds beyond my knowledge. I was thinking it was just translating certain calls but it sounds like new code has to be produced. The only code I've ever produced in c++ is calling a couple external programs.

Ideally what I'd want to happen at some point is avisynth being a multiple installer that if windows 64 is found both 32 and 64 bit are installed/registered otherwise only 32 bit avisynth. Like haali and coreavc currently do. That requires JoshyD to work with IanB, Wilbert, etc. They might welcome a 64 bit 'translator' have you consider contacting them about it? Or would you rather avisynth64 stay a separate project?

Concerning avisynth alpha versions, while their probably is bugs introduced from the last release version. From my experiences since 2.08 is there usually many more bugs fixed then introduced in the alphas. After browsing the thread I see only one known outstanding bug (mpeg2source(cpu=1+)) while many bugs have been fixed from 2.58.

[Poutnik]

Are there plans for porting DCTFilter to x64 ?
I was told plugins needed for MCTemporalDenoise by LaTo were ported,
but I noticed DCTFilter required by Didée's Deblock QED was not.

Didée's post in MCTemporalDenoise [v1.4.08 - Update 2010/01/30] thread (http://forum.doom9.org/showthread.php?p=1387595#post1387595)

Edit: BTW, with deblock=false, GPU=true and for testing commented out all SetMTmode commands,
I was able to load MCTD calling script, but Vdub64 crashed after few frames.
( latest 64b avisynth and plugings on MAR 30th, Vdub 1.9.8 stable )

IsInterlaced = false
mpeg2deblock = 0
AudioDub(DGDecode_mpeg2source("D2Vfile", info=3, cpu=(mpeg2deblock==1)? 4:0), wavsource("wavfile")).ColorMatrix(d2v="D2Vfile",interlaced=IsInterlaced, threads=0)
MCTemporalDenoise(sigma=5,settings="low",GPU=true,Deblock=false)

No particular crash info, usedto see at VDub, maybe later.
Edit2" avs2avi 64bit lasts longer, but not much.

[Andrey /MAG/]

@JoshyD
Thank you for last build of 64-bit MVTools2 (29 march).
But the results of my script are still differ from results of 32-bit build: new frames are still blended, not motion compensated. See details in http://www.sendspace.com/file/4u8s0t
How can I get the same results?
When the source code will be accessible?

[osgZach]

Not sure where the problem is exactly.. But I got the updated Avisynthx64, EEDI2, and Mvtools

Opened an AVS and started to encode and immediately got an Avisynth read error, Vdubx64 subsequently decided to crash whenever closing an AVS file.

I reverted Avisynth to 3-19 Intel build.. that seemed to stop the crashing on closing an AVS in Vdub..

Then I reverted to the older mvtools2, seems the newer one was causing the read errors.

[JoshyD]

@squid_80
Addresses local to your program can never be more than 32bit offsets relative to the instruction pointer. This is due to the implementation of x86-64. It is possible for a process to access the full 64 bit address space, but this is generally done by a process running at the kernel level, using special instructions. AMD docs refer to these as SIB memory accesses. The memory reference starts at 0 and works up computing the address with scale and index bits from the instruction. The virtual address space is currently limited to 48bits because of the original implementation of the Athlon64. Furthermore, because this is a Windows program, a single process cannot "see" memory beyond 32bit addresses, unless allocating memory with VirtualAlloc() or its sibling functions (Windows specific, non C standard allocation functions, and we're tethered to Windows inherently because of vfw reliance). The PE32+ specs are sketchy at best, MS claims that the HEAP RESERVE and HEAP COMMIT fields have been widened beyond 32bits. MS docs list these as just "widened," but not to any specific bit length. Compilers still write these values in 32bit lengths. Basically, if your program is not the OS, good luck getting into addresses that are beyond a 32bit value from your instruction pointer. All of your physical data references will be 32bits, and translated by the OS to a virtual address. Instruction data does hang out in the upper address space, though. Windows specifically loads 64 bit executables at addresses beyond what a 32bit process can use (>4GB). Anyhow, my point is, for the foreseeable future, writing the memory offset into an int array won't cause massive failures.

@Poutnik
You are one step ahead of me there. I've been wanting to test that script out, but haven't had the time. My quick response is that I've already found some silly bugs in my release yesterday, and should have a quick fix out soon (today-ish).

My longer response is I'll get around to porting DCTFilter, and then test the script well, as it's one that I personally have had great use for. With a little time, I should be able to get it running well.

@Andrey /MAG/
I did look at this quirk briefly, and think I found the source of the problem, but didn't have time to properly fix it. An older version of my source is available here, (http://www.mediafire.com/?yuzzwy3m1y1) as well as buried somewhere in the first post. The changes between that source and the current build don't relate to your blending bug, I've only really changed the memory copy routines, x264 functions ported directly from the x264 repository, and removed CPU checking for mmx/sse. I'll get the current source online so you can browse at your leisure. Which reminds me . . .

@osg_Zach
Any updates on getting a quick web page up? Something to just link the plugins/sources would be useful now that there's some interest in seeing them. The first post of this thread can only get so long ;). And finally,

@Turbojet
I haven't really considered contacting them, I wouldn't mind translating the project officially. I think it does require an official branch, though. There are so many #ifndef _AMD64_ instances in my source, that I eventually gave up on trying to compile my source both 32bit and 64bit for error checking. I'm also guessing that they'd want to see a final source that can be compiled by anyone, not just those with the Intel's C++ compiler, which means dismantling some functions that rely on inline assembler (look at the yv12 conversion routines, yikes!).

I was also afraid of coming to them with my source looking as unpolished as it is. It really does look terrible in some places. When I began the port, I wanted to get a working binary ASAP, which meant bad hack and slash coding on many occasions. If I can get the time to polish it up so it doesn't look like I was coding-impaired, I'll see what they think. Sidenote: Remember that Jeremy Duncan character? A lot of people thought I was him when I originally posted my work. I hope I'm not still carrying that stigma around . . . with the number of *working* plugin ports I've done, (aWarpSharp, MaskTools, and MVTools2 (working except for the blended frame issue) were all fairly complex ports) I hope I'm the real me in most people's opinions.


WARNING
The 3/29/2010 posted binaries for EEDI2, MVTools, and Avisynth64 are *not* stable. Fixed and linked on the first post.

[osgZach]

Responded to your PM. I have been dragging my feet on the web site thing, so I apologize for that. I had a tiring work weekend, and am working my second job Mon - Fri this week, plus helping my first job on Fri after that. So just been sleeping and diddling around..

I am looking into some ideas right now. I want to try and see what I can do with Word Press or another simple blog like that, so you can have a simple posting based site (and FTP access to upload/update Builds and Plugins). This way I don't have to worry about keeping the site up to date, and you don't get stressed that I haven't updated it ;)

The most you'd have to learn is how to login, make posts, and write a hyperlink to a file (assuming there isn't an easy button for that in wordpress), and update said hyperlink..

[squid_80]

@squid_80
Addresses local to your program can never be more than 32bit offsets relative to the instruction pointer. This is due to the implementation of x86-64. It is possible for a process to access the full 64 bit address space, but this is generally done by a process running at the kernel level, using special instructions. AMD docs refer to these as SIB memory accesses. The memory reference starts at 0 and works up computing the address with scale and index bits from the instruction. The virtual address space is currently limited to 48bits because of the original implementation of the Athlon64. Furthermore, because this is a Windows program, a single process cannot "see" memory beyond 32bit addresses, unless allocating memory with VirtualAlloc() or its sibling functions (Windows specific, non C standard allocation functions, and we're tethered to Windows inherently because of vfw reliance). The PE32+ specs are sketchy at best, MS claims that the HEAP RESERVE and HEAP COMMIT fields have been widened beyond 32bits. MS docs list these as just "widened," but not to any specific bit length. Compilers still write these values in 32bit lengths. Basically, if your program is not the OS, good luck getting into addresses that are beyond a 32bit value from your instruction pointer. All of your physical data references will be 32bits, and translated by the OS to a virtual address. Instruction data does hang out in the upper address space, though. Windows specifically loads 64 bit executables at addresses beyond what a 32bit process can use (>4GB). Anyhow, my point is, for the foreseeable future, writing the memory offset into an int array won't cause massive failures.


I'm not buying it. It's true that static data is accessed using 32-bit relative offsets, but you're not talking about static data. If ALL memory accesses were restriced to 32-bit offsets you would instantly get failures, since the kernel functions live at the top of memory and by default programs are at the bottom. DLLs like avisynth can be anywhere in the middle, depending on what their base address is set to (and in later OSes the base address is effectively ignored if ASR is used).

64-bit processes most certainly can see beyond 32-bit addresses, you can use a stack up there or you can change the default behaviour of windows to start dynamic allocation from the top instead of the bottom(HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference). Avisynth is already susceptible to getting memory allocated above 4GB due to the way it uses excess memory for caching.
If you want this code to be fully 64-bit compatible, it must treat addresses as 64-bits. Anything else is a time bomb.

[Poutnik]

MCTD stability in Vdub or AVS2AVI with AVS / EEDI2/ MVtools updates from 31/3 is lets say 30 % better :-) Tried both GPU=true/false

[Poutnik]

I performed AVS2AVI benchmark of avs containing basically just SetMTmode(2) and Mpeg2source.
Old AVS 32 MT 2.57.5 gives 180 FPS
New AVS 64 MT 2.5.8 (from 31/5, DGdecode v1.5.8) shows just 80 FPS, so less than 50%.
But it could be due mentioned some missing idct algos. ( used default )

Setmemorymax was set for both to 768, but changing it does not have big impact.

[turbojet]

It's only about a 5% speed decrease here using x264 but I also see about 3% decrease with 2.58 over mt 2.57. I didn't use avs2avi because many builds spit out exotic fps numbers, only squid_80's x86 builds give proper fps. I do notice the latest mt x64 build is using 2 theads per core if setmtmode is set to auto detect which could hurt performance.

That said avisynth MT is mostly placebo and in most cases it slows the script down significantly, like it does in this case. Even using an mt avisynth.dll slows you down. SetMTmode() and MT() are useful with heavy filters but even then it's usually not significantly faster then non-mt avisynth. I'm crossing my fingers a non-mt avisynth 2.60 comes out then everyone can start seeing the 15-20% speed increase like what we see with this build over 2.58 mt. However currently this avisynth is lucky to get a 5% speed increase over 2.60 and sometimes it's slower. 2.57 x64 is often a little faster then this build except not when resizing. In conclusion, 2.58 mt seems to be the slowest avisynth build among 2.57 - 2.60 in my tests.

It's looking like avisynth devs have been considering adding MT for some time but in a much more efficient way, hopefully it won't slow it down.

JoshyD: Have you come across anything that might be causing the x264 pts warning when resizing to certain resolutions? I haven't seen any weird playback issues but concerned that you did and have reverted back to using older x64 builds that don't have the warning. Also I hope you don't take my above comments disgcouragingly, I greatly appreciate you taking on avisynth x64. Just after a little testing with various builds I was disappointed in the performance decrease of avisynth mt, even with ivtc, deinterlacing, denoising, nothing real heavy though. But specifically 2.58 mt which is the slowest and happens to be what you built off of.

[osgZach]

MT is placebo? Tell that to my cut-in-half encode times.

It's one thing to say there are instances where it may not be the best performing option, and others where it really helps increase performance, but you can't have it both ways.

[turbojet]

What I mean is mostly placebo is people see multithreading avisynth and assume it's faster but in most cases it's actually slower. I don't know of a gui that makes use of it, it's not a complicated addition but it slows down all the functions they provide.

The assumption isn't necessarily wrong because almost all multithreaded programs have significant performance increase over their single threaded counterpart.

By cutting encoding time in half you must be using some very heavy filters, what exactly are you using?

[levi]

In my testing, I have found that performance can vary greatly depending on:

The complexity of the script
Using MT vs. not using MT
Using setmtmode properly
Choosing the number of setmtmode / MT threads (I have never had good luck with threads=0)
Choosing the number of encoder threads (I have never had good luck with threads=0)

I keep a log of my fastest script & threading combinations.

I have also seen hardware play a role in encoding speed (enabling Hyperthreading in the bios actually slows my encodes by about 10%).

Generally speaking, in my experience MT seems to be much more effective with x264 encodes vs. xvid (and multithreading in general has very low effectiveness in xvid).

Basically, I would caveat any recommendation to use it by saying "Your Mileage May Vary". There are certainly cases where MT does nothing to help.

However, to say MT avisynth is a placebo - I must disagree with that as that has not been my experience.

[JoshyD]

It's only about a 5% speed decrease here using x264 but I also see about 3% decrease with 2.58 over mt 2.57. I didn't use avs2avi because many builds spit out exotic fps numbers, only squid_80's x86 builds give proper fps. I do notice the latest mt x64 build is using 2 theads per core if setmtmode is set to auto detect which could hurt performance

Using two threads per core is strange, I'll go back and look at the threading auto-detection, I had never really run into this problem.

Even using an mt avisynth.dll slows you down. SetMTmode() and MT() are useful with heavy filters but even then it's usually not significantly faster then non-mt avisynth. I'm crossing my fingers a non-mt avisynth 2.60 comes out then everyone can start seeing the 15-20% speed increase like what we see with this build over 2.58 mt. However currently this avisynth is lucky to get a 5% speed increase over 2.60 and sometimes it's slower. 2.57 x64 is often a little faster then this build except not when resizing. In conclusion, 2.58 mt seems to be the slowest avisynth build among 2.57 - 2.60 in my tests.

As a preface to benchmark methodology, I personally have a script that just opens a video file and plays it back, not actual editing involved. At the very least, I can playback or encode through x64 and 32bit versions at the same speed, minus filtering. I mean, literally the same. I've been testing against 2.6 alpha 2, because it has the snazzy new resize code in full effect, minus SSE2-ized horizontal resize code. I also do not have SSE2 horizontal code implemented, mostly because I haven't come up with a "good" way of doing this.

Personally, with heavy filtering and threading my scripts, I get at least 100% performance gain, but I have to let it use 4 cores, so it definitely does not scale perfectly linearly (what does these days ;)) with the number of processors. Is the 2.58 mt build that's slowest for you the 32 bit version? My performance tests put my build (and the x64 filters to go with it) at least as fast as the 2.6 alpha 2, often a good deal faster when using filters like MVTools2 and Masktools that can take advantage of the extra registers that are available under 64bit mode.

What tests have you been running to gauge the speeds between the various builds? This will give me a better idea of where the code needs sprucing up. I'm aware the color space conversions, notably yuy2-->anything else, are pretty crappy. What else needs a good kick in the seat of the pants?

This goes for anyone and everyone, where are you guys seeing speed bottlenecks?

I haven't had time to look into the x264 weirdness, but hopefully that is something that can be taken care of swiftly, I'll look it over in my free time today. Here's the code that appears to be the source of the error, now to find out why . . . might have to wonder over to doom10 and look like a total idiot . . .


if( pic.i_pts <= largest_pts )
{
if( param->i_log_level >= X264_LOG_WARNING )
{
if( param->i_log_level >= X264_LOG_DEBUG || pts_warning_cnt < MAX_PTS_WARNING )
fprintf( stderr, "x264 [warning]: non-strictly-monotonic pts at frame %d (%"PRId64" <= %"PRId64")\n",
i_frame, output_pts, largest_pts * dts_compress_multiplier );
else if( pts_warning_cnt == MAX_PTS_WARNING )
fprintf( stderr, "x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones\n" );
pts_warning_cnt++;
}
pic.i_pts = largest_pts + ticks_per_frame;
output_pts = pic.i_pts * dts_compress_multiplier;
}


EDIT: This appears to only happen when x264 cannot understand the input file format. For example, if I explicitly tell x264 my clip is interlaced and at 30000/1001 (29.97fps), no warnings are displayed. The Avisynth support in x264 was intended to support 32bit Avisynth, perhaps there's something not being read from the avisynth64 input stream?

Turbojet, no discouragement taken, you've been very helpful, and always provide constructive and intelligent feedback. What more could a community driven developer ask for? This project started as a way to keep me busy, and wouldn't have gotten very far if people didn't take interest and provide feedback.

@levi
I wholeheartedly agree with your synopsis of the caveats that threading a script brings. Hyperthreading may slow your encodes down because, in essence, hyperthreading is a hack. Interestingly enough, AMD engineers publicly called it so when Intel introduced it. It just allows two threads access to your processors execution pipeline at the same time. Let me show you the shiny block diagram of the latest Core architecture from instruction issue to retirement. End story, the goal of hyperthreading is to keep all the execution units on your processor happily chunking through data.

http://www.mediafire.com/imgbnc.php/9c79e436e44bcdcbce3e37755d95640f4g.jpg

The Core architecture (latest, starting with Nehalem and its derivatives) can schedule 5 instructions (5 is a special case with macro op fusion, without, it can schedule/retire 4 instructions per clock) per clock, so keeping all the execution units busy can be difficult for some types of code. I'm guessing that encoding programs really have no problem abusing your processor, so hyperthreading can get in the way of efficient code. A lot of the code in Avisynth and x264 is hand written assembler, and it doesn't get much more efficient than that . . . as long as it's well written assembler.

I keep a log of my fastest script & threading combinations.

Any chance of sharing some of that log information? I think it would be interesting from a development standpoint.

[osgZach]

What I mean is mostly placebo is people see multithreading avisynth and assume it's faster but in most cases it's actually slower. I don't know of a gui that makes use of it, it's not a complicated addition but it slows down all the functions they provide.

The assumption isn't necessarily wrong because almost all multithreaded programs have significant performance increase over their single threaded counterpart.

By cutting encoding time in half you must be using some very heavy filters, what exactly are you using?

I only use MT on TGMC currently, which obviously is a very heavy filter. But its one of the few I need/use. I don't typically use heavy denoisers or anything like that, and typically I will just use a default "LSFMod()" call to clean things up a little. I haven't tried seeing what effect MT or SetMTMode would have with it however.

Also worth noting, I don't run filters on x264 encodes, except something with negligent impact such as "Undot()". I do all my filtering into a HuffYV12 first. But lately I have been working from a decent DVD source.. I have other DVD's which are quite horrible and have other problems of their own.. So I won't be able to do further broad comparisons until I get around to doing them (and at that point I hope to have a Core2 quad or i5 at least).

[Jeremy Duncan]

I see your using SET's 2.5.8. It's been a while since I saw it, but, if you look at the files in the project not all of the files in the src are in there. You should add the missing files to the project and then some bugs people are reporting will be fixed. I told SEt about this, maybe he fixed it since them?

[Stephen R. Savage]

I am getting an unknown exception with LaTo's GradFun2DBmod with the latest 4/01 build at resolutions 1440x1080 and 1280x720.

Edit: This also occurs with the 3/19 build. I am currently using GradFunkMirror as a replacement, and will see if I can isolate the script lines that cause this.

Edit2: I have traced the exception to the following fragment:

grain = temp<=0 ? grain
\ : temp==100 ? mt_makediff(dither,diff.temporalsoften(1,255,chr?255:0,255,2),u=chr?3:2,v=chr?3:2)
\ : mt_makediff(dither,diff.mergeluma(diff.temporalsoften(1,255,chr?255:0,255,2),temp/100.0),u=chr?3:2,v=chr?3:2)

The portion that is in effect is:

mt_makediff(dither,diff.mergeluma(diff.temporalsoften(1,255,0,255,2),50.0/100.0),u=2,v=2)

I can reproduce the exception with:

BlankClip()
ConvertToYV12()
MergeLuma(TemporalSoften(1, 255, 0, 255, 2), 50.0 / 100.0)

One instance of this managed to crash VirtualDub64, and the backtrace is:

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

Disassembly:
7feed284820: c410 les edx, fword ptr [eax]
7feed284822: 0100 add [eax], eax
7feed284824: 005dc3 add [ebp-3dh], bl
7feed284827: 660f db 0fh
7feed284829: 1f pop ds
7feed28482a: 8400 test [eax], al
7feed28482c: 0000 add [eax], al
7feed28482e: 0000 add [eax], al
7feed284830: 57 push edi
7feed284831: 48 dec eax
7feed284832: 83ec30 sub esp, 30h
7feed284835: 83792000 cmp dword ptr [ecx+20h], 00h
7feed284839: 7423 jz ed28485e
7feed28483b: 48 dec eax
7feed28483c: 8b7918 mov edi, [ecx+18h]
7feed28483f: 48 dec eax
7feed284840: 8b4f38 mov ecx, [edi+38h]
7feed284843: 48 dec eax
7feed284844: 8b01 mov eax, [ecx]
7feed284846: 4c dec esp
7feed284847: 8b5730 mov edx, [edi+30h]
7feed28484a: 4d dec ebp
7feed28484b: 63c0 arpl ax, ax
7feed28484d: 4d dec ebp
7feed28484e: 63c9 arpl cx, cx
7feed284850: 4c dec esp
7feed284851: 89542420 mov [esp+20h], edx
7feed284855: ff5018 call dword ptr [eax+18h]
7feed284858: 48 dec eax
7feed284859: 83c430 add esp, 30h
7feed28485c: 5f pop edi
7feed28485d: c3 ret
7feed28485e: e80d000000 call ed284870
7feed284863: 48 dec eax
7feed284864: 83c430 add esp, 30h
7feed284867: 5f pop edi
7feed284868: c3 ret
7feed284869: 0f db 0fh
7feed28486a: 1f pop ds
7feed28486b: 800000 add byte ptr [eax], 00h
7feed28486e: 0000 add [eax], al
7feed284870: 55 push ebp
7feed284871: 48 dec eax
7feed284872: 81ec90000000 sub esp, 00000090
7feed284878: 48 dec eax
7feed284879: 8d6c2420 lea ebp, [esp+20h]
7feed28487d: 4c dec esp
7feed28487e: 897d30 mov [ebp+30h], edi
7feed284881: 4c dec esp
7feed284882: 897538 mov [ebp+38h], esi
7feed284885: 4c dec esp
7feed284886: 896d40 mov [ebp+40h], ebp
7feed284889: 4c dec esp
7feed28488a: 896510 mov [ebp+10h], esp
7feed28488d: 48 dec eax
7feed28488e: 897d18 mov [ebp+18h], edi
7feed284891: 48 dec eax
7feed284892: 897520 mov [ebp+20h], esi
7feed284895: 48 dec eax
7feed284896: 895d28 mov [ebp+28h], ebx
7feed284899: 48 dec eax
7feed28489a: 89d6 mov esi, edx
7feed28489c: 48 dec eax
7feed28489d: 89cb mov ebx, ecx
7feed28489f: 48 dec eax
7feed2848a0: 8b4318 mov eax, [ebx+18h]
7feed2848a3: 48 dec eax
7feed2848a4: c74500feffffff mov dword ptr [ebp+00h], fffffffe
7feed2848ab: 48 dec eax
7feed2848ac: 8b4838 mov ecx, [eax+38h]
7feed2848af: 4c dec esp
7feed2848b0: 8b11 mov edx, [ecx]
7feed2848b2: 48 dec eax
7feed2848b3: 8d5508 lea edx, [ebp+08h]
7feed2848b6: 4c dec esp
7feed2848b7: 8b4830 mov ecx, [eax+30h]
7feed2848ba: 41 inc ecx
7feed2848bb: ff5208 call dword ptr [edx+08h]
7feed2848be: 90 nop <-- FAULT
7feed2848bf: 48 dec eax
7feed2848c0: 8b4508 mov eax, [ebp+08h]
7feed2848c3: 48 dec eax
7feed2848c4: 85c0 test eax, eax
7feed2848c6: 7515 jnz ed2848dd
7feed2848c8: 48 dec eax
7feed2848c9: 8b4318 mov eax, [ebx+18h]
7feed2848cc: 48 dec eax
7feed2848cd: 8b4830 mov ecx, [eax+30h]
7feed2848d0: 48 dec eax
7feed2848d1: 8b39 mov edi, [ecx]
7feed2848d3: 48 dec eax
7feed2848d4: 8d15c2cc2200 lea edx, [0022ccc2]
7feed2848da: ff5728 call dword ptr [edi+28h]
7feed2848dd: 48 dec eax
7feed2848de: 8b4318 mov eax, [ebx+18h]
7feed2848e1: 48 dec eax
7feed2848e2: 8b4838 mov ecx, [eax+38h]
7feed2848e5: 48 dec eax
7feed2848e6: 8b11 mov edx, [ecx]
7feed2848e8: ff5228 call dword ptr [edx+28h]
7feed2848eb: 48 dec eax
7feed2848ec: 8b4d08 mov ecx, [ebp+08h]
7feed2848ef: 8b5814 mov ebx, [eax+14h]
7feed2848f2: 44 inc esp
7feed2848f3: 8b4114 mov eax, [ecx+14h]
7feed2848f6: 44 inc esp
7feed2848f7: 8b611c mov esp, [ecx+1ch]
7feed2848fa: ba02000000 mov edx, 00000002
7feed2848ff: 44 inc esp
7feed284900: 894550 mov [ebp+50h], eax
7feed284903: 44 inc esp
7feed284904: 8b4118 mov eax, [ecx+18h]
7feed284907: 44 inc esp
7feed284908: 894558 mov [ebp+58h], eax
7feed28490b: 41 inc ecx
7feed28490c: 8d4003 lea eax, [eax+03h]
7feed28490f: 83e0fc and eax, 0fch
7feed284912: 894548 mov [ebp+48h], eax
7feed284915: e816e90b00 call ed343230
7feed28491a: 44 inc esp
7feed28491b: 8b4558 mov eax, [ebp+58h]
7feed28491e: 83 db 83h
7feed28491f: c0 db 0c0h

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

Windows 6.1 (Windows Vista x64 build 7600) []

RAX = 0
RBX = 26513c0
RCX = 12ed80
RDX = fdc9d0f4
RSI = 1d84c30
RDI = 1d84c30
RBP = 12f280
R8 = 12ec68
R9 = 12f280
R10 = 0
R11 = 286
R12 = 0
R13 = 12f5d8
R14 = 12f5d0
R15 = 70800
RSP = 12ecb0
RIP = 7feed475109
EFLAGS = 00000202


Crash reason: unknown exception 0x40000015

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

Pointer dumps:

RBX 026513c0: ed573500 000007fe ed573480 000007fe 00000001 00000000 02625000 00000000
RCX 0012ed80: 006124b0 00000000 000000d5 00000000 002f4f70 00000000 00000000 00000000
RSI 01d84c30: efefefef efefefef efefefef efefefef efefefef efefefef efefefef efefefef
RDI 01d84c30: efefefef efefefef efefefef efefefef efefefef efefefef efefefef efefefef
RSP 0012ecb0: 0012ecd0 00000000 00000006 00000000 00000000 00000000 00000001 00000000
0012ecd0: 0012ece0 00000000 0012ed80 00000000 40000015 00000000 00000000 00000000
0012ecf0: ed2848be 000007fe 00000000 00000000 00000000 00000000 00000000 00000000
0012ed10: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
RBP 0012f280: fffffffe ffffffff 00000000 00000000 00000000 00000000 01d84c30 00000000
0012f2a0: 01d84c30 00000000 00000036 00000000 00070800 00000000 0012f5d0 00000000
0012f2c0: 0012f5d8 00000000 7753c47b 00000000 01d7f390 00000000 00000020 00000000
0012f2e0: 0027056c 00000000 02000001 00000000 0012f340 00000000 ed284504 000007fe
R8 0012ec68: 77667dba 00000000 00070800 00000000 0012f5d0 00000000 0012f5d8 00000000
R9 0012f280: fffffffe ffffffff 00000000 00000000 00000000 00000000 01d84c30 00000000
R13 0012f5d8: 00000001 00000001 00000001 00000000 40122499 00000001 00070800 00000000
R14 0012f5d0: 00070800 00000000 00000001 00000001 00000001 00000000 40122499 00000001

Thread call stack:
7feed475109: avisynth!avs_at_exit [7feed230000+f8730+14c9d9]
7feed2848be: avisynth!avs_release_video_frame [7feed230000+4dcd0+6bee]
7feed475109: avisynth!avs_at_exit [7feed230000+f8730+14c9d9]
77682075: ntdll!RtlRestoreLastWin32Error [77630000+52040+35]
775a1511: USER32!MessageBoxTimeoutA [77530000+7135c+1b5]
7754c296: USER32!GetSystemMetrics [77530000+1c110+186]
775a11d6: USER32!MessageBoxA [77530000+71188+4e]
7feed488cb5: avisynth!avs_at_exit [7feed230000+f8730+160585]
7feed47e560: avisynth!avs_at_exit [7feed230000+f8730+155e30]
7feed4767a5: avisynth!avs_at_exit [7feed230000+f8730+14e075]
7feed2848be: avisynth!avs_release_video_frame [7feed230000+4dcd0+6bee]
7754a01b: USER32!IsDialogMessageW [77530000+19e80+19b]
7753c47b: USER32!RegisterPowerSettingNotification [77530000+c328+153]
7feed284504: avisynth!avs_release_video_frame [7feed230000+4dcd0+6834]
7fefbed1381: uxtheme!00001381
7767fdf5: ntdll!KiUserCallbackDispatcher [77630000+4fdd6+1f]
7754c3df: USER32!GetSystemMetrics [77530000+1c110+2cf]
7feed284128: avisynth!avs_release_video_frame [7feed230000+4dcd0+6458]
7fef59d783a: AVIFIL32!AVIStreamRead [7fef59d0000+7810+2a]
1401085e2: AVIReadTunnelStream::Read()
7754a46a: USER32!GetSysColor [77530000+1a418+52]
7fefd6a2593: COMCTL32!DefSubclassProc [7fefd680000+222ec+2a7]
7754a54d: USER32!IsWindow [77530000+1a544+9]
14003ec2d: VDFilterFrameBuffer::AddRef()
140122ae2: VideoSourceAVI::_read()
7fefd6a24af: COMCTL32!DefSubclassProc [7fefd680000+222ec+1c3]
140043bb6: VDFilterFrameVideoSource::RunRequests()
1400a6497: VDUIFrame::DefProc()
7754c3df: USER32!GetSystemMetrics [77530000+1c110+2cf]
14008d777: VDProjectUI::GetFrameString()
140083775: VDProject::UpdateFrame()
140042d0a: VDFilterFrameRequestAllocator::Allocate()
140041f91: VDFilterFrameQueue::GetRequest()
1400a5a93: VDTimeline::TimelineToSourceFrame()
1400846ec: VDProject::DisplayFrame()
14008fbc7: VDProjectUI::UICurrentPositionUpdated()
140081915: VDProject::MoveToFrame()
14008cbdb: VDProjectUI::OnPositionNotify()
1400952fe: VDProjectUI::MainWndProc()
7fefbed1644: uxtheme!00001644
7754a2d4: USER32!IsDialogMessageW [77530000+19e80+454]
7754c296: USER32!GetSystemMetrics [77530000+1c110+186]
77546072: USER32!GetWindowLongPtrA [77530000+16050+22]
1400a70a8: VDUIFrame::StaticWndProc()
7753e034: USER32!GetQueueStatus [77530000+de20+214]
7754c3c1: USER32!GetSystemMetrics [77530000+1c110+2b1]
1400f1bba: VDPositionControlW32::WndProc()
7754c333: USER32!GetSystemMetrics [77530000+1c110+223]
1400f1f82: VDPositionControlW32::StaticWndProc()
7754a6d8: USER32!IsWindow [77530000+1a544+194]
7753fd38: USER32!SendMessageA [77530000+fcd8+60]
77547d86: USER32!GetWindowLongA [77530000+17d64+22]
1400f1b66: VDPositionControlW32::WndProc()
1400f1f82: VDPositionControlW32::StaticWndProc()
7754c3c1: USER32!GetSystemMetrics [77530000+1c110+2b1]
7767fdf5: ntdll!KiUserCallbackDispatcher [77630000+4fdd6+1f]
7754c333: USER32!GetSystemMetrics [77530000+1c110+223]
7754c60a: USER32!GetSystemMetrics [77530000+1c110+4fa]
7754bd32: USER32!TranslateMessage [77530000+1bd10+22]
14006ec2e: inMain()
14022cb31: _tmainCRTStartup()
776cd94a: ntdll!MD5Final [77630000+93950+9ffa]
7742f56d: kernel32!BaseThreadInitThunk [77410000+1f560+d]
77663281: ntdll!RtlUserThreadStart [77630000+33260+21]

-- End of report

[squid_80]

EDIT: This appears to only happen when x264 cannot understand the input file format. For example, if I explicitly tell x264 my clip is interlaced and at 30000/1001 (29.97fps), no warnings are displayed. The Avisynth support in x264 was intended to support 32bit Avisynth, perhaps there's something not being read from the avisynth64 input stream?


If x264 is including avisynth.h, it will need the fixes to the AVSValue =operator to be 64-bit compatible.

[kemuri-_9]

If x264 is including avisynth.h, it will need the fixes to the AVSValue =operator to be 64-bit compatible.

x264 uses avisynth_c.h for the C interface, not avisynth.h for the standard C++ one.
and we do include this in x264's repository so as to not have users compiling for windows require it.

[jpsdr]

Two things :
1 :
In the first page, you said that for Dgindex, not all the idct mode are present. Can you specify which ones are present actualy ?
2 :
I've tested the automaptt3 avs script wich use the the masktools 2.0a with x64, result is a VDub crash (32bit version works fine).

Otherwise, thanks for your work, and good luck for the following.

[trevaaar]

Any chance you could post the avisynth.h/avisynth.lib from your port? I'm interested in compiling hqdn3d so TemporalDegrain will work. Only have VS2008, not ICL.

Also, I'm getting a crash with MCTemporalDenoise(settings="low",deblock=false) in Veedub64. It opens up alright but as soon as you try to step forward a frame or save the results it dies. I'm on an i7 920 if that makes any difference.

[JoshyD]

@Stephen R. Savage
As always very useful feedback, thanks for taking the time to create a simple test case. I've got some idle cycles today, and hopefully should get that shored up for you in no time. I was constantly playing with the way masktools handles the stack when compiling the 64 bit version, there's a chance it's already fixed (lucky me).

@Trevaaar
You can find my code and changes here. (http://code.google.com/p/avisynth64) If you just need the header, it's in trunk/src No real major changes were made save for some new CPUID's and compliance with any new operator wanting to be "size_t" instead of unsigned int when compiling for x64. I just looked at the source for hqdn3d, and it's a really easy compile. No inline asm or other funny business. I figured I already had it built so I'm just going to post it here. (http://www.mediafire.com/?gyvmmzx0v4z) Visual inspection looks like it's working . . .

Also, with the crash, what function are you using to open the source? I still haven't had time to sufficiently play with MCTemporalDenoise, hopefully I'll get it all ironed out soon, it's a relatively popular script.

@jpsdr
I'm not familiar with automaptt3 script, but perhaps Stephen's bug is related to some of the functionality employed in both cases. We'll see if I can't get this all straightened out.

[jpsdr]

Well, the automaptt3 script was just to report, as i'm not using it for now, it was just a test i've made out of curiosity. i'll post it here later if you want to test also.
Nevertheless, i'm greatly more interested to know what IDCT are implemented in DGDecode, because this one i intend to use it ! (i've begin to port my VDub filters to x64 for this)

[Stephen R. Savage]

Alright, I've gotten a DgDecode 1.5.8 built and running correctly on my system. It will only decode with SSE2 or SKALSSE algorithms for now, I'll work on getting the others back. Link is on the main page. It's not exactly x64 optimized, but at least it's the latest build.

This post. SKALSSE corresponds to idct=6. Not sure about the other. It doesn't matter, because all IDCT modes have an SSIM higher than 0.999.

[jpsdr]

Ok, thanks. I'll wait for the IDCT IEEE ... don't remember exactly.

[JoshyD]

The IDCT modes that are working are 6 and 3, the IEEE full floating point spec is written in some nasty floating point inline assembler. I've been kind of putting it off, but I guess if there's some demand . . . ;)

[Mr VacBob]

3 should be the fastest IDCT, no point in using anything else.

(If you replaced Skal with the SSE2 Skal in ffmpeg it would be much faster than that, though)

[Stephen R. Savage]

The IDCT modes that are working are 6 and 3, the IEEE full floating point spec is written in some nasty floating point inline assembler. I've been kind of putting it off, but I guess if there's some demand . . . ;)

On the other hand, wouldn't this one benefit the most from porting to 64-bit (and not just because of registers)?

[JoshyD]

DgDecode is using sse2 skal from somewhere, probably ffmpeg as you mentioned.

The thing about it's highest precision mode, is it does 80-bit precision floating point calculations, which means we're still tied down to the floating point registers (which are architecturally the mmx registers, plus some bits that mmx doesn't use). I'm not too well versed on assembly before all floating point calcs were done in either mmx or sse registers, but it definitely appears the highest precision mode of dgdecode is using the 80 bit extended registers. It's not exactly going to see any speed gains from vectorized instructions or that kind of thing.

On a lighter note, I got your bug ironed out, and finally wrote the horizontal resize code to work with the SSE registers instead of MMX. I'm going to poke it and prod it a bit, but should be up to tinker with this weekend.

[trevaaar]

Thanks for the build of hqdn3d!

The source I'm using in the script that crashes is AviSource with a huffyv12-through-ffdshow AVI. Works fine on its own.

[jpsdr]

I personnaly seek for the most precise and accurate, so, i'm only using this mode.
Can you send me the source code you've already ported, or put link on first page ?

[Stephen R. Savage]

I personnaly seek for the most precise and accurate, so, i'm only using this mode.
Can you send me the source code you've already ported, or put link on first page ?

If you wanted the most accurate output, you would use one of the MMX or SSE transforms and not the IEEE reference. This is because nothing is encoded with the IEEE defined DCT, and therefore you will lose approximately 0.0005 SSIM by using the IEEE.

[JoshyD]

I personnaly seek for the most precise and accurate, so, i'm only using this mode.
Can you send me the source code you've already ported, or put link on first page ?

Here's the source I'm building from. (http://www.mediafire.com/?o23z43nmj1x) If you do a wholesale diff on the directory with something like WinMerge, it's pretty easy to see where it's been hacked apart to work with x64, just look for #ifndef _AMD64_ for most of the 64bit only mods.

I'm sure everyone would be very appreciative if you could bring the floating point assembly up to 64bit compatibility, or just improve the source in general. A word of caution, it is inline asm, and can't be built with MSVS's C++ compiler. If you want to rewrite it, I'll more than happily compile it with Intel's compiler, which still happily accepts 64bit inline asm. As of now, I'm just not building with the fp source files at all.

They could be converted to C++ using the "long double" type apparently, that's one idea. Another idea is that Intel offers 30 day evals of their compilers, you could use that if you really want to compile the inline assembly.

I'm having a bit of trouble finding good documentation on the 8087+ fp implementation. It seems that through the years the 80bit format has been mostly dropped in favor of 64bit double precision computations.

Wikipedia articles, while not being the most credible sources have some insight into fp standards without being an IEEE member. The last IEEE754 spec appears to have been released in 2008.

Anyhow this may give insight into 80 bit computation (http://en.wikipedia.org/wiki/Extended_precision) and this gives an idea of how quad precision (http://en.wikipedia.org/wiki/Quadruple_precision) fp is supposed to work. However, current hardware implementations apparently do not support quad precision calculations directly (at least according to wikipedia!)

I'm fairly certain that the AMD64/EMT64 ABI's don't allow manipulation of things like the fp control word and will throw an exception when trying to even use _control87() in C++. It would appear that the powers that be are trying to move everything to a power of 2 standard (32, 64, or 128 bit fp computations).

Corrections, information, and ideas on these concepts is definitely appreciated.

If you wanted the most accurate output, you would use one of the MMX or SSE transforms and not the IEEE reference. This is because nothing is encoded with the IEEE defined DCT, and therefore you will lose approximately 0.0005 SSIM by using the IEEE.

Interesting point, and food for thought. I'm pretty sure straight up 80 bit calculations went the way of the dinosaur many moons ago. The DgDecode website lists IEEE 1180 encode/decode as the most accurate, but your point makes definite sense. Who encodes with 80 bit fp calcs? Most programming conventions I'm aware of obscure this format even from the assembly programmer. There are no modern MMX/SSE instructions that even attempt to support this, and to my knowledge, GPU's skipped it entirely. It's from the 8087, which was err, something like 30 years ago? If you debug C at the assembly level, modern compilers do all their FP work in the SSE registers, at least from what I've seen. I've never personally run into disassembled code that still makes reference to the old FP stack way of doing things.

Sticking with 64bit or 32bit calcs also allows offloading them to the GPU anyhow, this may be what DgNVDecode does. An open sourced DirectX or OpenGL / CL version of these calcs may be of more interest / use at the moment.

[jpsdr]

My thoughts are, but i may be wrong :
- IEEE (ect...) it strictly compliant to the MPEG-2 spec, and ways of doing things. Encoders are supposed to be strict compliant to the spec too.

Something else : A long time ago, i've made convertions with mpeg2avi. This SW propose around the same options of decoding than DGIndex.
At that time, i was wondering why my second convertions looked worse than my first, before realising that my 2nd convertions where done with mmx mode, and 1rst with IEEE... But the mmx was faster.

I'll take a look out of curiosity. For now, i'm porting my own VDub filters under x64, but, after this, i may take a look at this part, as i'm intersted in it.
I've in my youth made my own math library under DOS (turbo pascal) in ASM using FPUx87 instructions, so, i'ill probably recall old memories when i'll take a look.

Thanks.

[Stephen R. Savage]

MaskTools 2.0a37 is now available. I'm looking forward to an updated 64-bit version!

[levi]

using avisynth64_4-10-10 I still get warnings:


mpeg2source("my.d2v")
tfm(d2v="my.d2v")
tdecimate()
crop(16,8,1884,1072)
Lanczos4Resize(1280,720)



avs [info]: 1280x720p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 3.1
x264 [warning]: non-strictly-monotonic pts at frame 1 (0 <= 0)
x264 [warning]: non-strictly-monotonic pts at frame 2 (0 <= 1)
x264 [warning]: non-strictly-monotonic pts at frame 3 (0 <= 2)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones

[Stephen R. Savage]

My thoughts are, but i may be wrong :
- IEEE (ect...) it strictly compliant to the MPEG-2 spec, and ways of doing things. Encoders are supposed to be strict compliant to the spec too.

Quite the opposite. In fact, the MPEG-2 standard doesn't define the DCT at all! What this results in is every encoder using its own arbitrary-precision implementation of the DCT, which is also likely not the same one the decoder uses. Since it is incredibly unlikely that any encoder would use the very slow IEEE transform, there is no benefit in using it to decode. It was not until H.264 that we actually saw one specific DCT implementation mandated by the standard.

Edit: Also, JoshyD, could you move the plugins to the googlecode page and clean up some of the old cruft from the first post? It's getting hard to parse with the layers of outdated information. Perhaps you could copy the relevant information to documentation and changelogs on the googlecode project.

[osgZach]

That's my fault... dragging my feet on his web site. I've been sick for a week, just getting over it.

But good news!! Lost even more hours and pay at one of my jobs, so I will have more free time to get working on it! :D


edit:

I have started preleminary work on building up the site pages. I got WordPress 2.92 installed and put up a rather boorish "About" page.. Still have some work to do though, gotta find the right plugins and perhaps and spruce up the default theme and layout a little bit.. JoshyD isn't very web server savvy I think, so I need to come up with an easy way for him to add and update downloadable files for the main releases and x64 filter conversions, etc...

I'm still recommending you go with a main install-pack that gets the guts put in, and then a basic plugins pack that has all the plugins inside it. Then you can do staged update packs in the future, or have individual plugin pages as warranted for ongoing popular things.. We'll get it all sorted out in any case ;)

http://joshyd.oldskoolgames.com

[jpsdr]

Here the script of automttap3


#modified LanczosPlus using Masktools 2.0
#LanczosPlus is now LanczosmtPlus()
#autotap3 is now automttap3
# Optimisations by: wizboy11 and Didée
function automttap3(clip clp, int "dx", int "dy", int "mtaps3", int "thresh"){

c = clp
#g = clp.converttoy8()

dx = default(dx, c.width*2)
dy = default(dy, c.height*2)
mtaps3 = default(mtaps3, 1)
thresh = default(thresh, 256)

t1 = lanczosresize(clp, dx, dy, taps=1)
t2 = lanczosresize(clp, dx, dy, taps=2)
t3 = lanczosresize(clp, dx, dy, taps=3)
t4 = lanczosresize(clp, dx, dy, taps=4)
t5 = lanczosresize(clp, dx, dy, taps=5)
t6 = lanczosresize(clp, dx, dy, taps=9)
t7 = lanczosresize(clp, dx, dy, taps=36)


m1 = mt_makediff(clp, lanczosresize(t1, clp.width, clp.height, taps=1), u=1, v=1)
m2 = mt_makediff(clp, lanczosresize(t2, clp.width, clp.height, taps=1), u=1, v=1)
m3 = mt_makediff(clp, lanczosresize(t3, clp.width, clp.height, taps=1), u=1, v=1)
m4 = mt_makediff(clp, lanczosresize(t4, clp.width, clp.height, taps=2), u=1, v=1)
m5 = mt_makediff(clp, lanczosresize(t5, clp.width, clp.height, taps=2), u=1, v=1)
m6 = mt_makediff(clp, lanczosresize(t6, clp.width, clp.height, taps=3), u=1, v=1)
m7 = mt_makediff(clp, lanczosresize(t7, clp.width, clp.height, taps=6), u=1, v=1)


cp1 = mt_merge(t1.blur(1.42), t2, lanczosresize(mt_lutxy(m1, m2, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m100 = mt_makediff(clp, bilinearresize(cp1, clp.width, clp.height), u=3, v=3)

cp2 = mt_merge(cp1, t3, lanczosresize(mt_lutxy(m100, m3, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m101 = mt_makediff(clp, bilinearresize(cp2, clp.width, clp.height), u=3, v=3)

cp3 = mt_merge(cp2, t4, lanczosresize(mt_lutxy(m101, m4, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m102 = mt_makediff(clp, bilinearresize(cp3, clp.width, clp.height), u=3, v=3)

cp4 = mt_merge(cp3, t5, lanczosresize(mt_lutxy(m102, m5, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m103 = mt_makediff(clp, bilinearresize(cp4, clp.width, clp.height), u=3, v=3)

cp5 = mt_merge(cp4, t6, lanczosresize(mt_lutxy(m103, m6, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m104 = mt_makediff(clp, bilinearresize(cp5, clp.width, clp.height), u=3, v=3)

cp6 = mt_merge(cp5, t7, lanczosresize(mt_lutxy(m104, m7, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m105 = mt_makediff(clp, bilinearresize(cp6, clp.width, clp.height), u=3, v=3)

return(mergechroma(cp6, spline36resize(clp, dx, dy), 1))}

###
###
###

function Lanczosmtplus( clip c, int "dx", int "dy", int "thresh", int "thresh2", int "athresh",
\ float "sharp1", float "sharp2", float "blur1", float "blur2",
\ int "mtaps1", int "mtaps2", int "ttaps", int "ltaps", bool "preblur",
\ int "depth", float "wthresh", float "wblur", int "mtaps3"){

dx = default(dx, c.width*2)
dy = default(dy, c.height*2)
thresh = default(thresh, 0)
thresh2 = Default(thresh2, ((thresh+1)*(thresh+1))*64/(thresh+1))
sharp1 = default(sharp1, 1)
sharp2 = default(sharp2, 4)
blur1 = default(blur1, 0.33)
blur2 = default(blur2, 1.25)
mtaps1 = default(mtaps1, 1)
mtaps2 = default(mtaps2, 1)
ttaps = default(ttaps, 1)
ltaps = default(ltaps, 1)
depth = default(depth, 2)
wthresh = default(wthresh, 0.90)
wblur = default(wblur, 2)
mtaps3 = default(mtaps3, 1)
preblur = default(preblur, false)
athresh = default(athresh, 256)

c
s = c

fd1 = lanczosresize(c, dx, dy, taps=mtaps1)
fre1 = fd1.lanczosresize( c.width, c.height, taps=mtaps1)
fre2 = fre1.automttap3( ((c.width/16)*8 >= 144 ? (c.width/16)*8 : 144), ((c.height/16)*8 >= 144 ? (c.height/16)*8 : 144), \
mtaps3=mtaps3, thresh=athresh).automttap3( c.width, c.height, mtaps3=mtaps3, thresh=athresh)
m1 = mt_lutxy(fre1, s, "x y - abs "+string(thresh)+" - "+string(thresh2)+" *", u=1, v=1)
m2 = lanczosresize(lanczosresize(frfun7(m1, 2.01, 256, 256), (c.width/16)*8, (c.height/16)*8, taps=ttaps), \
dx, dy, taps=ttaps)

d = preblur ? mt_merge(c, fre2, m1) : c
d2 = d.automttap3(dx, dy, mtaps3=mtaps3, thresh=athresh)
d3 = lanczosresize(lanczosresize(d, c.width, c.height, taps=ttaps), \
d2.width, d2.height, taps=ttaps)
d4 = mt_merge( mt_lutxy(d2, d3 , "x y - "+string(sharp1)+" * x +" , u=1, v=1), \
mt_lutxy(d2, d3 , "y x - "+string(blur1)+" * x +" , u=1, v=1), m2)
d5 = d4.automttap3(d.width, d.height, mtaps3=mtaps3, thresh=athresh)

e = mt_merge(d5, c, m1).automttap3(dx, dy, mtaps3=mtaps3, thresh=athresh)
e = e.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e = e.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e = e.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e = e.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)


fd12 = lanczosresize(e, ((e.width*(dx/c.width))/16)*16, ((e.height*(dy/c.height))/16)*16, taps=mtaps2)
fre12 = fd12.lanczosresize( e.width, e.height, taps=mtaps2)
fre22 = fre12.lanczosresize( (e.width/16)*8, (e.height/16)*8, taps=mtaps2).lanczosresize( e.width, e.height, taps=mtaps2)
m12 = mt_lutxy(fre12, e, "x y - abs "+string(thresh)+" - "+string(thresh2*1)+" *", u=1, v=1)
m12 = m12.lanczosresize( (e.width/16)*8, (e.height/16)*8, taps=mtaps2).lanczosresize( e.width, e.height, taps=mtaps2)


e2 = lanczosresize(lanczosresize(e, c.width, c.height, taps=ltaps), \
e.width, e.height, taps=ltaps)
e2 = e2.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e2 = e2.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e2 = e2.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e2 = e2.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)

e3 = mt_merge( mt_lutxy(e, e2 , "y x - "+string(blur2)+" * x +" , u=1, v=1), \
mt_lutxy(e, e2 , "x y - "+string(sharp2)+" * x +" , u=1, v=1), \
m12)
e3 = e3.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e3 = e3.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e3 = e3.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)
e3 = e3.awarpsharp(depth=depth, cm=0, blurlevel=wblur, thresh=wthresh)


mt_merge(d4, e3, m2)

return(last.mergechroma(spline36resize(c, dx, dy), 1))}

[noee]

What is "frfun7" in the script above (automttap3, line 90)? That appears to be a missing component for 64bit.

Edit:

Okay, it appears to be a function in hqdn3d.dll, which I have added to the plugins64 folder. I still get an error when trying to run "Lanczosmtplus" above, saying "no function named frfun7".

[kemuri-_9]

What is "frfun7" in the script above (automttap3, line 90)? That appears to be a missing component for 64bit.

Edit:

Okay, it appears to be a function in hqdn3d.dll, which I have added to the plugins64 folder. I still get an error when trying to run "Lanczosmtplus" above, saying "no function named frfun7".

frfun7 is separate filter: a quick search lead to this thread (http://forum.doom9.org/showthread.php?t=110200) and this binary (http://avisynth.org/warpenterprises/files/frfun_25_dll_20060510.zip)
haven't seen the source lying around anywhere so won't be able to be ported...

[Stephen R. Savage]

Build 4/10/2010 displays highly incorrect results for horizontal resizing in YUV 4:2:0. No artifacts are seen in RGB. I tested a resize of 1920x1080 -> 704x1080 and 1920x1080 -> 704x480. Both show strong tearing artifacts in all resizers.

[ryrynz]

To be fair Stephen, this isn't an official release.

I'm sure JoshyD tests all he can given he most likely has other projects.

You shouldn't really ask that sort of a question from someone who is doing this in their free time, free of charge for the benefit of the community.

[kemuri-_9]

It's also impossible for one person to test every scenario that can occur with avisynth.

[jpsdr]

What is "frfun7" in the script above (automttap3, line 90)? That appears to be a missing component for 64bit.


Very strange... For me, when i load a script using automttap3,
VDub crash, nothing is telling me that there is an unknow function.
I'll check for the hqdn3d.dll in my 32 bits version, but i don't remember having this, so, i need checking.

[osgZach]

You're a knowledgeable fellow Stephen, feel free to volunteer helping him out with stuff...

[Zep]

Do you actually test your builds before releasing them? I don't mean to be rude, but this seems to be blatantly obvious.

But you are being rude. How about you simply point out problem and say thanks.

[turbojet]

I did some benchmarks of the common filters I use and a few slower filters here's the numbers (messy I know but I couldn't think of a better way). Trends and notes below may make more sense

1080p lanczosresize(1280,720) --ref 4 --psy-rd 1.0:0.2 2pass
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32mt2 64mt2
2.57 73.71 70.79 72.23 58.60 - 40.43 - 70.75 -
2.58 74.47 70.41 79.35 60.25 61.14 43.34 41.10 71.43 76.41
2.60 81.11 74.73 - 60.53 - 43.84 - 72.16 -

1080p --ref 4 --psy-rd 1.0:0.2 2pass
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32mt2 64mt2
2.57 45.60 45.68 47.44 40.30 - 31.36 - - -
2.58 45.06 45.77 46.80 40.83 40.66 37.54 38.33 - -
2.60 43.48 45.79 - 41.02 - 37.10 - - -

1080p --preset medium
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32mt2 64mt2
2.57 17.27 17.64 18.39 16.14 - 14.84 - - -
2.58 17.76 17.60 18.14 16.35 16.22 14.94 15.32 - -
2.60 17.89 17.89 - 16.13 - 15.72 - - -

1080p lanczosresize(1280,720) --preset medium
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32mt2 64mt2
2.57 35.49 34.32 35.36 26.75 - 24.23 - 33.86 -
2.58 35.90 34.20 37.27 27.76 29.98 21.66 21.89 34.29 36.29
2.60 37.13 35.33 - 28.71 - 22.14 - 34.65 -

480i TFM().TDecimate() --preset medium
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32mt2 64mt2
2.57 86.62 87.03 86.97 80.27 - 72.92 - 84.59 -
2.58 86.95 86.62 89.69 81.01 86.97 68.85 84.41 85.14 86.97
2.60 86.82 86.70 - 80.16 - 73.56 - 85.06 -

480i TDeint() --preset medium
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32mt2 64mt2
2.57 78.07 77.94 87.51 83.57 - 76.54 - 86.92 -
2.58 77.26 78.04 89.70 83.88 89.70 72.44 78.00 44.07 44.30
2.60 77.49 77.91 - 83.21 - 71.94 - 39.70 -

480i LeakKernelDeint(order=1) --preset medium
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32mt2 64mt2
2.57 103.0 103.7 105.5 71.94 - 51.66 - 79.23 -
2.58 102.1 102.1 108.7 69.80 78.00 50.42 52.00 79.81 78.00
2.60 102.6 103.2 - 70.57 - 49.58 - 79.31 -

480i TGMCmod_beta1(eedi2) --preset medium
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32sm6 64sm6 32mt2 64mt2 32mt4 64mt4
2.57 3.62 3.88 *1 4.56 - 7.97 - 11.98 - 7.76 - 11.86 -
2.58 3.87 3.86 4.96 4.19 5.83 8.30 10.66 12.63 16.16 7.46 9.36 11.48 14.11
2.60 3.69 3.87 - 4.18 - 8.02 - 12.03 - 7.11 - 10.92 -

480i LSFMod --preset medium
ver 32bit 32mt 64bit 32sm2 64sm2 32sm4 64sm4 32mt2 64mt2
2.57 42.12 41.81 *1 *2 *2 *2 - 64.23 -
2.58 41.62 41.76 62.95 *2 *2 *2 *2 64.59 70.35
2.60 50.93 42.56 - *2 - *2 - 64.19 -

Legend
32bit: 32 bit sourceforge version
32mt: 32 bit MT version
64bit: 64 bit (2.57 isn't MT, 2.58 is MT, no 2.60 build)
32sm2: 32 bit SetMTMode(2,2)
64sm2: 64 bit SetMTMode(2,2)
32sm4: 32 bit SetMTMode(2,4)
64sm4: 64 bit SetMTMode(2,4)
32sm6: 32 bit SetMTMode(2,6)
64sm6: 64 bit SetMTMode(2,6)
32mt2: 32 bit MT(2,2)
64mt2: 64 bit MT(2,2)

*1: temporalsoften unrecognized function in 64 2.57 MT
*2: SetMTMode().LSFMod() deadlocks with 25% CPU usage (only 1 thread serving?)

Trends:
- avisynth.dll from mt is slower when resizing
- Without slower filters MT() is slow SetMTMode() is slower
- with slower filters SetMTMode is very fast, MT() is fast
- 64 2.58 MT is faster except when resizing with fast x264 settings (loss from MT? coreavc?)

Notes:
- 2.58 MT and 2.60 MT have issues with MT.dll and TDeint, 2.57 MT doesn't
- 2.57 MT is often faster but sometimes slower then 2.58 MT, 2.60 MT
- 2.60 MT randomly caused 3 BSODs

All sources were AVC decoded by CoreAVC 2.0 on a quad core cpu. All used 95%+ cpu except SetMTMode.TGMC: 1 thread 25% 2=33% 4=66% 6=99%
MT(TGMC): 1 thread 30% 2=55% 4=90% 5=85% 6=85%
MT(LSFMOd): 1 thread=60% 2=90%

[turbojet]

Concerning 64 bit plugins, some organization with them would be nice. Alphabetically? Category+Alphabetically?

On the other hand, if you want to include the dll's in a separate directory with new versions the install script could easily move them for auto loading. Or just one big pack, downloading them individually is kind of annoying to begin with but easier updating I guess.

[JoshyD]

@Stephen
I noticed the artifacts last night myself, I'm currently looking into this. I did test with a variety of resizes before releasing, but apparently missed some corner cases. I'll revert the code for now, and come back soon with something more robust. It's hard to write the code and then test with all possible input variations. It really is hard to code and then extensively test all cases in the free time I do have. I'm sorry I screwed up this time, but, if I don't put out the code I do have, I'll never find some of the oddities that arise from code changes. I got excited on this one and jumped the gun.

For perspective, taking an already large project and just understanding it well enough to make minor modifications to it is difficult. There's not a million comments through the code, and you have to use a little intuition and some educated guesses as to the intended end result of the function. There's still oddities in the original source for 2.5.8 (Temporal::Soften accumulate_line_mode2 is commented as having funny results regardless of variable choice for the inline asm) and there were definitely times I found myself looking at the source and saying "what??". There's actually a pretty funny comment in squid_80's 2.5.7 64 bit port in this vein.
void Assign(const AVSValue* src, bool init) {
if (src->IsClip() && src->clip)
src->clip->AddRef();
if (!init && IsClip() && clip)
clip->Release();
// make sure this copies the whole struct!
/* UGH! what the- ?
((__int32*)this)[0] = ((__int32*)src)[0];
((__int32*)this)[1] = ((__int32*)src)[1];
*/
this->clip = src->clip;
this->type = src->type;
this->array_size = src->array_size;
}

I did the same thing when originally looking at the code, then compared the function to squid's conversion, and realized, yes, this was weird.

As per usual, older builds that do function as they should remain available. If I screw it up, roll back for the time being. It's a crappy answer, but it's the best I can do.

I guess kind of take this as the community took 2.6alpha2. That was released kind of as a community test. When you're just a few guys (the avisynth team) or just one guy (me) having the code put through the paces by the community at large expedites the process of bug finding / squashing.

As for personal testing methodology, I have a few core files I work from, and a few scripts that use a variety of filters, both internal and external. They usually turn up my blunders, but this time, they failed to do so. Apparently, I need to vary my sources / tests more.

@Turbojet
Thank you for your time running the comparisons . . . they're a nice insight into the good and bad of the various builds, as well as the pro's and cons of threading. As a point of reference, can you list the machine specs, I may tabularize these in a wiki page, if that's alright.

The problem with the way avisynth's cache was hacked around is that single threaded performance inherently suffers. The added complexity to a core component of the program eats away at overall performance.

As to the thread deadlock, I'll see if I can make it happen. I've had it run out of memory on me before, which was the root of the problem, but I'm guessing something popped up complaining about a deadlock? I have had this happen on occasion when I've done something stupid/illogical in the code.

The filters *DO* need to be organized, eventually I may just redirect to the google code hosted project, and format a wiki page there, for now, a clean-up of the first post is in order . . . after I figure out why the resizer is eating it. I'm fairly positive it's the horizontal part that's going awry, as the vertical code didn't change.

@levi
The monotonic points problem appears to be related to the caching. I get the error when trying to run through code with the regular cache, but it's all rosy when using SetMTMode(). It's definitely the frame rate information getting lost in translation. For now though, it's taking the number 2 spot on the todo list, so I can shore up the resize code.

Only so many hours in the day, I'll come back with something more stable soon.

EDIT: First post in alphabetical order, cleaned, easier to read . . . and the resize functionality is working properly, at least on my end, the clip that was showing artifacts last night no longer does.

[Andrey /MAG/]

Hello.
Still reminding about 'blending bug' in MVTools.
Maybe I can do something to solving this problem?
What the source of the problem and how can I help to fix it?

[Delerue]

Hello.
Still reminding about 'blending bug' in MVTools.
Maybe I can do something to solving this problem?
What the source of the problem and how can I help to fix it?

The interesting thing is that I can't reproduce the problem you're talking about. Everything works like it should be (i.e. equal to the x86 version). Here's the script I'm using:


setMTMode(2,12)
LoadPlugin("%path%\mvtools2 x64.dll")
source = ffdshow_source()
super = source.MSuper(pel=1)
backward_vec = MAnalyse(super, blksize=8, dct=10, overlap=2, isb = true, search=3, searchparam=2)
forward_vec = MAnalyse(super, blksize=8, dct=10, overlap=2, isb = false, search=3, searchparam=2)
source.MFlowFps(super, ThSCD1=350, blend=false, backward_vec, forward_vec, \
num=2*FramerateNumerator(source), den=FramerateDenominator(source))
distributor()


I've tried to set blend to 'true' and also remove the blend parameter. It still works flawlessly. Can you show your script so we can help you?

[tormento]

Has anybody compiled a x64 version ov MVTools 1.x?

[Andrey /MAG/]

I can't reproduce the problem
The problem is in specific means of function parameters in script. See details (source, script and results) in zip-file: http://www.sendspace.com/file/4u8s0t

This fact is submitted by JoshyD in his post (http://forum.doom9.org/showpost.php?p=1387856&postcount=286).

[Delerue]

The problem is in specific means of function parameters in script. See details (source, script and results) in zip-file: http://www.sendspace.com/file/4u8s0t

This fact is submitted by JoshyD in his post (http://forum.doom9.org/showpost.php?p=1387856&postcount=286).

There seems to be a problem with your 'blksize' value. Here, if I change it to '16' instead of '32', it works like it should. Also the 'searchparam' value 6 looks like an overkill. I did a lot of tests here with MFlowFPS (including your sample), and beyond 'searchparam' value 3 there's no visible gain, but the CPU usage increases a lot. I can guarantee you that the script I told you before gives a better final result. Of course you can tweak some parameters in order to get a better performance. What you think? :)

[Blue_MiSfit]

I just wanted to say thanks to everyone who is working hard on this project. This is a substantial development, and is making huge strides in AviSynth performance.

THANK YOU!!!

~MiSfit

[7ekno]

I just wanted to say thanks to everyone who is working hard on this project. This is a substantial development, and is making huge strides in AviSynth performance.


+1, Awesome work guys, keep it up! Viva la 64bit!

Am sure there will be hiccups along the way and the more information provided here (as opposed to critisism) will help all x64 users as a whole!

7

[Stephen R. Savage]

Artifacts confirmed fixed. Thanks a lot, JoshyD. By the way, I didn't notice the new build when it was originally uploaded, as you did not make a post about it. This is not a problem, but is there any chance of getting a RSS feed or similar to follow progress?

Also, could you add the original version numbers for the plugins listed on the first page?

@tormento: Only mvtools2 is up, but why do you need mvtools 1.x? If you have a custom script that requires it, perhaps I could help you migrate your script to mvtools2.

@Avs developers: I notice that resizing RGB images causes the hue/saturation/brightness to shift. Is this normal, and can it be fixed?

[Andrey /MAG/]

problem with your 'blksize' value.
Yes. This value causes another behavior of 64-bit plugin than 32-bit. It shows that conversion from 32 into 64 was with some inaccuracies.
Here, if I change it to '16' instead of '32', it works like it should.
I have done frame-by-frame comparing with 'subtract' and found that difference still present.
the 'searchparam' value 6 looks like an overkill. I did a lot of tests here with MFlowFPS (including your sample), and beyond 'searchparam' value 3 there's no visible gain, but the CPU usage increases a lot.
In some cases 'searchparam=3' was too small to find long vectors. I still use MVTools 2.4.7 (32bit) and 'searchparam' produce not big increase of CPU usage.
MVTools 2.5.10 is not so fast as 2.4.7.

I can guarantee you that the script I told you before gives a better final result. Of course you can tweak some parameters in order to get a better performance. What you think? :)
Thank you. I compared it too. The results is prety well. Better than ones of my script.

[Hiritsuki]

I found a filter this can help someone video non-waste bitrate, it's Dedup to using to making VFR video.
and it's no x64 ver.

[Stephen R. Savage]

I have done frame-by-frame comparing with 'subtract' and found that difference still present.

This was addressed on page two or three, and is the result of SoftWire performing rounding differently from JoshyD's native assembly.

I found a filter this can help someone video non-waste bitrate, it's Dedup to using to making VFR video.
and it's no x64 ver.

I've found that Dedup doesn't contribute significantly at all to compression ratio.

[Hiritsuki]

I've found that Dedup doesn't contribute significantly at all to compression ratio.

Oh, using big bitrate to compress video like anime ,dedup is good use.

[Pho3n1x]

i have a problem about the ffms2.dll from kemuri-_9's FFMS2 (The Fabulous FM Source 2)
when i open the avs in virtualdib64 it comes no funtion about ffvideosource.

my script is

loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\ffms2.dll")
ffvideosource("E:\Encode\0_2.mkv")
crop(0,22,-0,-22)

The same script with directshowsource works well but not with the ffms2.dll.

[Zathor]

Replace LoadPlugin with LoadCPlugin and everything should be fine.

[Wilbert]

@Avs developers: I notice that resizing RGB images causes the hue/saturation/brightness to shift. Is this normal, and can it be fixed?
Does that also happen with the regular v2.58? Could you post a script which shows this?

[Stephen R. Savage]

Does that also happen with the regular v2.58? Could you post a script which shows this?

I can confirm this with 2.58 standard.

The script I used was:

a = ImageSource("test.png")
b = Spline36Resize(a, 1280, 720).Spline36Resize(a.width, a.height)
Interleave(a, b)

I tested this with the following image (after decoding to PNG format):

http://img684.imageshack.us/img684/7910/testjc.png

After resizing, the image is noticeably darker:

http://img651.imageshack.us/img651/446/shiftcxifb.png

This also appears to happen with BicubicResize and LanczosResize, though it is a bit difficult to see with bicubic due to all the blur. Converting to YV12 first does not result in the same problem.

[Hiritsuki]

Some anime had few stationary frame only music runing.
So, can anyone make this "dedup" to x64 ver. ? please ...:)

[osgZach]

You've already asked once. If someone has the time and energy they will eventually get to it. But you are currently the only one asking for it. Repeating your request will not make it happen faster, you'll just make people ignore you.

[Hiritsuki]

You've already asked once. If someone has the time and energy they will eventually get to it. But you are currently the only one asking for it. Repeating your request will not make it happen faster, you'll just make people ignore you.

Sorry about my post I just explain what that filter is useable :(

[JoshyD]

@Stephen

Ah, I know why it happens in both . . . the resize code for RGB is pretty much left stock by myself, just pulled out into an asm file and written for all local register usage. It's never been performance optimized by anyone, to my knowledge. RGB resize doesn't come up that often I guess?

Found the problem, as well, I think. I'm uploading a new build for you to run through: Here's the test build. (http://avisynth64.googlecode.com/files/avisynth64_4-16-10.rar)

Slowly stepping through the interleave appears to be improved, but the original problem was subtle upon first inspection by my eyes. It's not completely gone . . .

32bit difference map:
http://www.mediafire.com/imgbnc.php/9fa6392282897d41706e823b120ce7642g.jpg


64bit difference map:
http://www.mediafire.com/imgbnc.php/3e7d1e79e38c6e26115da965894368f52g.jpg


Red means that the pixels are strictly different between adjacent frames of the image stream, using your script in VDub32 and VDub64. As you can see, it's better, but not perfect.

I've been playing around with the code seeing how much performance I could eek out of the core . . . let me know if anything breaks before I go update the first post.

For the devs, from the 2.58 source directly (and in 2.6 apparently):
// RGB24 is not recommended. 75% of all pixels are not aligned.
int y = vi.height;
int w = vi.width * 3;
int fir_filter_size = pattern_luma[0];
int* pattern_lumaP1 = pattern_luma+1 - fir_filter_size;
static const __int64 xFF000000 = 0xFF000000;
__asm {
push ebx
mov esi, srcp
mov edi, dstp
pxor mm2, mm2
movq mm4, xFF000000
align 16
yloop24:
xor ecx, ecx
mov edx, pattern_lumaP1 ;cur - fir_filter_size
align 16
xloop24:
mov eax, fir_filter_size
lea edx, [edx+eax*4] ;cur += fir_filter_size
mov ebx, [edx]
lea ebx, [ebx+ebx*2] ;ebx = ofs = *cur * 3
add edx, 4 ;cur++
pxor mm0, mm0 ;btotal, gtotal
pxor mm1, mm1 ;rtota
lea edx, [edx+eax*4] ;cur += fir_filter_size
add ebx, esi ;ebx = srcp + ofs*3
lea eax, [eax+eax*2] ;eax = a = fir_filter_size*3
align 16
aloop24:
sub edx, 4 ;cur--
sub eax, 3
movd mm7, [ebx+eax] ;mm7 = srcp[ofs+a] = 0|0|0|0|x|r|g|b
punpcklbw mm7, mm2 ;mm7 = 0x|0r|0g|0b
movq mm6, mm7
punpcklwd mm7, mm2 ;mm7 = 00|0g|00|0b
punpckhwd mm6, mm2 ;mm6 = 00|0x|00|0r
movd mm5, [edx] ;mm5 = 00|co (co = coefficient)
packssdw mm5, mm2
punpckldq mm5, mm5 ;mm5 = co|co
pmaddwd mm7, mm5 ;mm7 = g*co|b*co
pmaddwd mm6, mm5 ;mm6 = x*co|r*co
paddd mm0, mm7
paddd mm1, mm6
jnz aloop24
pslld mm0, 2
pslld mm1, 2 ;compensate the fact that FPScale = 16384
packuswb mm0, mm1 ;mm0 = x|_|r|_|g|_|b|_
psrlw mm0, 8 ;mm0 = 0|x|0|r|0|g|0|b
packuswb mm0, mm2 ;mm0 = 0|0|0|0|x|r|g|b
pslld mm0, 8
psrld mm0, 8 ;mm0 = 0|0|0|0|0|r|g|b
movd mm3, [edi+ecx] ;mm3 = 0|0|0|0|x|r|g|b (dst)
pand mm3, mm4 ;mm3 = 0|0|0|0|x|0|0|0 (dst)
por mm3, mm0
movd [edi+ecx], mm3

add ecx, 3
cmp ecx, w
jnz xloop24

add esi, src_pitch
add edi, dst_pitch
dec y
jnz yloop24
emms
pop ebx

Put the rounder in those registers, also, specifically why not change:


movd mm5, [edx] ;mm5 = 00|co (co = coefficient)
packssdw mm5, mm2
punpckldq mm5, mm5 ;mm5 = co|co


to


movd mm5, [edx] ;mm5 = 00|co (cocoefficient)
pshufw mm5, mm5,0xCCh


You're only interested in the low word anyhow, high double is zeroed on a movd.

[Stephen R. Savage]

Good work! Let's hope this update gets included in the main Avisynth trunk. I don't see any red on flat areas anymore, so I'm guessing it's about as fixed as it can get. Out of curiosity, what was the source of the bug?

Also, I hate to pester, but any chance of updating MaskTools to v2.0a37? The changes should be trivial.

Edit: Also, what did you use to make the difference map?
Edit2: Also, any chance you can port the Average() plugin (or write your own)?

[JoshyD]

@Stephen
The source of the problem is those two lines of highlighted inline ASM for 2.58, or in my case similar lines of code living in my .asm file of a comparable function. Basically, the resizers are working with an intent of doing the calculation of the new pixel value as a floating point value, and then converting it back to an integer quantity. For this, it's best to adopt some sort of rounding methodology, where I noted above. The rounding value is used in YV12 and YUY2 calculations, it was just omitted from the RGB functions, probably because they're pretty well neglected.

The masktools v2.0a37 changes are pretty trivial, I'll see what I can cook up in the next few days.

The program I was using is from an image analysis pack called ImageMagick. (http://www.imagemagick.org/script/binary-releases.php#windows) I'll just go back to their compare function to give some basic statistical analysis of changes I make to speed up the algorithms. Essentially, to weigh speed vs quality.

This error was a blatant error and actually was rather trivial to find, I was going to submit a SourceForge bug to the Avisynth guys, but apparently the site is down at the moment.

As for average, I'm not getting any hits from the filter collection or the web in general, is this something
a) in 2.58 that I didn't port and am totally drawing a blank on
b) in 2.6 that can be added
c) has the source tucked away in a location you are familiar with
d) closed source

If it falls under those categories a-c, then probably feasible, I just need to know where to find the basis. If it falls under the dreaded category d (nnedi2!) then well, I can try to recreate it, but ugh, I've been busy. I was considering writing a comparable plugin to nnedi2, but this conversion may be easier in the short term.

The busy factor also means I have limited time to set up an RSS feed, document well, etc. The downside of OSS is that it's generally poorly documented . . . I can see why now. Please, if you get a chance, put the posted build through the paces, it has a number of small tweaks which generate a measurable performance difference. I've been playing with a lot of instruction ordering and code size variability, but can only test it with my machine. It may throw up on itself under another environment. This would be good to know in advance to prevent another total mess like last time.

[Stephen R. Savage]

Average plugin: http://www.wilbertdijkhof.com/mg262/Average_v11.zip

It's actually very simple. It takes an arbitrary number of clips and weights, then calculates the weighted average (w_a * a + w_b * b + w_c * c [...]).

Edit:
@Avs developers: Why is the YV12 luma channel centered on 126?

@JoshyD: I can't tell a difference between the Y-channel differences for RGB and YUV resizing now. I think this problem is fixed for certain. Good work.

Edit2:

@JoshyD: Also, what happened to the TCPDeliver/Source plugin that ships with normal Avisynth?

[manoj4986]

Guys also need following 64 bit plugins
1)HDRAGC
2)dctfilter
3)medianblur
4)nnedi2

[Stephen R. Savage]

Guys also need following 64 bit plugins\
4)nnedi2

Good luck with that.

[squid_80]

pshufw isn't used because it's an SSE instruction, not MMX.

[turbojet]

JoshyD: Yeah you can use the benchmark results wherever you want. It was done on an Athlon II 620 at 3.4 ghz. The deadlock didn't display anything, x264.exe was using 25% cpu with no status updates. During the benchmark it seemed to me the goal with avisynth mt is hitting 90%+ CPU with the fewest number of threads with a truly multi-threaded encoder (x264 with fairly fast settings). Deciding between MT() and SetMTMode() seems to be a crap shoot and both may result in a deadlock. With a lot of research and some coding it might be possible to automatically set the optimal setmtmode or mt when it's helpful and works.

Stephen: For update notifications you can get an rss feed from the googlecode download page.

[levi]

I did some benchmarks of the common filters I use and a few slower filters here's the numbers (messy I know but I couldn't think of a better way). Trends and notes below may make more sense

Could you update your post with the full .avs scripts you used?

During the benchmark it seemed to me the goal with avisynth mt is hitting 90%+ CPU with the fewest number of threads with a truly multi-threaded encoder (x264 with fairly fast settings).

Agreed. I found the same in my testing.

Deciding between MT() and SetMTMode() seems to be a crap shoot and both may result in a deadlock. With a lot of research and some coding it might be possible to automatically set the optimal setmtmode or mt when it's helpful and works.

That would be awesome! It would also be nice to have a repository to submit & compare speeds among various filters. This database could be helpful in manually and/or programatically selecting the optimal setting.

[Blue_MiSfit]

I'm getting some nasty crashes in virtualdub x64 or x264 x64 when using the 4/12 release on an MDegrain2 script...


setmtmode(2,0)

directshowsource("E:\BluRay Rips\Extract\Extract.mkv", audio=false, fps=23.976)

assumefps("ntsc_film")

spline36resize(1280,720)
md2(150,300)

distributor


MD2 is just a little wrapper for MDegrain2... the two parameters are thSAD and thSADC respectively.

Has anyone had luck getting something like this working with the current x64 releases?

Thanks
~MiSfit

[Manao]

Hey guys

Anyone care to test the x64 version of masktools in my sig ? If it doesn't crash with mt_invert and mt_edge, then all the asm should work with 64bits asm.

[Stephen R. Savage]

I receive an unrecognized exception with both mt_edge() and mt_invert(), Manao. I tested both the -25 and -26 variants.

[Manao]

I was afraid of that :(

Can you test mt_lut("x", chroma="process") ? (that one doesn't have asm).

Oh, and just to be sure, you tested the -25-x64 and -26-x64 variant, didn't you ?

[Stephen R. Savage]

I still receive an exception with your mt_lut("x", chroma="process") command. I tried mt_masktools-25-x64.dll and mt_masktools-26-x64.dll.

[JoshyD]

For what it's worth, here's the hack job that I did on MaskTools 2.0a36. (http://www.mediafire.com/?txjumzey0jg)

It's far from pretty, but maybe can provide some basis or at least an idea or two.

FYI, there were some templates for functions that got shuffled around because ICC is a bit more strict on where you declare templates, and some other junk. I don't think I mangled the names of any of the functions, and I did some decent editing on the stack / heap management macros as well as the generic computation macros. There's just so many differences in the code it's hard to take a straight directory diff and merge the two sources selectively. One of the main reasons I haven't attempted this yet. If we're getting an officially maintained x64 version, that would be very cool.

[Manao]

You'll be interested in the modifications I made. The assembly rewrite was two fold : lots of cosmetics, and use of the new stack macros - which (ought to) supports win32, lin64 and win64. I hardly changed anything else. Now if it could only work...

I'll see tonight if I have some ideas.

Meanwhile, if you want to try and build it yourself, just be advised you'll need yasm 1.0 in order to do so.

[trevaaar]

Just tried Dehalo_alpha with the 4/12 build and output is seriously broken. The crashing with MCTemporalDenoise I said about earlier in the thread is gone now though.

[Stephen R. Savage]

Just tried Dehalo_alpha with the 4/12 build and output is seriously broken. The crashing with MCTemporalDenoise I said about earlier in the thread is gone now though.

I see no problems with DeHalo_alpha. I assume you are using a MaskTools2 modified version. In case you aren't:

function DeHalo_alpha(clip clp, float "rx", float "ry", float "darkstr", float "brightstr", float "lowsens", float "highsens", float "ss")
{
rx = default( rx, 2.0 )
ry = default( ry, 2.0 )
darkstr = default( darkstr, 1.0 )
brightstr = default( brightstr, 1.0 )
lowsens = default( lowsens, 50 )
highsens = default( highsens, 50 )
ss = default( ss, 1.5 )

LOS = string(lowsens)
HIS = string(highsens/100.0)
DRK = string(darkstr)
BRT = string(brightstr)
ox = clp.width()
oy = clp.height()

x = ox/rx
y = oy/ry
m4x = x<16?16:int(round(x/4.0)*4)
m4y = y<16?16:int(round(y/4.0)*4)
ssx = ox*ss
ssy = oy*ss
m4ssx = ssx<16?16:int(round(ssx/4.0)*4)
m4ssy = ssy<16?16:int(round(ssy/4.0)*4)

halos = clp.bicubicresize(m4x,m4y).bicubicresize(ox,oy,1,0)
are = mt_lutxy(clp.mt_expand(),clp.mt_inpand(),"x y -")
ugly = mt_lutxy(halos.mt_expand(),halos.mt_inpand(),"x y -")
so = mt_lutxy( ugly, are, "x", "y x - y 0.001 + / 255 * "+LOS+" - y 256 + 512 / "+HIS+" + *" )
lets = mt_merge(halos,clp,so)
remove = (ss==1.0) ? clp.repair(lets,1,0)
\ : clp.spline36resize(m4ssx,m4ssy)
\ .mt_logic(lets.mt_expand().bicubicresize(m4ssx,m4ssy),"min")
\ .mt_logic(lets.mt_inpand().bicubicresize(m4ssx,m4ssy),"max")
\ .spline36resize(ox,oy)
them = mt_lutxy(clp,remove,"x","x y < x x y - "+DRK+" * - x x y - "+BRT+" * - ?",U=2,V=2)

return( them )
}

[trevaaar]

Yep, that's the script I'm using. It's not an error running the script, it's garbled output. On further inspection, it only appears to do so if width is not mod8. Alignment problem somewhere?

[jpsdr]

Here's the source I'm building from. (http://www.mediafire.com/?o23z43nmj1x) If you do a wholesale diff on the directory with something like WinMerge, it's pretty easy to see where it's been hacked apart to work with x64, just look for #ifndef _AMD64_ for most of the 64bit only mods.



I'm totaly lost indeed... I'm absolutely not used with the way the asm files are writen, and i understand nothing...
I don't have (and will not install) things like WinMerge.
Can you tell me what files i need to take a look for the IEEE 1180 reference ?
I've already identify the idctref.cpp file, but it can't be the only one...

[moviefan]

I set up a fresh Windows 7 x64, SEt's Avisynth 2.5.8 MT and the required x64 plugins for GradFun2DBMod and LSFMod (RemoveGrain, AddGrainC, Repair, gradfun2db, masktools) + ffms2 all taken from the first page of this thread. I started encoding with x264.1542.x64 build from x264.nl but the encode always crashes after 1000-1500 frames. I removed the filters step by step and it still crashes when only loading the video with FFVideoSource without any filtering afterwards (ths time after 100 frames). Am I doing something wrong or is there a severe bug?

[Stephen R. Savage]

Yep, that's the script I'm using. It's not an error running the script, it's garbled output. On further inspection, it only appears to do so if width is not mod8. Alignment problem somewhere?

@ JoshyD
I have traced the problem to mt_merge(). It does not correctly process clips if they are not aligned to mod8. All other mt functions used provided correct output. You can verify the problem with the following script:


ColorBars()
ConvertToYV12()
mod4 = Crop(4, 0, 0, 0).mt_test().AddBorders(4, 0, 0, 0).Subtitle("mod4")
mod8 = Crop(8, 0, 0, 0).mt_test().AddBorders(8, 0, 0, 0).Subtitle("mod8")
Interleave(mod4, mod8)

function mt_test(clip input)
{
a = Invert(input)
b = FlipVertical(input)
return mt_merge(input, a, b)
}


Incidentally, I wonder why most programming languages don't let you set variables equal to the names of functions and data types like Avisynth does.

[kemuri-_9]

I've looked into the non-monotonic PTS warnings that x264 generates when SetMTMode is off and a resizer is used (i was using a 1920x1080 source -> Lanczos4Resize(1440,1080))
xmm6 through xmm14 are not zero and it's causing a situation a condition surrounding a double that should be false to be flagged as true and invalidating the input PTS.

this is indicating that the resizer asm code is violating the win64 calling convention by not preserving registers properly.

[JoshyD]

@kemuri-_9
You've got my number on that one.

Both MS and Intel compilers never ever conform to the published ABI originally set forth by AMD. Floats should be passed in those xmm0-xmm3 registers, but, in my experience I've never seen either compiler put this into play. So, I was sitting around watching xmm8-xmm15 being completely unused in any C++ code. I got into the habit of only coding around what the compiler I was using was going to produce. It's easy to change, it just makes the heuristics of the previous testing I've done invalid. End result, very very foolish.

I was just blown away by the fact that the compiler wasn't following spec, and as most of the interactions with Avisynth64 are from code compiled by either MS or Intel's compiler, I was greedy with my registers, not thinking that I'd even see this problem until ICC (insert ridiculously far off built) or something of the like became prevalent. Intel's all about having a great compiler to support their "awesome" silicon, and they were still shipping a product that minimally made use of x64 . . . and that can come back on them (and me).

I tucked away the code that follows spec in expectation of the day that a commercial compiler would simply comply to spec. I tested a number of cases to make sure that the registers weren't in use when the function call was made before committing to using the extra lot. My ABI compliant source is a bit out of sync with my current build, so I'll need some cycles to iterate on what's going to produce the best performance, but hopefully will have a nice little fix for the weekend. Register usage should be relatively simple to cut, some constants are kept in the registers at the top range (or lazily in xmm8 in earlier code that needs updating anyhow), a memory reference here and there shouldn't be too painful.

If you didn't research this, I personally am not familiar enough with the build practices of GCC (and derivatives like MinGW) nor the x264 source itself, it would have taken some time to realize the root cause. It's interesting from an academic standpoint. My familiarity of the x264 source stops at what is integrated into MVtool2s, and I had never seen the devs go beyond 8 XMM registers (in the functions borrowed in MVTools2) at the asm level until r1531 apparently. Is the double from the compiler or assembly?

As an aside, I've never broken spec on the other ASM. Performance impact of not explicitly defining the extra register use at the machine code level will likely be mitigated by the an out of order execution engine on silicon anyhow (unless you're encoding on Atom, which is just silly) as well as the fairly large / efficient caches on modern architectures . I just want to "get it right" before packaging it up all nice and pretty.

@Stephen
The mod 8 problem is most likely a problem with a direct conversion of the routines that relied on a parameter being mod 4, but when you move to x64, it gets changed to 8 . . . and you loose granularity. Manao's code is REALLY flexible, and was written with an incredible amount of reuse in mind. Unfortunately, there's going to be corner cases that don't get seen for a bit. If he's going forth with an official x64 build, he may have a better idea of where the underlying problem, and have a particular way he'd like to solve it. I'm willing to help at any turn though.

Oh, and the compiler rant above happens to coincide with your question of setting the function name the same as a variable. Compilers have to take what is known about the language syntax, assign variables in their workspace to various logic functions, do logic minimization, see what resources can be shared, where there will be constraints, etc.

Now, compilers are written by humans. I guess the main goal would be efficiency. If you name instantiate your class "Cat" as "Cat" it introduces confusion and overhead into process. Consider naming your cat "cat" in the real world, when speaking to other humans (the english language being our syntax in this case), you're going to run into cases where if not known a priori that you had a pet cat named "cat" they would have no idea how to distinguish the two in conversation.

The difference being that I can learn that your cat is named cat, compilers have no memory, and lack a good method of learning. We can build in some heuristics and some neat tricks, but we scorn the programmer who wants us to complicate our compiler to understand the difference between variable cat and function/class cat. We can mangle the names at compile time, but that's just unneeded overhead. Just name your variable "instance_of_cat," or similar.

Compilers really are quite dumb, amazingly so in some instances. The more explicit you code in a higher level language, the easier it is to produce a quality executable. Assembly becomes attractive when the compiler balks at the code. There's a good ~3 post discussion of mt_impand/mt_expand (or similar function) in the current masktools thread. They're written in straight up C++. When you execute TGMC, these two make up ~90% of the cpu time spent in MaskTools2, which accounts for ~30% CPU time of all processes combined. That's when you say "yes please" to some good ol' assembly.

@jpsdr
I actually fixed the IEEE 1180 about two weeks ago, and forgot to post The build. (http://www.mediafire.com/?ztinlyzjjz3) I hope that's the right one, will double check and update the first post accordingly.

It's been a long week, cheers to everyone keeping an active interest in the project.

[Mr VacBob]

Windows doesn't use the x86-64 ABI, so compilers shouldn't be expected to respect it.

[Stephen R. Savage]

@JoshyD: Do you think rewriting your code to conform to the Win64 ABI will cost performance? I had heard D_S mentioning in other threads that the Win64 ABI seriously limits the effectiveness of the extra ADM64 registers.

[kemuri-_9]

If you didn't research this, I personally am not familiar enough with the build practices of GCC (and derivatives like MinGW) nor the x264 source itself, it would have taken some time to realize the root cause. It's interesting from an academic standpoint. My familiarity of the x264 source stops at what is integrated into MVtool2s, and I had never seen the devs go beyond 8 XMM registers (in the functions borrowed in MVTools2) at the asm level until r1531 apparently. Is the double from the compiler or assembly?

line 1475 from x264.c (r1563) is the aforementioned double that was exhibiting the problem, so this would be GCC/MinGW.

I haven't been maintaining my ICL patch to x264 lately, so i haven't been able to see if it similarly shows issues.

As an aside, I've never broken spec on the other ASM. Performance impact of not explicitly defining the extra register use at the machine code level will likely be mitigated by the an out of order execution engine on silicon anyhow (unless you're encoding on Atom, which is just silly) as well as the fairly large / efficient caches on modern architectures . I just want to "get it right" before packaging it up all nice and pretty.

don't feel too bad about it as the problem was found and you are willing to fix it, unlike the situation with ffmpeg where they know they violate the win64 ABI and no one really wants to fix the problem it seems.

[Manao]

For the problem regarding mod8 + mt_merge, it might actually be my fault. Try the same script with masktools 2.0a36 win32, you should (i think) get the same garbled output. And it should be fixed in the win32 dlls contained here :

http://manao4.free.fr/masktools-v2.0a39.zip

Now, this package also contains another attempt at a 64bits masktools dll. If somebody could launch DebugView on his computer, then try with this dll mt_merge, mt_invert, mt_lut, mt_edge and mt_logic, then make the resulting log file available to me, it would be great. Alternatively, if somebody could give me RDP access to a win64 machine with avisynth 64, vdub 64 and debugview installed, it would be even better.


-

[noee]

Manao:
Testing with veedub64 (AMD1.9.9) your latest x64 masktools, I get a unrecognized exception on line 493 in LSFMod() (appears to be the MT_Luxy call). My script is:

loadCplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\ffms2.dll")
ffvideosource("E:\output\test.mkv")
lsfmod()

the mkv contains SD AVC source. Works fine with the mt_Masktools posted on the first page. I have a debugview log, where could I send it? I would gladly allow RDP, but I'm dial-up. :(

[manoj4986]

Guys also need following 64 bit plugins
1)HDRAGC
2)dctfilter
3)medianblur


Anyone working on these 3 filters to bring 64 bit version?

Regards,
manoj

[mp3dom]

If I can, I would like to request a porting of the "BlockBuster" filter to x64. Thanks!

[Stephen R. Savage]

For the problem regarding mod8 + mt_merge, it might actually be my fault. Try the same script with masktools 2.0a36 win32, you should (i think) get the same garbled output. And it should be fixed in the win32 dlls contained here :

http://manao4.free.fr/masktools-v2.0a39.zip

Now, this package also contains another attempt at a 64bits masktools dll. If somebody could launch DebugView on his computer, then try with this dll mt_merge, mt_invert, mt_lut, mt_edge and mt_logic, then make the resulting log file available to me, it would be great. Alternatively, if somebody could give me RDP access to a win64 machine with avisynth 64, vdub 64 and debugview installed, it would be even better.


-
Unfortunately, I can not arrange for RDP access, as I am behind a firewall.

I tested the following script using your new test version:

...
a = Invert()
b = FlipVertical()
mt_merge(a, b)

I get an exception for mod8 and mod16 but not mod2 and mod4.

DebugView log for mt_merge, mod4: http://pastebin.com/RJw1RGq6
DebugView log for mt_merge, mod16: http://pastebin.com/3xFjqCUg

mt_invert() passes.

mt_lut("x 5 -") fails with an unknown exception. Log here: http://pastebin.com/FiD3Krs0

mt_edge() crashes VirtualDub. Log here: http://pastebin.com/HaxPekiK

I don't know how to use mt_logic, so you'll have to give me instructions here.

[noee]

Okay, yeah, I forgot about pastebin. Here's mine (http://pastebin.com/3jf9uC29) for the LSFMod() (mt_luxy fail, line 493):

[Manao]

OK, thanks guys. Stephen, can I assume that all your logs and observations on mt_merge were made with the 64bits version ?

Apart from that, I have no idea why mt_lut raises an exception while doing float operations. I guess I'm doing something that makes my dll incompatible with JoshyD's avisynth. The working of mt_invert is a good sign, and the crash in mt_edge can only be my fault. I'll get back to you later.

As a side note, I've put a win xp 64bits in a virtualbox, and i tried vdub64 + avisynth64, but it refuses to load even a simple script. Is that dll compatible with xp64 ?

[kemuri-_9]

As a side note, I've put a win xp 64bits in a virtualbox, and i tried vdub64 + avisynth64, but it refuses to load even a simple script. Is that dll compatible with xp64 ?

I use xp x64 and JoshyD's avs works fine outside of known bugs. though his install script is broken as it uses bcdedit which is only on vista and later systems. also, my avs setup is a bit different than most people's so the install bat fails horribly for me even after that.

[turbojet]

Thanks for reporting the issue of the install script on XP 64. I took a look at it and fixed it among other things. Full package with the latest dll's from the first post can be found at Mediafire (http://www.mediafire.com/?j0dncmnyzi0) or http://www.multiupload.com/4PY7ZLPSCZ

Changes:
- Checks for dll's before installing, if one is missing it informs the user
- Fixed XP x64 install (asks for user/pass if the user doesn't have admin rights)
- Fixed Vista/7 with UAC disabled for a user with no admin rights (run as administrator doesn't work with batch files in this case. now it asks for user/pass)
- Notifies Vista/7 users to run as administrator when UAC is enabled

[Manao]

As for my problem with XP 64, I just had to install all the updates. A stock XP64 SP1 wasn't working with avs64 (while it did with avs32).

I can, at last, debug :)

[Frank K Abbott]

I tried using the MT.dll from the file in hope that it would correct the horizontal "shadow line" type issue which appears right in the sentral part of the video but it still hasn't been fixed yet :( And that faint horizontal line shows up with a lot of filters when using MT with them.

[jpsdr]

Apart from that, I have no idea why mt_lut raises an exception while doing float operations.

Just in case, a little notice, if by mischance you didn't know, (even if it's more unlikely), but the x87 stack register must be preserved if the calling function may alter it (as you mention float operations).

[Manao]

Here (http://manao4.free.fr/masktools-v2.0a40.zip) is another attempt. Everything seems to work on my virtualbox. Float registers are preserved (they already were), the exception wasn't float related (I thought so at first, but it actually was in the stl)

I checked mod8 mt_merge and it worked ok. Stephen, can you confirm it ?

[Stephen R. Savage]

mt_merge works in mod4 and mod8 now. mt_invert and mt_lut now pass.

mt_edge does not appear to work with custom kernels:
mt_edge("5 10 5 0 0 0 -5 -10 -5 4", 0, 255, 0, 255)
just produces a white frame.

Edit: Incidentally, could you make MaskTools produce a more useful error when fed RGB than "unknown exception"?

[Manao]

Now that's ironic. I disabled the asm function for custom kernels because it looked wrong to me. As it happens, it was working, while the C version itself didn't work (both for win32 & win64). I'll fix that ASAP, and try to remove the assertion too.

[JoshyD]

Wow, so much development . . . very cool, trying to digest it all

@Stephen and Manao
The error handling is probably MY fault. Avisynth32 has some custom code that passes the exceptions up the chain. Unfortunately, it doesn't play nice with x64's idea of not needing segmentation. There are cases where the error simply doesn't make it to the top of the chain because the custom error passing has been killed and a suitable replacement was never coded. I just never found myself running into quirky errors that weren't a result of code that I was currently in the process of debegging.

I was also the only filter writer at that time, so, not including descriptions to go with errors I knew the cause of didn't seem like a huge deal. Now that more people are playing with the source / targeting the build it seems pertinent to re-introduce this functionality, with a more future-proof method of error handling. From the top of my head, I think Avisynth 2.6 still attaches their custom handler to a segment register, which (I don't think) plays well with x86-64.

@Manao specifically
Any chance of getting a repository for masktools set up somewhere? I may be behind the times here, but I think most of the source is still hosted by you personally. I'm in the process of offloading all my personal filter mods into my repository, as hardly any of the source is easy to find for the modified filters. Say the word, and I think I can get you access / space to save your source. At the very least, data redundancy can be your friend.

@Turbojet
On top of things as always, thanks for maintaining the installer so vigilantly. I'm mirroring it over to the main link whenever I get done cleaning my repository / adding the filters.

@kemuri-_9
That's a wonderful bit of irony on the compiler. The one compiler that adheres to the ABI is open source and screws the code from the commercial compilers. You see this happen all too often, if people would just follow the spec set forth in the first place, we wouldn't be dumbfounded when we try and use code from ___ amount of time ago and realize it's non-functional. Fixing is in progress . . .

@Stephen
The abuse of the registers in the first place only added ~0.5% to the overall performance. I was just being a kid in a candy shop with my registers. There are few things more painful to a programmer than looking at their own code from months ago, and I'm in the midst of this right now. With some smart optimization, the removal of their usage may improve performance by reducing code size and just allowing the processor to register-rename at the hardware level. It's all a matter of how the architecture handles stalls due to data dependency. Intel got really smart about this (was forced to learn a lot) when they tried to make the Netburst execution pipeline ridiculously long. Now that I'm free to target architectures that benefit from their lessons, I'm seeing very few places where the processor balks at my compliant code.

[Manao]

JoshyD : The error handling was my fault (a division by zero that started occurring when I added Y8 / YV16 / YV24 support some times ago). And if you can provide write access to a repository, I'm all for it :)

[Stephen R. Savage]

Incidentally, Avisynth64 presents a good excuse to use the try:catch statement as it was originally intended.

Say, you wanted to share a common script between 32-bit and 64-bit Avisynth without putting all your plugins in autoload. You could use try:catch to load 32-bit plugins if the 64-bit plugins aren't recognized. This is obvious, but still useful.


try { LoadPlugin("64-bit.dll" }
catch(err_msg) { LoadPlugin("32-bit.dll") }

CrossPlatformFunction()


On another note, it appears that LoadPlugin() returns either a string corresponding to a description of the plugin or the Undefined() value. The return value of Import() when last is not defined in the script is the same. Can any AVS developer clarify on how the return value of LoadPlugin() works?

[Manao]

Stephen : masktools in my signature should fix your last issue.

[Stephen R. Savage]

Stephen : masktools in my signature should fix your last issue.

I can confirm that mt_masktools 2.0a41 is stable with all scripts tested. I believe they cover mt_lut, mt_lutxy, mt_edge, mt_merge, mt_inpand/expand, and mt_logic.

Congratulations on being the second (?) developer to port one of his projects to Avs64.

Edit @JoshyD:
I just finished my first non-trivial encode (dfttest, MaskTools, MVTools, aWarpSharp, GradFun2DB, AddGrainC) using Avisynth64. It completed 10% faster than previous encodes using the 32-bit release. Good work!

Also, could you link to Manao's mt_masktools64 on the first post of this thread?

[Gavino]

On another note, it appears that LoadPlugin() returns either a string corresponding to a description of the plugin or the Undefined() value. The return value of Import() when last is not defined in the script is the same.
LoadPlugin returns the string returned by the plugin's initialisation function AvisynthPluginInit2(), or an Undefined() value if the string is null or the plugin cannot be loaded. Conventionally, this string is a description provided by the plugin writer.

The return value of Import follows the same rule for function bodies and scripts in general. See here (http://avisynth.org/mediawiki/The_full_AviSynth_grammar#Closing_Remarks).

[Stephen R. Savage]

@JoshyD: There is a bug in the horizontal resizer code for the non-sinc resizers (point, bilinear, bicubic).

The following command will trigger an exception:

PointResize(last.width, last.height, src_left=2)

[Hiritsuki]

Can anyone help me build dedup x64 ver. ?
=> http://akuvian.org/src/avisynth/dedup/

[Buggle]

At last I am trying out the newest 64 bit possibilities. The only problem I am still having is that FluxSmoothST is not yet available in x64, plus the absence of a Nero AAC x64 version. I installed the Avisynth64 fine and then encoded some stuff with MeGuix64. All fine. Until of course I just tried to use Nero, since thats a 32bit executable. It returned an error, so I started the 32bit MeGUI again to try it in there. It failed again with an error. Looking at the SysWOW64 folder, I found the avisynth.dll to be the one I previously pasted in the System32 folder. This seems to be a bug, but by what is it caused? I reinstalled stock avisynth now and made sure that the system32 folder contains the x64 dll's and the WOW64 folder the old 32 bit ones. MeGUI 32 runs fine again, I'm currently encoding an ACC file. After that I'll check the MeGUI 64. Edit: reinstalling stock aivsynth fixed the problem.

Oh and of course very, very thanks for all the hard work! Was looking forward to going full 64 bit for quite some time. Now I can :D

Edit2: On second thought, I am also experiencing the non-strictly-monotonic pts warnings (your 16-4 release plus 1570 x264). Is there an ETA on fixing this? Or should I start using those MT capabilities? I'm a bit reluctant to do that, really...

[Jeremy Duncan]

This is how I'm multithreading with the avisynth I made version 2.5.8:

setmtmode(2)
Last=ffdshow_source()
setmemorymax(550)
LimitedSharpenFaster_JD(strength=11)
LimitedSharpenFaster_JD(strength=11)
super=MSuper(pel=2, hpad=16, vpad=16)
backward_1=MAnalyse(super, chroma=false, isb=true, blksize=32, blksizev=32, search=5, searchparam=1, badrange=(-24))
forward_1=MAnalyse(super, chroma=false, isb=false, blksize=32, blksizev=32, search=5, searchparam=2, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=32, blksizev=32, thSAD=100, search=5, searchparam=1)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=32, blksizev=32, thSAD=100, search=5, searchparam=2)
MBlockFps(super, backward_2, forward_2, num=FramerateNumerator(last)*2, den=FramerateDenominator(last)*1, mode=1)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

If I used the avisynth in this thread and the mvtools, would I be able to use multithreading?
If I can use multithreading can you tell me how?
And if it's not to much can you edit the code I post here so it's compatible with this version of avisynth? :thanks:

Edit, oh yeah since some people asked if you could make some plug ins 64 bit, could you make tsp's mt.dll 64 bit too? link (http://www.avisynth.org/tsp/avisynth257MT5_src.7z)

[Lyle_JP]

I tried using the MT.dll from the file in hope that it would correct the horizontal "shadow line" type issue which appears right in the sentral part of the video but it still hasn't been fixed yet :( And that faint horizontal line shows up with a lot of filters when using MT with them.

There's nothing wrong with MT. What's happening is this: MT divides the image into smaller images, processed separately as complete images in their respective threads. Some noise reduction tools treat border areas differently than other parts of the image. MT creates a new border (or multiple borders) within the image by dividing it up. So what you are seeing is an artifact of your chosen noise reduction tool, not MT.

Fortunately, MT offers a solution anyway. It's a parameter called "overlap". Setting it to about 4 pixels wipes out most of the artifacts you're seeing.

[Stephen R. Savage]

On the wiki "benchmarks" page, the antialiasing script is quoted incorrectly. This should be changed in case anybody tries to use it, as the correct form omits the return statement:


input=AviSource("D:\testfile.avi")

ox = width(input)
oy = height(input)

aa = input.TurnRight().EEDI2(field=0).TurnLeft().EEDI2(field=0)

edge = mt_logic(mt_edge(aa, "5 10 5 0 0 0 -5 -10 -5 4", 0, 255, 0, 255),
\ mt_edge(aa, "5 0 -5 10 0 -10 5 0 -5 4", 0, 255, 0, 255), "max").Greyscale().
\ Levels(0, 0.8, 128, 0, 255, false).Spline36Resize(ox, oy, -0.5, -0.5, 2 * ox, 2 * oy)

ds = Spline36Resize(aa, ox, oy, -0.5, -0.5, 2 * ox, 2 * oy)

maskmerge = mt_merge(input, ds, edge, U=1, V=1)

MergeChroma(ds,maskmerge)


On the plugins link page, "FieldHint" is misspelled as "FeildHint".

Incidentally, it seems JoshyD's last name is... Duncan. (See: http://code.google.com/u/joshua.d.duncan/). I'm going to refrain from commenting further on that.

[Wilbert]

On the wiki (...)
Could you correct those two issues please? Thanks.

Incidentally, it seems JoshyD's last name is... Duncan.
I noticed that too (both are even from Canada). I'm sure that this is just coincidence though.

[Stephen R. Savage]

Could you correct those two issues please? Thanks.


I noticed that too (both are even from Canada). I'm sure that this is just coincidence though.

I am not authorized to edit the Avs64 wiki (http://code.google.com/p/avisynth64/w/list), because I am not a developer of Avisynth64. Perhaps Jeremy Duncan is actually a really sophisticated coder, and he's been pulling our legs all along.

@ Buggle: The non-monotonic PTS warning is a bug, but it doesn't affect encoding since Avisynth is CFR and you can always reset the framerate when muxing anyway.

Edit: Incidentally, I wonder what happened to JoshyD. He hasn't shown up in several days now.

[kemuri-_9]

@ Buggle: The non-monotonic PTS warning is a bug, but it doesn't affect encoding since Avisynth is CFR and you can always reset the framerate when muxing anyway.

the bug directly rears its head there, but there is no guarantee that the effect is not more far reaching,
possibly breaking other calculations that involve use of doubles.

[Stephen R. Savage]

http://www.megaupload.com/?d=9ZWS9HDF

FoxyShadis has updated AddGrainC to v1.5, which is more compatible with MT.

[STaRGaZeR]

I've not read the entire thread, so sorry if these questions have been asked before.

Is the source code of GradFun2DB x64 (http://www.mediafire.com/?w0trndmni3j) available?

I can't use TIVTC x64, it crashes on me. tfm() is the cause. Is this a known problem?

Thanks!

[Razinal]

I think fft3dgpu crashes the mpc-hc64.exe when I'm using the avisynth in ffdshowx64.
when i press 'page down', 'ctrl+page down' or just wait untill it tries to play the next file, mpc-hc crashes.
It plays the first video just fine but when it's time to play the next one...

What I'm using :
ffdshowx64 => I've tried rev. 3300-3408 (in ~20 rev. steps)
avisynthx64 => 4/16/2010 and 3/15/2010
mpc-hc64 => 1249-1881 (in ~100 rev. steps)
Windows => Seven x64 Pro

Settings :
mpc-hc64 => All default
ffavisynth =>

PPS=5
fft3dgpu(bw=16, bh=16, plane=0, bt=4, sigma=PPS, mode=1, precision=2, wintype=2, degrid=2)
fft3dgpu(bw=64, bh=64, plane=0, bt=4, sigma=PPS/8, sigma2=PPS/4, sigma3=PPS/2, sigma4=PPS, mode=1, precision=2, wintype=2, degrid=2)
ffdshow => except 'avisynth' I've got 'Resize' set to always @ 1024xAUTO (Lanczos), 'Levels' using 'Didee's YlevelsG' at INPUT=0-240 and OSD to 'Decoder FPS' at top-left with classic shadows (outline's alpha set to 0% and body, shadow set to 100%)
Renderer => EVR_Custom (I've also tried EVR, VMR9 (both), EVR_Synced)

Notes :
I've copied both DevIL.dll and avisynth.dll to system32 folder, have already installed 2.5.8 x32 (and the MT ver of it over the original) beforehand and ran the batch file as admin.
I have a HD4850 card using Catalyst 10.2 drivers (with dynamic contrast set off).
I've tried turning fft3dgpu's options off one by one but nothing seems make it to work.
When i turn fft3dgpu off everything is fine.
Sometimes this happens immediately after opening a file.


Which one do you think is causing this problem : fft3dgpu, mpc-hc, ffavisynth or avisynth itself?:confused:

EDIT: after updating ffdshow to 3435 everything seem to be working just fine. (I've also changed my avisynth script to below)
setmemorymax(768)
SetMTMode(1,2)
Last=ffdshow_Source()
PPS=5
last.Framerate > 30 ? Eval("""
ConvertFPS(2997, 125)
MT("Spline64Resize(1024, last.height)")
MT("Spline64Resize(last.width, 576)", SplitVertical=True)
Undot()
fft3dgpu(bw=16, bh=16, plane=0, bt=4, sigma=PPS, mode=1, precision=1, wintype=2, degrid=2)
fft3dgpu(bw=64, bh=64, plane=0, bt=4, sigma=PPS/8, sigma2=PPS/4, sigma3=PPS/2, sigma4=PPS, mode=1, precision=2, wintype=2, degrid=2)
Subtitle("VFR", align=9, size=11)
""") : Eval("""
MT("Spline64Resize(1024, last.height)")
MT("Spline64Resize(last.width, 576)", SplitVertical=True)
Undot()
fft3dgpu(bw=16, bh=16, plane=0, bt=4, sigma=PPS, mode=1, precision=1, wintype=2, degrid=2)
fft3dgpu(bw=64, bh=64, plane=0, bt=4, sigma=PPS/8, sigma2=PPS/4, sigma3=PPS/2, sigma4=PPS, mode=1, precision=2, wintype=2, degrid=2)
""")

[Hagbard23]

i've not read all the postings here - but:...great work - just what i've been looking for. Most Plugs work fine to me - except those from Squid and Kassandro. For some Reason only the Versions of "removegrain"/"Repair" presented here are working with the actual x64 Build of avisynth. Kassandros Builds presented on his own page and NICAudio.DLL (Squid's Build) is not working at all. At least - that's what i tested.... ;)

Nevertheless i've been waiting long for this. Thanks ..keep up the work!

[Bi11]

Is there a 64-bit version of deblock.dll? If not, could someone compile it for use with Deblock_QED, thanks.

[jpsdr]

I've try the following :

a=mpeg2source("File.d2v",upConv=0).DoubleWeave().Pulldown(1,3).trim(0,1774)
b=mpeg2source("File.d2v",upConv=0).DoubleWeave().Pulldown(0,2).trim(1775,3780)
c=mpeg2source("File.d2v",upConv=0).DoubleWeave().Pulldown(1,3).trim(3781,34355)
a+b+c
SetMTMode(2,6)
TempGaussMC_beta2(edimode="eedi2")
SelectEven()

But, when i process in VDub, there is only one CPU running. Where i do wrong ?

[Gavino]

when i process in VDub, there is only one CPU running. Where i do wrong ?
Try adding this line at the end of your script:
Distributor()

When using SetMTMode, this is required for applications that invoke Avisynth directly rather than via the VfW interface, but I'm not sure if VDub is one of those.

[yo4kazu]

Is there a 64-bit version of deblock.dll? If not, could someone compile it for use with Deblock_QED, thanks.

64-bit version deblock 1.2
[link removed]

[Bi11]

64-bit version deblock 1.2
deblock12_x64.7z (http://www.mediafire.com/?azj5lgzyy22)I did a quick test and deblock12_x64 works. :thanks: yo4kazu

Unfortunately, I see now Deblock_QED uses DCTFilter to interpolate the border values over the whole block. Thus, I would need a 64-bit version of DCTFilter as well. :(

If anyone wants to compile a 64-bit version of DCTFilter, maybe you could take into account what Didée said:
AFAIK, no .... DCTFilter hasn't been ported yet.

But if someone *would* port it, that would be a good occasion to eliminate the stripe-bug that DCTFilter has had ever since. ;)

[yo4kazu]

64-bit version of DCTFilter as well. :(

If anyone wants to compile a 64-bit version of DCTFilter

I can just recompile to 64-bit.
But there DCTFilter in inline-asm, I can not be rewritten.
sorry

[Robert Martens]

But, when i process in VDub, there is only one CPU running. Where i do wrong ?

Try adding this line at the end of your script:
Distributor()

When using SetMTMode, this is required for applications that invoke Avisynth directly rather than via the VfW interface, but I'm not sure if VDub is one of those.

I don't think VirtualDub is in that category, I have great success using SetMTmode in VDub without Distributor added to my scripts.

I think the issue here is the lack of SetMTmode at the head of the script; as I understand it, SetMTmode must be the first line in any script where you wish to use it, or it won't work.

The posted sample script would therefore become:

SetMTmode(2,6)
a=mpeg2source("File.d2v",upConv=0).DoubleWeave().Pulldown(1,3).trim(0,1774)
b=mpeg2source("File.d2v",upConv=0).DoubleWeave().Pulldown(0,2).trim(1775,3780)
c=mpeg2source("File.d2v",upConv=0).DoubleWeave().Pulldown(1,3).trim(3781,34355)
a+b+c
TempGaussMC_beta2(edimode="eedi2")
SelectEven()

[Bi11]

I can just recompile to 64-bit.
Yes, please recompile DCTFilter to 64-bit as it is currently, thanks.

I understand that fixing the bug would require someone who knows the code well; no need to apologize. :)
Maybe JoshyD or someone else can fix the bug and release a new version at a later time.

[JoshyD]

Could you correct those two issues please? Thanks.


I noticed that too (both are even from Canada). I'm sure that this is just coincidence though.

I'm not from Canada, nothing against Canadians, I've just been very very busy with (paid) work. I've always lived in the US. Issues shall be addressed in due time. I have not abandoned the project. Expect updates and fixes in the next week or two.

[aegisofrime]

I'm not from Canada, nothing against Canadians, I've just been very very busy with (paid) work. I've always lived in the US. Issues shall be addressed in due time. I have not abandoned the project. Expect updates and fixes in the next week or two.

WELCOME BACK! I was getting a bit worried here!

[Zep]

I was getting a bit worried here!

me too :)

[levi]

good news!

[txporter]

Been looking into using 64-bit avisynth more now that I am using Didee's TGMC script with more regularity. I have done a few searches but have been unable to tell if yadif will run with 64bit avisynth or if it needs to be re-compiled (if it is even possible). I prefer edimode=Yadif over EEDI2. Does yadif work as-is with JoshyD's 64bit avisynth or does that need to get ported over?

update: found this to be a non-issue. Can update TGMC script to use Tdeint rather than Yadif for bobbing and have everything 64-bit then.

[txporter]

@turbojet- I assume that you are running various versions of avisynth along side each other (based on your performance comparison chart). If that is true, how would I go about installing a 32bit and 64bit version of avisynth that can be called by different encoders? I do encodes with HCenc (only 32bit) as well as x264 (either 32 or 64bit available). I need to be able to continue using 32bit avisynth but am interested in trying 64bit avisynth.

[turbojet]

The 64 bit installer requires avisynth 32 bit to be installed (at least the registry pointers). It won't affect avisynth 32 bit at all. For auto-loading 64 bit dll's go into avisynth 2.5\plugins64 directory. If all the filters are auto-loaded you can use the same avs script in a 32 bit and 64 bit exe.

[txporter]

The 64 bit installer requires avisynth 32 bit to be installed (at least the registry pointers). It won't affect avisynth 32 bit at all. For auto-loading 64 bit dll's go into avisynth 2.5\plugins64 directory. If all the filters are auto-loaded you can use the same avs script in a 32 bit and 64 bit exe.

Awesome! That's the kind of info I was hoping to hear. Excited to play around with 64bit avisynth. Thanks for the installer, turbojet.

[Buggle]

Awesome! That's the kind of info I was hoping to hear. Excited to play around with 64bit avisynth. Thanks for the installer, turbojet.
Just make sure the x32 avisynth dlls and such are in the sysWOW folder and the x64 avisynth dlls are in the system32 folder.
Everything will work without a problem.

[txporter]

Just make sure the x32 avisynth dlls and such are in the sysWOW folder and the x64 avisynth dlls are in the system32 folder.
Everything will work without a problem.

Yep. Works just as you say (and turbojet). Picked up a little speed from 32-bit set up. Working with PAL video on NTSC disc (using TGMC with either yadif or tdeint edimode to convert back to 25fps progressive): 32bit (yadif) = 4.2fps, 64bit (tdeint) = 4.6fps. Need to redo 32bit with tdeint for a good comparison, but getting ~8% with it as it is.

[yo4kazu]

more 64bit build filters:
[link removed]

[squid_80]

more 64bit build filters:
[link removed]

Is there source code to go with those?

[Guest]

Link removed pending correction of GPL violations.

[yo4kazu]

Is there source code to go with those?

sorry, linked source in my site

[Guest]

What is the URL to your site?

[yo4kazu]

What is the URL to your site?

yes, rewrite x64 source code upload to mediafire and linked my site

[Guest]

I do not see an URL in your response.

[levi]

It's on his profile?: http://yo4kazu.110mb.com/

Thanks yo4kazu.

If you are taking requests, I'd like to get tomsmocomp :)

[Didée]

If anyone is able to translate the description of "RequestThreads" from Japanese into understandable English, it would be much appreciated.
(From the Google online translation I can gather not more than what the naked parameter names already tell...)

[txporter]

Few fps numbers for full episode conversion of 1 episode of Dr. Who:

Q6600, 4gb RAM, Vista64
Avisynth 2.5.8MT (32bit and 64bit)
x264 r1613 builds (rack04)

Avisynth script (I updated TGMC to use tdeint since there is no 64bit Yadif):
setmtmode(5,0)
MPEG2Source("%%~nA.d2v")
setmtmode(2)
TempGaussMC_beta2(1,1,1,edimode="tdeint",Smode=1,SLmode=1,Sbb=0,SVthin=0.0)
srestore(frate=25)
RemoveGrain(1)
setmtmode(5)
Vobsub("%%~nA.idx")

x264 parameters:
%x264% --crf 19 --preset slow --keyint 50 --sar 40:33 --tune film -o %%~nA.264 %%~nA.avs 2>%%~nA.log

32bit (non-patched build): 4.03fps, 1271.54 kbps, ~4hr 27mins
32bit (patched build): 3.89fps, 1269.62 kbps, ~4hr 36mins
64bit (non-patched build): 4.56fps, 1268.47 kbps, ~3hr 55mins
64bit (patched build): 4.58fps, 1266.54 kbps, ~3hr 55mins

Seeing 13+% improvement in fps for 64bit avisynth conversion! Very nice work, JoshyD. Don't understand why the patched build of x264 32bit was slower than non-patched. Might not be real. Only difference in plugins during the test was that both non-patched build numbers (32 and 64) were run after I updated masktools from a43 to a44.

[Chikuzen]

If anyone is able to translate the description of "RequestThreads" from Japanese into understandable English, it would be much appreciated.
(From the Google online translation I can gather not more than what the naked parameter names already tell...)

http://forum.doom9.org/showthread.php?p=1404556#post1404556

[yo4kazu]

It's on his profile?: http://yo4kazu.110mb.com/

Thanks yo4kazu.

If you are taking requests, I'd like to get tomsmocomp :)

Thanks for following.
I can't rewrite inline assembly code tomsmocomp to 64bit...

[levi]

OK, thanks for responding.

FYI, I found a new DLL (msvcr100.dll) was required but was not installed on my system while using MCTemporalDenoise. I downloaded Microsoft Visual C++ 2010 Redistributable Package (http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=bd512d9e-43c8-4655-81bf-9350143d5867&displayLang=en) & that resolved it.

What about yadif, is that easy to port to 64bit?

[yo4kazu]

What about yadif, is that easy to port to 64bit?

ok, I just finished.
[removed]
only check was run on Avisynth64

[Guest]

@yo4kazu

Stop posting GPL violating archives. You must include source code or a offer of it in the archive.

[levi]

ok, I just finished.
[removed]
only check was run on Avisynth64

Cool, thanks!

It might be better to post the link to your site (where you already have the source posted). So there is no perceived GPL issues.

[Guest]

Cool, thanks!

It might be better to post the link to your site (where you already have the source posted). So there is no perceived GPL issues. Yes. Simply include a link in the archive.

Joshy, you need to do the same thing.

Your efforts are greatly appreciated but we have to support and abide by GPL. Thank you.

[Guest]

Running this script with the 4-16 version of Avisynth 64 produces a green screen:

version()
converttoyuy2()

Am I doing something wrong? Thank you.

EDIT: At first just version() worked, now after running the script above, it produces only a gray screen. Please advise. My porting efforts will be wasted if Avisynth 64 is not at least a little bit usable. Hopefully I am just ignorant.

[nixo]

Works here. Opening with Veedub64 and exporting to image gives me this:

http://i49.tinypic.com/2uj430h.jpg

I think it is recommended to always use SetMTMode with this version but here it doesn't seem to make a difference.

[Guest]

I think my PC went to sleep mode between when it worked and when it didn't. I will reboot when I get home to test that.
Thanks for your results.

[Didée]

Not-helpful post:
Sorry I've no idea what's going wrong on your side. All I can tell is that Avisynth64 is working quite well for me.

http://img821.imageshack.us/img821/50/avisynth64.th.png (http://img821.imageshack.us/i/avisynth64.png/)

My setup process was as painless as this:

- installed Avisynth 2.5.8 (32bit, standard)
- installed Avisynth-x86_64 as linked in the OP
- Installed VeeDub64, and all Avisynth64-Plugins I could get my fingers on

and bingo, everything was running as expected.

Anything special about your OS, or the application(s) you're using?
Accidentially cancelled an UAC message during Avisynth64 installation?
By chance, are you using a restricted user account?

[Guest]

Anything special about your OS, or the application(s) you're using?
Accidentially cancelled an UAC message during Avisynth64 installation?
By chance, are you using a restricted user account? No everything went fine as you described. I'll run through it again this evening.

Remember, it worked once and showed the Version frame in VeeDub64.

[Guest]

Whoa. Comedy of (my) errors.

Somehow I turned off the display planes. :eek:

When I disabled DirectX display in VeeDub, the green screen goes away too.

Now I'm cooking with gas. :)

[Buggle]

I also have a bug to mention. I normally crop my videos, then apply for instance noise reduction like degrainmedian, and then resize to appropriate proportion and size and subsequently encode. This has never been proven to be a problem when using the 32-bit stuff and pipe to x264_64.

Avisynth64 however crashes very often now, using the above sequence, probably because the input for DeGrainMedian64 to work with is non-mod16? When I move DGM to before cropping, the videos where the error turned up (majority), work fine.
I'm guessing this is probably a bug in the DeGrainMedian64 filter.

[tedkunich]

JoshyD,

If you have nothing else on your plate, ;) I have a couple of requests:

Deflicker
Depan
DepanEstimate
autolevels
removegrain

Thanks,
Ted

[lych_necross]

Has anyone heard from JoshyD? His last activity was on May 22. I'm beginning to worry... :confused:

[Joachim Buambeki]

May I request a 64bit version of ImageMagick (http://forum.doom9.org/showthread.php?t=135928)?

I read over at doom10 the warning about the monotonic thing in x264 is caused by the resizer code that violates whoknowswhat.
This is does not harm my encode, right?

Best Regards
David

[darkelf5]

Is there a 64 bit DGAVCDecode, or we should use ffindex?

[Guest]

DGAVCDec is a figment of your imagination. It no longer exists.

[Frogger13]

Hi there,

I did also give a try to AviSynth64 but I am running into problems when trying to use FFT3DFilter or FFT3DGPU. When I dont use any filter every thing is ok and encoding goes on. Hoever if I use the filters I get following error:

avs [error]: Evaluate: Unrecognized exception!
(D:\VIDEO_TS\make.avs, line 15)
x264 [error]: could not open input file `D:\VIDEO_TS\make.avs'

The system is Windows XP 64. When I use other Filters like Undot, it works.

I also put d3dx9_42.dll (64 bit version from microsoft installer) into System32 as x264 was complaining if I didn't (probably when x264 loaded AviSynth64 which scanned plugin64 dir...) :confused:

Any Help is Appreciated.

Here's the AVS Script:

# SOURCE
DirectShowSource("D:\Temp\Test.wmv", fps=29.970, audio=false, convertfps=true)
# TRIM
#trim(startframe,endframe)
# DEINTERLACE
#deinterlace
# CROPPING
crop( 2, 0, -2, 0)

# RESIZING
LanczosResize(720,400) # Lanczos (Sharp)
# DENOISING: choose one combination (or none)
Undot()
# 1) little noise
FFT3DFilter(sigma=3)
#FFT3DGPU(sigma=3)
#FluxSmoothST(3,7)
#FluxSmoothT(3)
# 2) medium noise
#FluxSmoothST(7,7)
#FluxSmoothT(7)
# 3) heavy noise
#FluxSmoothST(10,15)
#FluxSmoothT(10)

Edit: I see AviSynth64 is MT version and I just read this on another post. It's no help for me but here is it:

Avisynth 2.5.8 MT is derived from SEt's modified builds, so you were wasting your time, the system exception handling is missing from those builds. As I said try 2.5.7 and 2.6.0alpha their code alignment may just be different enough to get a sane error report.

[Frogger13]

Actually I solved the problem after a LOT of trial and error, restoring Windows from Image a couple of times :D

I had 2 Problems:

First of all, unlike the x32 versions of the FFT3D[Filter|GPU], the libfftw3f-3.dll must not be renamed FFTW3.dll (This caused FFT3DFilter to crash)
As for DirectX and FFT3DGPU x64, I am using an installer for the video tools and dont want to install full DirectX. And there was the problem: the file D3DX9_42.dll required another file D3DCompiler_42.dll. So for anyone else trying to put just the minimal amount of files: dont forget to put those two files from DirectX Redistribuable package (you can unzip it with winrar, and also the CABs which contain the required DLLs)

Speed Increase is dramatic at close to thrilling 34%!!!! :p

Edit: the x64 DLLs for System32 Directory can be found here http://www.mediafire.com/file/jkozznmnyj0/D3Dxxx_42 DLLs.rar

[levi]

Cool, thanks for sharing your results.

[Emulgator]

Many thanks to JoshyD and all who helped fixing and finding the parts together !

Today I gave 64bit a try and finally it worked
after reading all the posts and finding valuable information about missing dlls and their versions:

PAL-DV 720x576x25i to 720x576x25p uncompressed:
SetMTMode=(8)
TGMC with Edimode=EEDI, tr2=3, sharpness=2.8,
merge(selecteven,selectodd) to blend fields (dead Video8 camcorder tape)

OS: Win7U64, CPU i7-920XM@2.0Ghz
CPU Load 12%

Avisynth32 in VirtualDub32bit: 3.2fps
Avisynth64 in Veedub64bit: 4.0fps

[EmuAGR]

Hi.

Can someone compile this (http://forum.doom9.org/showthread.php?p=599828#post599828) filter? I couldn't. :(

And what about a NEEDI3 x64, could tritical compile it?

[Guest]

Can someone compile this (http://forum.doom9.org/showthread.php?p=599828#post599828) filter? I couldn't. What error did you run into?

[EmuAGR]

avisynth.h:312: error: 'operator new' takes type 'size_t' ('long long unsigned int') as first parameter

[Guest]

Change that line to:

void* operator new(size_t size);

Wasn't the error message clear enough?

[EmuAGR]

My knowledge is minimal C, and I'm noob at compiling. :P

I've just changed that, but...

C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text+0x1f5): undefined reference to `__gxx_personality_sj0'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text+0x6a4): undefined reference to `__gxx_personality_sj0'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text+0x7d2): undefined reference to `operator new(unsigned long long)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text+0x919): undefined reference to `operator delete(void*)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN5IClipD2Ev[IClip::~IClip()]+0x28): undefined reference to `operator delete(void*)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN5IClipD1Ev[IClip::~IClip()]+0x28): undefined reference to `operator delete(void*)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN5IClipD0Ev[IClip::~IClip()]+0x28): undefined reference to `operator delete(void*)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN18GenericVideoFilterC2E5PClip[GenericVideoFilter::GenericVideoFilter(PClip)]+0x6d): undefined reference to `__gxx_personality_sj0'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN18GenericVideoFilterD2Ev[GenericVideoFilter::~GenericVideoFilter()]+0x69): undefined reference to `__gxx_personality_sj0'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN18GenericVideoFilterD2Ev[GenericVideoFilter::~GenericVideoFilter()]+0x143): undefined reference to `operator delete(void*)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN18GenericVideoFilterD1Ev[GenericVideoFilter::~GenericVideoFilter()]+0x69): undefined reference to `__gxx_personality_sj0'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN18GenericVideoFilterD1Ev[GenericVideoFilter::~GenericVideoFilter()]+0x143): undefined reference to `operator delete(void*)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN18GenericVideoFilterD0Ev[GenericVideoFilter::~GenericVideoFilter()]+0x69): undefined reference to `__gxx_personality_sj0'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN18GenericVideoFilterD0Ev[GenericVideoFilter::~GenericVideoFilter()]+0x143): undefined reference to `operator delete(void*)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN12ChangeColourC1E5PClipiiiiP18IScriptEnvironment[ChangeColour::ChangeColour(PClip, int, int, int, int, IScriptEnvironment*)]+0x75): undefined reference to `__gxx_personality_sj0'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.data$_ZTV5IClip[vtable for IClip]+0x18): undefined reference to `__cxa_pure_virtual'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.data$_ZTV5IClip[vtable for IClip]+0x20): undefined reference to `__cxa_pure_virtual'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.data$_ZTV5IClip[vtable for IClip]+0x28): undefined reference to `__cxa_pure_virtual'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.data$_ZTV5IClip[vtable for IClip]+0x30): undefined reference to `__cxa_pure_virtual'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.data$_ZTV5IClip[vtable for IClip]+0x38): undefined reference to `__cxa_pure_virtual'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.data$_ZTI12ChangeColour[typeinfo for ChangeColour]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.data$_ZTI18GenericVideoFilter[typeinfo for GenericVideoFilter]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.data$_ZTI5IClip[typeinfo for IClip]+0x0):undefined reference to `vtable for __cxxabiv1::__class_type_info'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN12ChangeColourD1Ev[ChangeColour::~ChangeColour()]+0x34): undefined reference to `operator delete(void*)'
C:\Temp\cclalD4D.o:ChangeColour.cpp:(.text$_ZN12ChangeColourD0Ev[ChangeColour::~ChangeColour()]+0x34): undefined reference to `operator delete(void*)'
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.4.4/../../../../x86_64-w64-mingw32/lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o): In function `main':
g:\buildbot\vista64-mingw32\mingw-x86-x86_64\build\build\mingw\obj/../../../build/mingw/mingw-w64-crt/crt/crt0_c.c:18: undefined reference to `WinMain'
collect2: ld returned 1 exit status

[Guest]

LOL. Did you set up your library paths correctly?

What are you building this with?

BTW, this is now off-topic in this thread. Please post a new thread in Development.

[EmuAGR]

I think so, at least I can compile my own things. I'm using GCC 4.4.4.

[kemuri-_9]

I think so, at least I can compile my own things. I'm using GCC 4.4.4.

you can not use gcc, or more appropriately you should be using g++ since it's C++ (but g++ doesn't work either), to compile avisynth plugins that are using avisynth.h

[Artanis]

changecolour x64 (http://www.sendspace.com/file/qj8p2m)

Compiled with visual studio 2010, so you will need to download the vc++ 2010 redist (http://www.microsoft.com/downloads/details.aspx?FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867&displaylang=en).

I didn't test it much, just enough to see that it loads and does it's work in a simple one-color scene.

btw, I'm impressed by the amount of crap that visual studio generates just to open the project...

[tormento]

Latest DFTTest is out. Anyone compiled it to x64?

[Manao]

I didn't find rawsource x64, and I needed it. So I repackaged the whole thing here (http://manao4.free.fr/rawsource.zip). x64 et x86, avs 2.5 & 2.6 dll are present.

[levi]

Thanks for continuing to support this guys. It is appreciated.

[[ReX]]

I'm having some problems.

The x64 version of Avisynth used to work fine, but now it stopped working.
The same problem is happening with MeGUI and Virtualdub, when I load the Avisynth script, it freezes the program for one or two minutes and then only show a gray video.

I uninstalled both Avisynth x86 and x64 and installed again, still the same.

[Adub]

Remove all of the plugins in your plugin (except for directshow.dll) folder and then put them back one at a time. Chances are you have an offending plugin somewhere in that directory that autoloads and hangs, thus causing your issue.

Posting your script is also a good idea.

[[ReX]]

I don't have any additional plugin, only the defaults and it was happening with any script.

Anyway, I updated my codecs and it's working now...

[jpsdr]

As anyone be able to use SetMTMode on TGMC without having a crash ? (EEDI2 mode used).

[Didée]

Only with (very) few threads. The more threads being used, the more likely it is to crash, and the sooner the crash will happen.

It's not specifically TGMC. I get the same crashes with a "simple" MDegrain2 or MDegrain3.

It's not even specifically the x64 build. I get the same crashes with the 32bit builds.


Avisynth-MT generally faulty? MVTools faulty? Both together? I don't know.

All I know from personal experience is that MVTools+SetMTmode is great for benchmarking, but not practically usable.

[aegisofrime]

Only with (very) few threads. The more threads being used, the more likely it is to crash, and the sooner the crash will happen.

It's not specifically TGMC. I get the same crashes with a "simple" MDegrain2 or MDegrain3.

It's not even specifically the x64 build. I get the same crashes with the 32bit builds.


Avisynth-MT generally faulty? MVTools faulty? Both together? I don't know.

All I know from personal experience is that MVTools+SetMTmode is great for benchmarking, but not practically usable.

SetMTMode(2,4)
DGdecode_mpeg2source("D:\Raws\Vid.d2v")
TempGaussMC_Beta2u(2, 1, 1, EdiMode="NNEDI2")

Distributor()

A script like this runs flawlessly for me most of the time. If cropping out black lines and resizing is needed, I find it's wise to put a SetMTMode(5,4) before them.

Phenom II 955 here.

Also, this is with DVD content. With 1080i content it's almost impossible not to crash with the above script. In that case, I have to remove MT-ing. The result as you can guess is that the script runs slower than your proverbial molasses.

[Vincent Vega]

the GradFun2DB x64 zip does not come with a readme or link to new forum discussion. does it require GradFunkMirror.avsi like before or not? If it does, can I use the old avsi script? does it need to be modified?

thanks.

[jpsdr]

Ok, you have the same problems as me. I've made first some little tests with DVD resolution, seemed fine, but when tried 1080i, always crash.

[nixo]

I got crashes not only with HD but also with DVD resolutions. The encode may have run for an hour or two, but eventually I'd get either a vdub live lock or a crash in MVTools.

Now I just split my avs and run 3 or 4 single-threaded encodes at the same time. So far that's been rock stable, although it does require a good bit of memory.

[txporter]

Ok, you have the same problems as me. I've made first some little tests with DVD resolution, seemed fine, but when tried 1080i, always crash.

I see the same thing. 1080i material seems to use too much memory. I was trying to benchmark various TGMC settings with a 1080i clip and found that all script settings would result in memory usage going to 2+ gb and then a crash. Script was simply:
setmtmode(5,0)
MPEG2Source("video1.d2v")
setmtmode(2)
TempGaussMC_beta2(various settings changes here)

Interestingly, I was able to process 6 - 1hr episodes of 1080i material using the following script (clip used for speed testing was from the first of these 1 hr episodes):
setmtmode(5,0)
LoadCPlugin("C:\Program Files (x86)\Avisynth 2.5\plugins64\yadif.dll")
MPEG2Source("video.d2v",cpu=3)
setmtmode(2)
lanczosresize(1280, height)
TempGaussMC_beta2(1,1,0,4,0,0,edimode="Yadif",Smode=1,SLmode=1,Sbb=0,SVthin=0.0,pelsearch=1)
srestore(frate=25)
lanczosresize(width, 720)
removegrain(1)

I tried again to do the speed testing by resizing the video [mpeg2source+resize+tgmc (without the srestore call)] and the memory usage still goes 2+ gb and crashes. Is srestore somehow limiting the # of frames placed into memory or something?

update: Also wanted to add that both Avisynth64 or 32 see crashes with 1080i source material. All tests were done with setmtmode, so cannot say that is the cause or not. I have zero issues running setmtmode + TGMC with DVD source material.

update2: Confirmed findings from others that setmtmode is the problem. Eliminating setmtmode calls allows Avisynth32 (non-64bit system atm) to complete 1080i TGMC script with no issues.

[tormento]

Now I just split my avs and run 3 or 4 single-threaded encodes at the same time.
How? Could you post your scripts?

[nixo]

Ehh, it's just a simple trim() and outputting to lossless.

[kartman_canada]

I posted the following in the MeGUI x64 thread too... AVS script included:

LoadPlugin("C:\Program Files\MeGUI_64\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VIDEO_TS\VTS_06_1.d2v", info=3)
LoadPlugin("C:\Program Files\MeGUI_64\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
crop( 4, 54, -4, -58)

LanczosResize(712,302) # Lanczos (Sharp)
#denoise


I'm not sure where my issue sits... I've been using MuGUI x64 for a while now but I don't recall doing anything but crops. Today, I moved to process a DVD. When I apply the crop, no issues but when I add a "lanczosresize" line to the AVS script, MeGUI crashes.

Might this be because the resize function is pulling an x86 build from the original avisynth install and not an x64 version?

I'm just guessing... is there an update out there or am I missing something else? Maybe an install issue?

[kemuri-_9]

Files\MeGUI_64\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VIDEO_TS\VTS_06_1.d2v", info=3)
LoadPlugin("C:\Program Files\MeGUI_64\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
crop( 4, 54, -4, -58)

LanczosResize(712,302) # Lanczos (Sharp)
#denoise[/CODE]

I'm not sure where my issue sits... I've been using MuGUI x64 for a while now but I don't recall doing anything but crops. Today, I moved to process a DVD. When I apply the crop, no issues but when I add a "lanczosresize" line to the AVS script, MeGUI crashes.

no, it's already been mentioned in this thread that the resize functions violate the windows x86_64 calling convention causing either crashes or other odd issues when they are used.
As they are known to be broken in this fashion, they are to be used at-your-own-risk.

SWScale() in ffms2/ffmpegsource could be an alternate choice,
but it is also at-your-own-risk as ffmpeg is known to also violate the windows x86_64 calling convention,
though I've never had problems with it myself.

(this is the part where everyone chips in their hate over the windows x86_64 calling convention)

[SubJunk]

I've never had problems resizing with any versions and I do it all the time

[kemuri-_9]

I've never had problems resizing with any versions and I do it all the time

doesn't mean it's not a problem.
most people mask the issue to being unnoticeable outside of avisynth by using SetMTMode

[SubJunk]

doesn't mean it's not a problem.
most people mask the issue to being unnoticeable outside of avisynth by using SetMTModeIt's true, I do use MT

[kartman_canada]

doesn't mean it's not a problem.
most people mask the issue to being unnoticeable outside of avisynth by using SetMTMode

Sorry... I must have searched using a wrong key words. Now that I realize it's an issue seen by others, what are the work around(s)? are the options detailed earlier in the thread too?

1) switch back to x86 from x64?
2) ???

[aegisofrime]

I posted the following in the MeGUI x64 thread too... AVS script included:

LoadPlugin("C:\Program Files\MeGUI_64\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VIDEO_TS\VTS_06_1.d2v", info=3)
LoadPlugin("C:\Program Files\MeGUI_64\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
crop( 4, 54, -4, -58)

LanczosResize(712,302) # Lanczos (Sharp)
#denoise


I'm not sure where my issue sits... I've been using MuGUI x64 for a while now but I don't recall doing anything but crops. Today, I moved to process a DVD. When I apply the crop, no issues but when I add a "lanczosresize" line to the AVS script, MeGUI crashes.

Might this be because the resize function is pulling an x86 build from the original avisynth install and not an x64 version?

I'm just guessing... is there an update out there or am I missing something else? Maybe an install issue?

Put a SetMTMode(5) before your resize functions. I do this and I don't get a single crash.

[kartman_canada]

Put a SetMTMode(5) before your resize functions. I do this and I don't get a single crash.

Possible I have something else going on? Added SetMTMode(5) to the AVS script but I'm still getting a crash...

Starting to get a bit muddled... Is this a problem stemming from the fact I'm using Win7 x64 as an OS or can I move to the 32bit MeGUI/Avisynth?

Searched SWSScale from another post... I need to take a step back though as this wasn't clear how to implement as part of an AVS script.

From my script above, can I get FFDSHOW to act as the MPEG2 decoder? Input is a D2V with a VOB source... Maybe I can scale using ffdshow?

thanx for the help. I think I need to try a clean install as I've been messing about now trying different things... not confident I've not messed something up. :(

[kemuri-_9]

Searched SWSScale from another post... I need to take a step back though as this wasn't clear how to implement as part of an AVS script.

i doesn't appear to be well documented, so here's a quick shot
SWScale( PClip clip, int width, int height, string "resizer" = "bicubic", string "colorspace" = "" )

available resizers are
"fast_bilinear", "bilinear", "bicubic", "x" (experimental), "point", "area", "bicublin", "gauss", "sinc", "lanczos", and "spline"

available output colorspaces are currently
"yv12", "yuy2", "rgb24", "rgb32", and "" (no change)

(NOTE: it's a generally bad idea to use swscale to vertically resize interlaced material - this means within ffdshow too)

[kartman_canada]

i doesn't appear to be well documented, so here's a quick shot
SWScale( PClip clip, int width, int height, string "resizer" = "bicubic", string "colorspace" = "" )

available resizers are
"fast_bilinear", "bilinear", "bicubic", "x" (experimental), "point", "area", "bicublin", "gauss", "sinc", "lanczos", and "spline"

available output colorspaces are currently
"yv12", "yuy2", "rgb24", "rgb32", and "" (no change)

(NOTE: it's a generally bad idea to use swscale to vertically resize interlaced material - this means within ffdshow too)

What DLL do I have to load or package needs installing before I can call SWScale() in an AVS script?

[kemuri-_9]

What DLL do I have to load or package needs installing before I can call SWScale() in an AVS script?

it's included with ffmpegsource/ffms2.dll
the 64bit version of it is on the front page of this thread, though it neglects to mention that you load it with LoadCPlugin.
it's been a while since i've built or worked on the plugin, so let me know if you find issues.

[kartman_canada]

i doesn't appear to be well documented, so here's a quick shot
SWScale( PClip clip, int width, int height, string "resizer" = "bicubic", string "colorspace" = "" )

available resizers are
"fast_bilinear", "bilinear", "bicubic", "x" (experimental), "point", "area", "bicublin", "gauss", "sinc", "lanczos", and "spline"

available output colorspaces are currently
"yv12", "yuy2", "rgb24", "rgb32", and "" (no change)

(NOTE: it's a generally bad idea to use swscale to vertically resize interlaced material - this means within ffdshow too)

My material is progressive so i should be OK. ffms2.dll loaded. AVS script line:

SWScale (712,302,"lanczos","")

I'm sure this is formatted incorrectly... can you correct? I seem to get a couple of good frames if I preview the script and play... then a crash.

Decided to go for an encode anyways... Using MeGUI, when I add the job, I get a complaint that the clip is I420 and not YV12. I changed the above line to SWScale (712,302,"lanczos","yv12")... still complaining. Allowed MeGUI to append ConvertToYV12()... still complaining.

Grrrrr....

LoadPlugin("C:\Program Files\MeGUI_64\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VIDEO_TS\VTS_06_1.d2v", info=3)
LoadPlugin("C:\Program Files\MeGUI_64\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
crop( 4, 54, -4, -58)
LoadCPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64/ffms2.dll")
SWScale(712,302,"lanczos","yv12")

[kemuri-_9]

My material is progressive so i should be OK. ffms2.dll loaded. AVS script line:
SWScale (712,302,"lanczos","")

I'm sure this is formatted incorrectly... can you correct? I seem to get a couple of good frames if I preview the script and play... then a crash.

No, It looks fine enough.
I am not able to replicate a crash in x264 r1659 nor vdub 1.9.6 though.

Decided to go for an encode anyways... Using MeGUI, when I add the job, I get a complaint that the clip is I420 and not YV12. I changed the above line to SWScale (712,302,"lanczos","yv12")... still complaining. Allowed MeGUI to append ConvertToYV12()... still complaining.
Grrrrr....


Ah, I was unaware of MeGUI being this braindead (I never use it, since it has a history of irritating me to no ends with its consistent stupidities):
SWScale() does flag the video as being I420 instead of YV12 when outputting YV12 video.
(SWScale does not formally support YV12 itself, but due to the below reasoning this is not particularly an issue in most cases)

the difference between I420 and YV12 is simply
I420 is Y-U-V. YV12 is Y-V-U
- the chroma planes are simply swapped in memory
but the way avisynth handles acquiring the plane pointers, the above difference is generally unnoticeable.
for this same reason, ConvertToYV12() is a NOOP (No operation) when the video is I420 (in avs 2.5.x that is, in 2.6.0 looks like there might be a bug in this situation)

But it appears MeGUI is not capable of handling this properly either way, so I dare say to file a bug report to MeGUI.
It appears that you will not be able to use SWScale if you plan to use MeGUI due to the above, unless it fixes itself sometime rather soon

[elguaxo]

I dare say to file a bug report to MeGUI.

I reported it 2 years ago and it seems the bug is still there.
http://forum.doom9.org/showthread.php?p=1157503#post1157503

edit: back then I was using AviSynth 2.5.6 or 2.5.7

[quantum5uicid3]

nvm it's pointless

[Buggle]

Is there any news on the non-monotonic bug experienced in x264 yet? Judging from the reactions in the thread on doom10, it was supposed to be caused by AVS64.

[Stephen R. Savage]

The real question is where JoshyD went. The project is essentially dead without him, as he was the only developer. Last I heard, he was rewriting the resize code to fix the PTS warning.

[cretindesalpes]

I also asked him to send me the source code of a few plug-ins (as he doesn't publish the modified source code, whatever the original plug-in license) two weeks ago, and still no reply...

[Underground78]

I also asked him to send me the source code of a few plug-ins (as he doesn't publish the modified source code, whatever the original plug-in license) two weeks ago, and still no reply...

"Last Activity: 23rd May 2010 08:18"

[Didée]

Yeah, the pace of development has broken down noticeably ...

One thing I'm still missing on the side of plugins is: Median-filtering (spatial and temporal). Here are two rough scripts that mimick two not-yet-ported-to-x64 filters:

TemporalMedian1 is, big surprise, a radius=1 temporal median filter (like MedianBlurT(0,0,0,1) or Clense(reduceflicker=false)

ScriptedFluxSmoothT is, big surprise, a scripted version of the FluxSmoothT filter.

For the moment, both filters support only YV12 input. Lunchbreaks are short.
YUY2 will be added somewhen later, maybe also RGB. Also radius=2 temporal median, by using the nice Median2 script (http://forum.doom9.org/showthread.php?p=1169990&highlight=median2#post1169990) of g-force.

function TemporalMedian1(clip c, int "Y", int "U", int "V")
{
Y = default(Y,3)
U = default(U,2)
V = default(V,2)
p1 = c.selectevery(1,-1)
n1 = c.selectevery(1, 1)
mt_logic( mt_logic(c,p1,"min",Y=Y,U=U,V=V),
\ mt_logic(c,n1,"min",Y=Y,U=U,V=V),
\ "max",Y=Y,U=U,V=V)
mt_logic( last,
\ mt_logic(p1,n1,"min",Y=Y,U=U,V=V),
\ "max",Y=Y,U=U,V=V)
}


function ScriptedFluxSmoothT(clip c, int "th")
{
th = default(th,7)
diff1 = mt_makediff(c,c.TemporalMedian1(3,3,3),U=3,V=3)
diff2 = mt_makediff(c,c.TemporalSoften(1,th,th,255,2),U=3,V=3)
DD = mt_lutxy(diff1,diff2,"x 128 - abs 1 < 128 y ?",U=3,V=3)
c.mt_makediff(DD,U=3,V=3)
}

Better to have something, than nothing at all.

[pokazene_maslo]

Hello, I found a strange bug. First of all here is my avs script:global MeGUI_darx = 31
global MeGUI_dary = 17
LoadPlugin("D:\Install\meGUIx64\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\work\VIDEO_TS\VTS_01_1.d2v", info=3)
LoadPlugin("d:\Install\meGUIx64\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, interlaced=true, threads=0)
LoadPlugin("D:\Install\meGUIx64\tools\avisynth_plugin\TDeint.dll")
TDeint(full=false)
fft3dGPU(sigma=2.2, precision=2, sharpen=0, plane=4)
trim(188903,0)

when i try to open this script in megui following error will come up: "MeGUI encountered a fatal error and may not be able to proceed. Reason: attempted to read or write protected memory. This is often an indication that other memory is corrupt."
opening this script in virtual dub is fine until I start playback then this error will come up: "Avisynth read error: Avisynth: unknown exception."
When I disable TDeint in that script everything is running fine. When I disable fft3dgpu and leave Tdeint enabled everything is running fine.
Seems like those two filters don't like each other :)

[SaintDeath]

Well I know i am new to these been reading alot in the forum. but i would like to request 64 bit of these 32 bit dlls.

Deen
TemporalCleaner
SangNom
nnedi

[kjh7232]

I downloaded ffms2.dll and ffmsindex.exe x64 ver from this thread and ffms2.avsi from ffms2 project. but I got a error when use "FFmpegSource2". This error is 'There is no function named "ffindex"'. Why This problem happened?

P.S Sorry for my bad English ;)

[Alf Bundy]

I think the function's name is

FFvideoSource() #for video
FFaudioSource() #for audio

At least, it is with the 32bit version of ffms2 ...

[onesloth]

I downloaded ffms2.dll and ffmsindex.exe x64 ver from this thread and ffms2.avsi from ffms2 project. but I got a error when use "FFmpegSource2". This error is 'There is no function named "ffindex"'. Why This problem happened?

P.S Sorry for my bad English ;)

You need to load the 64-bit ffms2.dll with LoadCPlugin() in the beginning of the script.

[Alf Bundy]

I have a dumb problem : I've just installed Avisynth x64 and all is working fine (preview of my scripts with VDx64 & encoding them through MeGUI x64). :)

But sometimes I use plugins which don't have a x64 version yet. Unfortunately it seems that I can't use avisynth 32bit anymore.
If I add a 32bit-only plugin in my script, both VD x32 & x64 complains ! :(

VDmod 32bit says : AVI import filter error (unknown) (80040154)
VD x64 says : LoadPlugin : unable to load "C:\Program File (x86)\AviSynth 2.5\plugins\blockbuster.dll"

I tried LoadPlugin, LoadCPlugin and Load_Stdcall_Plugin
If I remove the 32bit plugin, the script is loading fine again in VDx64.

Is there some basic information that I missed when reading this topic ?
Because I wanted to use x64 when possible, but I didn't expected to lose the ability of using 32bit avisynth when needed.

[cegy]

someone should really change the title to x64 as it don't have anything to do with x86 nor is there is any x86 version of it aswelll !! :confused:

[Lyle_JP]

I have a dumb problem : I've just installed Avisynth x64 and all is working fine (preview of my scripts with VDx64 & encoding them through MeGUI x64). :)

But sometimes I use plugins which don't have a x64 version yet. Unfortunately it seems that I can't use avisynth 32bit anymore.

It's not a dumb problem, it's a dumb feature! :p

But seriously, x64 avisynth requires x64 plugins. No exceptions.

[Alf Bundy]

So it's not a mistake on my side, I can't use 32bit avisynth when x64 version is installed ?

That's good to know. So I won't have a headache figuring what I've done wrong.
And x64 version is easy and fast to uninstal/reinstall anyway, so when I'll need to use a 32bit plugin, I will temporarily uninstall avisynthx64.

Thanks.

[Stephen R. Savage]

someone should really change the title to x64 as it don't have anything to do with x86 nor is there is any x86 version of it aswelll !! :confused:

There's nothing wrong with the title. This thread is about Avisynth for x86-64.

So it's not a mistake on my side, I can't use 32bit avisynth when x64 version is installed ?

That's good to know. So I won't have a headache figuring what I've done wrong.
And x64 version is easy and fast to uninstal/reinstall anyway, so when I'll need to use a 32bit plugin, I will temporarily uninstall avisynthx64.

Thanks.

I'm using both versions simultaneously, and it works just fine. Which Avisynth version is loaded depends on whether the program you start is 32 or 64-bit. You just have to make sure your script is only loading 32 or 64-bit plugins and not a mix. Alternatively, you can use try/catch statements to make a script "cross-platform" which I detailed in this post (http://forum.doom9.org/showpost.php?p=1395050&postcount=395).


VDmod 32bit says : AVI import filter error (unknown) (80040154)


This error means that you have failed to install Avisynth 32-bit correctly.

[kjh7232]

You need to load the 64-bit ffms2.dll with LoadCPlugin() in the beginning of the script.

That works. thx :)

[cegy]

[QUOTE=Stephen R. Savage;1416218]There's nothing wrong with the title. This thread is about Avisynth for x86-64.

sure there is unless you can tell me where the x86 avisynth is for the users who want the x86 ?:confused: (the installer/install files are only for x64 this is what i am going on about !!!!)

the only thing on this forum i would class as x86/x64 is "Simple x264 Launcher" http://forum.doom9.org/showthread.php?t=144140

[Gavino]

@cegy
http://en.wikipedia.org/wiki/X86-64

[Alf Bundy]

This error means that you have failed to install Avisynth 32-bit correctly.

You're right, I did messed up Avisynth 32bit when installing x64 version.

My 64bit script worked fine in VDx64, I was happy, so I tried to drag & drop it in the main window of MeGUI.
But MeGUI told me "cannot find avisynth.dll".
That's where I made a stupid thing : I copied the 64bit dll in my Windows/sysWOW64 folder (thus overwriting the 32bit dll).

In fact it was a problem between Drag & Drop and MeGUI running with admin rights. It just doesn't work.
Instead I have to use the open dialog (CTRL+O) to browse for my 64bit script. This way the script is loaded correctly.

Long story short : I did a fresh clean install of AviSynth 32bit & 64bit, and now they both work simultaneously. :)

[Alf Bundy]

No, It looks fine enough.
I am not able to replicate a crash in x264 r1659 nor vdub 1.9.6 though.



Ah, I was unaware of MeGUI being this braindead (I never use it, since it has a history of irritating me to no ends with its consistent stupidities):
SWScale() does flag the video as being I420 instead of YV12 when outputting YV12 video.
(SWScale does not formally support YV12 itself, but due to the below reasoning this is not particularly an issue in most cases)

the difference between I420 and YV12 is simply
I420 is Y-U-V. YV12 is Y-V-U
- the chroma planes are simply swapped in memory
but the way avisynth handles acquiring the plane pointers, the above difference is generally unnoticeable.
for this same reason, ConvertToYV12() is a NOOP (No operation) when the video is I420 (in avs 2.5.x that is, in 2.6.0 looks like there might be a bug in this situation)

But it appears MeGUI is not capable of handling this properly either way, so I dare say to file a bug report to MeGUI.
It appears that you will not be able to use SWScale if you plan to use MeGUI due to the above, unless it fixes itself sometime rather soon

The same thing happens with FFvideoSource().
And I don't think we should blame MeGUI for that.
Flagging the video as being I420 instead of YV12 when outputting YV12 video is the problem.

When the Warning Dialog appears in MeGUI, we can hit the "Continue anyway" button, and we can encode the script without any further problem.
So it's not really a bug.

I guess the coders of MeGUI could remove the warning. But then, what would happen if someone try to encode a script which is really not YV12 ?

[kemuri-_9]

The same thing happens with FFvideoSource().
And I don't think we should blame MeGUI for that.
Flagging the video as being I420 instead of YV12 when outputting YV12 video is the problem.


I should've worded my statement more carefully:
FFVideoSouce()/SWScale() within ffms2 are both ffmpeg based.
anything and everything ffmpeg does not recognize YV12 as a valid colorspace, it only recognizes/supports I420.

so the video is I420 within avisynth, my previous statement of "flagging YV12 video as I420" is slightly incorrect:
what i was trying to say was more along the lines of
"the video is indeed I420, but within avisynth there's no real difference between I420 and YV12 past the point where the frames are created"

the difference can arise when dealing with Avisynth with the VFW interface,
but when working with the Avisynth through its own interface like x264 does, it doesn't matter as doing a isYV12() test returns true for both I420 and YV12.

[cegy]

@cegy
http://en.wikipedia.org/wiki/X86-64

ok you have a point there but still it says on there its 32bit (meaning there is both x86 and x64) when the installer is only for 64bit and not 32bit!!! he should add (x64) or (64bit) in the title as this is one big f*ck up other wise and can be very confusing so i'll quota a line for you

"Although most x86 processors used in new personal computers and servers have 64-bit capabilities, to avoid compatibility problems with older computers or systems, the term x86-64 (or x64) is often used to denote 64-bit software, with the term x86 implying only 32-bit."

p.s. my point will always stand untill the topic is changed or corrected :mad:

[kemuri-_9]

ok you have a point there but still it says on there its 32bit (meaning there is both x86 and x64) when the installer is only for 64bit and not 32bit!!! he should add (x64) or (64bit) in the title as this is one big f*ck up other wise and can be very confusing so i'll quota a line for you

"Although most x86 processors used in new personal computers and servers have 64-bit capabilities, to avoid compatibility problems with older computers or systems, the term x86-64 (or x64) is often used to denote 64-bit software, with the term x86 implying only 32-bit."


this topic says that this avisynth is for x86_64, in how any way does this conflict with your 'quote'?

code that is targeting the x86_64 architecture can only be executed by the x86_64 architecture alone.
code that is targeting the x86 architecture can be executed by the x86 and x86_64 architectures.


p.s. my point will always stand untill the topic is changed or corrected :mad:

[cegy]

code that is targeting the x86_64 architecture can only be executed by the x86_64 architecture alone.
code that is targeting the x86 architecture can be executed by the x86 and x86_64 architectures.


ok so where is the x86 (32bit) version of it then ?:eek: as the only thing i can see if links to only x64 (64bit):mad:

[Didée]

You are beating a dead horse.

A 32bit build to be executed under x86-64 is not needed. That is just the standard 32bit build.

The 64bit build to be executed under x86-64 is this thread's topic.

There is nothing more to it. You may stop it now.

[Atak_Snajpera]

ok so where is the x86 (32bit) version of it then ? as the only thing i can see if links to only x64 (64bit)
here you
http://forum.doom9.org/showthread.php?p=1412274#post1412274

[cegy]

here you angry boy (or girl)
http://forum.doom9.org/showthread.php?p=1412274#post1412274

thank you but you missed my point of where was it in this thread :p and this is why i am asking for the title to add (x64) to it at least to let users know its only for 64bit windows!

[Atak_Snajpera]

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

[Lyle_JP]

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

His vision seems fine. The problem is somewhere behind the eyes. To mister cegy, x86 means 32 bit, period. Which is wrong, of course, but no one seems able to sink that one into him.

[cegy]

His vision seems fine. The problem is somewhere behind the eyes. To mister cegy, x86 means 32 bit, period. Which is wrong, of course, but no one seems able to sink that one into him.

ahhh now your saying its x86 as in 32bit which is isn't is it ? as its only for 64bit thats why the installer and plugins on the first page is x64 only!

ps. check this http://forum.doom9.org/showpost.php?p=1390397&postcount=1 as you can see this person also says its x64 (grab the x64 avisynth from this thread)

[Atak_Snajpera]

x86-64 = 64 bit extension for old x86. So it is logical that this version will not work on 186 (16bit),286(16bit),386(32bit),486(32bit),586(32bit) and so on ... ;)

[Overdrive80]

Hi, fantastic job. My question is if you go to migrate all filters from x86 to x64, for in the list are not seen some as: TBilateral, TemporalDegrain ... Although it strikes me that are not necessarily convert AVSI files, only those who are dlls?

Thanks and sorry for the inconvenience

[cegy]

ok your right there but the last thing i will say from the wikipedia page it says
"x86-64 is still used by many in the industry as a vendor-neutral term, as is x64."
The x86-64 specification is distinct from the Intel Itanium (formerly IA-64) architecture, which is not compatible on the native instruction set level with either the x86 or x86-64 architectures.

[aegisofrime]

ok your right there but the last thing i will say from the wikipedia page it says
"x86-64 is still used by many in the industry as a vendor-neutral term, as is x64."
The x86-64 specification is distinct from the Intel Itanium (formerly IA-64) architecture, which is not compatible on the native instruction set level with either the x86 or x86-64 architectures.

What's your point? What the sentence you have quoted there means is that x86-64 is used to refer to the 64-bit extension to the x86 architecture in general. The reason for this is that Intel's name for x86-64 is Intel EMT64 and for AMD it's AMD64.

If JoshyD had used either of these vendor specific terms then people like you would be up in arms demanding that the title be changed!

[cegy]

What's your point? What the sentence you have quoted there means is that x86-64 is used to refer to the 64-bit extension to the x86 architecture in general. The reason for this is that Intel's name for x86-64 is Intel EMT64 and for AMD it's AMD64.

If JoshyD had used either of these vendor specific terms then people like you would be up in arms demanding that the title be changed!

ok so it should be intel ia-64/emt 64 or amd 64 (it still means you need a 64bit windows to run it or the intal ia of windows)

my point is vaild and still stand untill the title is correct also i won't be replying to any questions in this thread :mad:

[Guest]

Drop it cegy, you're starting to look like a troll. Followup to PM if you must.

[Chikuzen]

I found a bug.
I'm using latest version(build 4/16/2010).
Colorbars(320,240,"YUY2")
FadeIn(60)

http://img685.imageshack.us/img685/1357/fade32bitand64bit.png

A blackboarder appears left side when FadeIn(FadeIn0) is used with 64bit-AviSynth.

[Alf Bundy]

I can reproduce it.
And with FadeIO(), during the fade out the left border is in negative colors, not black.

[pokazene_maslo]

Alright, nobody was paying attention to my previous post so this time I prepared everything needed to reproduce the bug.
In zip is short sample of video I was trying to encode, d2v, avs script, and plugin that's causing crashes. Try it by yourself.

My setup: latest megui x64, avisynth x64 MT 4/16/2010, core 2 duo e6300.

http://hotfile.com/dl/54428190/eaf2166/sample.ZIP.html

[Alf Bundy]

Hi,

Is there a thread where I can politely ask for a plugin that is not yet compiled for x64 ?

I really miss Deblock (http://avisynth.org/warpenterprises/files/deblock_25_dll_20060214.zip) and BlockBuster (http://avisynth.org/warpenterprises/files/blockbuster_25_src_20021229.zip) in avisynth x64. :(

:thanks:

[Buggle]

I was wondering, since JoshyD seems preoccupied with matters other than AVS64 (which is completely understandable and he has every right to, of course), why is this code not merged with the main AVS branch/tree/whateveryoucallit? It seems somewhat inefficient to maintain two versions of the same origin. And it has become quite clear that there is a large crowd of people using and wanting to use full x64 capabilities, so it wouldn't really be a strange idea for the main developer(s) of AVS to also start paying attention to adjusting AVS to also include x64 out of the box, like x264 for instance now has for a while. Also, there seem to be so many filters compiled for x64, or even more and more. I'd even go so far as to say that 32bit is moving toward obsolescence: there is a good chance for instance that Win8 will only be available in a x64 edition. I for one support that; 32bit is lingering too long, while the transition from 16bit to 32bit was quite fast and almost painless, back then.

[kemuri-_9]

avisynth's compiler of choice is out-of-the box visual studio.
this version of avs x64 can not use visual studio out-of-the-box as it requires the use of Intel's compiler, which also costs a pretty penny to get.
You might ask "Why does it require Intel's Compiler?", the answer is "because of the inline asm which only Intel's compiler supports on x64."

and to my knowledge all that inline asm that was in avs x86 has been changed to to be for x64.
as long as there is inline asm in avisynth, this x64 version will forever remain incompatible with merging with the x86 version.

[asarian]

Also, there seem to be so many filters compiled for x64, or even more and more. I'd even go so far as to say that 32bit is moving toward obsolescence:.
That's a bit extreme. :) Gathering all the stuff for MCTemporalDenoise, for instance, not even half is available in x64 format. I guess we'll just have to wait a bit longer.

[muerteazul]

hi i try of install avisynth64_install.cmd but dont work it say "priviliges required" i install avisynth 2.5.8 before i think its for de xp x64 editon
some details
http://img9.imageshack.us/img9/123/capture07242010001538.jpg

[daimroc]

@Muerte Azul:

you must right click over the install.cmd and choose the option "execute as administrator" to be able to install it.

How you like to speak spanish for your nick, I tell you in spanish: para poder ejecutar el cmd con privilegios de administrador no tienes que hacer doble click sobre el cmd, sino pinchar con el botón derecho y elegir la opción de ejecutar como administrador.

___________________________________________________


Well, I have problems to install avisynth64. I am following these steps:

1) I have installed avisynth x86 version 2.5.8.

2) I have copy devil.dll and avisynth.dll in c:\windows\systems32 directory.

3) I have execute avisynth64_install.cmd. I get the following message:

AviSynth64 installed. To auto load put 64 bit dll's in
C:\Program Files (x86)\AviSynth 2.5\plugins64

So I understand that this steps it's correct.

4) I havae copied all the dlls of the zip to plugins64, incluided avisynth.dll and devil.dll. I think that's this is not neccessary, so I have in system32, but I prefer to avoid problems.

5) I import avisynth.reg in the register. The import it's correct.

So I understand that I have installed all correctly.

I have used the following avs:

DirectSHowSource("myVideo.mkv")

I try to open this avs with media player classic home cinema x64 and I have no problems. Also, with virtualdub x64 I have not problems.

How ever, If I try to use virtualdubmod, that is a x86 version, I get the following error:

Couldn't locate decompressor for format 'YV12' (unkonwn).
VirtualDub requires a Video for Windows (VFW) compatible codec to decompress video.

However, if I try to open the avs with media player classic home cinema x86 I have not any problem, it uses ffdshow to decompress the video.

So Why can't use now avs with virtualdubmod?.



Thanks.
Daimroc.

[kemuri-_9]

don't use virtualdubmod, it is beyond 'out-dated' - it is completely ancient.
use the x86 version of whatever virtualdub you also have as the x64 version

[tormento]

I saw somebody compiled RemoveGrain and Repair for x64. As ReduceFlicker is from the same author, would be possible to get it for x64 too?

[Overdrive80]

I saw somebody compiled RemoveGrain and Repair for x64. As ReduceFlicker is from the same author, would be possible to get it for x64 too?

And Tbilateral?

[crasus]

Many appreciations to all the creators of the x64 avisynth developments. One does hope to see someday a native x64 2.6 version available (dreaming....)

Adding to the list of kind requests for 64bits compiles of certain filters, would it be possible to have tdeint & degrainmedian?

All the warmest very best!

[Alf Bundy]

Tdeint x64 already exists (see on first post)
DegrainMedian x64 already exists (here (http://members.optusnet.com.au/squid_80/), as seen on first post)

:)

[Hiritsuki]

Who can compile yeadif and dedup x86 to x64 version?
This two plugin is now I had used long time for Subteam working.
Thanks a lot.

[steamroller]

I'm not able to get avisynth x64 (the 4/16/10 build linked to from the first post in this thread) to work with MPC x64 although it works perfectly with x264 x64 and virtualdub x64. MPC x64 says Cannot render the file. I'm just trying a simple script.

DirectShowSource("test.avi")

Playing test.avi directly with MPC x64 works. It loads ffdshow x64.
I followed the installation procedure outlined in the readme included in avisynth64_4-16-10.rar.
Any ideas why this might be happening? Any way to fix this? Thanks in advance.

[infiniter]

I had several problems with the installation. I'm running W7 64 bit on a quad core Intel CPU.

1. PROCESSOR_ARCHITECTURE
The install script aborts because it detects x86 by the variable PROCESSOR_ARCHITECTURE. I found out that, when opening the extended system setting in My Computer, where the environment variables are, that variable is set to AMD64 by Windows. But when opening a console and listing those variables with the SET command, it is PROCESSOR_ARCHITECTURE=x86 and PROCESSOR_ARCHITEW6432=AMD64. So the script can't work.

OK, so I removed the corresponding line in the script.

2. BCDEDIT
I'm logged in as administrator and chose right-click and "Run as administrator" to run the script, but it brings out "Administrator privileges required" error. Investigating the script, I found this is caused by trying to run bcdedit.exe. From the administrator console, this command is unknown. Searching for bcdedit, it is found in a WINSXS subfolder. So it seems that running bcdedit as test for admin privileges is the wrong way.

After I removed the corresponding line too, the script worked.

[kemuri-_9]

there are two command prompt modes for x64 window systems.

there's x86 mode where the environment is primarily setup for running x86 programs, e.g. PROCESSOR_ARCHITECTURE=x86 and ProgramFiles points to the x86 directory.
%WINDIR%\system32 is automatically redirected to point to %WINDIR%\syswow64
this mode is generated by using %WINDIR%\syswow64\cmd.exe

then there's the x64 mode, where everything is primarily setup to run x64 programs where the variables are the 'normal' ones.
this mode is generated by using %WINDIR%\system32\cmd.exe or more generally cmd.exe from the search/run prompt in w7 and other systems

overall though, yes, the script is known to have issues but with the development at a stand still on development of avisynth x86_64, there's not much of a point in fixing it avisynth x86_64 is going to stay broken/incomplete.

[muerteazul]

hi i run the %WINDIR%\system32\cmd.exe and i copy de files of avisynth64_4-16-10 on syswow64 then i write avisynth64_install.cmd
enter and say 64-bit windows not detected

reply to daimroc
Well, I have problems to install avisynth64. I am following these steps:

1) I have installed avisynth x86 version 2.5.8.

2) I have copy devil.dll and avisynth.dll in c:\windows\systems32 directory.

3) I have execute avisynth64_install.cmd. I get the following message: up this step is the problem i try and dont works
i am the administrator and say "priviliges required"
y si hablo español soy mexicano

[turbojet]

The install script on google code has a bunch of problems with non-admin accounts and uac.

The script posted here (http://forum.doom9.org/showthread.php?p=1394453#post1394453) should fix infiniter and muerteazul problems. Please report if they don't.

JoshyD said he was going to include the fixed install script in a new version months ago but that never came to fruition.

[Eric L]

Great job guys, Avisynth x64 Rocks!

There is only one key filter missing to use mainstream it in my everyday workflow.

May I request an x64 version of the SmartDecimate (http://web.missouri.edu/~kes25c/smartdecimate_avisynthc.zip) filter corrected by Tritical? Sources are included in the download.

Thanks

[muerteazul]

Thanks turbojet Avisynth its instaled now
Gracias turbojet Avisynth esta instalado ahora gracias por esa vercion

[The_Paya]

Hello.

Here's an attempt at porting one of the filters I use in my scripts to x64 avisynth.

FluxSmooth_icc_x64.7z (http://www.mediafire.com/file/a0qkrq13l17dgsn/FluxSmooth_icc_x64.7z)

This is by no means a "well done" job, I've left the __asm inlines there, used the Intel compiler to avoid having to rewrite them into .asm files, and just renamed address operations to their (x64) r-conterparts where it made sense. IMHO, it's a miracle that it compiled without warnings, and that it worked afterwards.

The modified sources are included as well as 3 precompiled binaries, all done in VS2008 with ICC 11.1.060. One without any kind of weird optimizations, another with SSE4.1 and the last one with more weird optimizations. Needless to say, it's very unlikely that there would be any noticeable speed differences between each version, given most of the code is MMX/SSE2 assembler.

As a long time lurker and first time poster, I'd like to thank the community and these x64 builds (they work better than the 32bit ones in my box for some reason). :thanks:

Salu2,
Paya.

[Overdrive80]

Hello first of all to congratulate on this job. The second is a question maybe simple but I have not clear. If I install this version of avisynth filters could also use 32-bit? An example would be my code (I say this because the title says "for *X86_64*, Latest Build 4/16/2010"):

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-
#MERGE
#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-

DGDecode_mpeg2source("E:\DB_1\Opening\ope.d2v", info=3)+\
DGDecode_mpeg2source("E:\DB_9\53\53.d2v", info=3)

ColorMatrix(hints=true, threads=0)

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-
#DEINTERLACED is used FORCE FILM, ISNT NECESARY
#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-
#CROOPING&RESIZE
#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-

D0=trim(0,2594).Crop(4,0,0,0).Spline64Resize(720,480)
D1=trim(2595,34718).Crop(6,0,-2,0).Spline64Resize(720,480)
D2=trim(34719,0).Crop(6,0,-2,-2).Spline64Resize(720,480)

UnalignedSplice(D0,D1,D2)

Tweak(sat=1.1)

#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-
#FILTERED RENDERING
#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-

TemporalDegrain(degrain=2, ov=2, blksize=4)#temporal

Denoised=FFT3DFilter(sigma=2.1,bw=32,bh=32,ow=16,oh=16,plane=0,sharpen=0.5)#spatial-temporal

MCTemporalDenoisePP(denoised,settings="very low")

TBilateral(diameterL=5,diameterC=5,sDevL=1.300,sDevC=1.300,iDevL=7.000,iDevC=7.000,\
csL=1.000,csC=1.000,d2=false,chroma=true,kernS=2,kernI=2,resType=0)#spatial

LSFMOD(defaults="slow") #Si queremos mas sharpen pero lo relentiza aun mas

threads=6

x=(framecount()/threads)

A=trim(0,x)
B=trim(x+1,2*x)
C=trim(2*x+1,3*x)
D=trim(3*x+1,4*x)
E=trim(4*x+1,5*x)
F=trim(5*x+1,0)

c

Thanks.

[Didée]

No. 64bit Avisynth can not use 32bit plugins. That's why people frequently ask about porting this-or-that filter to x64.

[Overdrive80]

No. 64bit Avisynth can not use 32bit plugins. That's why people frequently ask about porting this-or-that filter to x64.

Ok, thanks for your answer, dream with possibility of that it was true ^^. Imagine that to use avisynth in x64 system up to speed processating, doesnt it?

[trevaaar]

Just built this if anyone's interested:

Yadifmod x64 (http://www.mediafire.com/?tj93hvxillp35gf)
Unfortunately I don't have ICL (it's built with VC2010) so I had to remove the inline MMX asm. The asm methods in PlanarFrame were replaced by the implementations in joshyd's memcpy_x64.asm file.

[LeXXuz]

Here's an attempt at porting one of the filters I use in my scripts to x64 avisynth.

FluxSmooth_icc_x64.7z (http://www.mediafire.com/file/a0qkrq13l17dgsn/FluxSmooth_icc_x64.7z)


Thanks. I will try it out. We could use more denoisers on x64. :)

[Hagbard23]

Please Help!

I get strange green frames now, when i use DGDecode64 (1.5.8) together with DGIndex 1.5.8 and AviSynth64 (Build 16/4/2010).

It seems to be a DGDecode64 Problem, because the green frames do NOT appear in the VOB-Files, nor in DGIndex (w/ VOB), nor in DGIndex when i load the Project file (->Reload d2v). I can reproduce this "bug" with all possible DVD's.

I'm trying around now for some hours - but i couldn't find a solution - maybe someone can have an eye on the DGDecode64 Source? I am not experienced enough for that...

Thank you very much...

BTW:Green Frames appear every second/third/fourth frame regulary (difficult to distinguish - VD doesn't progress frame by frame with this error) ...yes, and they are totally green... ;(...I used VirtualDub 1.9.9 x64 AND MPC-HC x64 (SVN 2235) - both with the same result - green flickering frames

P.S.: MOD16 is confirmed - resolution is (as almost any PAL DVD) 720x576

Sys:
i7 870
WinVista
Geforce 9500GT
4GiG RAM


€DIT:
NO Problems occur, when i demux the MPEG2 Stream(with DGIndex) and load it into AviSynth64 via DirectShowSource64

[aegisofrime]

Please Help!

I get strange green frames now, when i use DGDecode64 (1.5.8) together with DGIndex 1.5.8 and AviSynth64 (Build 16/4/2010).

It seems to be a DGDecode64 Problem, because the green frames do NOT appear in the VOB-Files, nor in DGIndex (w/ VOB), nor in DGIndex when i load the Project file (->Reload d2v). I can reproduce this "bug" with all possible DVD's.

I'm trying around now for some hours - but i couldn't find a solution - maybe someone can have an eye on the DGDecode64 Source? I am not experienced enough for that...

Thank you very much...

BTW:Green Frames appear every second/third/fourth frame regulary (difficult to distinguish - VD doesn't progress frame by frame with this error) ...yes, and they are totally green... ;(...I used VirtualDub 1.9.9 x64 AND MPC-HC x64 (SVN 2235) - both with the same result - green flickering frames

P.S.: MOD16 is confirmed - resolution is (as almost any PAL DVD) 720x576

Sys:
i7 870
WinVista
Geforce 9500GT
4GiG RAM


€DIT:
NO Problems occur, when i demux the MPEG2 Stream(with DGIndex) and load it into AviSynth64 via DirectShowSource64

I have come across this problem before. To fix it, try using Colormatrix. Like so:

MpegSource2(info=3)
Colormatrix(hints=true)

[Hagbard23]

No - as expected - colormatrix has nothing to do with this error.

I've tried your proposal out ... it's the same error as before :confused:

any suggestions?

€dit: Testing with ordinary 32Bit Binaries (Avisynth,VDub,DGDecode) results in perfect behaviour without any error...

I KNOW that it worked a few weeks ago with all 64 Binaries, but now i can't get rid of these green frames - what have i done wrong?

[aegisofrime]

No - as expected - colormatrix has nothing to do with this error.

I've tried your proposal out ... it's the same error as before :confused:

any suggestions?

€dit: Testing with ordinary 32Bit Binaries (Avisynth,VDub,DGDecode) results in perfect behaviour without any error...

I KNOW that it worked a few weeks ago with all 64 Binaries, but now i can't get rid of these green frames - what have i done wrong?

Hmmm that's weird. I had a similar problem with green frames flashing randomly, which I fixed with ColorMatrix :(

[Hagbard23]

Because noone in here seems willing to help me with the described bug, i find myself pushed to the 32Bit Binaries again - :confused:

BTW: The FPS are nearly equal, so i don't see real advantages in processing in 64Bit.

Maybe someone in here gets the same Bug sometimes...if it is fixed then, i will give 64Bit another try...

Its a pity...

[trevaaar]

It wouldn't happen to be HD content you're having trouble with would it? MPEG2Source has worked perfectly for all the DVDs I've done with Avisynth64 but gives all green output every other frame when doing a Blu-ray. Unfortunately I can't help with a fix since I don't know assembly.

[Hagbard23]

Nope - it didn't happen with Directshowsource64 + HD Content (x264 encoded to speak more detailed), nor did it happen with Directshowsource64+MPEG2 Stream. And -no- i am not as dumb to try loading HD-Content via DGDecode... ;)... Testing with DGAVCSource was not possible, since there is no free version ATM - the old version is too old for me, so i've thrown it away. (btw: "thanks" to Donald Graft for his capitalistic sense, being commercial is a "no-go" for me, and i will avoid using his tools as far as possible. Nevertheless he is technically an overwhelming coder but that's not enough actually, there are new coders with good "free" tools/plugins, which i would prefer)

The Problem is, that one can't use Directshowsource with (unindexed) MPEG2 Sources - severe Problems with the video-length would occur. So there is no way for me to load MPEG2-Content with AVISYNTH64 as long as i don't get DGDECODE64 working. (Except loading and converting every VOB one by one)

It makes me a little paranoid, because it worked a few months ago without errors and i would say i am well experienced with avisynth.
This error really disturbs me, because i don't see the cause for that.

That exactly is the reason why i switch to the 32Bit Binaries again.

Maybe there is a problem with the Multithreading function of the newest build of AviSynth64+DGDecode64, but i don't exactly know - my knowledge regarding Coding is really limited.

Why noone of the developers is responding my question? Am i too stupid or what? I'm starting to really believe in that... ;-(

It is really a pity, because i liked the 64Bit Project in here....

[kemuri-_9]

It seems like you're purposefully excluding ffms2 as a valid option, which does have a working x64 plugin version...
(no one's told me that it has issues specific to it that are not in the standard x86 version)

see the ffmpegsource thread for the binary link, unless you come up with some reasoning why it's not a valid option here.

[Stephen R. Savage]

Can FFMS2 actually load VOB sequences? I was under the impression that VOBs are not cut at frame boundaries but simply at the 1 GB mark, so loading each VOB individually would lose frames at the ends of the files.

[lych_necross]

I think you would have to demux the vob files first if you want to go that route. I've personally never loaded a vob sequence directly into ffms2 before. I always index first and use dgsource.

[kemuri-_9]

Can FFMS2 actually load VOB sequences? I was under the impression that VOBs are not cut at frame boundaries but simply at the 1 GB mark, so loading each VOB individually would lose frames at the ends of the files.

it depends on how you ripped the DVD/source:
on DVDs themselves VOB files are generally at the 1 GB mark, but there are options in some (if not most/all) rippers that allow for concatenating all the relevant split VOBs into a single resultant one.
if you are reading the 1GB split VOB files, then you will likely have dropped frames if you utilize ffms2 and thus is not a valid option, but if you concatenated all of them when you ripped to your HDD then it becomes valid.

[Blue_MiSfit]

Indeed. If you made the mistake of configuring your ripping software to leave the VOBs as 1GB each, you can usually get away with a simple binary concatenate... i.e.


copy /b vts_01_00.vob+vts_01_01.vob joined.vob


USUALLY. Not always :)

Re-ripping is probably a good idea... or DGDecNV which has native, up-to-date 64 bit binaries

[Boogerlad]

Could you compile the soundout filter to x64 as well?

[JoshyD]

I'm not dead yet . . .

Here's a test release (http://code.google.com/p/avisynth64/downloads/detail?name=avisynth64_8-29-10.rar&can=2&q=)

I've not done any testing beyond the resize code, which is what I've mostly changed.

It's been updated to actually save the volatile XMM registers that were causing some problems with x264.

I can't promise quick responses to anything, I've been extremely busy, sorry guys, hopefully this will tide everyone over for a bit.

[Lyle_JP]

I'm not dead yet . . .

Here's a test release (http://code.google.com/p/avisynth64/downloads/detail?name=avisynth64_8-29-10.rar&can=2&q=)

http://i73.photobucket.com/albums/i228/steady_thinker/banana5.gif

So glad it's not abandonware!!

EDIT: Okay, so I tested this new avisynth by resizing with Spline64 to a mod2 (not mod4) height, which works with 32-bit avisynth. It worked the first time I opened it, but the second time gave me this crash:

Problem signature:
Problem Event Name: APPCRASH
Application Name: MeGUI.exe
Application Version: 0.3.5.8
Application Timestamp: 4c6ae542
Fault Module Name: StackHash_2ef6
Fault Module Version: 6.1.7600.16559
Fault Module Timestamp: 4ba9b802
Exception Code: c0000374
Exception Offset: 00000000000c6df2
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 1033
Additional Information 1: 2ef6
Additional Information 2: 2ef6e93bbf5e6d4df380510142a2d6b7
Additional Information 3: c756
Additional Information 4: c7562d668f76b39cc9466cba9c05d37a

[levi]

I'm not dead yet . . .

Here's a test release (http://code.google.com/p/avisynth64/downloads/detail?name=avisynth64_8-29-10.rar&can=2&q=)

I've not done any testing beyond the resize code, which is what I've mostly changed.

It's been updated to actually save the volatile XMM registers that were causing some problems with x264.

I can't promise quick responses to anything, I've been extremely busy, sorry guys, hopefully this will tide everyone over for a bit.

Awesome! Thanks for not giving up!!

[livetolove92]

Anyone upload ffms2 dll for me? Link in page 1 is dead.

[Didée]

Still there, it just moved in the folder hierarchy.

See? (http://kemuri9.net/dev/avs/ffms2/) ;)

[kemuri-_9]

Anyone upload ffms2 dll for me? Link in page 1 is dead.

I moved it so i could put it into a package.
sorry for the hassle.

[LeXXuz]

I'm not sure where to put my problem, since it works fine with my x86 system I thought to put it here.

Anybody managed to run ac3filter x64 with Megui x64/Avisynth x64 and DirectShow audio?

On my x86 sys everything's fine, no problem at all. On the x64 machine I cant get it to work. I installed ac3filter x64 and it is used and working in the system since MPC-HC x64 works with it just fine, but Megui/Avisynth doesnt. I've forced the use of DirectShow Audio in the encoder settings and already gave ac3filter a very high filter merrit but it does not work. The output file is very small, like 4MB while it should be 100 or more and is completely silent.

I dont know where to look anymore, I dont even know if avisynth's Directshowsource maybe uses some other (broken) decoder filter.

Would appreciate any ideo/help how I could fix this or how to find out which DirectShow audiofilter is used by Avisynth.

[Stephen R. Savage]

If you use GraphEdit or GraphStudio, you can build a custom filter chain and save it to a GRF file, which DirectShowSource will accept. The "Connect to Remote Graph" function in GraphEdit/GraphStudio is supposed to be able to determine what chain is being used in a running application, but I have never figured out how to use it.

[ajp_anton]

Could someone please compile a 64-bit eedi3 for me?
There appears to be a source code in the zip file (http://bengal.missouri.edu/~kes25c/eedi3.zip).

edit: Actually, nevermind that. I also need nnedi2 x64 to make 64-bit Avisynth useful...

[aegisofrime]

Could someone please compile a 64-bit eedi3 for me?
There appears to be a source code in the zip file (http://bengal.missouri.edu/~kes25c/eedi3.zip).

edit: Actually, nevermind that. I also need nnedi2 x64 to make 64-bit Avisynth useful...

You and everyone else. x64 NNEDI2 is the only thing missing in 64-bit TGMC... Unfortunately since it's closed source the only thing we can do is to wait for tritical to compile it...

[Prettz]

Hello.

Here's an attempt at porting one of the filters I use in my scripts to x64 avisynth.

FluxSmooth_icc_x64.7z (http://www.mediafire.com/file/a0qkrq13l17dgsn/FluxSmooth_icc_x64.7z)

This is by no means a "well done" job, I've left the __asm inlines there, used the Intel compiler to avoid having to rewrite them into .asm files, and just renamed address operations to their (x64) r-conterparts where it made sense. IMHO, it's a miracle that it compiled without warnings, and that it worked afterwards.

The modified sources are included as well as 3 precompiled binaries, all done in VS2008 with ICC 11.1.060. One without any kind of weird optimizations, another with SSE4.1 and the last one with more weird optimizations. Needless to say, it's very unlikely that there would be any noticeable speed differences between each version, given most of the code is MMX/SSE2 assembler.

As a long time lurker and first time poster, I'd like to thank the community and these x64 builds (they work better than the 32bit ones in my box for some reason). :thanks:

Salu2,
Paya.
Ahhhhh, nice. I've been hoping for an x64 port of FluxSmooth. (And Convolution3D.) It's pretty much my main denoiser... I still don't get why it isn't the same among many others.

I definitely can't promise I'll test this properly for you, but I think I'll start looking at the code right away -- I've been wanting to get my foot in the door on helping the Avisynth project. What better way to start than one of my dearest filters. I recently cut my teeth at making the jump from x86 to x86-64 assembly, so I'd love to look at the iSSE code and see if I can do anything to help rewrite it for the doubled number of XMM registers.

[levi]

I'm not dead yet . . .

Here's a test release (http://code.google.com/p/avisynth64/downloads/detail?name=avisynth64_8-29-10.rar&can=2&q=)

I've not done any testing beyond the resize code, which is what I've mostly changed.

It's been updated to actually save the volatile XMM registers that were causing some problems with x264.

I can't promise quick responses to anything, I've been extremely busy, sorry guys, hopefully this will tide everyone over for a bit.

No Problems with x264 now. Great Work! :thanks:

[royia]

Is there a 64 Bit version of yadif, or any other fast yet solid deinterlace plug in?

Is there a compatible MeGUI version to use with?

I wish many people will join to the development of this project to push AVISynth into the next level.

Thanks.

[Didée]

> Is there a 64 Bit version of yadif,

http://yo4kazu.110mb.com/

[royia]

I'm not dead yet . . .

Here's a test release (http://code.google.com/p/avisynth64/downloads/detail?name=avisynth64_8-29-10.rar&can=2&q=)

For daily use, would you recommend it?
I hope you get more time to work it out.

Thanks.

[STaRGaZeR]

Joshy, I PMed you some time ago asking for GradFun2DB x64's source code, can you share it please?

[jpsdr]

I'm not dead yet . . .
I've not done any testing beyond the resize code, which is what I've mostly changed.
It's been updated to actually save the volatile XMM registers that were causing some problems with x264.
I can't promise quick responses to anything, I've been extremely busy, sorry guys, hopefully this will tide everyone over for a bit.

This new release make QTGMC v2.46r crash, wich is working fine with 4-16-10 release.

[tschi]

Sorry if I am irrelevant with this thread, I don't really know if it could be solved by avisynth dev's or ffdshow dev's and where I can post it :confused:
Since rev2374 (DLL-Vulnerability fix) mpc-hc is not anymore compatible with avisynth script in ffdshow :(
http://forum.doom9.org/showpost.php?p=1431247&postcount=14424

[kemuri-_9]

Sorry if I am irrelevant with this thread, I don't really know if it could be solved by avisynth dev's or ffdshow dev's and where I can post it :confused:
Since rev2374 (DLL-Vulnerability fix) mpc-hc is not anymore compatible with avisynth script in ffdshow :(
http://forum.doom9.org/showpost.php?p=1431247&postcount=14424

This thread is for a specialized version of avisynth for x64.
Issues like that which are caused by external applications using/breaking avisynth by altering the windows DLL search path are outside of this thread's purpose.
you should take your complaints back to the mpc-hc thread(s)

[LeXXuz]

If you use GraphEdit or GraphStudio, you can build a custom filter chain and save it to a GRF file, which DirectShowSource will accept. The "Connect to Remote Graph" function in GraphEdit/GraphStudio is supposed to be able to determine what chain is being used in a running application, but I have never figured out how to use it.

I played around a little the last couple of days. Graphedit shows me the normal filter chain, same as on my x86 sys:

input => AC3 parser filter => AC3 filter > Output.

That made me suspicious. So I copied my x86 MeGui installation to my x64 system. And guess what: it worked as it should.

So I'm back to square one, having no idea why I can't use DirectShowAudio on Megui x64. Since AC3filter x64 is installed and properly used by MPC-HC x64 it's either a problem with Megui x64 or Avisynth x64 or both.

Would appreciate any ideas.

[GRKNGLR]

Hi,

When do you expect the x64 compilation of SangNom.dll? I can't use filters like LSF with Avisynth64. And one more thing... Can't Avisynth64 run 32bit filters?

[Didée]

Avisynth64 can not use 32bit plugins. That's why people ask for porting plugins to x64, after all.

You don't need SangNom for LSF. And for me, LSF works fine with Avisynth64. What problem do you experience?

[GRKNGLR]

When I installed Avisynth64 properly and placed the filters correctly, though, it ran pretty well. No problems at all. Thanks Didée.

P.S.: Avisynth64 8-29-10 causes problems using filters, but 4-16-10 runs fluently.

[jpsdr]

P.S.: Avisynth64 8-29-10 causes problems using filters, but 4-16-10 runs fluently.

Same for me.

[levi]

What problems did you see & with what filters?

[GRKNGLR]

What problems did you see & with what filters?

Preview problem & All filters. :)

[jpsdr]

Crash with QTGMC.

[buck-tick]

internal filter SSRC does not produce audio

[asarian]

Edit: Quicklinks Updated 4/26/2010

New on 3/13/2010
kemuri-_9's FFMS2 (The Fabulous FM Source 2) (http://kemuri9.net/dev/avs/ffms2/x64/ffms2.dll)
Big thanks to kemuri-_9 for the build

Dead link. :(

[Mr_Khyron]

Dead link. :(

http://kemuri9.net/dev/avs/ffms2/ffms2-x64.zip

[asarian]

http://kemuri9.net/dev/avs/ffms2/ffms2-x64.zip

Thanks.

Just installed the 64-bit version of AviSynth, to the letter of the documention, rebooted, and yet I can still run a script with the 32-bit version of FFVideoSource (as I haven't installed the 64-bit version yet). How is that possible?! I thought I wouldn't be able to run 32-filters any more. Sigh. :(

[aegisofrime]

Thanks.

Just installed the 64-bit version of AviSynth, to the letter of the documention, rebooted, and yet I can still run a script with the 32-bit version of FFVideoSource (as I haven't installed the 64-bit version yet). How is that possible?! I thought I wouldn't be able to run 32-filters any more. Sigh. :(

No, you can choose which version to run by specifying which plugins to load. You just can't mix 32-bit and 64-bit filters in the same script.

[asarian]

No, you can choose which version to run by specifying which plugins to load. You just can't mix 32-bit and 64-bit filters in the same script.
Oh, that's actually pretty cool. :) So it doesn't really break the entire existing environment. Thanks.

So, if I start my script with a loadplugin command to the 64-bit version of FFVideoSource, for example, does that mean AviSynth unloads the one from its default 32-bit location? Or should I physically remove all 32-bit scripts that have a 64-bit equivalent?

[Hagbard23]

€dit: misunderstood asarian....

Sorry asarian - i really misunderstood you - put my words into the toilet and flush, because it doesn't fit to your question.

Sorry sorry sorry....

[asarian]

asarian - if you read the readme.txt carefully, you would have known, that from the point of the installation of the x64 Version, there is another Autoload-Folder - it is no more AVISYNTH/PLUGINS but AVISYNTH/PLUGINS_x64 (or similar - i am at work ATM and can't remember well).

So: If you can load 32 Bit plugins, it is obvious, that you do not have installed the x64 Avisynth correctly. If you would have done that, loading 32Bit Plugs will give you an error.

So be sure, that you copied the new x64 avisynth.dll in the Windows/System32/ folder, and your autoload-plugins in the PROGRAM_FILES/AVISYNTH/PLUGINS_64 folder.

It should be no problem...


Seriously, I read and followed the instruction in the readme.txt to the letter. In regedit, seems there are now 2 plugin dirs listed (underneath each other):

(default) C:\Program Files (x86)\AviSynth 2.5\plugins
plugindir2_5 C:\Program Files (x86)\AviSynth 2.5\plugins64

Which, if I understood it correctly, is how it should be. What I'm still confused about, is what to do with that 32-bit plugin dir. Must I remove everything from it, for 64-bit to work? Or will 64-bit mode be determined by what your script uses? Which is to say, if my script only uses 64-bit plugins, will processing, and output (!), all be in 64-bit too? And then I still don't know whether a LoadPlugin command (for a 64-bit plugin) overrides its 32-bit equivalent.

EDIT: Is okay, Hagbard23. :) As I still don't really grasp how the concurrency/exclusivity of 64-bit filters is supposed to work exactly, I'll just leave my questions be.

[kemuri-_9]

Which, if I understood it correctly, is how it should be. What I'm still confused about, is what to do with that 32-bit plugin dir. Must I remove everything from it, for 64-bit to work? Or will 64-bit mode be determined by what your script uses? Which is to say, if my script only uses 64-bit plugins, will processing, and output (!), all be in 64-bit too? And then I still don't know whether a LoadPlugin command (for a 64-bit plugin) overrides its 32-bit equivalent.

EDIT: Is okay, Hagbard23. :) As I still don't really grasp how the concurrency/exclusivity of 64-bit filters is supposed to work exactly, I'll just leave my questions be.

you can leave the 32bit plugin dir alone, which version of avisynth gets used depends on the program that requests it:
if a 32bit program requests avisynth it will use the 32bit avisynth and use the 32bit plugin directory,
if a 64bit program requests avisynth it will use the 64bit avisynth and use the 64bit plugin directory.

LoadPlugin will fail when you try to use a 32bit plugin in 64bit avisynth and vice versa.


but it looks like you didn't follow the instructions for editing the registry correctly:
HKLM\Software\Aviysnth will contain the plugindir2_5 for 64bit avisynth
while
HKLM\Software\WOW6432Node\Avisynth will contain the plugindir2_5 for 32bit avisynth



Also, I have not updated the ffms2-x64 plugin in a while and it has become outdated.
I will do that when i get back from work...
tho do note that it does not support using Haali as a demuxer.

[asarian]

but it looks like you didn't follow the instructions for editing the registry correctly:
HKLM\Software\Aviysnth will contain the plugindir2_5 for 64bit avisynth
while
HKLM\Software\WOW6432Node\Avisynth will contain the plugindir2_5 for 32bit avisynth



Also, I have not updated the ffms2-x64 plugin in a while and it has become outdated.
I will do that when i get back from work...
tho do note that it does not support using Haali as a demuxer.


Thanks for your time, Kemuri.

Honestly, there's no (longer?) something in the readme.txt about also having to patch the registry manually (it comes with an install script now, which allegedly does it for you). I think I understand the concept better now, though; so I will start experimenting. :)

Also, thanks for working on the 64-bit version of ffms2; I'm still having frame inconsistency issues with other decoders, and ffms2 still does the job the best! (At least for me).

[kemuri-_9]

I've updated the zip package for ffms2-x64 on my website.

[levi]

I've updated the zip package for ffms2-x64 on my website.

Thanks Kemuri!

[asarian]

I've updated the zip package for ffms2-x64 on my website.

Much appreciated!

[Hagbard23]

yeah - really good work, thanks Kemuri...

[Chumbo]

Not sure who updates this, but the avisynth64_install.cmd file needs to be updated so it does not crash when the folder path has spaces in it. Basically, these lines at the top of the fileif not exist %~dp0avisynth.dll goto :NOAVSDLL
if not exist %~dp0DevIL.dll goto :NODEVIL
if not exist %~dp0DirectShowSource.dll goto :NODSS
if not exist %~dp0MT.dll goto :NOMTneed to be updated to include quotes, i.e., if not exist "%~dp0avisynth.dll" goto :NOAVSDLL
if not exist "%~dp0DevIL.dll" goto :NODEVIL
if not exist "%~dp0DirectShowSource.dll" goto :NODSS
if not exist "%~dp0MT.dll" goto :NOMT
Which takes care of the path issue.

[Zerofool]

Hi, now that nnedi3 and eedi3 do have 64-bit experimental builds, I only need a 64-bit version of the plug-in "Average". I see it's been requested (http://forum.doom9.org/showthread.php?p=1392388&highlight=average#post1392388) by Stephen R. Savage, but there's no progress as far as I can see. If someone can port the plug-in, that would be very nice.

I would also like to request a feature from Avisynth 2.6. The ConvertTo function has this "chromaresample" argument, which is very helpful for my needs (mostly RGB videogame footage), If it could be ported to this 64-bit build of Avisynth, that would be great, thanks in advance.
And godspeed to the project :).

[LeXXuz]

Is there any known problem with the resizer in Avisynth x64?

I got lots of crashes in MeGui and after some more testing and checking with Vdub, it seems Avisynth x64 crashes on certain source resolutions for the resizer.

f.e.
1920x1080 autocropped in MeGui to 1916x1080 => any resizer => 1280x720 = crash

1920x1080 autocropped in MeGui to 1918x822 => any resizer => 1280x544 = crash

Same machine, same source files, same resolutions on Avisynth x86 work without any problems.

[zmaster]

Which version of AviSynth_MT do you use? Resizing works great in the version of 4/16/2010.

[Lyle_JP]

Which version of AviSynth_MT do you use? Resizing works great in the version of 4/16/2010.

Not really. Try resizing to a mod2 (not mod4) height.

[zmaster]

Lyle_JP,
Hmm... You can specify any particular case? I think resizing always works correctly.


1920x1080 autocropped in MeGui to 1916x1080 => 1280x720
1920x1080 autocropped in MeGui to 1918x822 => 1280x544These situations I have reproduced. The desired result is achieved, no problem.

[asarian]

I still can't get this to work properly. :( I did everything in the readme.txt, to the letter, ran the avisynth64_install.cmd, but I can't even get this simple script to work (gits2.avs):

LoadCPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\ffms2.dll")
FFVideoSource("f:\jobs\gits2.mkv").ConvertToYV12()
MCTemporalDenoise(settings="low", useEEDI2=true)

And I call it as follows:

c:\x264\x264.exe --crf 14 --sar 1:1 --aud --nal-hrd none --level 4.1 --preset placebo --vbv-bufsize 70000 --vbv-maxrate 60000 --bframes 8 --aq-mode 2 --tune film --output "c:\video\gits2.264" "f:\jobs\gits2.avs"

(x264.exe is the 64-bit executable)

Nothing happens, for a long time. Then I get this error:

avs [error]: Script error: there is no function named "gradfun2db"
(MCTemporalDenoise.v1.4.20.avsi, line 700)
(f:\jobs\gits2.avs, line 6)

I am not even using "gradfun2db", nor have I set ENHANCE to true.

Please, tell me what I'm missing.

[kypec]

I am not even using "gradfun2db", nor have I set ENHANCE to true.

Please, tell me what I'm missing.
MCTD "low" settings have enhance option enabled by default, try to set it false explicitly in your filter call.

[asarian]

MCTD "low" settings have enhance option enabled by default, try to set it false explicitly in your filter call.

Good catch! Sadly, it keeps throwing the same error, even when I set it to 'medium'.

[AlekseiV]

The script seems to suggest setting GFthr to 1.0 to disable Gradfun2db:
enhance : Enable GradFun2DBmod post processing to enhance flat areas
GFthr : Gradfun2db threshold [1.0=off,...]

[LeXXuz]

Lyle_JP,
Hmm... You can specify any particular case? I think resizing always works correctly.


These situations I have reproduced. The desired result is achieved, no problem.

Yep. Works with x86 version also without any problems.

I'm not sure which x64 version is installed. Have to see if it's from 4/16.

[asarian]

The script seems to suggest setting GFthr to 1.0 to disable Gradfun2db:
enhance : Enable GradFun2DBmod post processing to enhance flat areas
GFthr : Gradfun2db threshold [1.0=off,...]

So, this is interesting. Seems basically GradFun2DB is always on by default then. Didn't know that (I usually have a second line following with a separate GradFun2DB command). I just thought GradFun2DB was a function of ENHANCE.

Now, who do I suck up to to have GradFun2DB ported to 64-bit? :) Seriously, if someone were to do so, then MCTemporalDenoise could finally run with all the trimmies in 64-bit (where it solidly belongs).

[LaTo]

So, this is interesting. Seems basically GradFun2DB is always on by default then. Didn't know that (I usually have a second line following with a separate GradFun2DB command). I just thought GradFun2DB was a function of ENHANCE.

Now, who do I suck up to to have GradFun2DB ported to 64-bit? :) Seriously, if someone were to do so, then MCTemporalDenoise could finally run with all the trimmies in 64-bit (where it solidly belongs).
Set fixband=false in MCTD.

[asarian]

Set fixband=false in MCTD.
Thanks for letting me know the official way.

But, erm, any chance you'll compile GradFunDB for 64-bit one day?

[AlekseiV]

Avisynth 8-29-10 with DGDecode_mpeg2source post-processing and SetMTMode(2) has bad artifacting for me.
If cpu=1 or 2, small white dots occasionally appear. Hard to spot in a still frame.
If >2, lots of green or white things often appear. See here (http://img32.imageshack.us/img32/9868/cpu4.png) or here (http://img42.imageshack.us/img42/4273/cpu6.png) (cpu=4 and cpu=6)
Shows up even in a script consisting only of:
SetMTMode(2,4)
return DGDecode_mpeg2source("Dresden.d2v", info=3, idct=5, cpu=6) #tested: idct=3|5, cpu=1-6
They're non-deterministic, reloading the script and requesting the same frame causes different artifacts (or none)
It works fine with SetMTMode(3) or just disabling post-processing.
Has anybody else seen this?

[asarian]

Just want to thank everyone involved (to no small degree, Kemuri) for porting all this stuff to 64-bit. :) I can now run a full MCTemporalDenoise job, complete with GradFun2DB and SupTitle plugin, all in 64-bit. No more mucking around with avs2yuv.exe, and hope it still all fits into memory.

[kypec]

Finally succeeded to install that x64 build on my Win 7. The culprit was to execute all scripts and registry editing from inside "cmd.exe", otherwise the enviroment was configured like 32-bit and though the import of registry keys appeared good, they were never really written into proper place! :angry:

Quick benchmark of simple AVS scripts utilizing MCTemporalDenoise(settings="medium") on 1920x800 source [no MT at all I remind you] returned following results:
32-bit avs2avi.exe = 0.97 FPS
64-bit avs2avi64.exe = 1.13 FPS
for E8400 @ 3.0GHz that I've in my office.
~17% speedup is not that much but I believe MT will boost the performance even more once I run it at home i7-920 @ 2.66GHz.
:thanks:

[cweb]

I just installed this 64 bit build, and I'm looking right now for a 64-bit version of hdragc... hoping someone ports it someday :)

Edit: What's needed to port these plugins actually? Is there any documentation available or examples?

[AlekseiV]

You need the source code, for one. Since HDRAGC is closed-source, the author would need to rewrite any x86-only code and recompile for x64.

[cweb]

You need the source code, for one. Since HDRAGC is closed-source, the author would need to rewrite any x86-only code and recompile for x64.
I've got the source I think of an older GPLed version dated 2005, at least that's what it says...
I just installed visual studio 2008 with the x64 tools.

[cweb]

I've got the source I think of an older GPLed version dated 2005, at least that's what it says...
I just installed visual studio 2008 with the x64 tools.
I built hdragc for x64 and got it to load but it kept adding green frames every now and then.. so I gave up on it.. for now at least.

This is avsrecursion.dll which I built for 64 bits too.. I didn't test it but here it is just in case. No guarantees that it works..

http://www.filesonic.com/file/25354761/AvsRecursion.rar

[tormento]

Do not use the august build. That gave me green frames too.

[cweb]

Do not use the august build. That gave me green frames too.
I only had green frames with my 64 build of hdragc, running a 64 bit toolchain of course.
Without it, my test video encoded well.

[warofhell]

i still have a problem about resizing.

spline36resize or lanczosresize doesnt work as well

DirectShowSource("C:\Users\User\Desktop\Back2Future\Back2Future.grf",audio=false,fps=23.976)
crop(0,20,0,-20)
spline36Resize(1024,554)

if i remove resize code , it works properly. How can i fix these?

ps: i am using x264_1745 and ( 4-16-10 ) avisynth

[kemuri-_9]

it was already mentioned in large that the april build of avisynth64 has broken resizers, don't use its resizers at all.

there is an option of trying to use the SWScale resizer inside of ffms2 instead....
or doing the resizing in x264cli (which also uses libswscale)

[bayex]

X6 AMD Phenom processor usage does not exceed 30% when I use a filter with a kind of encoding.
I use Mt avisyth SetMTMode topic (2, 6) and after 5 minutes this time fails to x264 x264 error 6 kernel works but gave about 80% off.

What could be the reason.

My system is:

Main card: asus crosshair formula 4 iv

Processor: Phenom 1090 x6 t

http://img830.imageshack.us/img830/2126/adszxi.jpg

[levi]

What is your script? What is your encoding?

[bayex]

I think it is not as important as the script used. But I still give.


SetMTMode(2, 6)
import("C:\Program Files\AviSynth 2.5\plugins\LimitedSharpen.avs")
import("C:\Program Files\AviSynth 2.5\plugins\Soothe.avs")

AVCSource("C:\Users\bayex\Desktop\hade.dga")
Crop(0, 140, -0, -140)

Lanczos4Resize(1920, 800)

dull = last
sharp = dull.LimitedSharpen(ss_x=1,4, ss_y=1,4, Smode=3, strength=75, radius=0, Lmode=3, overshoot=1)
Soothe(sharp, dull, 65)

Blu-ray would encode

32-bit operating system for win7

[Zep]

Try this:



import("C:\Program Files\AviSynth 2.5\plugins\LimitedSharpen.avs")
import("C:\Program Files\AviSynth 2.5\plugins\Soothe.avs")

SetMTMode(5,6)

AVCSource("C:\Users\bayex\Desktop\hade.dga")
Crop(0, 140, -0, -140)


SetMTMode(2,6)


Lanczos4Resize(1920, 800)

dull = last
sharp = dull.LimitedSharpen(ss_x=1,4, ss_y=1,4, Smode=3, strength=75, radius=0, Lmode=3, overshoot=1)
Soothe(sharp, dull, 65)

[7ekno]

32-bit operating system for win7

Seriously?!? This thread and all the filters within relate to 64 bit CPUs AND OSes ...

You can't run 64bit apps on a 32bit OS even if your CPU is 64bit ...

7ek

[Zep]

Seriously?!? This thread and all the filters within relate to 64 bit CPUs AND OSes ...

You can't run 64bit apps on a 32bit OS even if your CPU is 64bit ...

7ek

The 32 bit version of everything will run which brings us back to his original problem. My guess is the AVCSource call barfs in (2,6).

[bayex]

Seriously?!? This thread and all the filters within relate to 64 bit CPUs AND OSes ...

You can't run 64bit apps on a 32bit OS even if your CPU is 64bit ...

7ek
Avis dll files which I use 32-bit operating system setmtmode () to be active in the

[Livesms]

Update: I copied avisynth.dll and devil.dll to system32 on a Windows 2008 R2 setup, after which I imported avisynth.reg. I created a test script with the code "BlankClip().ConvertToYV12()". It does not load in either VirtualDub64 or x264. Both crash upon exit. VirtualDub64 gives an error message "AVI Import Filter error: (Unknown) 80040154".

The same problem.
Installed Avisynth_258, then unrar avisynth64_8-29-10.rar and installed avisynth64_install.cmd.
VDub says "AVI Import Filter error".
Opening any avs script before installing avisynth64_install.cmd - gives no error. x86 works fine.

CPU: Core i5-660, Windows 7 Ultimate x64.

[Livesms]

===

BTW - %PROCESSOR_ARCHITECTURE% with Windows 7 Ultimate + Core i5-660 returns " x86"

Need to comment "IF %PROCESSOR_ARCHITECTURE% == x86 (GOTO 32BIT)" in avisynth64_install.cmd

[nividia]

hi guys ...
is there a x64 build of Toon-v1.0-lite.dll yet ?

[travolter]

hi guys ...
is there a x64 build of Toon-v1.0-lite.dll yet ?

LOL I just entered into this post to ask same question ;)

Toon, toonlite or any line darkener is available in x64?

[GRKNGLR]

Hi,
When will new stable version be ready?

[Delerue]

===

BTW - %PROCESSOR_ARCHITECTURE% with Windows 7 Ultimate + Core i5-660 returns " x86"

Need to comment "IF %PROCESSOR_ARCHITECTURE% == x86 (GOTO 32BIT)" in avisynth64_install.cmd

Maybe checking if %WINDIR%\syswow64 exists (which exists only in x64 systems) is another solution. What you think?

[AlekseiV]

PROCESSOR_ARCHITECTURE will be "x86" if on x86 Windows or if an x86 program is asking, neither of which should happen on x64 with a batch file AFAIK.

If crazy you can use this to get accurate response without caring about process bitness:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /f "AMD64" /e /d
it will set errorlevel to 1 if it finds no matches

[kypec]

PROCESSOR_ARCHITECTURE will be "x86" if on x86 Windows or if an x86 program is asking, neither of which should happen on x64 with a batch file AFAIK.

It happened to me as well, just because I was launching installation .bat file directly from my file manager (Altap Salamander) which is still available as 32-bit application only.

[kemuri-_9]

if you don't want to check the registry, you can also check
%PROCESSOR_ARCHITEW6432% to be amd64 if %PROCESSOR_ARCHITECTURE% is x86
this is the scheme of how windows handles keeping x64 environment variables around in x86 mode.

though, the bat still had numerous issues last i looked at it, since it required avisynth32's plugin directory to be in the registry, which is not guaranteed at all
(e.g. manual removing of the registry key or not having avs32 installed at all).
I'm not even sure the not working on XP x64 issue was fixed either.

[GRKNGLR]

I have AviSynth64 installed on my system but when I try to load a script on Veedub64, I receive an error which says I don't have "libfftw3l-3.dll".
Though I have downloaded the required files from ftp://ftp.fftw.org/pub/fftw/fftw-3.2.2-dll64.zip address and have placed them in my system32 folder, it's still the same. The script opens ok on Veedub64, but I can't take screenshots. BTW AvsP and AvsPmod never work. Is it because I have Avisynth64 installed? When I try to use FFT3DFilter, I receive an error saying that I don't have "FFTW3.dll". Though I have placed that folder in system32 adn SySWOW64, it is the same. What can I do?

[soulkeeper]

i use avisynth64 with mvtools2 x64(from the 1st post) in ffdshow in order to do frame interpolation...
there are 2 new versions of mvtools2 x86 since then (2.5.10.1 and 2.5.11) which contains important fixes for my use..
is it possible to have updated mvtools2 x64?

PS if i understand correctly each x64 plugin is "based" on it's x86 version and it's just ported to x64..

Thanks!

[Turtleggjp]

I'm having trouble getting this to work in Windows XP x64. Scanning quickly through this thread, it seems that it should work. The error I'm getting when trying to open a simple script in 64-bit VirtualDub is: "AVI Import Filter error: (Unknown) (80040154)"

My script is pretty simple:

Version()

And it works if I use a 32-bit version of VirtualDub, so at least 32-bit AVISynth is installed. I get this same error in 32-bit VirtualDub if I uninstall AVISynth, so it seems that it is an indication that 64-bit VirtualDub can't locate the 64-bit AVISynth DLL, or the correct registry entries are not there. I've gone over the install procedure many times, and everything seems to be where it needs to be. I've tried doing a fresh install of XP x64, installing SP2, and running Windows Update (based on things I read earlier in this thread). If I had a copy of Windows 7 handy, I'd try that too, but I really don't want to run Windows 7 if I don't have to.

Here's some other info:
Core2 Duo 3.16 GHz
4GB memory
32-bit AVISynth version: 2.5.8 (no MT version, but I did try that too with no luck)
32-bit VirtualDub: 1.9.6 (works)
64-bit VirtualDub: 1.9.10

I'd appreciate your help. I'd really like to start using 64-bit x264 for my encodes. I have 64-bit DGNV Tools and 64-bit x264. 64-bit AVISynth is the last piece of my puzzle. Thanks!

Matt

[kemuri-_9]

Make sure that the avisynth and devil dlls are in the System32 folder and make sure you have run the registry file that came with the installer.

that should be a bare minimum for getting it to work at all.
then there's some extra stuff if you want to have an autoload directory for avisynth x86_64 like there is for the x86 one.

btw, this is what i did with Squid_80's x86_64 avisynth build long before JoshyD made this thread. I'm also on XP x86_64

[Turtleggjp]

The files are there, and I had added the registry entries. I even went as far as to make copies of all the included DLL files and put them in the VirtualDub x64 folder. I noticed that once 32-bit AVISynth was installed, if I moved the avisynth.dll file out of the SysWOW64 folder, 32-bit VirtualDub would give the same error message. Putting the DLL file into the same folder as the 32-bit VirtualDub binary would allow it to work again. Having the DLL in there without having it installed did NOT work. That's what led me to think that in order to get the 64-bit version to work, there might be some additional registry entries that need to get added in. At least it is encouraging to know that it should work in XP x64.

Matt

[henryho_hk]

You may need to correct the plugin path in registry manually coz it may be generated as "plugins 64" (yes, there is an extra space in between).

[kemuri-_9]

the plugin path is only required to have the autoload plugin feature, it is not required to have avisynth work:
I've removed the plugindir2_5 registry entry because I find plugin autoloading annoying and avisynth still works here.

however, x264 does not rely on avisynth being registered in the registry to utilize it like apps that use it through VFW do (virtualdub).

so you should be able to use avisynth with x264 x86_64 as long as it and the devil dll are in your System32 folder (technically as long as they're in the PATH, but System32 would be the best spot).

though the fact that it doesn't work with virtualdub does make it harder to preview the script...

You will probably need to check and make sure the registry values went in correctly.

so manually open the 64bit regedit (NOT the 32bit version) (doing it from a standard x64 cmd prompt or the run command will be the correct one)
and verify that all the values in the registry file are actually in the registry.

all 3 values are important, the first is to register avs as an AVIFile (so anything that uses VFW api on it will try and use avisynth)
and the latter two are to register avisynth as a valid application/service per se - so the first value works.

if they are in correctly, then i'm not sure what the problem would be... all i could say at that point is "try the windows cure-all - restarting if you haven't already"

[Turtleggjp]

When I've been running regedit, I have been doing so from the Run command in the start menu. It sounds like I was opening the right version. I had been checking to see if the registry entries were there, as well as trying to figure out exactly what they all meant.

I will try running 64-bit x264 on that version() script and see if that works.

@kermuri, have you installed SP2 and all the updates from Windows Update too?

[Turtleggjp]

No go on x264:

D:\Documents and Settings\Administrator>E:\Apps\x264.1745.x64.exe -o E:\apps\version.mp4 e:\apps\Version.avs
avs [error]: failed to load avisynth
x264 [error]: could not open input file `e:\apps\Version.avs'

I even tried putting all the DLLs right next to the x264 binary:

DirectShowSource.dll
MT.dll
avisynth.dll
DevIL.dll

with no change. These are the DLLs from the 8-29-10 release in this thread. @kermuri, what version are you using?

[kemuri-_9]

i have the 8-29-10 release.
i have SP2, tho i haven't done windows updates for about a month.

Strange, it should work with the scenario you're providing...

hmm... i have visual studio installed, do you have the visual studio 2008 runtime installed? this may be required...

overall, it does look like you can absolutely not use the avisynth.dll as it can't be loaded for some particular reason,
you can try a small test program (http://kemuri9.net/dev/avs/test_avs_load.7z) that will actually output the error code from the loadlibrary call on it to see what the problem is (you'll likely need to google the error code).
I suspect that it may indeed be the visual studio 2008 runtime if you don't have it installed.

[Turtleggjp]

Update:

I found a copy of Windows 7, and I installed 64-bit Ultimate version. No serial number, no activation, just installed it. The result: it worked! :angry: (yes, I'm angry. I don't want to have to run Windows 7 just for this)

I didn't copy any DLL files into the system32 folder or anything, I just used the copies that I had put in the folder with the x264 x64 binary. I came right back to XP x64, didn't change anything, just ran the same command from the command line, and it still doesn't work here.

I do not have Visual Studio 2008 anything installed. Is the runtime library you mentioned free to download? I have a feeling that may be the key to this...

EDIT: I think I found it here (http://www.microsoft.com/downloads/en/details.aspx?familyid=BD2A6171-E2D6-4230-B809-9A8D7548C1B6&displaylang=en). I installed that, rebooted, and it still doesn't work. I'll see what I can find out with that last link you posted.

EDIT2:
Running the 64-bit version of that little program gives this:

E:\Apps>E:\Apps\testavsload64.exe
unable to load avisynth, error code = 14001

Running the 32-bit version gives this:

E:\Apps>"D:\Documents and Settings\Administrator\My Documents\Downloads\testavsload32.exe"
can load avisynth without issues

[henryho_hk]

Try installing those Visual Studio/C Redistributable 2005 2008 2010... SP1 SP2 SP3..... x86 x64.... etc.

[kemuri-_9]

hmm.
error 14001 that's a vague error that usually ends up referring to visual studio runtime/manifest issues.

hmm... ok, i did what i should've in the first place: run dumpbin/dependency walker on avisynth.dll and devil.dll and see what they're importing from other dlls.

results:
avisynth.dll itself does not require anything outside of normal windows libraries and devil.dll

devil.dll requires Microsoft visual studio 2005 runtime (the x64 version) to be installed in addition to normal windows libraries.

so install this (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=eb4ebe2d-33c0-4a47-9dd4-b9a6d7bd44da)

[Turtleggjp]

Ok, got it. I'll install that tonight when I get home. Hopefully that will do it then. Thanks so much for your help!

[Tuik]

Hey people, can you give me some help?

Hey, i don't know what happen but now i'm getting this error when opening the avs script (a simple DirectShowSource("video.mkv")) on megui 64:

---------------------------
AviSynth error
---------------------------
AviSynth script error:

DirectShowSource: RenderFile, the filter graph manager won't talk to me
(C:\Users\Admin\Documents\Encodes\script.avs, line 8)
---------------------------
OK
---------------------------

I'm using DirectShowSource with Haali Media Splitter and CoreAVC Pro installed.

Also i'm using avisynth64_4-16-10 version and in MPC x64 the movie opens well (not the .avs but the HD source since the .avs opened in MPC gives the same error). Maybe it's something wrong with avisynth no?

[Turtleggjp]

devil.dll requires Microsoft visual studio 2005 runtime (the x64 version) to be installed in addition to normal windows libraries.

so install this (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=eb4ebe2d-33c0-4a47-9dd4-b9a6d7bd44da)

SUCCESS!! That did it. I tried encoding my version.avs script using 64-bit x264, and it worked, just like in Windows 7 x64. I'm now going to do a clean install to see if SP2 and all the updates are necessary or not.

Perhaps this requirement should be added to the first page for those few others trying to run this on XP x64. Also, is it possible in the future that this requirement will be dropped? I can't exactly wave the bloatware flag over a little 3MB download, but it would be nice if this was no longer required, since it never has been for 32-bit AVISynth.

Thanks again Kemuri!

Matt

EDIT: After doing my clean resinstall, the first thing I did was install that runtime library (before drivers, updates, even 32-bit AVISynth). Once I did that, 64-bit x264 could use the 64-bit avisynth.dll, so it definitely seems that it is required for use in XP x64. Windows 7 didn't need it, and I did not test Vista.

[travolter]

There is any bug with assumefps()?

Im trying to change fps and create slowmotion videos with assumefps(10) (I use this line in x86 and works), but its not working in avisynth x64 (the video is not slowed down.. its like it loses frames).

If its confirmed bug.. there is any workarround for continue working on x64 and do slowmotion?

[henryho_hk]

I've modified the install and uninstall cmd batches to fix the plugins64 directory name generation and tidy up the codes. Please enjoy.

[Hagbard23]

@JoshyD: Is still something going on in here, or is it like you have no time to maintain the project any further? That would be a damn pity, because i really liked this project.

Please give a sign from yourself... ;)

[zmaster]

Hi!

I just want to say that many users (myself included) eagerly awaiting the development branch x64 plugins. Current status makes the possibility of using AviSynth x64 somewhat limited.

[AlekseiV]

@JoshyD: Is still something going on in here, or is it like you have no time to maintain the project any further? That would be a damn pity, because i really liked this project.

Please give a sign from yourself... ;)Last update was only 3 months ago. Not even close to dead.

[Didée]

Alas, the last update is buggy. (Aug 24 build)

I have been wondering why so many scripts are crashing upon script loading. Tested plenty of plugins, but couldn't find the culprit.

Today I found something:

In the 08-24 build, TemporalSoften() is broken.

More precisely: the scenechange detection is broken.

Works: clip.TemporalSoften(3,4,5) # RGB / YUY2 / YV12 colorspaces

Crashes: clip.TemporalSoften(3,4,5,6,2) # YUY2 / YV12 colorspace. (RGB never did support scenechange detection anyway.)


That's what I call a showstopper.

[Prettz]

I'm just about done with the YV12 version of a new 64-bit FluxSmooth, completely rewritten for SSE2 and SSSE3. I had to obtain the Intel compiler, due to needing inline assembly, before I could even make sure it compiles, so I still need a bit more time before it's ready for testing and feedback. I'm going to post a new thread for it when I'm ready.

[tormento]

Even a MedianBlur_x64 would be very nice. Anyone skilled enough?

Please ;)

[AppleA]

Its.dll is useful plugin for vfr(Variable Frame Rate) source.
And we can easily get chapter file.
Could someone please compile a 64-bit Its.dll?
There appears to be a source code in the 7z file.
http://www.avisynth.info/?plugin=attach&refer=%A5%A2%A1%BC%A5%AB%A5%A4%A5%D6&openfile=Its086.7z

[jpsdr]

Latest version, PointResize don't work/crash on 1080p YV12 video.

[blausand]

Hey there,
i appreciate that, after clicking through the devasted areas of

AviSynth.org,
there: /mediawiki, /avisynth3, German pages etc.
SourceForge.net
QUITE some forum.doom9.org threads,
and, finally, some absolutely uncommented indexOf in
members.optusnet.com.au/squid_80
for AviSynth x64,


i finally find some sign of life here, in this very thread. Brave developers! Really.
Thank you for sissiphossing all those lines of x86 code to x86-64, thanks for struggling through the pains and wonders of Windows Media Foundation Whatsoever.

As everybody knows, some major media production software vendors have finally managed to release 64bit versions of their video editing software - where we so much loved to directly open our RGB32-formatted AVS-output into.
And i think right now it is time to plan some changes to the FRONTpages of Avisynth. It is just evident that a software without noticeable signes of life on it's homepage is -yes- DOOMED to die.
Let's talk about updating those wiki-pages.
NOW.HERE. (http://forum.doom9.org/showthread.php?t=158527)

[Wilbert]

And i think right now it is time to plan some changes to the FRONTpages of Avisynth. It is just evident that a software without noticeable signes of life on it's homepage is -yes- DOOMED to die.
Let's talk about updating those wiki-pages.
NOW.
Go ahead, talk :) I know nothing about x86-64, nor have the time to do much at the moment. Perhaps it's best to open a separate thread about it.

[blausand]

Did so here (http://forum.doom9.org/showthread.php?t=158527).
Sorry for repeating part of the previous post there.
Even more sorry for inconvenience in this very thread.

[osgZach]

Its.dll is useful plugin for vfr(Variable Frame Rate) source.
And we can easily get chapter file.
Could someone please compile a 64-bit Its.dll?
There appears to be a source code in the 7z file.
http://www.avisynth.info/?plugin=attach&refer=%A5%A2%A1%BC%A5%AB%A5%A4%A5%D6&openfile=Its086.7z


That links is busted for some reason.. Here

http://www.avisynth.info/?%A5%A2%A1%BC%A5%AB%A5%A4%A5%D6

Maybe this one will work.. otherwise just google ( Avisynth, "its.dll" ) to bring up a result for the Japanese page, it was easy enough to find.

Anyway... is there english documentation for this? WHAT does it do? I'm always interested in VFR stuff, and I think I heard of this DLL before when I got into using YATTA, but I couldn't find it back then..

[Stephen R. Savage]

That links is busted for some reason.. Here

http://www.avisynth.info/?%A5%A2%A1%BC%A5%AB%A5%A4%A5%D6

Maybe this one will work.. otherwise just google ( Avisynth, "its.dll" ) to bring up a result for the Japanese page, it was easy enough to find.

Anyway... is there english documentation for this? WHAT does it do? I'm always interested in VFR stuff, and I think I heard of this DLL before when I got into using YATTA, but I couldn't find it back then..

IT is a combination field matching and decimation filter. It's briefly mentioned in the Yatta manual as one of the three metric sources. From the source, it appears to have automatic VFR detection and timecodes output. As for whether it's any good... I don't know, I've never used it.

[osgZach]

IT is a combination field matching and decimation filter. It's briefly mentioned in the Yatta manual as one of the three metric sources. From the source, it appears to have automatic VFR detection and timecodes output. As for whether it's any good... I don't know, I've never used it.

Automatic VFR detection? Would be interesting to play with :p

Wish someone around here had made a filter like that to see how well it works.

Although I suppose our current tools do the job pretty well. Still would be a neat idea.

[AppleA]

Its.dll is different from It.dll or itvfr.dll.
Its.dll is support filter to make vfr file.
Its.dll can't do automatic VFR detection.

Its.dll Usage

Its( def, tpr, fps, debug, posx, posy, chapter , output )

def [strig]
set definition file pass
tpr [string]
set TMPGEnc(ver 2.5xx) projectfile pass
this is capable to be abbreviated.
fps [int default=-1]
set output fps
=-1:120pfs(mixed fps)Delete frame stripped mode
=0:120fps(mixed fps)
=24:24fps
=30:30fps
it should use exavi_vfr.auo to set 120fps
debug [bool default=false]
=true:show debug infomation
=false:don't show degub infomation
posx,posy [int default=0]
set pixel value for debug infomation position
chapter [string]
set generated chapter file pass
chapter file is output quickly after initialize
output [string]
set generated timecode pass
timecode is output quickly after initialize
if chapter file pass is seted, only extension is ok

example
------ foo.avs -------------------------
OpenDMLSource("baz.avi")
AssumeFrameBased().ComplementParity()
its(debug=false, def="foo.def", fps=-1, posx=300, chapter="bar.xml", output=".tmc" )
return last
-----------------------------------------

construction for definition file

definition file is SHIFT-JIS or UTF-8.
set a instruction evry a line.
comment line take off #.
substitution line homologize function name InverseTelecine plugin or deinterlace plugin.
example
set [24] tfm = 'TFM(order=1,mode=1,PP=1,slow=2).tdecimate()'
set [24] it = 'IT(ref="TOP")'
set [30] it = 'IT(fps=30,ref="TOP")'
set [30] td = 'TDeint(order=1,field=1,slow=2,mode=0)'
set [24] tmpgenc = tpr<"c:\foo.tpr">

string is bracketed off ' '," ",` ', { }.
[24],[30],[60],[48],[20],[10],[12],[15] set fps.
[24] it is differentiated [30] it.

default behavior set on range set line(later discussion).
default 24 = it
default 30 = td

range set line
set handling like that.

0-99999 [24]:command / function name

range is set startframe-endframe.
if startframe only, range is startframe only.
[24] set fps.
command make a choice frame after doubleweaved frame.
It should set field order before Its.
frame number is 0(0a), 1(0b), 2(1a), 3(1b), 4(2a), 5(2b), ...
there are some command.
on_a(on), on_b, off_a(off), off_b, dup_a(dup), dup_b, null_a(null), null_b , tpr<"foo.tpr">, <10010>, (5,0,3)、chapter=

here, on is output, off is delete, dup is frame copy, null is drop.
tpr<> is TMPGEnc project, <10010> is frame choice pattern.
(5,0,3) is choice 0th frame nad 3rd frame every 5 frames.
max cycle is up to 30.
chapter=string set chapter at first frame for range.

mode set line
default fps set like
mode fps_priority=24
mode fps_priority=30
set chapter character.[default: "SHIFT_JIS"]
mode chapter_charset = SHIFT_JIS
mode chapter_charset = UTF-8

keyframe set line
example

keyframes {
100 "OP"
200
300 A Part
400
500
600
700 'B Part'
800
900
1000 Trailer
}

character after num set chapter.


about debug infomation
frame=80(100 80<+0>) 24fps (for fps=24)
frame=100(100 100<+0>) 30fps (for fps=0/30)

definition file example

set [24] it = 'IT(ref="TOP")'
set [24] xx = 'DoubleWeave().a60224()'
set [24] /01 = <01010> #01frame is strip for 2:3pulldown source.
set [24] /12 = <10010> #12frame is strip for 2:3pulldown source.
set [24] /23 = <10100> #23frame is strip for 2:3pulldown source.
set [24] /34 = <00101> #34frame is strip for 2:3pulldown source.
set [24] /40 = <01001> #40frame is strip for 2:3pulldown source.
set [24] decimate = 'tdecimate()'
set [24] tfm = 'TFM(order=1,mode=1,PP=1,slow=2).tdecimate()'
set [24] tfm2 = 'TFM(order=1,mode=1,PP=6,slow=2).tdecimate()'
set [30] td = 'TDeint(order=1,field=1,slow=2,mode=0)'
set [30] tddefo = 'tdeint(order=1,field=1,tryWeave=true,slow=2)'
set [30] td2 = 'tdeint(order=1,field=1,tryWeave=true,slow=2,emask=last.TMM(order=1,field=1))'
set [30] fs ='doubleweave().selectodd()'
set [30] pp = <10>
set [60] eedi = 'separatefields().MT("""EEDI2(field=3)""",threads=8,splitvertical=true)'
mode fps_priority = 24
default 24 = tfm2
default 30 = td
default 60 = eedi
keyframes{
4434"OP"
7427"A-Part"
23307"B-Part"
40130"ED"
42842"Trailer"
}
0- 7426 00:04:07[24] /01
7126[24]dup_a
7426[24]dup_a
7427- 7665 00:00:07[24] /01
7666- 8264 00:00:19[60] eedi
8265-23306 00:08:21[24] /23
23307-42841 00:10:51[24] /01
42842-44039 00:00:39[24] /01

[miker3x]

windows 7 does not open .rar what program due we use to open avisynth.

[Chikuzen]

windows 7 does not open .rar what program due we use to open avisynth.

just use 7zip (http://www.7-zip.org/), winrar (http://www.rarlab.com/), or something you like.

[GRKNGLR]

I wouldn't like to ask about it but has AVS64 really died? The last release (test release) came at the end of August. No new releases or plugin updates since then. Can anyone make a clear explanation about it?

[nividia]

Any plan to do a x64 build of Toon,Toonlite ..etc or any line darkener is available in x64 ?

[Stephen R. Savage]

I wouldn't like to ask about it but has AVS64 really died? The last release (test release) came at the end of August. No new releases or plugin updates since then. Can anyone make a clear explanation about it?

There was only ever one developer, and he has disappeared. As far as I know, the original (2010-04) build still works, minus a few bugs. Overall, I'd say that the main reason AVS64 died was simply a lack of interest. Plugin developers had no interest in 64-bit, and nobody really bothered to contribute to the project.

Known bugs in 2010-04 AVS64:

The src_* parameters to Point/Bilinear/Bicubic resize cause an exception
XMM registers are clobbered ("PTS < 0" message in x264)


Known bugs in 2010-08 AVS64:

The src_* parameters to Point/Bilinear/Bicubic resize cause an exception
TemporalSoften crashes when the scene change detection is used


Plugin writers maintaining 64-bit versions:

tritical: eedi3 and nnedi3
manao: mt_masktools
kemuri-_9: ffmpegsource


In the interest of maintaining whatever information is available about this (hopefully not) dead fork, please contribute anything you might know that I have not summarized above.

[GRKNGLR]

Thank you very much for your answer, Stephen R. Savage. Too bad, coz we liked AVS64 a lot... A few questions then... When will AVS officially support x64? I mean, will the 2.6 or any later version officially support x64? The April release is stable but the August release has resizing bugs. The developer of AVS64 is missing and I'm really wondering where he is now. One last thing; where can I find the x64 versions of nnedi3 and eedi3?
Kind Regards

[Stephen R. Savage]

Thank you very much for your answer, Stephen R. Savage. Too bad, coz we liked AVS64 a lot... A few questions then... When will AVS officially support x64? I mean, will the 2.6 or any later version officially support x64? The April release is stable but the August release has resizing bugs. The developer of AVS64 is missing and I'm really wondering where he is now. One last thing; where can I find the x64 versions of nnedi3 and eedi3?
Kind Regards

64-bit support is not planned for Avisynth 2.6, nor any future version. There is simply no interest in it.

eedi3: http://bengal.missouri.edu/~kes25c/eedi3_64.dll
nnedi3: http://bengal.missouri.edu/~kes25c/nnedi3_64.dll

They require the MSVC runtimes (not sure which ones) to run.

[GRKNGLR]

Thank you so much for the quick reply.

[aegisofrime]

64-bit support is not planned for Avisynth 2.6, nor any future version. There is simply no interest in it.

eedi3: http://bengal.missouri.edu/~kes25c/eedi3_64.dll
nnedi3: http://bengal.missouri.edu/~kes25c/nnedi3_64.dll

They require the MSVC runtimes (not sure which ones) to run.

No interest by whom? The developers or the users? Looking at the requests for 64-bit versions of various plugins in this thread, I would say there is substantial interest. Also, as the proportion of content grows towards HD, 64-bit might become necessary in the future.

[asarian]

No interest by whom? The developers or the users? Looking at the requests for 64-bit versions of various plugins in this thread, I would say there is substantial interest. Also, as the proportion of content grows towards HD, 64-bit might become necessary in the future.

^^ This. My HD content screams for 64-bit! Right now we already have to resort to using avs2yuv, to create a process seperation that will barely keep AVS running (and sometimes just not; and then your MCTemporalDenoise or other script just runs out of memory anyway).

So, yes, I'd say there is substantial interest. Also, as the proportion of content grows towards HD, 64-bit might become necessary in the future... Oh wait, he already said that. :) It bears repeating, though.

[lych_necross]

Clarification, there is no interest on the developers' side. Currently, the 64bit version offers no significant advantage over the 32bit version. Consumers want 64bit because they assume its twice as fast as 32bit, which isn't true.

[asarian]

Clarification, there is no interest on the developers' side. Currently, the 64bit version offers no significant advantage over the 32bit version. Consumers want 64bit because they assume its twice as fast as 32bit, which isn't true.

No, comsumers want 64-bit because of the huge memory constraints imposed on 32-bit. With HD material, and memory hungry, complex scripts, the need for the virtually unlimited memory space 64 bit offers becomes progressively more pertinent. In fact, if AviSynth won't go to 64-bit, then ere long it will obsolete itself, as 5-10 years from now, who will primarily still use DVD?

Speed-wise I reckon the increase for AviSynth 64-bit to be comparable to what you get with a 64-bit version of x264: a few percent.

[travolter]

FastLineDarkenMOD

do you have link for FastLineDarkenMOD x64?

[Didée]

What link? It's the very same script as you'd use in 32bit. The script utilizes mt_masktools and RemoveGrain. Both plugins are available compiled for x64.

[pokazene_maslo]

eedi3: http://bengal.missouri.edu/~kes25c/eedi3_64.dll
nnedi3: http://bengal.missouri.edu/~kes25c/nnedi3_64.dll

How did you get those links??? I was looking for x64 versions of those plugins for a long time without any success! On tritical's page are no references about them.

And I'm also interested in x64 avisynth because some functions are a lot faster in 64bit than in 32bit. (30% speed-up means a lot when we are talking about 10 hours of encoding)

[aegisofrime]

How did you get those links??? I was looking for x64 versions of those plugins for a long time without any success! On tritical's page are no references about them.

And I'm also interested in x64 avisynth because some functions are a lot faster in 64bit than in 32bit. (30% speed-up means a lot when we are talking about 10 hours of encoding)

Agreed. Any speedup is better than none, even if it's not twice as fast :) Of course, as asarian has pointed out, the demands of HD content on memory is more critical.

[travolter]

What link? It's the very same script as you'd use in 32bit. The script utilizes mt_masktools and RemoveGrain. Both plugins are available compiled for x64.

Well, FastLineDarkenMOD is a script. You can get it here. The plugin you need is just masktools2 x64, which is already contained in official package.

Thanks for the help guys! :) all is working in x64 now.
(Im not used to avisynth a lot, sometimes I dont know if certain filter is a .dll or a .avs that needs other dependencies)

[Romario]

Hi guys,I have urgent question...because my build of Avisynth x64 won't work in my Windows 7 x64.

I applied ALL updates for Win 7 x64 via Windows Update,but when I try to install Avisynth64 I get a following message: "64-bit of Windows not detected, press any key to continue".

Maybe I using wrong installer,I don't know.

[kypec]

but when I try to install Avisynth64 I get a following message: "64-bit of Windows not detected, press any key to continue".

Maybe I using wrong installer,I don't know.
Please see this post (http://forum.doom9.org/showthread.php?p=1448981#post1448981) where I did explain what one has to do in order to install it properly onto Win7 x64.

[travolter]

is assumefps() working in the x64 avisynth?.

Im trying to use it with a script loaded into ffdshow x64 and I dont know if the problem come from avisynth or ffdshow

[ryrynz]

How did you get those links??? I was looking for x64 versions of those plugins for a long time without any success! On tritical's page are no references about them.

It's because he is the man.

[cweb]

I ported stickyboy's selectbystring to x64 in case anyone finds it useful. It's working fine for me.

http://hotfile.com/dl/106518262/464a052/selectbystring_x64.rar.html

It's needed for the JDL_Wipe transition...

[djesteban]

^^ This. My HD content screams for 64-bit! Right now we already have to resort to using avs2yuv, to create a process seperation that will barely keep AVS running (and sometimes just not; and then your MCTemporalDenoise or other script just runs out of memory anyway).

So, yes, I'd say there is substantial interest. Also, as the proportion of content grows towards HD, 64-bit might become necessary in the future... Oh wait, he already said that. :) It bears repeating, though.

Yeah, it would really be nice if they start supporting x64. Even dgdecnv as x64 binairies now. Hope the devs change their minds in the future.

[fabje]

Is it possible to run this script in 64bit?
The source.ts will be encoded to a mkv file.

LoadCPlugin("E:\Staxrip\Applications\AviSynth\plugins\Yadif\yadif.dll")
SetMTMode(5,2)
DirectShowSource("E:\source.ts", audio=false, convertfps=true, fps=25.000)
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
SetMTMode(2)
Yadif()
LanczosResize(1280,720)
Trim(52,38210)

[cweb]

Is it possible to run this script in 64bit?
The source.ts will be encoded to a mkv file.

LoadCPlugin("E:\Staxrip\Applications\AviSynth\plugins\Yadif\yadif.dll")
SetMTMode(5,2)
DirectShowSource("E:\source.ts", audio=false, convertfps=true, fps=25.000)
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
SetMTMode(2)
Yadif()
LanczosResize(1280,720)
Trim(52,38210)
IMHO it should work. Remember to use the 64 bit Yadif.

I'd like to encourage people to port plugins to 64 bits as it helps with the adoption of the 64 version...

[fabje]

IMHO it should work. Remember to use the 64 bit Yadif.

I'd like to encourage people to port plugins to 64 bits as it helps with the adoption of the 64 version...
I'm using a 64Bit version of Yadif, but I keep getting this error:
Unable to load C Plugin: E:\Staxrip\Applications\AviSynth\plugins\Yadif\yadif.dll(E:\source temp files\source.avs, line 1)

I got the 64bit Yadif from here (http://blog.niiyan.net/post/663681140/64-bit-version-of-yadif-plugin).

When I disable Yadif the encoding will start.

[cweb]

I'm using a 64Bit version of Yadif, but I keep getting this error:
Unable to load C Plugin: E:\Staxrip\Applications\AviSynth\plugins\Yadif\yadif.dll(E:\source temp files\source.avs, line 1)

I got the 64bit Yadif from here (http://blog.niiyan.net/post/663681140/64-bit-version-of-yadif-plugin).

When I disable Yadif the encoding will start.
I haven't tried using yadif since I usually use DGIndexNV for GPU-based deinterlacing.. perhaps you could try this.

[fabje]

I haven't tried using yadif since I usually use DGIndexNV for GPU-based deinterlacing.. perhaps you could try this.
Well I'm using FFMPEG and the reason for that is because it speeds up the encoding of an 1280x720 mkv file with 40fps more. Well at least when I was using DGAVCIndex.

When I'm using DGIndexNV I get this error: Unable to load ("DGDecodeNV.dll"), but the path to the file is correct.

[fabje]

I'm using a 64Bit version of Yadif, but I keep getting this error:
Unable to load C Plugin: E:\Staxrip\Applications\AviSynth\plugins\Yadif\yadif.dll(E:\source temp files\source.avs, line 1)

I got the 64bit Yadif from here (http://blog.niiyan.net/post/663681140/64-bit-version-of-yadif-plugin).

When I disable Yadif the encoding will start.
Someone knows how to solve this?

[Adub]

I take it that you switched out Staxrip's version of the Yadif plugin, and replaced it with your own?

[fabje]

I take it that you switched out Staxrip's version of the Yadif plugin, and replaced it with your own?
Yes this is what I replaced with a 64bit version.
I changed this to 64bit:
Avisynth
FFDShow
Autocrop
Yadif
x264

The only thing that I didn't find was Lanczos in 64bit.

[fabje]

Nobody?

[cweb]

Nobody?
I might try it if I find some time in the coming days.
As I said I use the GPU's deinterlacing that's why I had never tried the 64 bit yadif.

[Delerue]

I might try it if I find some time in the coming days.
As I said I use the GPU's deinterlacing that's why I had never tried the 64 bit yadif.

Sorry if this sound a little off-topic, but since GPU deinterlacing requires DXVA (or am I wrong?) do you know any kind of CPU deinterlacing that uses vector adaptive technology (http://www.anandtech.com/show/2931/4)?

Edit: is there a 64 bit version of QTGMC?

Thanks

[Mr VacBob]

There are several non-realtime motion adaptive deinterlacers available as Avisynth scripts. Try yadif and see if you're unhappy with it.

[Delerue]

There are several non-realtime motion adaptive deinterlacers available as Avisynth scripts. Try yadif and see if you're unhappy with it.

Sorry, I mean vector adaptative. Yadif isn't a vector adaptive technology, right?

[trevaaar]

QTGMC is a script, not a plugin. As long as you get a 64-bit version of all its dependencies it runs fine, I'm using it right now for an encode.

[Delerue]

@trevaaar, thanks for the tip. I'll try later.

[Delerue]

I've tried to run QTGMC with all 64-bit dependencies, but no success. It crashes instantly with MPC-HC x64 1.5.2.2972 + FFDShow x64 3760. I've tried to use with avisynth tab inside FFDShow (checking 'Add ffdshow video source') using only this line of code:

QTGMC( Preset="Medium" )

Here's the list of the dependencies I have:

nnedi3_64.dll (0.9.2.0)
mt_masktools-25-x64.dll (2.0.48.0)
mvtools2.dll (last 'official' version of Joshua Duncan from the first page of this very thread)
avisynth.dll (same as above)
Repair.dll and Removegrain.dll (from here: http://code.google.com/p/avisynth64/wiki/PluginLinks)

Any idea?

[camorra]

I've tried to run QTGMC with all 64-bit dependencies, but no success. It crashes instantly with MPC-HC x64 1.5.2.2972 + FFDShow x64 3760. I've tried to use with avisynth tab inside FFDShow (checking 'Add ffdshow video source') using only this line of code:

QTGMC( Preset="Medium" )

Here's the list of the dependencies I have:

nnedi3_64.dll (0.9.2.0)
mt_masktools-25-x64.dll (2.0.48.0)
mvtools2.dll (last 'official' version of Joshua Duncan from the first page of this very thread)
avisynth.dll (same as above)
Repair.dll and Removegrain.dll (from here: http://code.google.com/p/avisynth64/wiki/PluginLinks)

Any idea?

Same problem here...
win7 x64 prof. I tried all QTGMC versions but no results.

[Delerue]

Same problem here...
win7 x64 prof. I tried all QTGMC versions but no results.

Try this, unchecking the option 'Add ffdshow video source':

setMTMode(2,4)
ffdshow_source()
ComplementParity()
QTGMC( Preset="Medium", EdiThreads=4 )
distributor()

[camorra]

Try this, unchecking the option 'Add ffdshow video source':

setMTMode(2,4)
ffdshow_source()
ComplementParity()
QTGMC( Preset="Medium", EdiThreads=4 )
distributor()

nope, doesnt works :/

[Delerue]

nope, doesnt works :/

You also should have this installed: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=90548130-4468-4bbc-9673-d6acabd5d13b

If even with this you don't get any success, maybe you should download the new full package in the first page of this thread.

[camorra]

You also should have this installed: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=90548130-4468-4bbc-9673-d6acabd5d13b

If even with this you don't get any success, maybe you should download the new full package in the first page of this thread.

got 2008, 2005... still same problem. :/

[Didée]

@ camorra: You're a bit vague with your initial "same problem here". Is it specifically when you try to use QTGMC within ffdshow-tab/Avisynth in MPC-HC64? Can you load & run that script in VeeDub64, or not?

In any case, try it without "distributor()" ....

[VincAlastor]

i can't get to run avisynth x64 and staxrip. i use the following scipt:

DGSource(...)
fft3dgpu(sigma=2.3, sharpen=0.9, precision=1)
gradfun2db(1.51)

staxrip says: "could not load C:\staxrip\applications\DGDecNV\dgdecnv.dll" - but i have changed dgdecodenv.dll 32bit with dgdecodenv.dll 64bit.
how get to run avisynth x64 with staxrip? what apps beside avisynth, the used filters and x264 i have to replace with there x64 versions?

[7ekno]

how get to run avisynth x64 with staxrip?

impossible, StaxRip is 32bit code, it can't call 64bit apps ....

7ek

[aegisofrime]

If you need a GUI, then use MeGUI x64...

[VincAlastor]

impossible, StaxRip is 32bit code, it can't call 64bit apps ....

7ek

If you need a GUI, then use MeGUI x64...

thank you to answer me. then i use staxrip 32bit further. MeGUI is not an alternative for me. :thanks:

[PhrostByte]

I'm getting "Avisynth open failure: Evaluate: Unrecognized exception!", after AvisynthPluginInit2 but before my function creation callback gets called. Anyone experienced something similar?

[tormento]

Is there any chance to get the x64 compiled version of the latest MVTools2?

[Motenai Yoda]

I found a chroma bug in resizers if the target height is mod2 and the colorspace is YV12...

[levi]

Sadly, JoshyD has long been silent. I don't expect to see further enhancements. :(

did you try the test release with resizer fixes?

http://code.google.com/p/avisynth64/downloads/detail?name=avisynth64_8-29-10.rar&can=2&q=

[EmuAGR]

That test release fixed my "non-strictly-monotonic pts" warning in x264 when using a resizer in the avs64 script. I'll continue testing it. :)

Thanks.

[blindbox]

Maybe I should make a new thread but I'm not sure. Long post, so bear with me :).

[you can skip this part]
I'm very thankful that we can have 64-bit though I have a big problem that many other probably face - the lack of plugins. It never hurts to ask, so does anyone knows of any subtitle editing plugins (SubtitleEx or TextSub for example) that exists in a 64-bit dll? I desperately tried to find SubtitleEx and TextSub 64-bit builds, with higher hopes on TextSub since it's made by Gabest but I couldn't find any. I also tried to find the source code of TextSub (again, made by Gabest so there might be a source code) so that maybe I can compile a 64-bit dll myself (I am THAT desperate) but I couldn't find any either.
[/you can skip this part]


Is there no other way? I currently have three options. One is to use softsubs. The second option is to use avisynth 32-bit, and consequently, use a 32-bit encoder(I preferrably not do this). The third option is for me to learn how to program (I definitely prefer NOT to due to the time it takes :eek: ).

I figured that using softsubs is probably the best but with softsubs, I will have to encode twice, unless there is a method of turning softsubs into hardsubs that I do not know of. Less painful to learn to write .ass than to write .cpp files.

I have to say AviSynth is one heck of an impressive software (also with the help of AvsPmod), so good that it drove me to want to start programming and made me lack sleep.

I'm thinking about using 32-bit again. The performance difference between 32-bit and 64-bit isn't too much is it? Should I go through the pains of learning .ass or just stick to 32-bit simply because it's not worth it?

Someone recommend me an option.

[Lyle_JP]

Someone recommend me an option.

Well, there is an x64 version of VSFilter.dll, which will allow you to use textsub() and vobsub(). It's distributed via the online updating system for MeGUI x64, and I'm sure there's a link to it somewhere.

[sneaker_ger]

You can also get it here:
http://xhmikosr.1f0.de/index.php?folder=bXBjLWhj

It's in the standalone filter package.

[blindbox]

Wow guys, thanks a lot! I managed to find it in megui x64.

P.S.: Just realised that was my first post. Man, I've lurked the forum for a year.

EDIT: Now I face another problem. It says

LoadPlugin: unable to load "<plugin filename here>.dll"

EDIT2: Nevermind, I figured it out, AvsPmod is 32-bit.

[levi]

Use
try { Load_StdCall_Plugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\<plugin filename here>.dll") }
catch(err_msg) { Load_StdCall_Plugin("C:\Program Files (x86)\AviSynth 2.5\plugins\<plugin filename here>") }

It will fall back to 32-bit version if you are using a 32-bit app.

[azulazules]

Hey there...
Does anyone know if dup.dll v2.30 was compiled for x64 2.5.8 avisynth?
Or can someone help me in compiling it?
Source code of dup.dll v2.30 is here: http://neuron2.net/dup/dupnew.html
Thanks alot! :-)

[asarian]

Can someone please mention a frame-accurate source filter for use with SEt's Avisynth 2.5.8 MT compiled for *X86_64*? FFVideoSource yields an (obvious) error that there is no function named; and DirectshowSource craps in all directions it can whiz.

This is meant for use with MCTemporalDenoise, btw.

Much obliged.

[levi]

http://neuron2.net/dgdecnv/dgdecnv.html

64bit version included in the standard zip

[AlekseiV]

FFVideoSource yields an (obvious) error that there is no function named You have installed FFMS2 x64?

[asarian]

You have installed FFMS2 x64?

Thanks. I just did. :) I'm getting an immediate error, though ("x264 has stopped responding") when I run the following script (for 64-bit):



LoadCPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\ffms2.dll")

SetMTMode(5,4)

FFVideoSource("f:\jobs\unter.mkv").ConvertToYV12()

SetMTMode(3)

MCTemporalDenoise(settings="medium", stabilize=true)
GradFun2DBmod(thr=1.4,thrC=1.0,mode=0,str=1.2,strC=0.0,temp=50,adapt=64,mask=false,show=false)

SupTitle("f:\jobs\unter_exp.sup", forcedOnly=false, swapCbCr=false, relocate=true, relocOffset="0,0,0,0")

[cezar]

It will be so good, if someone compiles DGAVCdecode for x64 avisynth. It's very nice frame-accurate source filter.
I ask to consider it as request.

[kypec]

DGAVCDecode has been abandoned & its support has ceased. Try DGDecNV (http://neuron2.net/board/viewforum.php?f=8) or DGAVCDecDI (http://neuron2.net/board/viewforum.php?f=6) if you don't have NVidia GPU.

[cweb]

I finally tried the 64 bit yadif, had the same problem you had.

Managed to solve it.

Just specify the path of the 64 bit yadif explicitly:
Loadcplugin("c:\apps\avisynth2\plugins 64\yadif.dll")

[eni9ma]

FFT3DGPU working on Avisynth x64?

I put in the fft3dgpu.hlsl+dll same directory

but unable to load fft3dgpu.dll

What's the problem?


LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\FFT3dGPU.dll")
FFT3dGPU(bt=1, sigma=2.0, bw=32, bh=32, ow=16,oh=16)

[easyfab]

Here's no problem and I don't use loadplugin ,
Do you have the correct x64 version (see first page of this thread ) ?

[Chris_Smith]

Hi JoshyD,

Have tested avisynth-4-16--2010 on Win7_x64, and have been using it to encode to x264, using 64-bit DGDecode and ColorMatrix. do you know if there is a version of avisynth64 that will run on 64-bit Server 2003/XP?

[TheRyuu]

Well I managed to 'fix' TemporalSoften although it's not much of a fix. Turns out several of the SSE3 asm functions don't seem to work (I don't exactly understand what's going on). The offending functions are: scenechange_sse3_asm and accumulate_line_mode2_axmm.

Basically I disabled those so now it uses the next best one by default now (ISSE). Not much of a fix but I don't understand it enough to really fix it correctly. Same with pointresize and company, I just don't know enough to fix it.

Also I noticed some rather weird settings in the build options. It kind of looks like a case of someone who doesn't know what they're doing screwing with random options. Since it's built with ICL I also included code which will cause it to not penalize AMD cpu's although there shouldn't be much dispatching with only /arch:SSE2.

Build: avisynth-x64-20110906.7z (http://warpsharp.info/avisynth/avisynth-x64-20110906.7z)
Diff: Index: src/filters/Video/focus.cpp
===================================================================
--- src/filters/Video/focus.cpp (revision 43)
+++ src/filters/Video/focus.cpp (working copy)
@@ -1708,10 +1708,10 @@
if ((!skiprest) && (!planeDisabled[i]))
{
int scenevalues = 0;
- if (env->GetCPUFlags() & CPUF_SSE3)
+ /* if (env->GetCPUFlags() & CPUF_SSE3) //FIXME: BROKEN?
scenevalues = scenechange_sse3_asm(c_plane, planeP[i], h, frames[radius]->GetRowSize(planes[c]), pitch, planePitch[i]);
- else
- scenevalues = scenechange_isse_asm(c_plane, planeP[i], h, frames[radius]->GetRowSize(planes[c]), pitch, planePitch[i]);
+ else */
+ scenevalues = scenechange_isse_asm(c_plane, planeP[i], h, frames[radius]->GetRowSize(planes[c]), pitch, planePitch[i]);

if (scenevalues < scenechange)
{
@@ -1732,10 +1732,10 @@
if ((!skiprest) && (!planeDisabled[i+radius]) ) { // Disable this frame on next plane (so that Y can affect UV)

int scenevalues = 0;
- if (env->GetCPUFlags() & CPUF_SSE3)
+ /* if (env->GetCPUFlags() & CPUF_SSE3) //FIXME: MORE BROKEN SHIT?
scenevalues = scenechange_sse3_asm(c_plane, planeP[i+radius], h, frames[radius]->GetRowSize(planes[c]), pitch, planePitch[i+radius]);
- else
- scenevalues = scenechange_isse_asm(c_plane, planeP[i+radius], h, frames[radius]->GetRowSize(planes[c]), pitch, planePitch[i+radius]);
+ else */
+ scenevalues = scenechange_isse_asm(c_plane, planeP[i+radius], h, frames[radius]->GetRowSize(planes[c]), pitch, planePitch[i+radius]);

if (scenevalues < scenechange) {
planePitch2[d2] = planePitch[i+radius];
@@ -1783,15 +1783,19 @@
int div=divtab[b_div_line[i]];
c_plane[i]=(div*(int)s_accum_line[i]+16384)>>15; //Todo: Attempt asm/mmx mix - maybe faster
}
- } else { //TODO: transfer this loop from C++ to plain ol' asm
- if(env->GetCPUFlags() & CPUF_SSE3) //FIX: does address alignment ever screw us here?
- accumulate_line_mode2_axmm(c_plane, planeP, d, rowsize,i64_thresholds, c_div);
- else if ((env->GetCPUFlags() & CPUF_INTEGER_SSE)) {
- //isse_accumulate_line_mode2(c_plane, planeP, d, rowsize,&i64_thresholds, c_div);
+ } else {
+ /* TODO: transfer this loop from C++ to plain ol' asm
+ if(env->GetCPUFlags() & CPUF_SSE3) FIX: does address alignment ever screw us here? MAYBE SO I DONT KNOW
+ accumulate_line_mode2_axmm(c_plane, planeP, d, rowsize,i64_thresholds, c_div); */
+
+ if ((env->GetCPUFlags() & CPUF_INTEGER_SSE))
+ isse_accumulate_line_mode2(c_plane, planeP, d, rowsize,&i64_thresholds, c_div);
+ else
accumulate_line_mode2_mmx(c_plane, planeP, d, rowsize,i64_thresholds, c_div);
- } else {
- mmx_accumulate_line_mode2(c_plane, planeP, d, rowsize,&i64_thresholds, c_div);
- }
+
+ /* } else {
+ mmx_accumulate_line_mode2(c_plane, planeP, d, rowsize,&i64_thresholds, c_div);
+ } */
}
for (int p=0;p<d;p++)
planeP[p] += planePitch[p];

[jpsdr]

@TheRyuu.
I don't understand where your build comes from ? Have-you been able to get the code from Joshy_D ?

[kemuri-_9]

He probably got it from the googlecode site (http://code.google.com/p/avisynth64/)

[TheRyuu]

@TheRyuu.
I don't understand where your build comes from ? Have-you been able to get the code from Joshy_D ?

The source code is publicly available at the google code site. I built it myself...

[noee]

Not sure how I can help, but I get an immediate crash in avisynth.dll with:

Command Line:
"C:\Users\Mike\Documents\Utils\Conversion Tools\HDConverToX3\applications\x264\x264-64bit_10.exe" --crf 22 --preset medium --aq-mode 2 --tune film --sar 40:33 --output "C:\Temp\job1\hdconverttox_vts_01_1.h264" "C:\Temp\job1\input.avs"

INPUT.AVS:
SetMTmode(5,4)
Mpeg2Source("C:\Temp\job1\movie.d2v")
ChangeFPS(last,last,true)
SetMTMode(2)
tfm(last,d2v="C:\Temp\job1\movie.d2v", pp=0).tdecimate()
Spline64Resize(720,352,0,62,-0,-66)


Tried it without SetMTMode(), same crash.

4.16 build (which I've been using for months), works fine.

[dannyboy48888]

I am using fluxsmooth (ssse3), TIVTC and DGindexNV all in 64 bit land with no issues. my times increased (or decreased....) as follows on a core2 duo 2Ghz p7350:

pass1 avs2avi null output
(704x384 mpeg2 source)
32 bit: 97fps
64 bit: 142fps

pass2, the actual x264 encode
(704x288 resize)
32 bit: 26fps
64 bit: 32fps

and that is all, no complaints. Just wanted to say THANK YOU!!

and of course the scripts....

pass1
LoadPlugin("C:\Users\ChuckD\Desktop\MeGUI_2028_x86\tools\dgindexnv\x64 Binaries\DGDecodeNV.dll")
LoadPlugin("C:\Users\ChuckD\Desktop\avi64\TIVTC.dll")
LoadPlugin("C:\Users\ChuckD\Desktop\avi64\FluxSmoothSSSE3.dll")
DGSource("C:\Users\ChuckD\Desktop\TODO\00000.dgi",fieldop=0)
crop( 4, 64, -4, -64)
TFM(mode=1, output="C:\Users\ChuckD\Desktop\TODO\tfm.txt")
FluxSmoothST(7,7) # Medium Noise
TDecimate(mode=4, output="C:\Users\ChuckD\Desktop\TODO\stats.txt")

pass 2
LoadPlugin("C:\Users\ChuckD\Desktop\MeGUI_2028_x86\tools\dgindexnv\x64 Binaries\DGDecodeNV.dll")
LoadPlugin("C:\Users\ChuckD\Desktop\avi64\TIVTC.dll")
LoadPlugin("C:\Users\ChuckD\Desktop\avi64\FluxSmoothSSSE3.dll")
DGSource("C:\Users\ChuckD\Desktop\TODO\00000.dgi",fieldop=0)
crop( 4, 64, -4, -64)
TFM(mode=1,input="C:\Users\ChuckD\Desktop\TODO\tfm.txt")
fluxSmoothST(7,7) # Medium Noise
TDecimate(mode=5, hybrid=2, dupthresh=1.0, input="C:\Users\ChuckD\Desktop\TODO\stats.txt", tfmin="C:\Users\ChuckD\Desktop\TODO\tfm.txt", mkvout="C:\Users\ChuckD\Desktop\TODO\timecodes.txt")
Spline64Resize(704,288) # Spline64 (Sharp)

[jpsdr]

The source code is publicly available at the google code site. I built it myself...

Interesting and nice thing, but, question : How do you download it ? Is there any other way than getting files one by one with the browser ???

[kemuri-_9]

Interesting and nice thing, but, question : How do you download it ? Is there any other way than getting files one by one with the browser ???

it's a svn repository so you can check it out.

[jpsdr]

Sorry, as i don't know about svn, i don't realy understand your answer.
If TheRyuu has been able to compile it, he has been able to download the whole files/project ?

[kemuri-_9]

Sorry, as i don't know about svn, i don't realy understand your answer.

I interpret that as "I'm too lazy to google it", so even though I'm supplying the link to the wikipedia article (http://en.wikipedia.org/wiki/Apache_Subversion), you probably still won't read it.

[TheRyuu]

Sorry, as i don't know about svn, i don't realy understand your answer.
If TheRyuu has been able to compile it, he has been able to download the whole files/project ?

If you don't understand svn, I'm not exactly sure what you have to offer that would make getting the source files worth while. If you're simply curious I'm sure you can figure out how to checkout a svn repository with the help of google. It even gives you some tips on the source->checkout page of googlecode.

[jpsdr]

Ok, finaly able to get the source got... Thanks.

[WILLIS]

Do the 64bit builds found @ this link http://code.google.com/p/avisynth64/ have a SetMTMode function?

[TheRyuu]

Do the 64bit builds found @ this link http://code.google.com/p/avisynth64/ have a SetMTMode function?

They should, everything should be pretty much the same as the 32bit version, except way more broken. And since we're talking about the 32bit MT version which is already broken, I'm surprised that this shit even works at all.

[aegisofrime]

They should, everything should be pretty much the same as the 32bit version, except way more broken. And since we're talking about the 32bit MT version which is already broken, I'm surprised that this shit even works at all.

You should be. From my experience with QTGMC'ing LOTS OF DVD videos on my i7-2600K, 64-bit is no less stable than 32-bit.

[mbcd]

Does MT work on your i7 ?

I have much problems with MT, its not usable here, avisynth always crashes (directly loaded into x264). Mostly I crashes at 80-90% of the movie, or sometimes at the beginning.

I tried 2.5.8 MT and 2.6.0 in 32 bit (is QTGMC 64bit ?).
Both with the patched plugins for better MT-stability

Now I tried converting without MT and It runs very stable, no crash since the beginning.

[MDCore]

I'm trying to setup a 64bit toolchain with AVISynth 64 and VirtualDub64. I have installed all the relevant programs and after reading through this thread I found testavsload. When I run testavsload64 with the 64bit DLL's (avisynth.dll and devil.dll) in place I get:
unable to load avisynth, error code = 126
If I put in the 32bit DLL's and run testavsload32 then it works.

I have installed the Microsoft C++2005 64bit redistributable. When I use Dependancy Walker on avisynth.dll it complains about MSVCR80.DLL. The 32bit dll doesn't complain about this.

Any ideas?

[TheFluff]

You should be. From my experience with QTGMC'ing LOTS OF DVD videos on my i7-2600K, 64-bit is no less stable than 32-bit.

This, kids, is a good example of the logical fallacy called "argument by anecdotal evidence".

[aegisofrime]

This, kids, is a good example of the logical fallacy called "argument by anecdotal evidence".

I posted that because I was curious as to under what circumstances 64-bit is unstable. I understand that my experience does not cover every single plugin so I cannot say with certainty that 64-bit is as stable as 32-bit. But then, I'm also wondering based on what evidence TheRyuu says that? Has he tested every single plugin? Or is his statement based on looking at the source code and finding out that it is very poorly coded? A short explanation as such is more helpful. :thanks:

[redfordxx]

Hi.
I am now trying working with MeGui64, AviSynth64, x264_64 and 64bit filters.
But I have two problems:many crashes and not many filters.
So I am going back to 32 and see if it is better.

I have question, whether I can have mixed chain...something like Avisynth32+x264_64...or so?
After some browsing I understand, that there is no way to put filter32 in avisynth64, right?

Tnx

[WILLIS]

Can't seem to get SetMTMode to work...it's unrecognized...any ideas?

[LeXXuz]

Anybody got a working sharpening filter for Avisynth64?

I need some working sharpening filter to slightly resharpen the image after noise removal.

I don't like the results from warpsharp or the default sharpening filter from Avisynth.

[Didée]

@LeXXuz: What, how, and why.

[LeXXuz]

I tried warpsharp and it looks okay on anime but removes too much texture detail on normal movies.

[Didée]

Now we've changed from "poking in the blue" to "poking in the green". A major improvement.

[levi]

lsfmod works

[zmaster]

Is there any way to make anti-aliasing?
p/s: «Anti-aliasing x64» of course :)

[tomcat_]

i have installed avisynth the way it was described on the first post however i have noticed that:

1. the time on the analysis it takes quite longer than the 32bit before (for the same movie)

2. After i press save on the avs script creater a video preview window opens while before it wasn't.

am i doing something obviously wrong or other users experienced the same?

[DarkDream]

Windows XP 64-Bit

This is my first 64 bit operating system and I cant get this to install.

It says I need Administrator privilages to install it. I am the damn administrator and the only account on the computer so thats fucked up.

I go to right click it and choose Run as Administrator and that doesnt even show up in windows, its not there to even click like it is on my other computer.

What should I do? i tried editing that out of the batch file where it checks for administrator privilages and it doesnt even work then.

[DarkDream]

NVM i edited the batch file again and got it to work this time without needing admin crap

[DarkDream]

Windows XP 64-Bit

I try to run MeGui in 64 bit mode enabled and thats the error I get when it starts to encode my video. avs4x264mod.exe

I have AVISynth 64-Bit installed

Why is MeGui giving me this error? how would I go about fixing this?

[XMEN3]

Sorry, would be possible medianblur x64 and removegrainHD ? thanks anyway

[Jou]

This is the first time in 14 years I need to post a question here, previously everything I needed to ask has already been answered somewhere else or I had to post in another forum...

Request: Multidecimate for Avisynth in x64 http://neuron2.net/multidecimate/multidecimate.html
I would only need the MultiDecimate.dll in x64, the rest of the filter does not really need to be x64. If possible without too much work: Make it accept RGB directly so ConvertToYUY2() is not needed.

Reason: I record some game videos in 3968x2480 with pseudo-60-fps in fraps. Generates huge amount of duplicate/identical frames in an irregular patten. Multidecimate is the most simple way to get rid of them.

BUT: I cannot encode that resolution with 32 bit virtualdub/avidemux/x264.exe or any other codec I tried. I HAVE to use x64 to just encode the video.
My ugly workaround was: Since the videos were rather short and I had enough space I could save the multidecumated video as uncompressed video, 2 Minutes 40 Seconds made a nearly 400 GB .avi.
But it would be SO much more elegant to have multidecimate for x64 avisynth to spare that workaround.
(Results at http://www.youtube.com/watch?v=-y335WQvGzY and http://www.youtube.com/watch?v=0FhUKndMrAY , including links to the original encodings which require an OC'ed i7 just to play...)

[thewebchat]

This is the first time in 14 years I need to post a question here, previously everything I needed to ask has already been answered somewhere else or I had to post in another forum...

Request: Multidecimate for Avisynth in x64 http://neuron2.net/multidecimate/multidecimate.html
I would only need the MultiDecimate.dll in x64, the rest of the filter does not really need to be x64. If possible without too much work: Make it accept RGB directly so ConvertToYUY2() is not needed.

Reason: I record some game videos in 3968x2480 with pseudo-60-fps in fraps. Generates huge amount of duplicate/identical frames in an irregular patten. Multidecimate is the most simple way to get rid of them.

BUT: I cannot encode that resolution with 32 bit virtualdub/avidemux/x264.exe or any other codec I tried. I HAVE to use x64 to just encode the video.
My ugly workaround was: Since the videos were rather short and I had enough space I could save the multidecumated video as uncompressed video, 2 Minutes 40 Seconds made a nearly 400 GB .avi.
But it would be SO much more elegant to have multidecimate for x64 avisynth to spare that workaround.
(Results at http://www.youtube.com/watch?v=-y335WQvGzY and http://www.youtube.com/watch?v=0FhUKndMrAY , including links to the original encodings which require an OC'ed i7 just to play...)


Multidecimate is a CLOSED SOURCE plugin so nobody but the author can help you.
There is no reason you can't use 32-bit Avisynth to do this. Please read about the standard input/output interface (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx) available in all Windows versions since DOS.
64-bit Avisynth is a DEAD project so there is no point in posting anything to this thread.

[Jou]

Multidecimate is a CLOSED SOURCE plugin so nobody but the author can help you.
There is no reason you can't use 32-bit Avisynth to do this. Please read about the standard input/output interface (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx) available in all Windows versions since DOS.
64-bit Avisynth is a DEAD project so there is no point in posting anything to this thread.


Closed source - damn.

I know redirection, I tried the "avs2yuv.exe input.avs - | x264-x64.exe --stdin y4m" way which I used until about ~two years ago. Since then the x264-vfw codec and avidemux x264 implementations were good enough to get rid of that workaround. But it didn't work here. Recent versions of x264 threw me an error, older versions work, but I didn't invest much time since the uncompressed workaround was the lazier way.

[GrofLuigi]

Hi,

Any solution for the green frames yet?

My script consist only of MPEG2Source ("x.d2v"). Is the plugin buggy?

I will try to learn FFMpegSource, but currently I need DGDecode. Is there another version maybe?

And by the way, this (http://forum.doom9.org/showthread.php?p=1499263#post1499263) is vital. It should be put into the installer. DirectShow (read: MPC-HC) doesn't work without it. I banged my head against the wall until I remembered to :search: :).

* Edit: this is all on x64, of course.

* Edit2: both 4/16/2010 and 3/19/2010 releases.

GL

[cweb]

Why don't you use DGINDEX instead? It's more up-to-date.
Hi,

Any solution for the green frames yet?

My script consist only of MPEG2Source ("x.d2v"). Is the plugin buggy?

I will try to learn FFMpegSource, but currently I need DGDecode. Is there another version maybe?

And by the way, this (http://forum.doom9.org/showthread.php?p=1499263#post1499263) is vital. It should be put into the installer. DirectShow (read: MPC-HC) doesn't work without it. I banged my head against the wall until I remembered to :search: :).

* Edit: this is all on x64, of course.

* Edit2: both 4/16/2010 and 3/19/2010 releases.

GL

[GrofLuigi]

Why don't you use DGINDEX instead? It's more up-to-date.

I am using DGINDEX. If you mean DGINDEXNV, I don't have NVidia card.

GL

[StainlessS]

@Jou, Find below source comparable to Multidecimate, not sure, I think Neuron2 said that he would release
source when it was more mature, but then wrote FDecimate and never did release the source.
Below was modified from FDecimate and so far as I remember works pretty good, but I have not used it for some time.
You still need to use the exe file that comes with Multidecimate. I always use this mod rather than Multidecimate
when there is need.

Link is temporary and will be deleted at some time.

EDIT: DELETED

EDIT: Named MDec2

MDEC2(clip c,float rate(Default=24.0),bool show(default=false),bool create (default=false),string dir(default="C:\"))


Args are different to Multidecimate, and after having a quick look at the source, it must use YV12 on first pass
(create=true in MDEC2) but can use YUY2 on second pass (create=false).

EDIT: Added GPL & FDecimate source to zip and re-upped.

EDIT: Updated to All Planar, YUY2 and RGB. see post below.

[StainlessS]

Warning, the link to MDEC2 source in post prior to this one, will be deleted at the weekend coming.
This is your last chance to get a copy if you want it. (You could always PM me for a copy in future).

EDIT: DELETED

EDIT: See new thread on MDec2 here:
http://forum.doom9.org/showthread.php?p=1639822#post1639822

[djonline]

Why Avisynth x64 doesn't have any news ?
I think in 2013 we all must use only x64 software, there is 5%-25% on the same cpu for free! Why anybody use old slow x32 avisynth ?

Gunnar Thalin make famous Deshaker x64, I benchmark it, +26% in first pass, +4% on second pass in vdub64. But there is an error in avisynth x64 and LoadVirtualDubPlugin, I have exception on second pass under Windows 7, author Gunnar have exception under first pass on Windows 8.

Look at these images from a debug session in Visual Studio.
http://forum.doom9.org/attachment.php?attachmentid=13212&d=1357239279
http://forum.doom9.org/attachment.php?attachmentid=13213&d=1357239286
The first (or left) one is how the data of a source video frame looks from VirtualDub64, and the next one is from AviSynth64. The values for pitch, modulo and size look completely wrong, maybe not initialized at all.

[paradoxical]

Why anybody use old slow x32 avisynth ?

Because people still run 32-bit OSes. Maybe not all of the 32-bit Avisynth plugins that a person uses may have been ported to 64-bit. Also, for people using Wine to use Avisynth they are only able to use the 32-bit version. There are a variety of reasons for why people still run 32-bit Avisynth.

[djonline]

Because people still run 32-bit OSes. Maybe not all of the 32-bit Avisynth plugins that a person uses may have been ported to 64-bit. Also, for people using Wine to use Avisynth they are only able to use the 32-bit version. There are a variety of reasons for why people still run 32-bit Avisynth.

But x64 must be mainstream, like Adobe does. Everyone like free gain +20%. All mainstream plugins have x64 version, even mvtools, QTGMC, Deshaker.
May be somebody can fix this stupid bug in LoadVirtualDubPlugin ? I see source code of avisynth x64 on google code.

[sscheidegger]

I programmed a filter that uses SetCacheHints(0, 0); because I need to ensure that the source frame is not cached. It works in Avisynth 2.5.8. However, I don't get it to work in Avisynth x64 MT. The filter uses cached frames anyway!

Is this problem known? Does someone know a solution?

[real.finder]

Avisynth 2.6 MT currently is a bit faster than 2.5.8 x64 MT for my tests. Using Y8, YV16 and other 2.6 features has some benefits in speed and usability.

mvtools are buggy on most non-default modes (Yes, they are required), nnedi is 5x slower, there is no Dither, FFdshowSource his very buggy some time ago (not use now currently, so don't know). These plugins are absolutely required now for my tasks and there are no replacements. So I just have deleted x64 version.

you can use 32 with 64 in one script

here an example http://forum.doom9.org/showthread.php?p=1607063#post1607063

[sutha25]

can some one please share the Avisynth.DLL MT 2.5.8 i searched Google and couldn't find 1....Mediafire Link file removed

[jihyo]

Can someone get AviSynth64 working with Potplayer 64 bit?

Potplayer settings:
http://s13.postimg.org/7jq9ops8z/Screenshot_1.jpg (http://postimg.org/image/7jq9ops8z/)

SetMTMode(6,#CPUS * 2)
potplayer_source()
SetMTMode(2)
LoadPlugin("#PROGRAMDIR\AviSynth\plugins\InterFrame-2.8.2\Dependencies\svpflow1.dll")
LoadPlugin("#PROGRAMDIR\AviSynth\plugins\InterFrame-2.8.2\Dependencies\svpflow2.dll")
Import("#PROGRAMDIR\AviSynth\plugins\InterFrame-2.8.2\InterFrame2.avsi")
InterFrame(Preset="Medium", Tuning="Animation", GPU=false, Cores=#CPUS)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

Potplayer 32 & 64 - http://potplayer.daum.net/
SVPflow 1.1.17 dll 32 & 64 - http://www.svp-team.com/files/gpl/svpflow-1.1.17.zip (https://www.svp-team.com/wiki/Download#libs)
InterFrame - http://www.spirton.com/interframe/

Original instruction for 32bit Potplayer/AviSynth - http://www.parkoz.com/zboard/view.php?id=my_tips&no=15368

[StainlessS]

Not sure if you will have any joy with your request, Potplayer is not in favor on this forum, due to infringement of GPL.
I myself use and like said player (on occasion) but you may see this thread closed because of this request.
Merry Xmas, just the same :).

EDIT: Maybe not thread closed, possible post deleted.

[jihyo]

Ok, understood. Now it's my last mention about that player on this forum:
It's the best modern player nowadays. No one can beat it.

[Marsu42]

Ok, understood. Now it's my last mention about that player on this forum

Is there an official ban (yet)? I for one cannot find it in the forum rules.

It's the best modern player nowadays. No one can beat it.

It's indeed very hard to miss, and I'm wondering too about how to get the avisynth scripts working. Since they didn't throw out this option in the 64bit builds, I guess there should be some way...

[jmartinr]

For 64bit you should try avisynth+. That's what I use in ffdshow64.

[Marsu42]

For 64bit you should try avysinth+. That's what I use in ffdshow64.

Thanks, I was already wondering why the official avisynth seems to be stalled since 2010 ... though since the latest Plus build is nearly 2y old it might be time for an avisynth++ :-p

[Groucho2004]

Thanks, I was already wondering why the official avisynth seems to be stalled since 2010
Not true, Avisynth 2.6 was released on May 31st, 2015 (http://forum.doom9.org/showthread.php?t=172213).

[Marsu42]

Not true, Avisynth 2.6 was released on May 31st, 2015 (http://forum.doom9.org/showthread.php?t=172213).

Right, I was looking at the x64 version though (since the problem above was w/ PodPlayer x64). In any case, it's good to the open source video processing doesn't get abandoned or sold out to major enterprises like Cyberlink.

[jihyo]

But who can get AVS+ working at least with Potplayer 32 bit?

\DAUM\PotPlayer\AviSynth\ColorBars.avs - the script works in PP with AVS+
\DAUM\PotPlayer\AviSynth\OverlayText.avs - doesn't work

[Marsu42]

But who can get AVS+ working at least with Potplayer 32 bit?

\DAUM\PotPlayer\AviSynth\ColorBars.avs - the script works in PP with AVS+
\DAUM\PotPlayer\AviSynth\OverlayText.avs - doesn't work

It's the same for me w/ 64bit - at least colorbars work, which proves that the potplayer avs interface isn't the problem, *if* you use yv12 and have the same input/output size.

I'd suggest you try the other scripts outside potplayer first, i.e. load any video with directshowsource() into virtualdub. With this old-school working setup, you can find out if your're for example missing some plugins.

[jihyo]

DirectShowSource("D:\video\1.avi")
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\InterFrame\Dependencies\svpflow1.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\InterFrame\Dependencies\svpflow2.dll")
Import("C:\Program Files (x86)\AviSynth\plugins\InterFrame\InterFrame2.avsi")
InterFrame(Preset="Medium", Tuning="Film", GPU=false, Cores=4)

avs script works in VirtualDub 32 when using AviSynth+:

http://s10.postimg.org/9g2bfel5x/Screenshot_1.jpg (http://postimg.org/image/9g2bfel5x/)
(29.97 > 60)

But it doesn't work for Potplayer 32 with AviSynth+, so it only works with AviSynth 2.6:
potplayer_source()
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\InterFrame\Dependencies\svpflow1.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\InterFrame\Dependencies\svpflow2.dll")
Import("C:\Program Files (x86)\AviSynth\plugins\InterFrame\InterFrame2.avsi")
InterFrame(Preset="Medium", Tuning="Film", GPU=false, Cores=4)

Also when using AVS+ it doesn't show any messages in the player if your avs script has errors

But good thing that InterFrame & svpflow*.dll also works in VirtualDub 64 (must replace .dll 32 to 64 in "...\AviSynth\plugins\InterFrame\Dependencies\" from http://www.svp-team.com/files/gpl/svpflow-1.1.17.zip)
So we can get 60 fps in 64 bit programs

* Note: sometimes you must use ConvertToYV12 in the script:
DirectShowSource("D:\video\1.avi")
ConvertToYV12
...
for one my video I had to use ConvertToYV12 only in VirtualDub 64 while in VirtualDub 32 the script opens normally without it

[jihyo]

But it doesn't work for Potplayer 32 with AviSynth+


http://avisynth.nl/index.php/AviSynth+#Downloads

NOTE:

1) It doesn't works with AviSynth+ r1825 (March 23, 2015) but works with AviSynth+ r1779 (March 17, 2015)

So yeah I got 60 fps in Potplayer 64 bit

2) We have to use AviSynth with MT enabled otherwise it would be useless (low perfomance)

For "AviSynth 2.58/2.6 MT" MT is already enabled in Potplayer's original scripts

but "AviSynth+" has different functions for MT: http://avisynth.nl/index.php/AviSynth+#MT_Notes

[real.finder]

I build GetSystemEnv for avs 64

no source change, just make c++ 6.0 project workspace by Microsoft Visual Studio 6.0 in winxp then open it in Visual c++ 2008 in win7 and update and convert project to c++ 2008, and last, open c++ 2008 project file in vs2012 and update the project and build it in x64 with avs 2.5 x64 header

http://rgho.st/6F54dcFcd

edit: I build LoadDll too now
http://rgho.st/89sqKfBpg

[ultim]

But it doesn't work for Potplayer 32 with AviSynth+

Can somebody verify this with a recent Avs+ (preferably r2085)?
If this problem still persists, I'm willing to look at it and provide a fix.

[real.finder]

another x64 filter ;)

made it for my mod of MotionRamp (http://forum.doom9.org/showpost.php?p=1750019&postcount=77)

[VoodooFX]

another x64 filter ;)

made it for my mod of MotionRamp (http://forum.doom9.org/showpost.php?p=1750019&postcount=77)

Can you share 32bit version of this plugin?

[kedautinh12]

Can you share 32bit version of this plugin?

If you use avs is 2.6 or up, you can use Average to replacw

[real.finder]

Can you share 32bit version of this plugin?

you can find it here https://web.archive.org/web/20201020085042/https://sites.google.com/site/ourenthusiasmsasham/soft