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

[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]

Originally Posted by Adub

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/2...adfun2db32.png
64-bit version: http://img691.imageshack.us/img691/1...adfun2db64.png
unprocessed: http://img411.imageshack.us/img411/7...fun2dborig.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
- 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 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:


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.