Avisynth 2.6 MT

[SubJunk]

Sure, the thread-detection has always seemed weird. On my previous quad-core CPU I had to run SetMTMode(x,8) to get full CPU usage, even though it only had 4 cores/threads. It seems to detect my current CPU properly, though.
As a rule-of-thumb on AVSForum we usually recommend users enter 1.8* their core count into it (so an 8-core CPU would use SetMTMode(x,14), etc.). Some CPUs work ~80% faster with that value, others crash, in which case the user should enter the real number of cores.
I had always assumed that it was done on purpose by the AviSynth developers *shrugs*

[Atak_Snajpera]

it all depends what filters you use. When I was using mvtools for 50 fps -> 100 fps interpolation I also had to use SetMTMode(x,8 or 10) in order to achieve max speed/cpu usage on my Q6600@3Ghz. For less intensive filtering SetMTMode(x,4) was sufficient.

[SubJunk]

Yeah that could be it, since most of these times I was using mvtools2 or scripts that use it like QTGMC

[yup]

Sure, the thread-detection has always seemed weird. On my previous quad-core CPU I had to run SetMTMode(x,8) to get full CPU usage, even though it only had 4 cores/threads. It seems to detect my current CPU properly, though.
As a rule-of-thumb on AVSForum we usually recommend users enter 1.8* their core count into it (so an 8-core CPU would use SetMTMode(x,14), etc.). Some CPUs work ~80% faster with that value, others crash, in which case the user should enter the real number of cores.
I had always assumed that it was done on purpose by the AviSynth developers *shrugs*
Hi Subjunk!
I am also increase filtering speed on Q6600 1.5 times replace SetMTMode(x,3) to SetMTMode(x,7) load CPU increase from 40 to 60%, if increase up to SetMTMode(x,8) load CPU increase up to 100% but filtering speed drop.
Script contain QTGMC.
Interesting.
Subjunk! Thanks for trick.
yup.

[VideoFanatic]

I've replaced the avisynth.dll in the System 32 folder with the file from MT. However when I try to encode the video in Simple x264 Launcher it crashes and I get the following message "avs2yux_x86.exe has stopped working". Yet if I encode with HC Encoder I don't get any problems.

[VideoFanatic]

The following works.

setmtmode(5,3)
Mpeg2Source("L:\Raw 2001\01 Raw January 2001\Jan 8\Raw January 08 2001.d2v", CPU=6)
setmtmode(2,0)

However when I add the following to the bottom, HC Encoder encodes the video with a white glow around the edges of objects. It won't encode at all in Simple x264 Launcher and it crashes saying that "avs2yuv_x86.exe has stopped working".

McTemporalDenoise(settings="medium", interlaced=true)

[VEGITA]

I have similar problems with QTGMC, I can open the script in AvsP but when I load it in MeGUI I get a gray output in preview window and it just freezes after I close the preview window.
Script:

SetMemoryMax(512)
SetMTMode(3 )
LoadPlugin("D:\MeGUI_2028_x86\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\ohi04.d2v", info=3)
LoadPlugin("D:\MeGUI_2028_x86\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
SetMTMode(2)
QTGMC( Preset="Medium", SourceMatch=1, EdiThreads=1 )

[yup]

holygamer and VEGITA!
Your problem related to DGIndex.
At DGIndex demux to m2v Your VOB files.
MeGUI at tab tools have AVS script creator from source try ffmpegsource instead of DGDecode.
yup.

[Adub]

Yeah, if I remember correctly you want to be careful when calling a source function in a multithreaded fashion. Try loading your source with DGDecode and THEN loading SetMTMode().

[Groucho2004]

Try loading your source with DGDecode and THEN loading SetMTMode().
That would certainly solve the problems but might be pretty slow. :)

[phoenixxl]

Hello.

I am using avisynth with wine1.4 (current stable)

I write this to mention that the 3 versions of avisynth.dll made after 2011.09.13 do not work in wine.

Instead of trying to describe what is wrong i'll simply add 2 screenshots.

I would not think functionality on linux is the main concern for this dll , but i'm sure it's nice to be able to say it works everywhere. Unlike the original dll in 2.6 this mt one at least works.

anyway,

post 2011.09.13 ->
http://i.imgur.com/7EDgS.jpg


the dll from 2011.09.13 ->
http://i.imgur.com/hBcmD.jpg

The avs is nothing more than loading a sequence of images:


ImageSource("Mintgrow\%06d.ebmp", 0, 1231)


Friendly regards
Phoenixxl.

[Groucho2004]

I recall some problems with ImageSource() and devil.dll, you may have to update (http://sourceforge.net/projects/openil/files/DevIL%20Win32/).

[phoenixxl]

Nope. After replacing dll's it's still the same.

Thank you for suggesting it though

[Groucho2004]

Nope. After replacing dll's it's still the same.

Thank you for suggesting it though

The usual things:
- Does it happen with the "official" Avisynth (2.6 A3)?
- Did you try different MT modes?
- Post the entire script.

[phoenixxl]

That is the entire script. -> ImageSource("Mintgrow\%06d.ebmp", 0, 1231)
The "official" avisynth 2.6 Alpha 3 doesn't work at all on wine.
I am not using any mt modes.

The only difference between working and not working is the dlls from before 2011.09.13 work and those after 2011.09.13 don't.
The exact same setup on a windows machine works without any issue.

@Groucho If you have no hands on experience with using avisyth with wine , don't feel obliged to look into this any further. My message was meant as a note for SeT , nothing more. This isn't a general "request for assistance".


Since the 3 compiles after 2011.09.13 are significantly smaller something drastic in design terms probably happened at that point . Since the change generates no faults with avisynth running on windows it was probably considered valid.
At best with this post I am hoping SeT -or someone close to him involved with the development - takes the extra step of checking if the DLL works on wine before releasing the next version.

[Are_]

As far as I know "official" build does not work because wine does not bundle needed vcs6 dlls with it, if you manually install them it should work (I know you are not in the need neither in the urge, it's ofyi).

The difference in size is most likely, because beforehand it linked against something statically (packing it in avisynth.dll), and now it does it dynamically, and if you have errors because that, it may be wine's fault by doing something wrong.

I was not able to replicate your problem using 2012.05.16 dll and wine 1.5.8 (I created an image sequence with "ImageWriter("", type = "ebmp")" and then loaded it with "ImageSource("%06d.ebmp", 0, 200)").
I tested with wine 1.4 and I was able to replicate your results, so wine 1.4 is the one to blame.

[phoenixxl]

@Are_

Thank you for taking the time to check this.

For now I will probably be keeping to stable wine14 and use an older version of avisynth.dll. I'm already happy knowing that when 1.5 is stable the problem will be solved.

Friendly regards
Phoenixxl.

[SEt]

Indeed in recent versions build chain changed: from VS2005/2008 and static crt linkage to VS2010 and dynamic crt linkage to msvcrt.dll (XP level). I don't think there is anything wrong with avisynth.dll – probably it's wine to blame for incomplete/incorrect msvcrt.dll implementation.

[LoRd_MuldeR]

AFAIK, binaries that were compiled with VS2010 and that are using the DLL version of the Visual C++ Runtime ("/MD" switch) will depend on MSVCR100.DLL, not MSVCR.DLL. The latter (without a version number in the name) is part of the Windows operating system and many system programs (like e.g. Explorer.exe) make use of it. Also binaries compiled with MinGW/GCC use the MSVCR.DLL. The MSVCR100.DLL, on the other hand, is not part of the operating system. It's a VS2010 redistributable and any application that needs this DLL must install it! Fortunately, starting with VS2010, Microsoft made it possible again to simply put the MSVCR100.DLL into the same folder as the EXE file. The Visual C++ Runtime DLL's of VS2005 and VS2008 (MSVCR80.DLL and MSVCR90.DLL) would not work this way, because they were managed by "Windows Side-by-Side" (WinSxS) and therefore had to be installed using the Visual Studio 2005/2008 Redistributable installer program. It also has to be noted that, starting with VS2010, Microsoft has increased the minimum system version (in the binary's PE header) to "5.1", i.e. Windows XP. Trying to run such binaries on Windows 2000 (or even older) will result in "Not a valid Win32 executable" error message. The Visual C++ Runtime of VS2010 also makes use of two Win32 API functions un-available before Windows XP with Service-Pack 2! I have implemented a workaround (http://mulder.googlecode.com/svn/trunk/Utils/EncodePointerLib/README.txt) for this, but it can only work with the static Visual C++ Runtime.

As for Wine, I'm not sure whether it ships with a MSVCR.DLL, like a "real" Windows system does, or not. But for a binary compiled with VS2010 that shouldn't matter at all, as such application has to provide its own MSVCR100.DLL anyway...

(BTW: It might be possible that certain versions of Wine refuse to load binaries that need a minimum system version of 5.1 and/or have problems with the new Win32 API functions. It definitely does work with Ubuntu 12.04 though!)

[phoenixxl]

It definitely does work with Ubuntu 12.04 though!)

Try reading a sequence of ebmp's. Use wine 1.4

[SEt]

I know well what I'm talking about. It's linked exactly to msvcrt.dll, not msvcr100.dll or some other troublesome runtime dll. The change was made because this way has both advantages of reducing code size and not requiring some non-system dll.

[LoRd_MuldeR]

Try reading a sequence of ebmp's. Use wine 1.4

Well, all I was saying is that applications compiled with VS2010 and thus using MSVCR100.DLL generally do work under Ubuntu 12.04 + Wine (whatever version of Wine is bundled with Ubuntu 12.04).

I have checked this with my own applications. Still other random problems might pop up with other applications when running under Wine. For example I noticed that calling SetConsoleIcon() crashed my application under Wine :rolleyes:

[djonline]

When x64 2.6.0 will be ?

[SEt]

From me – likely never. Not anytime soon at least.

[tormento]

x64 is useless if no "modern" plugin is compiled, as MVTools2 from cretinesdesalpes and so.

[kypec]

From me – likely never. Not anytime soon at least.
I don't care about x64 Avisynth either but what about new x86 build that would include two recent Ian's bug fixes (http://forum.doom9.org/showthread.php?p=1585355#post1585355) :D
:thanks:

[ryrynz]

Those were only just added. Give the man some time! :P

[SEt]

I don't have access to by usual build environment now, so expect new build in around two weeks.
You can get all my code changes from first post and apply them to current cvs yourself if you can't wait – results won't differ much.

[SEt]

How about dropping WinXP/2003 support? I'm updating to VS2012 and by default it produces files that require minimum NT 6.0 (Vista/2008).

[mastrboy]

How about dropping WinXP/2003 support? I'm updating to VS2012 and by default it produces files that require minimum NT 6.0 (Vista/2008).

I don't mind, XP/2003 are ancient after all.

[ryrynz]

I'm for it also, compile with VS2012.

[forclip]

I'm still on XP.. I don't think that is a good idea to drop support for XP.

[Atak_Snajpera]

so it is your problem now. wake up it is 2012 time to upgrade to windows 7! set you have green light from as well.

[ryrynz]

I read there will be an update to VS2012 that will allow for XP support later this year.
New builds up until that time can lack XP support until the patch arrives and then perhaps you could make a build that has XP support, either by default or a separate build (just a special case if there's any drawback to having XP support by default)

[forclip]

so it is your problem now. wake up it is 2012 time to upgrade to windows 7!
Why I must pay for upgrading to Win7 if WinXP is enough for me and I'm satisfied with it?!

Also, quick googling gave me this links:
one (http://www.w3schools.com/browsers/browsers_os.asp)
two (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
- if this statistics is correct, not less than 25% of users still uses WinXP.

[Atak_Snajpera]

Why I must pay for upgrading to Win7 if WinXP is enough for me and I'm satisfied with it?!

Also, quick googling gave me this links:
one (http://www.w3schools.com/browsers/browsers_os.asp)
two (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
- if this statistics is correct, not less than 25% of users still uses WinXP.

the same could say user with windows 98... besides you can compile your own avisynth mt.

[Groucho2004]

Why I must pay for upgrading to Win7 if WinXP is enough for me and I'm satisfied with it?!
Just ignore this guy. His arrogant and childish attitude is becoming tiresome.

[forclip]

The same for you:
besides you can compile your own avisynth mt
that will only support Vista+. But for "mass production" I think that WinXP still should be supported. The fact that you already on Win7 doesn't mean that everyone around is also on Win7. So many people for one or another reasons is still on XP, why they must be forced to move to Win7?!

Sorry, don't want to discuss about it, just put my 5 cents.

[ryrynz]

I love it how when updates are made to programs that discontinue support for a sub section of users they suddenly "seem" to think that the program they're currently using just stops working.

You do realize you can still use what you're using right? Are you having any issues with the program? No? Then why do you need to upgrade?

Isn't this the very opinion you have of the OS you're running?

"I have no issues so I don't need to upgrade!" Hypocritical? You bet.

Everybody loves updating their apps, they're free and easy to update after all! but when it comes to the OS.. oh it's so much work and money to upgrade.

You're always going to have complaints from people with their heels planted firmly in the ground.

Do it anyway. :)

[Atak_Snajpera]

Just ignore this guy. His arrogant and childish attitude is becoming tiresome.

xp users must extinct. i don't care whether you like it or not. the same happened with win9x users and your whinning won't prevent that!

[SEt]

I'm using 'tweaked' Visual Studio, so it's not directly related to what it/will officially support but making NT 6.0 baseline would require way less hacks.
Actually I'm most worried about 2003(=WinXP 64) since it, unlike awful WinXP, is still reasonable OS to use for video processing. WinXP with its licensing limit of 4GB of address space is a joke here.
Also note that Avisynth is no way "mass product" ;).

As for the need to update Avisynth – as ryrynz mentioned, there is no real reason to update. Avisynth 2.6 is dead for quite some time now and changes are very minor, even the "new API" introduces nothing new.

About upgrading OS. New interface of VS2012 is bad, but new interface of Win8/Server2012 is plain unbearable. So, as much as I welcome kernel improvements, these OS are unusable right now. There are bad sides of Win7, but it is definitely useable.

[Groucho2004]

xp users must extinct. i don't care whether you like it or not.
I rest my case.

[kypec]

@SEt - do as you like, these are your builds and no one should be forcing you to make them this or that way. I don't mind leaving XP support at all, Win7 is so much better and I've been using it for more than 2 years now...

[StainlessS]

Dont worry guys, there will undoubtedly be yet another fork/build set for XP users, it will just have a name change.

[cretindesalpes]

I’m also in favor of keeping a WinXP support.

[Wilbert]

xp users must extinct. i don't care whether you like it or not. the same happened with win9x users and your whinning won't prevent that!
Perhaps that would be a valid point if using this was not necessary: http://forum.doom9.org/showthread.php?t=146910. I'm also running XP and won't upgrade as long as possible.

[pbristow]

My 2 groats: I'd prefer to see WinXP (or at least 2003) supported for a while longer, at least in the sense that we try to avoid making code changes that will only work with later versions... but that doesn't mean Set has to produce WinXP *builds* if he doesn't find it convenient to do so. What matters is that the Avisynth code moves forwards in power, performance and stability, and if having to mess up his build environment to provide backward-compatible builds is going to slow that development down, then it should not be required.

Set: Build things the way that's easiest for you to get your work done. There are plenty of people here who have the ability to re-build a given version of the code for XP, if there's enough demand for it.

(My 2nd/"backup" machine is still on XP, and rather than ever being upgraded to Win7 it's more likely to get replaced entirely someday... But in practice, unless my main machine goes bang/gets infected or I have a rush job on, I only do video processing stuff on Win7/64.)

[Sparktank]

I have 3 machines: WinXP (x86), Vista (x86), and Win7 (x64).

The other two machines are too old (and expensive) to upgrade, there's currently no driver support for them in Win7.

I use mostly WinXP for all my Avisynth needs.
I rarely used Win7 for Avisynth.
That is not to say that I won't in the future.

But keeping XP builds would be favourable.

[SEt]

As far as I can see in VS2012 there are no major portability problems with C part or runtime, but C++ part (strings) heavily uses NT6.0 WinAPI functions.

Wilbert, those tools are definitely unnecessary: all you need is to wipe 1 (2 for x64) registry key – and DirectShow will behave the same as on NT5.

[StainlessS]

SEt, you go the way you feel you have to, its not the right move but it's your call.
Nothing wrong with another fork, all the advantages of SEt's builds but with XP too.
Looking forward to it. :)