Avisynth+

[real.finder]

hi :)

I got

http://i.imgur.com/qJ2gvlZ.png

with "Dither_convert_yuv_to_rgb"

and thank you for this project :)

[zero9999]

hi :)

I got (some masktools error) with "Dither_convert_yuv_to_rgb"

and thank you for this project :)
you're using a masktools version built with avisynth 2.5 header. use this (http://tmod.nmm-hd.org/Misc/mt_masktools-26-for-2.6alpha4.7z)version instead.

[turbojet]

Some first observations:

1. Installer doesn't play nice with avisynth, assigns new plugin directory and doesn't restore old after uninstall
2. Installer installs VC++ redist even though they were already up to date
3. Installer migration option deletes avisynth plugins, luckily they were backed up.
4. Installer isn't extractable, if extractable it's a simple copy/paste of avisynth.dll Wasn't this supposed to be extractable like avisynth installers?
5. Getting all sorts of dll missing with avisynth+, avsrecursion.dll and opencl.dll mostly which are in avisynth+ and avisynth plugin directories.
6. Some speed tests: With a 1080i mpeg2 source with dss2x86/dssx64(lav avcodec decoding).tfm().tdecimate().lanczosresize()

2.6a5icl
720x404 = 37.96 fps (50-60% cpu)
1280x720 = 25.74 (100%)

avs+:
720x404 = 36.98(50-60%)
1280x720 = 24.74(100%)

avs64 (JoshyD)
720x404 = 25.02(30-40%)
1280x720 = 21.80(70-80%)

avs+64
720x404 = 22.84(30-40%)
1280x720 = 19.17(70-80%)

I've been battling with fixing avisynth plugins directory for almost an hour now and still haven't solved it. Guess a rollback is necessary. EDIT: IOBit uninstall of avs+ then clean install of avisynth fixed the plugins directory. Seems the uninstaller doesn't clean up very well.

[zero9999]

Some first observations:

1. Installer doesn't play nice with avisynth, assigns new plugin directory and doesn't restore old after uninstall
3. Installer migration option deletes avisynth plugins, luckily they were backed up.


Which upgrade option did you pick? The second one (migration) is designed to do exactly what you described in [1]. It also does [3], but only after copying all your plugins to the new plugin directory for 2.5 plugins.

Some first observations:
2. Installer installs VC++ redist even though they were already up to date

The VC++ Redist installers automatically determine whether or not they need to install/update the runtimes and just do nothing if everything is up-to-date. Are you sure you were already running Update 4?

4. Installer isn't extractable, if extractable it's a simple copy/paste of avisynth.dll Wasn't this supposed to be extractable like avisynth installers?

You can extract it with InnoExtract.


5. Getting all sorts of dll missing with avisynth+, avsrecursion.dll and opencl.dll mostly which are in avisynth+ and avisynth plugin directories.

not sure about this, please be more precise. Avs+ doesn't touch those libs (which should reside in your SysWoW64 folder on 64-bit windows)


6. Some speed tests: With a 1080i mpeg2 source with dss2x86/dssx64(lav avcodec decoding).tfm().tdecimate().lanczosresize()

is this the full script? What tool did you use to get those numbers and where did you get it from?

[turbojet]

Which upgrade option did you pick? The second one (migration) is designed to do exactly what you described in [1]. It also does [3], but only after copying all your plugins to the new plugin directory for 2.5 plugins.
At first the top option, then uninstalled and installed avisynth and plugins weren't loading. Then tried bottom option, avisynth\plugins and plugins64 were moved to empty avs+\plugins plugins64 dir thus deleted. IOBit uninstalled, installed avisynth again and plugin autoloading was working again.



The VC++ Redist installers automatically determine whether or not they need to install/update the runtimes and just do nothing if everything is up-to-date. Are you sure you were already running Update 4?
I don't think it was actually, they dated back to September I believe. Even so it's says installing on reinstall for about 5 seconds, although it might just be a bad message.


You can extract it with InnoExtract.
All I can get out of it is avisynth.dll and devil.dll not sure if it's x86 or x64. Avisynth installers are fully extractable with 7zip. If installer isn't extractable could a zip with the dll's also available?


not sure about this, please be more precise. Avs+ doesn't touch those libs (which should reside in your SysWoW64 folder on 64-bit windows)
These libs were in avisynth+\plugins directory and it was throwing errors with them, works fine with avisynth.


is this the full script?
Yes. The x64 speed decrease is I believe a decoder issue. That's fed through x264 same options.

[real.finder]

you're using a masktools version built with avisynth 2.5 header. use this (http://tmod.nmm-hd.org/Misc/mt_masktools-26-for-2.6alpha4.7z)version instead.

That's weird, I use this version but load it manually, 2.5 version of masktool in autoload folder

it supposed that manual load eliminates the auto one like the normal avs did, not vice versa

[zero9999]

At first the top option, then uninstalled and installed avisynth and plugins weren't loading. Then tried bottom option, avisynth\plugins and plugins64 were moved to empty avs+\plugins plugins64 dir thus deleted. IOBit uninstalled, installed avisynth again and plugin autoloading was working again.

So after you tried the first option (backup) and then uninstalled Avs+, did the uninstaller not restore your previous AviSynth installation, or why did you reinstall AviSynth again after that?
Did you try to install AviSynth+ into your previous AviSynth folder?

As far as IOBit software goes, you'd have to check with them because i don't know anything about what it does.

Since you seem to have restored your previous state, it's kinda hard to investigate the issues but could you please check the following registry keys and post the contents:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AviSynth
HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{AC78780F-BACA-4805-8D4F-AE1B52B7E7D3}_is1


I don't think it was actually, they dated back to September I believe. Even so it's says installing on reinstall for about 5 seconds, although it might just be a bad message.

This is normal. The vcredist installers are always run to let them decide for themselves whether they need to install anything or not


All I can get out of it is avisynth.dll and devil.dll not sure if it's x86 or x64. Avisynth installers are fully extractable with 7zip. If installer isn't extractable could a zip with the dll's also available?

<line0> zip build with just the DLLs would be nice too
<&ultim> will do


These libs were in avisynth+\plugins directory and it was throwing errors with them, works fine with avisynth.

Those libraries are not AviSynth plugins so they shouldn't go into the plugin directories in the first place.
Actually this is interesting. You said the Avs+ installer was not copying the contents of the old plugin folders to the new locations, but apparently it did so at least for 32 bit stuff.
am i right to assume that only the migration of the 64-bit plugins failed?


Yes. The x64 speed decrease is I believe a decoder issue. That's fed through x264 same options.
don't use x264 to benchmark scripts. Use AvsMeter insteadl

That's weird, I use this version but load it manually, 2.5 version of masktool in autoload folder

it supposed that manual load eliminates the auto one like the normal avs did, not vice versa
yes, and that's exactly the way it works here.

[TurboPascal7]

real.finder
I just tried your way and it works as expected.

[real.finder]

real.finder
I just tried your way and it works as expected.

If I back to normal avs I have no problem with the same script, I'll do more tests to see what causes this

[TurboPascal7]

If I back to normal avs I have no problem with the same script, I'll do more test to see what causes this
Please paste the exact script you have issues with.

[real.finder]

Please paste the exact script you have issues with.

DGDecode_MPEG2Source("C:\Documents and Settings\a\Desktop\New Folder\One Piece 517__cut.demuxed.d2v")
LoadPlugin("C:\Documents and Settings\a\Desktop\mt_masktools-26.dll")
Dither_convert_yuv_to_rgb

in winxp sp3 on VirtualBox v4.3.2.90405

[TurboPascal7]

Ok, the issue is related to the placement of the LoadPlugin line. It will work correctly if you place it before the MPEG2Source call.
Yet this is a bug, will investigate. Thanks for the report.

[real.finder]

Ok, the issue is related to the placement of the LoadPlugin line. It will work correctly if you place it before the MPEG2Source call.
Yet this is a bug, will investigate. Thanks for the report.

LoadPlugin("C:\Documents and Settings\a\Desktop\mt_masktools-26.dll")
DGDecode_MPEG2Source("C:\Documents and Settings\a\Desktop\New Folder\One Piece 517__cut.demuxed.d2v")
Dither_convert_yuv_to_rgb

yes, that work :)

[Lenchik]

Those libraries are not AviSynth plugins so they shouldn't go into the plugin directories in the first place.
AFAIK, starting with some 2.6 build Avisynth is searching for additional libraries in plugins folder before system folder.

[the_weirdo]

AFAIK, starting with some 2.6 build Avisynth is searching for additional libraries in plugins folder before system folder.

IIRC, this is only applied to SEt's Avisynth 2.6 MT builds. I don't know if those changes have been merged to upstream yet, though.

[qyot27]

One thing I saw regarding the ISS installer was that it failed to install on an Athlon64 machine I have access to that runs 32-bit XP, complaining that it can't install x64 versions and then quits (why is it trying to install 64-bit on a 32-bit OS?).

Another, more minor thing is that under 64-bit Wine, it installed the 64-bit plugin directories under Program Files (x86) and didn't put anything in Program Files. This might be a Wine vs. real Windows issue, though (especially since it ended up hanging on the vcredist step).

[turbojet]

So after you tried the first option (backup) and then uninstalled Avs+, did the uninstaller not restore your previous AviSynth installation, or why did you reinstall AviSynth again after that?
Did you try to install AviSynth+ into your previous AviSynth folder?

Correct, tried to install avisynth to get the plugin autoloading working again but failed. Never tried installing avs+ into avs install directory.

As far as IOBit software goes, you'd have to check with them because i don't know anything about what it does.

It's like Revo uninstaller, but completely free, it cleans up after uninstaller that don't clean up well.

Since you seem to have restored your previous state, it's kinda hard to investigate the issues but could you please check the following registry keys and post the contents:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AviSynth
HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{AC78780F-BACA-4805-8D4F-AE1B52B7E7D3}_is1

After installing avs+ with second option, uninstalling, installing avisynth there was some reg entries and the plugin directory was set to the correct path in either hklm\software\avisynth or hklm\software\wow6432node\avisynth but not both like they are set currently in the working state, but it wasn't autoloading. I'm not sure about the uninstall key, it's currently not there in it's current working state. I'll try to break autoloading again in a vm tomorrow if I find time and it's necessary.

This is normal. The vcredist installers are always run to let them decide for themselves whether they need to install anything or not

Would it make sense, if possible, to hide the 'installing vcredist' message in the installer?

<line0> zip build with just the DLLs would be nice too
<&ultim> will do

Thanks


Those libraries are not AviSynth plugins so they shouldn't go into the plugin directories in the first place.
Actually this is interesting. You said the Avs+ installer was not copying the contents of the old plugin folders to the new locations, but apparently it did so at least for 32 bit stuff.
am i right to assume that only the migration of the 64-bit plugins failed?

I'm not sure where avsrecursion came from but I don't use the filters that requires it, at least not often. nnedi3ocl.cl is required for nnedi3ocl() to function. Replacing avisynth.dll with avisynth+'s does not throw the errors. Autoloading other dll's from avisynth plugins makes a lot of sense and makes life easier. A lot of programs load dll's from their directory.

Originally had F:\tools\avisynth\plugins and F:\tools\avisynth\plugins64, when installing avisynth+ with the top install option to F:\tools\avisynth+ it created empty directories of F:\tools\avisynth+\plugins and F:\tools\avisynth+\plugins32 and deleted F:\tools\avisynth\plugins and F:\tools\avisynth\plugins64, the rest of F:\tools\avisynth\ was untouched. The only thing in avisynth+'s default plugins directory were ones in the installer.

don't use x264 to benchmark scripts. Use AvsMeter insteadl

While good for finding bottlenecks, it's not nearly as accurate of a real world test as an encode but here they are (x86 only):

ICL: 720x404 40.46fps (25% cpu) 1280x720 39.97(27%)
AVS+: 720x404 38.75(28%) 1280x720 38.26(29%)

My whole script for x86: dss2().tfm().sorathread().tdecimate().sorathread().lanczosresize()
x64: dss().tfm().tdecimate().lanczosresize()

[ultim]

Looks like there's a confirmed bug in the installer, and as per turbojet's report the DLL search path handling in the plugin loader looks to be inconsistent with classic avs. This wasn't changed though since the very first release of avs+, so that's what you get for not testing early enough :) Furthermore, tp7 confirmed some filter bug in the intrinsics port. Expect a bugfix release tonight (CET).


Would it make sense, if possible, to hide the 'installing vcredist' message in the installer?
It wouldn't. That's what it's doing, so why lie about it? As already said by others, vcredist won't do anything if it is already installed. The 2012 runtime alone has multiple versions though, and the one used by avs+ is the latest that is pretty new. So you probably don't have it already.

[zero9999]

One thing I saw regarding the ISS installer was that it failed to install on an Athlon64 machine I have access to that runs 32-bit XP, complaining that it can't install x64 versions and then quits (why is it trying to install 64-bit on a 32-bit OS?).

yup, already fixed that one. it was actually trying to back up x64 AviSynth files. This (https://files.line0.in/builds/AviSynth%2B-2013-11-24.exe) installer should work


Another, more minor thing is that under 64-bit Wine, it installed the 64-bit plugin directories under Program Files (x86) and didn't put anything in Program Files. This might be a Wine vs. real Windows issue, though (especially since it ended up hanging on the vcredist step).
The installer doesn't create two program directories, even if both x86 and x64 AviSynth are to be installed. Everything goes into the Folder you pick on the 'Select application directory' screen (which defaults to a location in Program Files (x86).

Do you think it would be better to install x64 AviSynth+ to Program Files and x86 AviSynth+ to Program Files (x86)?
IMO it only serves to confuse the users (Where are my plugin directories?) and we'd have to ask for a second Install folder. On top of that it's complicated to pull off because in InnoSetup the components selection screen comes after the select directory screen, so we'd have to do something custom instead.

[real.finder]

Some first observations:
2. Installer installs VC++ redist even though they were already up to date


same thing happened to me, and confirmed it via System Restore

And I saw that c++ 2012 installed many times



<line0> zip build with just the DLLs would be nice too
<&ultim> will do



that very nice :) especially with the new feature in mp_pipeline

[zero9999]

Correct, tried to install avisynth to get the plugin autoloading working again but failed. Never tried installing avs+ into avs install directory.

After installing avs+ with second option, uninstalling, installing avisynth there was some reg entries and the plugin directory was set to the correct path in either hklm\software\avisynth or hklm\software\wow6432node\avisynth but not both like they are set currently in the working state, but it wasn't autoloading. I'm not sure about the uninstall key, it's currently not there in it's current working state. I'll try to break autoloading again in a vm tomorrow if I find time and it's necessary.


just a heads up: i've been able to reproduce and fix the plugin folders issue. please do not try again until ultim posts a new build (which will also include a fix for the autoload issue).

[qyot27]

The installer doesn't create two program directories, even if both x86 and x64 AviSynth are to be installed. Everything goes into the Folder you pick on the 'Select application directory' screen (which defaults to a location in Program Files (x86).

Do you think it would be better to install x64 AviSynth+ to Program Files and x86 AviSynth+ to Program Files (x86)?
IMO it only serves to confuse the users (Where are my plugin directories?) and we'd have to ask for a second Install folder. On top of that it's complicated to pull off because in InnoSetup the components selection screen comes after the select directory screen, so we'd have to do something custom instead.
I think it's potentially confusing to have to put 64-bit plugins under Program Files (x86), even if the folder does say plugins64. If the user knows the 64-bit version of AviSynth+ is getting installed, they'd expect it to be in Program Files and the 32-bit to be in Program Files (x86). At least if they're knowledgeable enough to know that on Win64, 'Program Files' is for 64-bit and 'Program Files (x86)' is for 32-bit.

If InnoSetup can take advantage of it, using an NTFS junction to link the installation directories together might be a solution. That way, there still is only one installation folder, but it's visible in two places that agree with the convention of installing x64 to one place and x86 to another.

[jpsdr]

First, thanks for this project and all of your work.
Just out of curiosity : On some resample filters (i think the spline36 at least), the avisynth64 version took advantage of extra registers avaibles in x64 mode to greatly increase the speed (around 30% if i remember properly). Have you been able to keep this kind of improvement ?

Edit : Just seeing the previous post, and it may have no effect, but remember that Windows XP can be installed on FAT32, so installation partition may not be in NTFS... So, make sure the installer don't take for granted that partition is NTFS (unless you drop XP support).

[TurboPascal7]

Just out of curiosity : On some resample filters (i think the spline36 at least), the avisynth64 version took advantage of extra registers avaibles in x64 mode to greatly increase the speed (around 30% if i remember properly). Have you been able to keep this kind of improvement ?

The code generated for SSSE3, which is the fastest vertical resizer implementation, does not use any additional registers and I don't see where it could benefit from those. SSE2 version does but it's probably still slower than SSSE3.

I have no idea how the final performance compares to avs64, I never checked.

[qyot27]

yup, already fixed that one. it was actually trying to back up x64 AviSynth files. This (https://files.line0.in/builds/AviSynth%2B-2013-11-24.exe) installer should work
It does work. Although, is it from installing AviSynth.dll and DevIL.dll that it requires a restart every time, or from the vcredist?

Edit : Just seeing the previous post, and it may have no effect, but remember that Windows XP can be installed on FAT32, so installation partition may not be in NTFS... So, make sure the installer don't take for granted that partition is NTFS (unless you drop XP support).
Junctioning would only happen on x64 (since x86 doesn't need to bother with it), and this then factors down to:

Probability: The percentage of users that would actually be using Windows XP Professional x64 is ridiculously small amongst the XP userbase because it wasn't widely available to consumers except as an OEM/direct purchase from Microsoft. I don't know if the x64 version will let you install to FAT32, but even if it can, the percentage of users that would do this is even smaller. So a tiny fraction of a tiny fraction of XP users would be affected by the lack of support for junctioning.

At first, I thought that the service pack situation would exclude it since XP Pro x64 never got a Service Pack 3, but it turns out it identifies itself as 5.2, same as Server 2003 (which it was based on).

Regardless, this won't stop anything if junctioning isn't supported on the filesystem; you just have the current situation of everything being in one Program Files location or the other. That is, if you even tell it to install to Program Files at all.

[ultim]

Hello folks, here is the bugfix we promised to you. Issues with the installer are hopefully fixed, and the plugin loader got two patches too for things that have been reported. This (http://forum.doom9.org/showthread.php?p=1655169#post1655169) had to stay off the fix-list though, I didn't even get to look at it due time (but I have a pretty good guess what is going on). I will reach in a fix for that another day, shortly. Until then, enjoy line0's updated installer look and icons.

EDIT: oh I almost forgot, there's a zip-release too.

[ryrynz]

Will we see mulithreading this year?

[TurboPascal7]

Will we see mulithreading this year?
Likely.

[turbojet]

Does the new installer need to be tested for plugin issues I reported?

Also is there some reason why avisynth+ is 5-10% slower with higher cpu usage then avisynth on an fx8320?

[TurboPascal7]

Also is there some reason why avisynth+ is 5-10% slower with higher cpu usage then avisynth on an fx8320?

No one ever tested it on an AMD CPU. What filters? Exact testing scripts if possible.

Also what version of avs you're comparing with (ICL build, 2.5.8., 2.6a5?) and how are you measuring performance?

[turbojet]

http://forum.doom9.org/showthread.php?p=1655141#post1655141
http://forum.doom9.org/showthread.php?p=1655193#post1655193
are the benchmarks, what sort of speed increases are there on intel cpus?

[TurboPascal7]

what sort of speed increases are there on intel cpus?
I don't get any performance difference between the ICL build and avs+ with your script on Nehalem.

Could you please benchmark the resizer call alone on blankclip?

[turbojet]

blankclip(1000,1920,1080).lanczosresize()
ICL: 720x404: 47.99(12%) 1280x720: 39.95 (12%)
AVS+: 720x404 45.67(12%) 1280x720: 32.56 (12%)

[Groucho2004]

blankclip(1000,1920,1080).lanczosresize()
ICL: 720x404: 47.99(12%) 1280x720: 39.95 (12%)
AVS+: 720x404 45.67(12%) 1280x720: 32.56 (12%)

With the same script, on a i5 2500K@4GHz I get this:
blankclip(1000,1920,1080).lanczosresize()
ICL: 720x404: 51.51(25%) 1280x720: 46.80 (25%)
AVS+: 720x404: 74.31(25%) 1280x720: 60.77 (25%)

How about for speed testing we use something more elaborate like this:
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(24000, 1001)

trim(0,499)
fadeio(248)
trim(0,499)

spline36resize(width() - 64, height() - 64).turnleft()
spline64resize(width() + 64, height() + 64).turnright()
bicubicresize(width() - 64, height() - 64).fliphorizontal()
sincresize(width() + 64, height() + 64).flipvertical()

a = tweak(hue=33)
u_chroma = blankclip(utoy(a), color=$808080)
ytouv(u_chroma, a.vtoy)
mergeluma(a)
tweak(hue=-33)

temporalsoften(4,4,8,15,2)
limiter(16, 235, 16, 240)
levels(0, 1, 255, 16, 235)
scriptclip("subtitle(string(ydifferencefromprevious))")
a=selectevery(3, 0).addborders(0,0, 16,0).crop(0,0, -16,0)
b=selectevery(3, 1).addborders(0,0, 32,0).crop(0,0, -32,0)
c=selectevery(3, 2).addborders(0,0, 64,0).crop(0,0, -64,0)
interleave(a, b, c)

I think it has most internal functions, suggestions for improvement are of course welcome. Possibly the GScript component should be added?

[andybkma]

Hello, downloaded newest 2013. nov. 25 binaries, replaced the orig avisynth.dll file (Avisynth 2.6.0 Alpha 5) with the x86 version (and tried the x64 version as well), now when I try to play a video with Zoom Player (with LSFMod as post processing) I get error "Access Violation at 00000000, Read of address 00000000". Putting back the orig avisynth.dll file all is fine again. Note: Previous Avisynth+ version from Sept (?) didn't have this problem...

[TurboPascal7]

Hello, downloaded newest 2013. nov. 25 binaries, replaced the orig avisynth.dll file (Avisynth 2.6.0 Alpha 5) with the x86 version (and tried the x64 version as well), now when I try to play a video with Zoom Player (with LSFMod as post processing) I get error "Access Violation at 00000000, Read of address 00000000". Putting back the orig avisynth.dll file all is fine again. Note: Previous Avisynth+ version from Sept (?) didn't have this problem...

Does it happen with any video or maybe only specific resolution?

[Gavino]

Possibly the GScript component should be added?
GScript (or its equivalent now incorporated into Avisynth+) has no effect on run-time performance, as it is purely a compile-time function. I suppose it could be used to construct more elaborate filter graphs, if that's what you mean.

[Groucho2004]

GScript (or its equivalent now incorporated into Avisynth+) has no effect on run-time performance, as it is purely a compile-time function. I suppose it could be used to construct more elaborate filter graphs, if that's what you mean.
I see. The idea is simply to put as many internal functions as possible into the script for error/speed testing.

[turbojet]

I think the slowdown on amd's is limited to the resizers. Running the second script Groucho2004 posted:

ICL: 4.13 fps
AVS+: 6.21 (33% faster)

No Resizing
ICL: 5.95
AVS+: 9.05 (35% faster)

Just Colorbars+Resizing
ICL: 13.52
AVS+: 18.46 (27% faster)

...and then the blankclip benchmarks above

Unfortunately resizing is about the only internal function I ever use. Would the devs care to look into it? I'm willing to continue testing.

MP_pipeline makes testing the 2 versions much easier.

[ultim]

Will we see mulithreading this year?

Hopefully the last major thing left for MT is making he caches adaptive in their size (and some misc. things). I'm saying "hopefully" because there have already been unexpected challenges in the past, but let's hope most of them are over. The basic elements of MT are all in place now, but the new caches are not yet up to par with the old one. Their problem is that they have a constant and static size currently, so small caches make the encoding slow, large caches cause out of memory. Anyway I'm working on that now in the little free time i have.

[ultim]

Hello, downloaded newest 2013. nov. 25 binaries, replaced the orig avisynth.dll file (Avisynth 2.6.0 Alpha 5) with the x86 version (and tried the x64 version as well), now when I try to play a video with Zoom Player (with LSFMod as post processing) I get error "Access Violation at 00000000, Read of address 00000000". Putting back the orig avisynth.dll file all is fine again. Note: Previous Avisynth+ version from Sept (?) didn't have this problem...

Please send me your script, and it might be also useful if you uploaded a piece of your video somewhere. If the video is long, just a second of it is more than enough.

[ryrynz]

Anyway I'm working on that now

Awesome, great to see so many commits to the project from you guys. How will the MT code in Avisynth+ stack up vs SEt's Avisynth MT?

[jpsdr]

The percentage of users that would actually be using Windows XP Professional x64 is ridiculously small amongst the XP userbase because it wasn't widely available to consumers except as an OEM/direct purchase from Microsoft. I don't know if the x64 version will let you install to FAT32...
Yes it will...:D

[zero9999]

Yes it will...:D
so does Windows 8.1

[jpsdr]

Euh...? :eek: They rolled back ? Because with Windows 7 you can't install it on FAT32 partition, neither x86 or x64. I don't know for sure, but i think it's the same for Vista, you can't install it on FAT32 partition...

[zero9999]

Euh...? :eek: They rolled back ? Because with Windows 7 you can't install it on FAT32 partition, neither x86 or x64. I don't know for sure, but i think it's the same for Vista, you can't install it on FAT32 partition...
just because you can't install Windows on a FAT32 partition, the same is not true for application software.

[TurboPascal7]

Unfortunately resizing is about the only internal function I ever use. Would the devs care to look into it? I'm willing to continue testing.

As I understand it right now (I didn't work on resizers), this performance drop comes from the removed loop unrolling in the innermost resizer loop and branch prediction sucking on your CPU. Previous implementation used softwire to generate this loop but it isn't an option anymore.

We will look into other ways of optimizing it later but our motivation is not exactly high here. As usual - pull requests welcome.

[turbojet]

As I understand it right now (I didn't work on resizers), this performance drop comes from the removed loop unrolling in the innermost resizer loop and branch prediction sucking on your CPU. Previous implementation used softwire to generate this loop but it isn't an option anymore.

We will look into other ways of optimizing it later but our motivation is not exactly high here. As usual - pull requests welcome.

Directshowsource is also much slower, is it for the same reason?

In the meantime maybe MT will give me reason to switch. Will it mt filters like (t)decimate that require frames to come in order?

[TurboPascal7]

Directshowsource is also much slower, is it for the same reason?
No, we didn't touch it. How much slower and what's the test script/source?

Will it mt filters like (t)decimate that require frames to come in order?
Filters that cannot be multithreaded efficiently won't magically become threaded. TDecimate is one of the most complex cases and it most likely won't benefit much if at all.

[andybkma]

Please send me your script, and it might be also useful if you uploaded a piece of your video somewhere. If the video is long, just a second of it is more than enough.

LSFMod script which is here : http://forum.doom9.org/showthread.php?t=142706

Video is anything (using in conjunction with ffdshow raw as post processing filter, no other settings checked in ffdshow raw, just avisynth)

Cheers ;-)