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

[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