SEt's Avisynth 2.5.8 MT compiled for *X86_64*, Latest Build 4/16/2010 [Archive] - Page 13

asarian

27th September 2010, 11:31

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

27th September 2010, 11:50

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

27th September 2010, 12:02

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

27th September 2010, 12:25

€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

27th September 2010, 12:39

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

27th September 2010, 13:18

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

27th September 2010, 13:41

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

28th September 2010, 03:14

I've updated the zip package for ffms2-x64 on my website.

levi

28th September 2010, 04:33

I've updated the zip package for ffms2-x64 on my website.

Thanks Kemuri!

asarian

28th September 2010, 07:27

I've updated the zip package for ffms2-x64 on my website.

Much appreciated!

Hagbard23

28th September 2010, 08:46

yeah - really good work, thanks Kemuri...

Chumbo

28th September 2010, 19:57

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

29th September 2010, 13:03

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

1st October 2010, 18:13

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

2nd October 2010, 04:22

Which version of AviSynth_MT do you use? Resizing works great in the version of 4/16/2010.

Lyle_JP

2nd October 2010, 05:59

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

2nd October 2010, 07:05

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

2nd October 2010, 07:52

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

2nd October 2010, 09:54

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

2nd October 2010, 10:51

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

2nd October 2010, 20:27

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

3rd October 2010, 12:31

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

3rd October 2010, 14:19

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

3rd October 2010, 16:11

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

3rd October 2010, 16:20

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

5th October 2010, 12:59

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

5th October 2010, 22:33

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

7th October 2010, 16:37

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

15th October 2010, 17:20

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

16th October 2010, 02:36

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

16th October 2010, 08:51

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

16th October 2010, 14:58

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

18th October 2010, 07:06

Do not use the august build. That gave me green frames too.

cweb

18th October 2010, 07:47

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

19th October 2010, 00:30

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

19th October 2010, 01:20

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

22nd October 2010, 19:05

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

23rd October 2010, 02:50

What is your script? What is your encoding?

bayex

23rd October 2010, 18:15

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

23rd October 2010, 21:31

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

24th October 2010, 05:28

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

24th October 2010, 13:15

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).