I made a mt 2.5.8 avisynth.dll and mt.dll [Archive]

Jeremy Duncan

7th February 2009, 22:49

src (http://www.mediafire.com/?tmjdmn2igfm)
dlls (http://www.mediafire.com/?kghxrwtzmrx)
Microsoft Visual C++ 2008 Redistributable (http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en)
msvcp71 and msvcp71 plugins (http://www.megaupload.com/?d=SP5FE2KG)

dlls. Updated january 10, 2010. These were compiled using the windows 7 sdk so it may be more compatible with windows 7. (http://www.mediafire.com/?zy2xm2ejvzg)
________ Notes ________

\\\\\ Once installed. Reboot twice.

\\\\\ How do I use these new avisynth and mt dll's you made?
install avisynth 2.5.8
substitute the avisynth dll in windows\system32 folder with the one I made
ADD the mt.dll in C:\Program Files\AviSynth 2.5\plugins folder
done.

\\\\\ It's crashing on me.
Install the "Microsoft Visual C++ 2008 Redistributable"

\\\\\ It's crashing on me and I'm using a windows 32 bit os.
In the system32 folder is there the msvcp71 and msvcr71.dll?

\\\\\ It's crashing on me and I'm using a windows 64 bit os.
In the syswow64 folder is there the msvcp71 and msvcr71.dll?
In the syswow64folder is there a avisynth.dll?

\\\\ I can't build it?
I built them in windows 7 build 7100 on july 2, 2009. I ran visual studio as administrator.

\\\\ Your Avisynth makes the video ugly and the audio choppy.
Reboot. Before I thought that one dll compile build was different from the other. But I was wrong.

I was recompiling the dll everytime to get one that worked, but then I decided to just try removing the dll giving the ugly picture and choppy sound from the avisynth or system 32 folder, and put it on my desktop.
Then I put the dll back in either the system32 folder or the avisynth folder and it gave no ugly picture or choppy sound.

So for some reason when I put the mt or avisynth dll in the folder they should go into (mt in the avisynth folder and avisynth into the system32 folder), sometimes the video player gives ugly bad results.
Simply removing it from the folder and then putting it back in there fixes this, or you may leave it in there and just reboot and it will be fixed.

\\\\ What is different about these dll's than the other SEt builds you munkeyed around with?: October 6, 2009

I updated some files in the src, core folder. I got the new ones from SEt's 2.6 src. I read the bug fix he made in that 2.6 thread of his today and so decided to make a new dll with the fix and thought it would be cool to include other mt files from his src so I did.
I forget which ones though.

\\\\ What is different about these dll's than the other SEt builds you munkeyed around with?: September 11, 2009

I fixed a bug gavino found and I added the mt in the file info tab that was requested.

\\\\ What is different about these dll's than the other SEt builds you munkeyed around with?: August 17, 2009
I shrunk the avisynth.dll using upx.exe. The code I used with upx.exe is in the src distrib folder, nsi file. I use upx.exe version 3.3.0.0

\\\\ What is different about these dll's than the other SEt builds you munkeyed around with?: August 16, 2009
I deleted this line from the main.cpp and avisynth.h in the src core folder:
#define Interlockedincrement _Interlockedincrement

\\\\ What is different about these dll's than the other SEt builds you munkeyed around with?: July 22, 2009

This is second build on July 22. No, now it's july 23 2009.
What did I do?
I found much to my surprise the project wasn't calling all the files in the src folders. So I added those then spent some time optimizing the project settings, making sure mt.dll was made right and then posted them here.
I was going to use upx.exe to shrink the dlls but it didn't work like before, so I didn't shrink the file size this time.

Works pretty good though. :)

\\\\ What is different about these dll's than the other SEt builds you munkeyed around with?: July 22, 2009
This is the build made on July 22, 2009 and not July 17 2009.
Look below to see previous changes I made.

I used the july 17 src and put SEt's stdafx.h file in there, before it was the japan one.
And I put my project settings in the include folder: softwire, soundtouch, pfc.

One other thing I did was shrink the file size.
I think shrinking it made it more stable.

When you install the avisynth dll, reboot Twice. I dunno why but rebooting twice helps make sure it's fine after that. Maybe I'm wrong?

And I'm using tsp's mt.dll in the dlls link above.

\\\\ What is different about these dll's than the other SEt builds you munkeyed around with?: July 17, 2009
What I did was find the different files between the SEt July 12 build and the original Japan src.
Then I guessed the files that SEt modified and the ones I did. It wasn't hard as my adjustments were of a base skill and SEt's were expert.

I then cross checked the ones I changed with the Japan src and the Japan src files were the same as the official avisynth 2.5.8 src.
So I switched the ones I changed for the japan src ones, and kept the ones SEt changed.
Then I kept the include libs: softwire, soundtouch, pfc from the japan version, and the stdafx from the japan version as well. I put all these into the SEt july 12 src.

I will post a list of the files different from the SEt july 12 src from the original japan src below.

This list I changed to the japan src version:

core parser folder
expression.cpp

filters folder
color.cpp
convolution.cpp
edit.cpp
focus.cpp
greyscale.cpp
histogram.cpp
layer.cpp
layer.h
levels.cpp
planeswap.cpp
resample.cpp
resize.cpp
transform.cpp

filters overlay, conditional folders

sources folder
source.cpp

sources, avi folder
AVIReadHandler.cpp

____________________________________________

This version I kept as they were altered by SEt:

Audio folder
audio.cpp ++
avs-soundtouch.cpp ++
supereq.cpp ++

core folder

Avisynth.h ++
Avisynth.cpp ++
avisynth_c.cpp ++
cache.cpp ++
cachemt.cpp ++
main.cpp ++
mt.cpp ++
mt.h ++
softwire_helpers.cpp ++

filters folder
merge.cpp ++

\\\\ I did a comparison of my july 9th, july 11th, 5th version, and SE'ts version from his new thread.

http://thumbnails9.imagebam.com/4186/c1905941854223.gif (http://www.imagebam.com/image/c1905941854223)
http://thumbnails16.imagebam.com/4186/af6ddb41854227.gif (http://www.imagebam.com/image/af6ddb41854227)

Link to see pictures of the stats. In case the picture host is too slow or goes kaput. (http://www.mediafire.com/?miv4dndzim2)

\\\\ I wanna build my own. How do I do it?

Follow the instructions in this link: link (http://forum.doom9.org/showthread.php?t=145130)

A.) You will need to use the sw in the link at the top of the link as the instructions for other versions are different.

B.) The youtube video showing avisynth compilation is for the official 2.5.8 version, not my mt version.
To compile my version you setup visul studio as shown in the video then unzip my src and change to release in configuration manager (in visual studio). Then you build the soundtouch, softwire, pfc then you build avisynth.dll

C.) when you build the softwire, soundtouch, pfc, avisynth.
Highlight the one your going to build then from the "build tab, project only, build only" on the top menu.
You build only the one thing at a time, or else you will get a bunch of errors and that's not cool. :)

D.)

1.) Once the dll is made then go to the avisynth src folder, release and get the avisynth dll and put it on your desktop.

2.) Then go and get the upx.exe from google, windows console version, and put the upx.exe on your desktop.

3.) Then open cmd prompt in admin and go to the desktop using the cd command as shown in the link to how to build the dll. Example: cd C:\Users\aye\Desktop

4.) Then with cmd prompt still open and both the upx.exe and avisynth dll on the desktop, in cmd prompt type: upx avisynth.dll
and then press enter and it will reduce the size of your dll!

5.) Then you put it in place of the other one in the system32 folder and reboot twice and then test your new dll.

@Tron@

9th February 2009, 22:35

Fully agree with the previous speaker!
Very useful to MT version avisynth 2.5.8 But I think no one will be taken for this as it is a long and laborious process!

Few will be able to change and adjust to avisint in MT and therefore unnecessary to wait and hope (at least for this year is already accurately) just so many unnecessary and all here (in the process remake MT)

lych_necross

10th February 2009, 07:17

:search:
This has already been discussed. The MT mod will be integrated into Avisynth in version 2.6.0. I wouldn't expect MT to be updated for 2.5.8 as it is currently based on 2.5.7.5.

Jeremy Duncan

16th February 2009, 06:40

Older stable versions of my avisynth builds and src's:

July 12th

src (http://www.mediafire.com/?nej4djmomw3)
dlls (http://www.mediafire.com/?tlvzmtjjnly)

July 23, 2009
src (http://www.mediafire.com/?djz11jcinjj)
dlls (http://www.mediafire.com/?mi1wrmynvw1)

August 17, 2009
src (http://www.mediafire.com/?m1zmylqdjjv)
dlls (http://www.mediafire.com/?wnxujmydded)

September 11, 2009
src (http://www.mediafire.com/?jjckmgtjmvw)
dlls (http://www.mediafire.com/?o1dccmm1l1t)

gator1102

16th February 2009, 15:46

http://seraphy.fam.cx/~seraphy/
http://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=1990&type=287&space=15&no=0
http://seraphy.fam.cx/~seraphy/cgi-bin/upload/MT_07_with_Avisynth258.rar

@Tron@

16th February 2009, 17:56

http://seraphy.fam.cx/~seraphy/
http://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=1990&type=287&space=15&no=0
http://seraphy.fam.cx/~seraphy/cgi-bin/upload/MT_07_with_Avisynth258.rar

Is it true !? Wow :eek::eek:!!! BIG THX !!! :thanks::thanks::thanks::thanks:

Now testing it !

Fizick

16th February 2009, 18:39

online translation 1 (excite)

DustMT Avisynth2.5.8 - contribution person/seraphy@ curator - (2009/01/12 (Mon) 13:21:43

DustV5 MT conversion of remodelling (with the society you call DustMT selfishly, it seems) is,
but It became unable to use the environment of the house by moving to Avisynth 2.5.8.5.
So, still as for tsp, as Avisynth.dll of MT correspondence (2.5.8) release not done.
http://forum.doom9.org/showthread.php?p=660247#poststop
Because is, taking diff of 2.5.7 and 2.5.7MT, it tried applying to 2.5.8 selfishly.
As for me as for the source of Avisynth you have not read seriously because and,
you do not read either the MT conversion tsp securely, whether or not it does properly, it does not guarantee.
Only the one which it can cope entirely on self responsibility please utilize.
Rash is different from courage.
It will wait wise one for the correspondence tsp.
By the way, because it compiles this with VC2008, (the birthplace VC6 kana? ) Execution time becomes necessary.

online translation 2 (babel fish):

- Contributor/ Seraphy@ manager -(2009/01/12(Mon) 13:21:43)

Without permission it is making remodeling (It seems to be called DustMT on the street) DustV5 MT
It is not possible to use it by having shifted the environment of the house to Avisynth 2.5.8.5.
And Avisynth.dll(2.5.8) for MT has not been released to Mr. tsp yet.
http://forum.doom9.org/showthread.php?p=660247#poststop

Diff of, 2.5.7, and 2.5.7MT was taken and it applied it to 2.5.8 without permission.
I seriously read the source of Avisynth, do not exist, and : because I do not firmly read Mr. tsp's making to MT.
It is not secured can tidy.
Please use can only all actions by the self-responsibility.
Courage and rashness are different. Wise one waits for Mr. tsp's correspondence.

By the way, because here is compiled with VC2008 (Is the head of the house VC6?), run time is needed.

@Tron@

16th February 2009, 20:06

online translation 1 (excite)

So ... its not full version ((((((9 Very bad ...

:confused::(:(:(

Razorholt

16th February 2009, 23:31

@Tron: did you try it yet?

Mug Funky

17th February 2009, 00:08

i'm going to try this out because the machine translation told me it's better to be rash than courageous :)

Jeremy Duncan

17th February 2009, 15:11

@Tron: did you try it yet?

I tried it, and it really works. :)

No problems playing ffdshow avisynth in realtime with this new mt.

I tried seesaw, lsf, spresso, and mvtools v2 frame doubler.

I have a new upload of it if you don't want to unzip a rar.
link (http://files.filefront.com/MT+07+with+Avisynth258zip/;13308431;/fileinfo.html)

I will wait and hope somebody looks at the code to make sure it's safe before I use it and link to it in the guide i made.
I have since ghosted my pc to a earlier state since I tested this grand mt this kind fellow made.

Many thanks mr or ms gator1102

Fizick

17th February 2009, 19:11

It seems, there is no source code explicitlly posted

lych_necross

18th February 2009, 11:28

Woops... source is now posted... nevermind :)

MfA

18th February 2009, 16:04

Have you tried simply asking him for the source code?

RedDwarf1

18th February 2009, 21:39

Would be nice if it works.

burfadel

18th February 2009, 23:29

It works :) I already have fairly good CPU utilisation, but with this it make it almost perfect, and it shows in the higher fps of encoding speed. I take it this doesn't affect the output too much?

cyberbeing

19th February 2009, 00:48

The source code is now available here: http://seraphy.fam.cx/~seraphy/cgi-bin/upload/avisynth258MT.zip
Source is here.
I don't think to post on the Doom9's Forum. (I'm not a member.)

These were modified based on the tsp's Patch,
but can't guarantee to work correctly because I don't understand the content of the change well.
Please use this at your own risk. ;-)

Jeremy Duncan

19th February 2009, 17:40

I can't see any avisynth file that shows major changes from the 2.5.8
And some files are in a format I can't open.

If you would be so kind as to find a avisynth with the changes this fellow made to it, and post it in c++.

:)

lych_necross

20th February 2009, 07:29

You need Visual Studio to open the project files. Other than that, all of the files can be read with either wordpad or notepad.:)

burfadel

20th February 2009, 09:07

The reason why this peaked my curiosity is I just got a Q9400 as an upgrade to my E6600 CPU a couple of days ago.

It works for me, although I don't use complex lengthy avisynth scripts. Just RemovegrainHD, spline64resize, gradfun2db, crop etc

On a sidenote I do believe in using gradfun2db before encoding, it not only takes out banding but other colour distortions too (with a threshold of around 1.6 is what I use). For re-encoding XVID/DIVX around 3. Not only do I believe the output looks better, but at least the encoder isn't trying to encode the banding and colour distortion (or abberations?)! Slight Debanding can also be used during playback :)

The settings I use for the MT is just the basic:

SetMTmode(2,4)

With 4 threads of course because of it being a quad core.

This is the very first line of the avisynth script (well filter list, as using Staxrip), and thats all thats different.

I believe using the combined functions such as
Filter().Filter2(...

Is a bad idea with the MT avisynth as the combined function will be passed as a complete fuction, and not separate functions and threads (so you negate the benefit)?

I do realise SetMTmode(1,4) would be faster but that has compatibility issues with most filters, and the benefit would be almost none I believe over using SetMTmode(2,4).

If you have a an avisynth filter list that isn't too taxing, and slow x264 settings its probably not that beneficial for older CPU's or even more modern dual cores (including the E8xxx). The Avisnth ratio is 1 thread to 2 (in terms of encoding potential). Since x264 for example can make use of 4 threads, the ratio between avisynth and x264 is 1:4, meaning unless you have an extremely fast avisynth filter list x264 is waiting for data from Avisynth.

This is an over-simplification, but consider that even if a dual core was ten times faster than those today, it just means the avisynth filters can run ten times as fast and still pass the frames on to x264 which, although is also running 10 times as fast can still only process at a ratio of 1:2!

If you use fast enough encoder settings on dual core that the encoder has to wait for the avisynth input, it would be beneficial to increase the encoder settings to make use of the CPU time and the loss of encoding speed won't be too excessive.

The only time on a dual core where I see the multithreading patch to be effective is when you have a very complex and slow script, or using a fast encoder.

I use very high settings for my encoding, so this probably becomes more visible if you use still quite reasonable settings. I think the key point when trialling this patch is to encode a couple minutes of a clip, with the typical input type and encoder settings that you usually use, and check the fps you achieve for the encoder. Then try the MT, and do the same. The cpu utilisation may not be a good indication of improved performance. If the encoder is the limiting factor, increasing the speed of avisynth won't give you any benefit and could potentially slightly slow down the system due to thread utilisation (from what I've heard), if Avisynth is the limiting factor then this patch will give you potentially a nice boost :)

Gavino

20th February 2009, 10:55

I believe using the combined functions such as
Filter().Filter2(...
Is a bad idea with the MT avisynth as the combined function will be passed as a complete fuction, and not separate functions and threads (so you negate the benefit)?
No, that only applies when using the explicit MT function, ie MT("Filter().Filter2()...)".

With SetMTMode switched on, the MT Avisynth treats each filter in a chain distinctly, since this is handled by changes to the parser in the amended avisynth.dll.

leeperry

20th February 2009, 17:15

nice! 2.5.8 should allow mod2 in LSF, where 2.5.7 is mod4 only

but I've tried it on a few mod2 samples, and sometimes it works....but most of the time it's very slow and crashes :o

burfadel

20th February 2009, 17:53

No, that only applies when using the explicit MT function, ie MT("Filter().Filter2()...)".

With SetMTMode switched on, the MT Avisynth treats each filter in a chain distinctly, since this is handled by changes to the parser in the amended avisynth.dll.

Ah ok! thats good to know :)

The Mpeg2source filter when decoding HD material doesn't like it when SetMTmode is set! It works fine set to 2 for standard definition 720x576 material though, so this may need to be taken in to consideration for other people that different resolutions may lead to different compatibility! Easiest way around this is just to set MT mode after the source filter! :)

leeperry

22nd February 2009, 06:52

humm yeah, it crashes all the time w/ mod2...back to 2.57 :o

lych_necross

22nd February 2009, 07:15

I've got the same problem with mod2 files... Oh well, 2.57 works. Does anyone know if ConvertFPS( benefits with either SetMTMode or MT( ?

Edit: I test convertfps with both MT and SetMTMode and I found no discernible difference on my system (others may differ).

Jeremy Duncan

12th March 2009, 17:29

nice! 2.5.8 should allow mod2 in LSF, where 2.5.7 is mod4 only

but I've tried it on a few mod2 samples, and sometimes it works....but most of the time it's very slow and crashes :o

I have made my version of the dll the kind person made. I used their src and fixed some code.

Go see! :helpful:

Edit.
2 days and nobody says how the dll I made did for them?
It is different than the one seraphy made!
It should do the mythical mod2 you talk about...try it out and tell us what it did? :)

lych_necross

13th March 2009, 07:51

Hi Jeremy, I tried your version of the dll and it seems to work alright. No problems so far. I'll test it some more and report any problems. The only thing I noticed is that when you display the avisynth version in a script, it still says Seraphy (just add version() to the end of a script). You might want to alter that to reflect your additional changes.

@leeperry
Does it work on your end?

cweb

13th March 2009, 07:59

leeperry

13th March 2009, 10:30

@leeperry
Does it work on your end?
looking good indeed! :eek:
I've got a 672x384 AVI file w 7/4 DAR(that becomes 1022*584 after resizing to 1024*768 in ffdshow), I've tried to open it like 20 times...it only crashed once(same as the old buggy DLL), basically it went really slow and crashed my player after a few secs.

it also crashes a lot when I seek..

when it's mod2, it seems to stall for a few seconds before starting playback

if only ffdshow could resize to 1024* when I ask it to, but it doesn't seem possible..

alph@

13th March 2009, 21:01

hi jeremy, thanks for your work, the question :), why your version of avisynth dll mt is so big '1287 ko' instead of the other one wich is smaller '336 ko':eek:

Guest

13th March 2009, 21:24

He probably built the debug version.

Jeremy Duncan

14th March 2009, 01:42

I updated the dll in the first post.

I don't know why it's so big. :)

Guest

14th March 2009, 03:07

Set the project to "Release" instead of "Debug".

Build/Configuration Manager.

squid_80

14th March 2009, 06:55

I think the official builds have been UPX'd or similar.

lych_necross

14th March 2009, 07:23

Yes, the official builds have been UPX'd.

Jeremy Duncan

14th March 2009, 08:19

Set the project to "Release" instead of "Debug".

Build/Configuration Manager.

I did. For all the libs: soundtouch, softwire, pfc. And the avisynth dll.

"when it's mod2, it seems to stall for a few seconds before starting playback".
if you specify the fps and then run your code under that it should be ok.
See assumefps (http://avisynth.org/mediawiki/ConvertFPS)

My film is 29.970 fps I think. So I use assumefps like this:
ffdshow_source()
MT("
assumefps(30000, 1000, false)
",2)

The false is to show no audio is used in the setting.

The stall is due to the avisynth dll having 64 to 32 bit conversion. I think. :)

alph@

14th March 2009, 10:42

'Yes, the official builds have been UPX'd' , yes it is , thanks:)

Gavino

14th March 2009, 11:36

I use assumefps like this:
ffdshow_source()
MT("
assumefps(30000, 1000, false)
",2)
It's pointless putting MT around assumefps since the filter does not process any pixels - it just changes the clip properties.
Using MT here will actually slow it down instead of speeding it up - just use assumefps on its own.

Jeremy Duncan

14th March 2009, 17:23

It's pointless putting MT around assumefps since the filter does not process any pixels - it just changes the clip properties.
Using MT here will actually slow it down instead of speeding it up - just use assumefps on its own.

I tried my frame doubler with no mt around assumefps and it crashed. Not right away, but after some time.
Putting it in mt solved this problem.

I made another avisynth mt dll today and put it in the first post.
I included a build log so you can see it's a release and not a debug.

This version had most of the convert warnings fixed.
It's more stable I think after testing it with my frame doubler in ffdshow.

Leak

14th March 2009, 19:28

I tried my frame doubler with no mt around assumefps and it crashed. Not right away, but after some time.
Putting it in mt solved this problem.
Except that AssumeFPS plain doesn't work in ffdshow. I made sure of that, as no matter what you it'll destroy any synchonization between audio and video since AviSynth only operates on the audio.

AssumeFPS all you want - ffdshow will use the timestamps of the input frames to calculate the output frame timestamps. If your file itself has it's framerate wrong remux it with the correct framerate.

np: Fink - If Only (Distance And Time)

leeperry

14th March 2009, 19:37

I made another avisynth mt dll today [...] It's more stable I think
righty, will look into it. :thanks: for your efforts!

Jeremy Duncan

15th March 2009, 10:59

Except that AssumeFPS plain doesn't work in ffdshow. I made sure of that, as no matter what you it'll destroy any synchonization between audio and video since AviSynth only operates on the audio.

AssumeFPS all you want - ffdshow will use the timestamps of the input frames to calculate the output frame timestamps. If your file itself has it's framerate wrong remux it with the correct framerate.

np: Fink - If Only (Distance And Time)

changefps still works though?

I have remade a new avisynth mt and put it in the first post.
The last one I made I just suppressed the warnings.
With this new one I went to the first src I made and instead of suppressing warnings I fixed them.

There were other warnings I fixed too.

I tried it on my frame doubler and it is used more cache in the task manager performance tab than my 3rd try.

There are other warnings, but I won't even bother trying to fix those.
Look at the buildlog to see the warnings.

Leak

15th March 2009, 12:09

changefps still works though?
You can't set an arbitrary framerate, but if your filter returns more or less frames the timestamps will be adjusted accordingly.

Otherwise even a simple Bob() wouldn't work.

np: The Fireman - Is This Love? (Electric Arguments)

Jeremy Duncan

15th March 2009, 13:58

You can't set an arbitrary framerate, but if your filter returns more or less frames the timestamps will be adjusted accordingly.

Otherwise even a simple Bob() wouldn't work.

np: The Fireman - Is This Love? (Electric Arguments)

I just set the changefps to the fps in the dvd.
See the ffdshow configuration below.

________ advanced ffdshow: framerate doubler. (ntsc 60hz monitor compatible) ________

Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Avisynth tab checked
YV12 checked,
Add FFdshow Video source checked,
3:2 Pulldown box: Ignore Pulldown checked,
check Buffer back/Ahead: 0, 2

setmtmode(mode=1)
changefps(30000, 1001)
super = MSuper(pel=2,hpad=8,vpad=8)
backward_vec = MAnalyse(super,chroma=false, blksize=16, overlap=4, isb = true, search=5, searchparam=1)
forward_vec = MAnalyse(super, chroma=false, blksize=16, overlap=4, isb = false, search=5, searchparam=1)
MFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(last), \
den=FramerateDenominator(last), mask=0, ml=49)
distributor()

Resize & aspect tab checked
Multiply by:
1.844 (for 1280x720 16:9 aspect ratio)
2.729 (for 1920x1080 16:9 aspect ratio)
Process Pixel aspect ratio internally checked
No aspect ratio correction checked
spline
Luma Sharpen: 0.00
Accurate rounding checked

Queue & Output tab
Queue output samples unchecked
Very unstable. May cause player to crash.
No box is checked.

Output tab
rgb32 checked
high quality yv12 to rgb conversion checked

rgb conversion tab
ycbcr: itu-bt 601
contrast: standard
Output levels: Tv/Projector
Reclock: Be sure to use reclock vsync

lych_necross

16th March 2009, 08:14

If you want to double the framerate, why not just use ConvertFPS(framerate*2)
If you don't like blend mode, set the output to yuy2 and use
ConvertFPS(framerate*2, zone=80)

Jeremy Duncan

16th March 2009, 09:58

If you want to double the framerate, why not just use ConvertFPS(framerate*2)
If you don't like blend mode, set the output to yuy2 and use
ConvertFPS(framerate*2, zone=80)

I solved the problem.
THe solution was to use info by itself in the ffdshow avisynth tab and then to use the right mt.

I was using setmtmode before.
I tried the mt in the mvtools read me and with the info info() gave me I got it going.

:thanks: though.

Edit,

If I hadn't seen the chart in th mediawiki in the fps section I would still be trying different settings.

leeperry

16th March 2009, 10:30

well the framerate doubler used to be in ffdshow, but Haruhiko took it off for some reason...and doesn't want to put it back :D

anyway, your latest build seems to work perfectly fine! maybe you can work on Haali's Renderer now...j/k :p

Leak

16th March 2009, 11:30

well the framerate doubler used to be in ffdshow, but Haruhiko took it off for some reason...and doesn't want to put it back :D
Say what? (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2642)

leeperry

16th March 2009, 13:15

oops...so he did put it back after all :cool:

anyway I needed mod2 in MT avisynth because the ffdshow resizer doesn't do what I want(resize to 1024 wide) :
https://forum.doom9.org/showpost.php?p=1261217&postcount=6836

but maybe there's some obscure AR voodooness I'm clueless about, as it works fine if I force 1.78 AR :rolleyes:

also, why is it mandatory to have avisynth.dll in /system32/? because you enforce it in ffdshow?

Leak

16th March 2009, 15:22

also, why is it mandatory to have avisynth.dll in /system32/? because you enforce it in ffdshow?
I don't think it's mandatory to have it in system32, it just has to be somewhere that Windows will look for it, like one of the directories specified in the PATH environment variable or in the player application's current directory, wherever that is...

I could be wrong, though - I always install AviSynth in the default location, i.e. system32.

cweb

16th March 2009, 15:24

I don't think it's mandatory to have it in system32, it just has to be somewhere that Windows will look for it, like one of the directories specified in the PATH environment variable or in the player application's current directory, wherever that is...

I could be wrong, though - I always install AviSynth in the default location, i.e. system32.
My AviSynth is installed to another location yet it places its main dll in system32...

leeperry

16th March 2009, 15:32

I don't think it's mandatory to have it in system32, it just has to be somewhere that Windows will look for it, like one of the directories specified in the PATH environment variable or in the player application's current directory, wherever that is...

I could be wrong, though - I always install AviSynth in the default location, i.e. system32.
actually, you can't regsvr32 avisynth.dll
I thought you were assuming in ffdshow that it was in /system32/ because its location is not indicated anywhere(.ini/registry)...I'd love to put it on my ramdisk to make my movies open faster in ffdshow, but that's a no go :o

Leak

16th March 2009, 15:37

actually, you can't regsvr32 avisynth.dll
I thought you were assuming in ffdshow that it was in /system32/ because its location is not indicated anywhere(.ini/registry)...I'd love to put it on my ramdisk to make my movies open faster in ffdshow, but that's a no go :o
It's loaded just like any other DLL, and system32 is one of the default locations that Windows looks in for DLLs. Like I said, adding a folder on your ramdisk to the PATH environment variable should do the trick.

And you can't regsvr32 it because the DLL isn't meant to be registered - it's installed as a VfW codec simply by adding a registry entry.

@cweb: You need to select "Standalone, unpack files only" as the install type to get it to copy AviSynth.dll into your installation folder.

cweb

16th March 2009, 15:56

@cweb: You need to select "Standalone, unpack files only" as the install type to get it to copy AviSynth.dll into your installation folder.
I see..
well I never had any problems with it placing avisynth.dll in system32.. thanks for the info anyway.

leeperry

16th March 2009, 15:58

Like I said, adding a folder on your ramdisk to the PATH environment variable should do the trick.

And you can't regsvr32 it because the DLL isn't meant to be registered - it's installed as a VfW codec simply by adding a registry entry.
wow cool, you were right! I thought all the .DLL's had to be registered :rolleyes:

:thanks:

totozero

17th March 2009, 09:19

Say what? (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2642)

Yup, noticed it tho.
But strangely it doesn't work anymore (nor does yadif x2 framerate setting).
Got to run framedbl.dll / yadif.dll from avisynth tab in order to achieve time real doubling framerate.

Former ffds versions (ie until 08/11) are still acting normally.
Maybe I'm missing a point :sly:.

C'ya,
ToT'.

Leak

17th March 2009, 09:27

Yup, noticed it tho.
But strangely it doesn't work anymore (nor does yadif x2 framerate setting).
Well, I never used the framerate doubler, but I can assure you that YADIF's "Double framerate" option very much works here.

Have you checked "Process frames flagged as progressive"? Because that's what you definitely want for bobbing...

np: Telefon Tel Aviv - What's The Use Of Feet If You Haven't Got Legs (Fahrenheit Fair Enough)

totozero

17th March 2009, 10:01

Have you checked "Process frames flagged as progressive"? Because that's what you definitely want for bobbing...

Kudos to you.
It works now, there was no need to check this stuff with previous versions.
But it makes sense:thanks:.

C'ya,
ToT'.

lych_necross

18th March 2009, 07:36

Well, I never used the framerate doubler, but I can assure you that YADIF's "Double framerate" option very much works here.

Have you checked "Process frames flagged as progressive"? Because that's what you definitely want for bobbing...)
I tried it with "Process frames flagged as..." option and it seems to work. In MPC-HC, displaying stats does indeed show the framerate is doubling, but ffdshow and avisynth say otherwises. If playing a progressive file, would using yadif to double the framerate degrade the image quality any?

Also, maybe some devs could chime in on this question. Is it normal/safe for the build log on a project to contain warnings?

Leak

18th March 2009, 09:28

If playing a progressive file, would using yadif to double the framerate degrade the image quality any?
I'd assume so, yes - don't deinterlace if there is no need to deinterlace, as any reconstruction of the "missing lines" of both fields can only be inferior to the progressive image that's already there.

That, and since there's no extra temporal information in progressive video you'll get exact duplicates of each frame in the best case...

Also, maybe some devs could chime in on this question. Is it normal/safe for the build log on a project to contain warnings?
If you're talking about building ffdshow - yes, that's quite normal... sure, you could fix most of those by making the code a bit more verbose, but as long as it's not strictly neccessary probably nobody is going to do it...

lych_necross

19th March 2009, 08:00

Is there any chance that avisynth's wiki entry about MT will be updated to reflect this update?

Zelos

19th March 2009, 22:46

Hi,

working here on core i7-920 , 5 fps better than 2.5.7 :)
Still bugs on tweak.dll filter, seems it doesn't like mt ...

thanks for the work.

leeperry

20th March 2009, 02:43

I've got a 362*272 AVI file that crashes instantly...works fine if I disable the Avisynth filter in ffdshow :)

I guess it doesn't like pure mod2 files, when only x is mod2 it works a lot better

lych_necross

21st March 2009, 07:13

Maybe it is a problem with ffdshow's avisynth wrapper and not the actual avisynth files. Does it work with an official build of avisynth through ffdshow?

leeperry

21st March 2009, 11:42

it also crashes w/ 2.57 MT, probably having the height mod2 is not a good option...even if I resize it to 1024*768 keeping the AR, it resizes to 1024*766 and still crashes...I have to enforce 1.3333333 AR then it's fine.

lych_necross

22nd March 2009, 07:12

I'd bet money that the mod2 height issue is related to poor floating point to integer and integer to floating point conversions. The truncation of necessary values can cause unexpected and sometimes bad results. Some of those warnings will have to be reviewed.

SEt

5th April 2009, 20:27

I've made some changes to sources in the first post: now it should crash less and be a bit faster:
moved to http://forum.doom9.org/showthread.php?t=148117

BigDid

6th April 2009, 07:47

I've made some changes to sources in the first post: now it should crash less and be a bit faster:
...
Well, working fine up to now! :thanks:

Did

Jeremy Duncan

7th April 2009, 09:12

I've made some changes to sources in the first post: now it should crash less and be a bit faster:
DLL (http://www.mediafire.com/?hc3fcibfyck)
Source (http://www.mediafire.com/?nzixxzywx0x)

I updated the first post with the changes made by SEt.
The src he made was not able to be used by visual studio 2008 professional, so I fixed that and made the dll in the process.

Can't say it's faster than the previous one though, but it seems to make the frame interpolator code I tweaked look better. :D

SEt

7th April 2009, 17:53

I've only changed version number in files so they can be used with VS2005 enviroment, so just change it back if you want to use VS2008. Actually used compiler was from VS2008.
Also note that my build is statically linked and doesn't require any msvc*.dll

You should see noticeable speedup after some seeking events while playing .avs script, though there is much to improve there.

=A=RGOS

7th April 2009, 18:45

Hello,

It's work fine for me too (for Jeremy Duncan release).

An idea, Jeremy Duncan or SEt, do you have in your plan to create a centralized source code and version on sourceforge or google. ;)

Bye and many thank at all for this release ! :p

BigDid

8th April 2009, 17:58

I've only changed version number in files so they can be used with VS2005 enviroment, so just change it back if you want to use VS2008...

So this is it "VS 2008" needed and for your release, 2005 only.

I am fortunate to have had 2005 installed for another app :o

If not I would have continued to search /swap and wonder why it was not working on my new partition and windows install :angry:

A "Requirements" somewhere at the beginning would be welcome for other dummies like me :thanks:

Did

Jeremy Duncan

8th April 2009, 22:01

A "Requirements" somewhere at the beginning would be welcome for other dummies like me :thanks:

Did

I added some info to the first post to help you build it yourself.

Razorholt

10th April 2009, 18:15

I did installed the new dll in 2 other PCs just fine, but not the third one. The 2.5.8 version works fine but as soon as I copy the dll to the system32 folder I get the "Cannot load avisynth" error.

Thanks,
- Dan

BigDid

10th April 2009, 19:07

... The 2.5.8 version works fine but as soon as I copy the dll to the system32 folder I get the "Cannot load avisynth" error.
Hi,

2 posts above: http://forum.doom9.org/showthread.php?p=1271377#post1271377

Explanations: http://forum.doom9.org/showthread.php?p=1271986#post1271986

Did

Razorholt

10th April 2009, 19:38

Problem fixed. Thanks BigDid!

Adub

17th May 2009, 00:07

Well, I suppose that it's about time that I upgraded to 2.5.8. Thank you for offering this dll.

For future proofing, I have created a mirror for the necessary dlls.

For the dll only:
www.mirror.adubvideo.net/avisynth_258_mt.zip

For the dll and src:
www.mirror.adubvideo.net/avisynth258MT_src.zip

For the src, dll and MT 07, full package:
www.mirror.adubvideo.net/avisynth_258_mt_full.7z

Thanks to the authors.

Arshad07

17th May 2009, 01:45

I recently encode a small portion of an avi, and am getting an output movie splitted in 4 images

script used

LoadPlugin("RemoveGrainS.dll")
LoadPlugin("mt_masktools-26.dll")
LoadPlugin("mvtools.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("VagueDenoiser.dll")
DirectShowSource("bluray", fps=23.976, audio=false)
#deinterlace
#crop
Spline64Resize(1280,544) # Spline64 (Sharp)
MT("
backward_vec3 = last.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec2 = last.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec1 = last.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec1 = last.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec2 = last.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec3 = last.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
last.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=300,idx=1)",threads=4)

LimitedSharpenFaster(ss_x=1.5, ss_y=1.5, dest_x=last.width, dest_y=last.height, Smode=3, strength=20, radius=2, Lmode=1, wide=false, overshoot=1, edgemode=0, special=false, exborder=0)

Any help appreciated!

Jeremy Duncan

17th May 2009, 03:54

LoadPlugin("RemoveGrainS.dll")
LoadPlugin("mt_masktools-26.dll")
LoadPlugin("mvtools.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("VagueDenoiser.dll")
setmtmode(5)
DirectShowSource("bluray", fps=23.976, audio=false)
setmtmode(2)
backward_vec3 = last.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec2 = last.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec1 = last.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec1 = last.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec2 = last.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec3 = last.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
last.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=300,idx=1)
MT("
LimitedSharpenFaster(ss_x=1.5, ss_y=1.5, dest_x=last.width, dest_y=last.height, Smode=3, strength=20, radius=2, Lmode=1, wide=false, overshoot=1, edgemode=0, special=false, exborder=0)
",2)
MT("spline64resize(1280, last.height)",4)
MT("spline64resize(last.width, 544)",4, splitvertical=true)

rkalwaitis

17th May 2009, 08:46

Jeremy,

With this version of avisynth, do I still need to load the MT.dll? Or is it no longer required?

buzzqw

17th May 2009, 10:07

afaik mt.dll isn't to load BUT to put in your system32 folder

BHH

Gavino

17th May 2009, 10:31

afaik mt.dll isn't to load BUT to put in your system32 folder
No, it is the modified avisynth.dll that goes in your system32 folder.

mt.dll only needs to be loaded if using the MT (or MTi) function - if just using SetMTMode, it is not needed at all. As with any plugin, loading can be done explicitly via LoadPlugin, or implicitly by installing it in your plugins folder.

Arshad07

17th May 2009, 10:54

LoadPlugin("RemoveGrainS.dll")
LoadPlugin("mt_masktools-26.dll")
LoadPlugin("mvtools.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("VagueDenoiser.dll")
DirectShowSource("bluray", fps=23.976, audio=false)
#deinterlace
#crop
Spline64Resize(1280,544) # Spline64 (Sharp)
MT("""
backward_vec3 = last.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec2 = last.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec1 = last.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec1 = last.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec2 = last.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec3 = last.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
last.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=300,idx=1)
""",2)
LimitedSharpenFaster(ss_x=1.5, ss_y=1.5, dest_x=last.width, dest_y=last.height, Smode=3, strength=20, radius=2, Lmode=1, wide=false, overshoot=1, edgemode=0, special=false, exborder=0)

LoadPlugin("RemoveGrainS.dll")
LoadPlugin("mt_masktools-26.dll")
LoadPlugin("mvtools.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("VagueDenoiser.dll")
setmtmode(5)
DirectShowSource("bluray", fps=23.976, audio=false)
setmtmode(2)
backward_vec3 = last.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec2 = last.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec1 = last.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec1 = last.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec2 = last.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec3 = last.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
last.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=300,idx=1)
setmtmode(1)
LimitedSharpenFaster(ss_x=1.5, ss_y=1.5, dest_x=last.width, dest_y=last.height, Smode=3, strength=20, radius=2, Lmode=1, wide=false, overshoot=1, edgemode=0, special=false, exborder=0)
setmtmode(2)
Spline64Resize(1280,544) # Spline64 (Sharp)

First one still result in two screens. Whereas the second one works perfectly fine. Thanks a lot mate.

Without MT in my script, it was running at 2 fps with 15% CPU Utilization and now with MT it's running at nearly 8 fps with 95 % CPU Utilization....
what an improvement i must say. Thanks again

http://i39.tinypic.com/zivnuo.png

Arshad07

17th May 2009, 12:05

^ It works yea, but after 10/30 %, x264 crashes :confused:

Arshad07

17th May 2009, 15:57

the error for that ^

http://i40.tinypic.com/23usumd.png

http://i44.tinypic.com/2v8qptl.png

Sude

17th May 2009, 16:52

http://i44.tinypic.com/2v8qptl.png
you should be using mt_masktools-25.dll

mt_masktools-25.dll -> avisynth 2.5.x
mt_masktools-26.dll -> avisynth 2.6.x

Arshad07

17th May 2009, 17:45

you should be using mt_masktools-25.dll

mt_masktools-25.dll -> avisynth 2.5.x
mt_masktools-26.dll -> avisynth 2.6.x

crashed again :(

http://i42.tinypic.com/2u5xu2g.png

rkalwaitis

17th May 2009, 21:51

Arshad07

17th May 2009, 22:08

I have the same problem with Megui and this version of avisynth.dll I never noticed I was loading both the 25 and 26 version. However it did not always make my x264 stop working. Im gonna check it out and see what happens.

Mine keeps stopping at different % :(

I can not see how the vaguedenoise is used in the above scripts....a little help please :)

VagueDenoiser(threshold=0.8, method=1, nsteps=6, chromaT=0.8)

More info here (http://avisynth.org.ru/vague/vaguedenoiser.html)

Jeremy Duncan

17th May 2009, 22:30

LoadPlugin("RemoveGrainS.dll")
LoadPlugin("mt_masktools-25.dll")
LoadPlugin("mvtools.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("VagueDenoiser.dll")
setmtmode(5)
DirectShowSource("bluray", fps=23.976, audio=false)
setmtmode(2)
backward_vec3 = last.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec2 = last.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
backward_vec1 = last.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec1 = last.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec2 = last.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=2, sharp=1, idx = 1)
forward_vec3 = last.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=2, sharp=1, idx = 1)
last.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=300,idx=1)
MT("
LimitedSharpenFaster(ss_x=1.5, ss_y=1.5, dest_x=last.width, dest_y=last.height, Smode=3, strength=20, radius=2, Lmode=1, wide=false, overshoot=1, edgemode=0, special=false, exborder=0)
",4)
MT("spline64resize(1280, last.height)",4)
MT("spline64resize(last.width, 544)",4, splitvertical=true)

Try this code Arshad. And install the 2008 c++ redistributable I linked to in the first post.

"I have the same problem with Megui and this version of avisynth.dll I never noticed I was loading both the 25 and 26 version." - Rkwaltis

Remove the 26 version tfrom the plugins folder.

Arshad07

17th May 2009, 23:03

Try this code Arshad. And install the 2008 c++ redistributable I linked to in the first post.

Right now, am updating my Vista with SP2. I'll wait for it to finish to try it out. Thanks a lot mate

Arshad07

17th May 2009, 23:10

Btw, u edited ur post with reason stating ''changed mt to use 2 cores not 4''. Can u make it for 4 cores please. TY

J_Darnley

18th May 2009, 01:20

Why aren't you using MVTools2? It is much more thread-safe then the v1 series.

Jeremy Duncan

18th May 2009, 06:47

Why aren't you using MVTools2? It is much more thread-safe then the v1 series.

This is true. Try this with mvtools2:

LoadPlugin("RemoveGrainSSE3.dll")
LoadPlugin("sse2tools.dll")
LoadPlugin("mt_masktools-25.dll")
LoadPlugin("mvtools2.dll")
setmtmode(5)
DirectShowSource("bluray", fps=23.976, audio=false)
setmtmode(2)
Interleaved2Planar() # convert clip to planar
super = MSuper(planar=true)
bv1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
fv1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
bv2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
fv2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
bv3 = MAnalyse(super, isb = true, delta = 3, overlap=4)
fv3 = MAnalyse(super, isb = false, delta = 3, overlap=4)
MDegrain3(super,bv1,fv1,bv2,fv2,bv3,fv3,thSAD=400,planar=true)
Planar2Interleaved() # convert back to normal interleave YUY2
MT("
LimitedSharpenFaster(ss_x=1.5, ss_y=1.5, dest_x=last.width, dest_y=last.height, Smode=3, strength=20, radius=2, Lmode=1, wide=false, overshoot=1, edgemode=0, special=false, exborder=0)
",4)
MT("spline64resize(1280, last.height)",4)
MT("spline64resize(last.width, 544)",4, splitvertical=true)

mvtools2 (http://avisynth.org.ru/mvtools/mvtools-v2.4.2.zip)

Get ssetools and removegrains from removegrain 0.9: link (http://home.pages.at/kassandro/RemoveGrain/RemoveGrain.zip)

Arshad07

18th May 2009, 11:35

Will give it a try after my damn pc would get updated to SP2. Taking ages man :(

Btw, can u upload '' mt_masktools-25.dll '' on a hosting server please. I searched a lot, but coudnt find it. :(

J_Darnley

18th May 2009, 13:37

It comes in the masktools-v2 packages that you download. They are available plus the dlls only, here: http://manao4.free.fr/ Which is the second result from Google when you search for masktools

Arshad07

18th May 2009, 15:59

It comes in the masktools-v2 packages that you download. They are available plus the dlls only, here: http://manao4.free.fr/ Which is the second result from Google when you search for masktools

is it this one: '' mt_masktools2.dll '' ?

Arshad07

18th May 2009, 18:44

It works FINALLY!!! Thanks a lot to ppl who have contributed !! Appreciate it!

Just some screens:-

Before V/s After

http://i42.tinypic.com/10z253o.png
http://i41.tinypic.com/25tvz1x.png

Arshad07

18th May 2009, 19:04

Again guys, when i close the previewer window megui crashes :(

http://i44.tinypic.com/52i6jb.png

What am i doing wrong? :confused:

Arshad07

18th May 2009, 21:19

Ok, sorry for multiple consecutive posts about this issue....but i got it to work. I had to demux the video from the mkv, then create a dga file from the VC-1 i got. Then it works fine but slooooooooooooow :(

@ Jeremy Duncan

Why MDegrain3 and not MVDegrain3 ? :confused: What's the difference?

Jeremy Duncan

19th May 2009, 03:08

Arshad07,

I tried a few encodes. First I demuxed the audio from video using tsmuxer. I only used the video in the encoding. I had to switch where the filters went. After I used tsmuxer I used dgsplit to rip 100MB and used the extension on the tsmuxed video file on the dgsplit file.
Loadplugins
setmtmode(5)
DirectShowSource
MT("
LimitedSharpenFaster
",2)
spline64resize # this wasn't using mt and it worked fine
Setmtmode(2)
mvtools code

I could see the part of the video I cliped using dgsplit was not entirely in the encoded version. i was missing around 30 seconds of the minute I prepared for encoding tests. I could not get the whole 60 seconds regardless of how i tried various scripts.
I don't encode blu ray but I think maybe directshowsource can't handle the .mpv I was using with it.
So what I'm saying is you may encode and eith er see a ugly picture because the filters were not stacked right, or you may not see the whole movie only half of it.

mdegrain is in mvtools2, mvdegrain is in mvtools.

Arshad07

19th May 2009, 09:12

Why aren't you using MVTools2? It is much more thread-safe then the v1 series.

and slower :p

Arshad07

19th May 2009, 14:57

@Jeremy Duncan

Whats better in your opinion, MT or SETMODE?

BigDid

19th May 2009, 20:45

...
Whats better in your opinion, MT or SETMODE?
Hi,

You can get infos at the source:
http://avisynth.org/mediawiki/MT_support_page

Did

lych_necross

20th May 2009, 07:15

Whether MT or SetMTMode is better depends greatly on what the script is trying to do. Try using one, then the other, and finally use what works best. SetMTMode is probably safer, but a little slower in some cases. Like BigDid said, read the info and experiment.

Adub

21st May 2009, 18:16

and slower :p

I beg to differ. With it's increased threading stability, you can run v2 faster than you can v1 when using functions such as SetMTMode.

BigDid

21st May 2009, 19:28

Hi Merlin,

http://forum.doom9.org/showthread.php?p=1286353#post1286353
I did not had the opportunity to thank you for mirroring the MT 2.58 files, also to Jeremy for starting the thread and to SET for his alternate dll :)

It seems more and more people are using the MT 2.58 without always reading the doc first :rolleyes:

Did

Adub

22nd May 2009, 18:55

@BigDid
You are more than welcome! Mirroring the files is the least I could do.

Arshad07

30th May 2009, 03:23

@ Jeremy Duncan

Is there any way to increase the speed of this script, cos its not using my cores that much; only like 40% [ with XviD ]

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\SSE2Tools.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\MT.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrainSSE3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrainSSE2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrain.dll")
Load_Stdcall_Plugin("C:\Program Files (x86)\megui\tools\yadif\yadif.dll")
setmtmode(5)
DGDecode_mpeg2source("VZ.d2v", cpu=4, info=3)
ColorMatrix(hints=true, interlaced=true, threads=4)
Yadif(Mode=1,Order=1)
srestore(frate=25,omode=6,dmode=4,blocks=16,chroma=true)
Crop( 4, 52, -2, -50)
Spline64Resize(576,240)
setmtmode(2)
MT("""
super = MSuper()
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=2)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=2)
MDegrain1( super, backward_vec2,forward_vec2,thSAD=400)
LimitedSharpenFaster(ss_x=1.5, ss_y=1.5, dest_x=last.width, dest_y=last.height, Smode=3, strength=40, radius=2, Lmode=1, wide=false, overshoot=1,edgemode=0, special=false, exborder=0)""",4)

Delerue

31st May 2009, 02:17

@ Jeremy Duncan

Is there any way to increase the speed of this script, cos its not using my cores that much; only like 40% [ with XviD ]

Increase the number of threads. I mean, change the '4' in the end of the script to something like 6 or 8. Here, with my dual-core CPU, '3' is the magic number. ;)

nuhi

31st May 2009, 11:11

Increase the number of threads. I mean, change the '4' in the end of the script to something like 6 or 8. Here, with my dual-core CPU, '3' is the magic number. ;)
Problem with a bigger number of threads than cores is when a scene gets more demanding 2 cores won't be able to process 3 threads and it will start slowing down and loosing frames.
You should find a demanding moving scene when testing CPU usage.
After a lot of testing best is SetMTMode(2).
Then focus on setting up the actual filters parameters.

Arshad07

31st May 2009, 11:18

Anyone could check the sample, the video is messed up using SetMtMode and MT

http://www.sendspace.com/file/s1q5m1

carlmart

31st May 2009, 12:50

I tried seesaw, lsf, spresso, and mvtools v2 frame doubler.

What would be a syntax example for an MT script using lsfmod?

Something like this would work?

SetMTmode(2,2)
directshowsource("file.avi")
lsfmod(smode=5)

Arshad07

31st May 2009, 13:02

What would be a syntax example for an MT script using lsfmod?

Something like this would work?

SetMtMode(2,2)
Directshowsource(avi)
LimitedSharpenFaster(strength=50)

Of course, lsf requires removegrain :)

carlmart

31st May 2009, 13:13

SetMtMode(2,2)
Directshowsource(avi)
LimitedSharpenFaster(strength=50)

Of course, lsf requires removegrain :)

Why LimitedSharpenFaster instead of lsfmod?

I am a beginner in this sharpening matters, so I would like to try different ways and learning about them.

Delerue

31st May 2009, 20:40

Problem with a bigger number of threads than cores is when a scene gets more demanding 2 cores won't be able to process 3 threads and it will start slowing down and loosing frames.

Hmmm... Weird, because here the problem with 2 threads using a dual-core CPU is that AviSynth (with a MVTools script) can't load the CPU entirely (i.e.: not 100%), slowing down videos with large resolution. With 3 threads I can get a full load and better performance. Maybe we need another opinion here, ahn? :)

BigDid

31st May 2009, 21:05

...With 3 threads I can get a full load and better performance. Maybe we need another opinion here, ahn? :)
Hi,

3 threads for
- the setmtmode() like (1,3)
- for the xvid encoder
- for boths?

I have 2 cores also, use defaut (0) or 2 cores and I am willing to try :)

Did

Adub

31st May 2009, 22:22

Why LimitedSharpenFaster instead of lsfmod?

I am a beginner in this sharpening matters, so I would like to try different ways and learning about them.

You can use LSFmod in the same way. LSFmod is a little newer in comparison to LimitedSharpenFaster. It has a couple of bug fixes, and more features. Just replace the LimitedSharpenFaster line with your own LSFmod line and you should be fine.

Delerue

1st June 2009, 00:22

Hi,

3 threads for
- the setmtmode() like (1,3)
- for the xvid encoder
- for boths?

I have 2 cores also, use defaut (0) or 2 cores and I am willing to try :)

Did

I mean 'setMTMode'. I don't know anything about the Xvid encoder, hehehe.

Inspector.Gadget

1st June 2009, 02:46

BigDid

1st June 2009, 03:21

I mean 'setMTMode'. I don't know anything about the Xvid encoder, hehehe.
Hi,

1st test, simple script no MVtools, 2Cpu utilization between 50 to 80%
Film with 176290 frames
setmtmode(1,0) 1h42mn
setmtmode(1,3) 1h40mn

Did

Adub

1st June 2009, 05:37

If I'm using only the following in a script, do I get any benefit out of using any sort of multithreading in Avisynth itself? How would I do it? Since DGMPGDecNV runs on the GPU, I assume that it can't be multithreaded using MT or SetMTMode (unless anyone knows to the contrary). Suggestions? Thanks!

GPU Decoding is already so darn fast anyways for mpeg2 you hardly need multithreading. Besides, I don't think neuron2's decoders play nice with multithreading. Not that that is his fault, but that the way the decoder interacts with the gpu would not like asynchronous access.

squid_80

1st June 2009, 09:51

GPU Decoding is already so darn fast anyways for mpeg2 you hardly need multithreading.
Uh, what? Unless you've got a really slow CPU, MPEG2 GPU decoding is always slower than even single-threaded software decoding.

Adub

1st June 2009, 20:21

kemuri-_9

1st June 2009, 21:53

Wait seriously? I don't have an Nvidia graphics card (yet) but if that is the case, then what is the whole point of neuron2's DGMPGDecNV then? Sure it offloads cpu usage, but if it is in fact slower to decode mpeg2, then your encodes should be slower, not faster.

generally most scripts and encoding settings people use don't process faster than what the gpu versions decode at.
so it does help with encoding as you generally aren't bottlenecking at the decoding offloaded to the GPU.
the processing power (however minimal) that was used to decode on the cpu is now available for use.

and another note, DGMPGDecNV also can do some deinterlacing on the GPU as well.

fantasyl

3rd June 2009, 11:18

:thanks: to jeremy, seraphy and all the other for the modified avisynth.dll

Works perfectly on windows7 build 7077 and solved my day while trying to use avisynth with mvtools2 and SetMTMode.

I have 2 pc, almost identical configuration (q6600, same mboard, ram, only difference being the ati hd2600 and nvidia 8600 video board). One (the nvidia based) was working perfectly fine with the avisynth.dll found in the mt0.7 package, while the ATI based pc crashed every time I tried using avisynth with the modified avisynth.dll.
Same software was working fine on the very same pc (ATI based) and a Vista SP1 partition....
So there started my journey installing in windows7 various avisynth versions (2.5.x), video drivers, avisynth.dll (from different mt0.x packages), ffdshow builds.....

Nothing worked.......as soon as I tried to use the MT avisynth.dll in Win7 the player (mpc-hc , bsplayer, ecc.) crashed.......

This until I reinstalled (for the n-th time) avisynth 2.5.8 and used the MT avisynth.dll from the first post.......from that moment all is working fine and stable!!

Again, THANKS.....I hope this could help someone using windows 7 with avisynth crashing due to avisynth.dll ;)

burfadel

3rd June 2009, 13:57

What would be good is if someone helped neuron2 out and update the dgdecode filter so support the instructions it doesn't support (I know the decoder is based on an old mpeg2 decoder) and multithread it. That would be a noticeable improvement for encoding, and very noticeable for HDTV Mpeg2 encoding and avisynth editing :)

onesloth

11th June 2009, 18:23

BigDid

12th June 2009, 00:46

Is the avisynth.dll from post #1 (http://forum.doom9.org/showthread.php?p=1246719#post1246719) the most recent (and stable) version? Do I need to replace my old 2.5.7.5 mt.dll with the fourth version of mt.dll in post #4 (http://forum.doom9.org/showthread.php?p=1250271#post1250271)?
Hi,

This trhread is about different builds of non-official MT releases for avisynth 2.58. It is recent but I will not qualify it as "stable".
The 2 links you have quoted are from Jeremy Duncan and I will let him clear the confusion if he wants.
You may be interested to know that there also is a build from SET included in a set available for download from Adub; see:
http://forum.doom9.org/showthread.php?p=1286353#post1286353

Did

onesloth

12th June 2009, 01:16

Thanks. I installed the Jeremy Duncan's avisynth.dll and mt.dll and everything seems to be working fine. Does anyone have any comments about any significant differences between Jeremy's and SET's builds?

SEt

12th June 2009, 01:35

Mine doesn't require any msvc*.dll, otherwise they should be the same.

tedkunich

16th June 2009, 17:55

Mine doesn't require any msvc*.dll, otherwise they should be the same.

SEt,

Any idea why Mdegrain would crash repeatedly on a SD source (VHS capture) using any of the setMTmodes? Using the latest MVtools. CPU is an AMD quad core, 4G ram, XP OS. If I do not use setMTmode at all, it will process the entire clip (30 min) without issues: if I enable MT, it crashes anywhere from 5% to 25% into the encode, every single time.

T

BigDid

16th June 2009, 21:27

... If I do not use setMTmode at all, it will process the entire clip (30 min) without issues: if I enable MT, it crashes anywhere from 5% to 25% into the encode, every single time.
Hi Ted,

If you take a look around the avisynth sections, you will find some issues related. Mvtools and Mdegrain are very sensitive to MT (or MT is very sensitive to recursive scripts).

When having problems with MT(), best (but slower) solution is to try some of the Setmtmode() 1 to 4; 1 being the quickest and less compatible, 4 being the slowest and most compatible; 5 and 6 being there to include some non-compatible commands in that kind of script.

You could also try Jeremy build instead of Set ?

I have read that the Avisynth2.6 should integrate/include some/most of the MT stuff...

Did

tedkunich

17th June 2009, 05:59

Hi Ted,

If you take a look around the avisynth sections, you will find some issues related. Mvtools and Mdegrain are very sensitive to MT (or MT is very sensitive to recursive scripts).

When having problems with MT(), best (but slower) solution is to try some of the Setmtmode() 1 to 4; 1 being the quickest and less compatible, 4 being the slowest and most compatible; 5 and 6 being there to include some non-compatible commands in that kind of script.

You could also try Jeremy build instead of Set ?

I have read that the Avisynth2.6 should integrate/include some/most of the MT stuff...

Did

Did,

I have tried all the combinations - even leaving it in mode 5... it ALWAYS crashes. Interestingly, I can process some HDV footage (1440x1080) without problems - something about the the SD resolution.

SEt's build seemingly worked on my HDV footage, but it would also crash on the SD stuff. What prompted my initial query was that I am also experiencing the same crash with the original MT build. Not sure if this is an MT problem or an MVTools problem.

Franky, I would not touch anything that Jerremy built - from following his hacks at it, it was obvious that he had no clue what he was doing - he has his own reasons/uses for MT avisynth and realtime ffdshow processing is not something that I care about. I did try one of his builds and it would crash almost instantly, so I never bothered with his builds since.

T

tedkunich

17th June 2009, 07:06

Did,

I have tried all the combinations - even leaving it in mode 5... it ALWAYS crashes. Interestingly, I can process some HDV footage (1440x1080) without problems - something about the the SD resolution.

SEt's build seemingly worked on my HDV footage, but it would also crash on the SD stuff. What prompted my initial query was that I am also experiencing the same crash with the original MT build. Not sure if this is an MT problem or an MVTools problem.

Franky, I would not touch anything that Jerremy built - from following his hacks at it, it was obvious that he had no clue what he was doing - he has his own reasons/uses for MT avisynth and realtime ffdshow processing is not something that I care about. I did try one of his builds and it would crash almost instantly, so I never bothered with his builds since.

T

Hmmm.... just did an experiment... my HDV source had no sound, while the SD source does (and I selected no compression - PCM in Vdub). Placed a killaudio() command right after my source and am running the script in MT mode and it is is currently cranking along at 50fps and is about a third the way through the source. I'm wondering if there is a file size limit with the AVI container or is there some bug in MT in regards to audio? The source is 15G...

SetMemoryMax(1024)
setmtmode(5,4)

AVISource("E:\tapes\nessa.avi")
killaudio()
setmtmode(2)

super = MSuper(pel=2, sharp=1)
bvec1 = MAnalyse(super, isb = true, delta = 1)
fvec1 = MAnalyse(super, isb = false, delta = 1)
bvec2 = MAnalyse(super, isb = true, delta = 2)
fvec2 = MAnalyse(super, isb = false, delta = 2)
#bvec3 = MAnalyse(super, isb = true, delta = 3)
#fvec3 = MAnalyse(super, isb = false, delta = 3)
MDegrain2(super, bvec1,fvec1,bvec2,fvec2,thSAD=400)

UPDATE: Completed the above script without problems, plus added some LSF and some other filters and it completed as well. Conclusion - there is some issue with MT and sound? Easy enough of a workaround but still a PITA!

SEt

17th June 2009, 17:15

tedkunich

17th June 2009, 19:13

MT mod for AviSynth is a dirty hack. It's a wonder that it works so well and crashes so rarely. It will crash due to its design. In general, if you experience crashes after some working period - try reducing number of threads (for example - from 8 to 6) and play with SetMemoryMax (the more is not always the better even if you have plenty of free system memory).

EEDI2 uses outdated OpenMP and crashes because of it - can be solved by rebuilding the sources with new libraries. As for MVTools - i haven't looked into the problem yet, but version 2.3.1 seems to work well while both 2.4.1 and 2.4.2 crash.

SEt,

It appears to be related to having audio - killing the audio right after the source filter allows MT to handle the processing task without problems, keeping the audio in avisynth and passing it on to the encoder causes the problem (telling Vdub to ignore the audio stream has no effect).

Ted

BigDid

17th June 2009, 20:40

Hi,

The audio "connection" is interesting, I usually don't process audio in avisynth (Xvid encode via vdub with avs script mainly, audio muxed afterward) so it could explain why I have so few problems -except Mdegrain-; will check if i use MVtools 2.31 or other rev. Having 2gig of emory I set memorymax to 512 or 640, works well :)

Not confirmed but MCtemporaldenoise may work better than Mdegrain with MT, slower and less ease of use though...

Did

SEt

17th June 2009, 21:15

I never process audio with AviSynth, so can't say what is going wrong with it. Probably no one bothered to test multi-threaded cache (that is used with MT mode 1-5) with it. Different SetMemoryMax might help.

Jeremy Duncan

20th June 2009, 14:08

I would not touch anything that Jerremy built ... I did try one of his builds and it would crash almost instantly, so I never bothered with his builds since.

T

I updated the first post with a list of errors and how to fix them as well as the dll's needed to run the plugin without crashing.

leeperry

21st June 2009, 23:10

Franky, I would not touch anything that Jeremy built - from following his hacks at it, it was obvious that he had no clue what he was doing - he has his own reasons/uses for MT avisynth and realtime ffdshow processing is not something that I care about.
well, build your own then...instead of bashing other ppl's work. I use it in ffdshow w/ LSF+GrainFactory3+ddcc, it works like a champ. Well done Jeremy!

chipzoller

28th June 2009, 18:03

Arshad07

28th June 2009, 22:48

What about MT + 64-bit OS in loading sources through MPEG2Source? I read on the forums the x64 plugin was out of date. Can someone post script examples of a scenario like this, either with or without 64-bit OS?

You can still use 32-bit s/ws on a 64-bit platform ( what i'm doing right now ). Thats the best idea i think. Don't complicate your life using 64-bit version of avisynth.......:)

chipzoller

28th June 2009, 22:56

I know you CAN use it, but I wanted to see what sort of speed gains I could get by using native 64-bit apps especially since my filter chains usually aren't very complex, just mpeg2source, some degrainmedian, IVTC and resize...

Arshad07

29th June 2009, 00:15

kemuri-_9

29th June 2009, 00:19

from what i've heard, most of the time a program sees up to a 10% performance boost going to x64 from x86,
granted it's optimized on an equal level as the x86 version.

chipzoller

29th June 2009, 00:31

@ Arshad07

No doubt, especially since I followed many of your posts in a thread about MT in avisynth a while back and know you struggled.

@ kemuri-_9

This is what I understand, although since there seems to be so much rigmarole that currently has to go into getting MT to work in avisynth to work in the first place, or avisynth64, I wonder if that performance boost is even worth it. I understand the next version of Avisynth is supposed to officially support MT and 64-bit?

kemuri-_9

29th June 2009, 01:30

2.6 has MT support out of the box,
and from what i remember reading some time ago,
some 2.6.x release will have native x64 support.

Jeremy Duncan

29th June 2009, 08:54

I tried to get the source to be 64 bit using the sw I used for the current avisynth.dll.
I got the sw I use to make the avisynth.dll all setup and 64 bit compliant, but the source itself wasn't able to be made 64 bit.
So many lines need to be rewritten, so many bits and pieces it's not funny.
And looking at that I said to myself that I couldn't do that.

If the source had been made 64 bit compliant then I could run it through the sw and make one, but it's only 32 bit compliant. :)

SEt

29th June 2009, 15:14

I can port it to 64 bit, but it will take "some" time and the most important thing is i think it's not worth it now. To regular user "64 bit" is just a cool number. If it's why you want it - don't worry, large part of avisynth is already 64/128 bit (MMX/SSE) and there is no any x86 hardware now that supports more. The most time consuming parts are written in MMX/SSE, so even if you'll see 10% speedup for C++ part it will be <1% overall.

The main advantage of 64 bit is addressing space. Usual for 32 bit programs 2Gb indeed seems to become not enough for avisynth now, but it's not due to actual memory demand but due to inefficiency of multithreading caching. If you want to see good speedup in avisynth - i'd say it's in better threading, not in 64 bit.

leeperry

30th June 2009, 01:19

I fail to understand why(as I had tried lot of files already), but some x264+AC3 files crash ffdshow instantly w/ your 2.58 avisynth.dll and work fine w/ 2.57(they are 1280*720 or 1920*1080, so no funky mod2 or anything)...maybe some of my scripts don't like 2.58, or indeed some compiling problem :o

SEt

30th June 2009, 02:25

There are some threading problems in posted builds that i've fixed already. Will post it a bit later (need to sleep too >_>). I've also modified ffdshow to be somewhat usable with SetMTMode (still crashes sometimes on shutdown).

Can't say that everything is fixed, so post the files and actions to reproduce the crashes if you want them to be fixed by someone.

leeperry

30th June 2009, 03:25

ok, sounds great! you got PM :)

lych_necross

30th June 2009, 07:13

Jeremy Duncan

2nd July 2009, 10:55

I updated the first post with new dll's: avisynth.dll and mt.dll.

I used Set's src, but made it in visual studio 2008 with totally different settings.
:D

Runs like a champ. Try them out. Don't use avisynth.dll without using the mt.dll I made though.

The src is visual studio 2008 compliant now.

Efenstor

2nd July 2009, 13:50

Thanks, Jeremy! This is blazing cool!

Gavino

2nd July 2009, 13:50

Jeremy, What is the purpose of this release when we already have SEt's version? :confused:
What 'added value' does it bring?

Perhaps the answer is in the changed settings you mention. If so, could you please explain what effect these have and under what circumstances I should use your version instead of SEt's?
The src is tricky, you build a dll then test it and it runs awful, tehn you build it again and test it and it runs beautifully.
So if you build it and it runs awful, just delete your build and startup visual studio without messing around with the src and build another one.
keep doing this rebuilding until you get a good one.
it's weird I know, but now you know what to do if you build it and it's ugly. :)
Hmm, does this not suggest that you might be doing something wrong?
I know you mean well, but can we really have confidence in software you release in these conditions?

SEt

2nd July 2009, 17:35

I don't see see the point of rebuilding too - as i said earlier, i use the same 2008 compiler for building so of course sources are already 2008 compliant. Converting project 2005<->2008 is trivial - just open .sln and .vcproj in notepad and change version.

As for practical use - you can use either version. There is no difference other that my version is smaller and doesn't require installing VS runtime. The speed is the same too (could be said that my version is faster, but the difference is so small that you can see it only in profiler).

Jeremy Duncan, your first post is misleading - your build doesn't interact with msvcp71 or msvcr71.dll at all, so if something requires them (or crashes as you write) - it's probably external filters, not the avisynth.dll/mt.dll themselves. Also, if it's not for viruses or serious hardware problems rebuilding the same source always produce the same binary no matter how many times you build or reopen VS (files will be different only in some bytes in header that represent time of the build and aren't used anywhere).

Jeremy Duncan

2nd July 2009, 20:55

Jeremy, What is the purpose of this release when we already have SEt's version? :confused:
What 'added value' does it bring?

Set's version crashed mpc. I use ffdshow in mpc, both clsid's version.

When I got mpc to open the audio and video were all garbled.

When I tried again (as I just kept closing mpc and reopening it), it worked.

Many different times I opened Set's avisynth.dll and mt and the video and audio were all messed up.
Mind you, I play the movie from the disk so I have to get to the root menu.

Now, with my build using set's src I have no garbled screen or audio when I open the movie using mpc.
_____________________________________
And as to why one build is different than the other.
Yes, the size is the same, but one build is different than the other.
Why is this? I don't know.
The os was a clean build just for that day to build the dll's, so no malware.
_____________________________________

Set,

I never read you switched the scr to be visual studio 2008 compliant. In fact the MT was not able to be made using your src settings for mt. I had to munkey around and got it to go. :D

______________________________________

"Jeremy Duncan, your first post is misleading - your build doesn't interact with msvcp71 or msvcr71.dll at all"

I haven't tested if I did or didn't need them yet.
I used different project settings, I told you this already.

SEt

2nd July 2009, 21:23

Jeremy Duncan

3rd July 2009, 00:06

Ew, i'm changing my option from "either version can be used" to "better not use Jeremy Duncan's version" as it seems you have serious problems with your system stability (again, possibly hardware related).

:D

Ok man.

But if you want to read more I will oblige.
When I said it was different I meant it worked like your avisynth.dll and mt.dll. meaning the picture was all garbled and audio was choppy.

Remaking it did away with this.

To be honest I wondered if this was a trick in the src to make one dll compile good and another like yours. Sort of like a....what do you call it. A "Puzzle", that's it. I wondered if the src was designed as a puzzle so one compile runs smooth and another runs like yours.

There is nothing wrong with my hw or sw. I had no maleware either. So, no offense to you or anybody. I just couldn't advise others ot use your compile when I had such problems with it so I made my own and one that worked for me, and others i hope.
Thank you for the src Mr.SEt. :)

Efenstor

3rd July 2009, 08:18

Installed all DLL's and redistributables and getting the error with the new build (with VirtualDub 1.9.2): An application has made an attempt to load the C runtime library incorrectly.

Jeremy Duncan

3rd July 2009, 15:59

Installed all DLL's and redistributables and getting the error with the new build (with VirtualDub 1.9.2): An application has made an attempt to load the C runtime library incorrectly.

I made new avisynth and mt dll's. They are in the first post.

I reformated my pc then installed vista 32 bit home again.
I then got all my updates for windows os.
I got all the newest drivers: soundcard, videocard, nic, mobo
After all this and there was no more updates i then installed visual studio 2008 pro trial and the sdk.

I tell you there was no possibility for any type of malware to be installed.

Then I made the dll using the src in the first post and one build operated differently than the other.
Meaning one played smooth, the other choppy, the dll's I made i mean.

So I made sure to grab the ones that played with no problem and saved the src and uploaded them and here I am talking to yuo right now. :D

I am sure nothing is wrong with my pc. However I am sure some pc guru would know for sure, but I do not. I am not a pc hw guru. :)

Have fun trying out my new mt and avisynth bulds.

Gavino

3rd July 2009, 16:53

can we really have confidence in software you release in these conditions?
Then I made the dll using the src in the first post and one build operated differently than the other.
Meaning one played smooth, the other choppy, the dll's I made i mean.
I think that answers my question. Thank you.

Jeremy Duncan

3rd July 2009, 17:06

gavino,

I wonder if people will try it out and report their results? No problems then maybe you can put more confidence in it.
Myself, i'm waiting for this. I keep checking the site to see what new results people report. I hope nobody makes false reports though.
Inparticular I'm waiting for leeparry to tell me how it did. :)

leeperry

3rd July 2009, 19:02

Inparticular I'm waiting for leeparry to tell me how it did. :)
lol the name is leeperry :D

well, honestly, man I really appreciate your efforts! I really do :cool:

but SEt's build works fine so far for me, if I start getting pixelated garbage like you did...I'll drop him a PM w/ a sample, my script and the hope that at some point he will have time to look into it :)

and, unlike some others here, I can't blame you for being a Didée fanboy...his scripts have completely blown up my HTPC experience up in the sky! :eek:

Jeremy Duncan

6th July 2009, 02:36

I updated the first post yesterday. I found that the problem I was having with the dlls was not in compiling them, but in putting them into their folder.
If I dragged and dropped them into either the system32 or plugins folder there was a chance the video and audio may be ugly.
If I dragged them out from the system32 and plugins folder, then put them back into those folders the audio video problem would go away.
Also if the audio and video was ugly after the plugins were put into the system32 folder or plugins folder, simply rebooting fixed the problem with my just leaving the plugins in those folders.

So all this time I thought it was a compiling problem but it wasn't. Sorry for the confusion.

Edit,
I tried to unregister and delete the msvcp71 and msvcr71 dll's but I don't know how so I can't say if they are needed or not.

Efenstor

6th July 2009, 15:58

Yes, the new build works OK.:D

Jeremy Duncan

9th July 2009, 11:06

I updated the mt and avisynth dll's and added a link to the ffdshow.ax SEt made.
I updated the notes in the first post as well. :D

ser2

9th July 2009, 12:51

Version dated july 9, 2009 works great! Thank you, Jeremy!
But what's about ffdshow? I don't understand.

Jeremy Duncan

9th July 2009, 22:44

Version dated july 9, 2009 works great! Thank you, Jeremy!
But what's about ffdshow? I don't understand.

SEt fixed the timestamps I think he called it, in ffdshow.ax.

So if you use the regular ffdshow without adding SEt's ffdshow.ax, skipping to different parts of the video results in a stuck frame with new audio of the part you skipped too. This is using the mvtools2 frame interpolation.

hajj_3

10th July 2009, 09:44

Jeremy Duncan

12th July 2009, 09:48

an interesting thread indeed:)

what kind of speed up will people see when using with xvid 1.2.2 or x264 when using a quadcore and 4gb ram?

I hope lots of you programmers can help him out, a stable multithreaded avisynth would be great.

I'm sorry it took me a few days to respond. I was busy and made a new avisynth and mt which I just put in the first post.
below is my tests done:

___________________________

july 12 archived version (my mt and avisynth builds)
13 minutes 26 seconds

Size of encoded video
Size: 71,027,906
Size on disk: 71,028,736

Frames per second
First pass: 7.29
Second pass: 1.77
____________________________________________

july 12 custom version (my mt and avisynth builds)
13 minutes 24 seconds

Size of encoded video
Size: 71,039,639
Size on disk: 71,041,024

Frames per second
First pass: 7.15
Second pass: 1.78
____________________________________________

SEt's July 12 version (SEt's mt and avisynth builds)
13 minutes 23 seconds

Size of encoded video
Size: 71,032,981
Size on disk: 71,036,928

Frames per second
First pass: 7.24
Second pass: 1.78

_________________________________

Tsp's version (Tsp's mt and avisynth builds)
13 minutes 24 seconds

Size of encoded video
Size: 71,045,371 bytes
Size on disk: 71,049,216

Frames per second
First pass: 7.24
Second pass: 1.77

_________________________________
video sample used
http://www.mediafire.com/?ywjmlttweuy

dgindex, used to index the mpv file
http://neuron2.net/dgmpgdec/dgmpgdec155.zip

megui, used to encode
http://sourceforge.net/project/downloading.php?group_id=156112&filename=megui-0_3_1_1028.exe&a=55118057

avs file used for mine and SEt's:
loadplugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
mpeg2source("C:\Documents and Settings\Eyaaw\Desktop\Kiss of the Dragon\Kiss of the Dragon.d2v")
assumefps(24000,1001)
Spline64Resize(1920,1072)

avsfile used for Tsp's:
loadplugin("C:\Program Files\AviSynth 2.5\plugins\newresize.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
mpeg2source("C:\Documents and Settings\Eyaaw\Desktop\Kiss of the Dragon\Kiss of the Dragon.d2v")
assumefps(24000,1001)
Spline64Resize(1920,1072)
__________________________________

When I took the picture of the taskmanager I played the unprocessed mpv sample with the settings below.

FFDshow settings used
Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Avisynth tab checked
YV12 checked,
Add FFdshow Video source Unchecked,
3:2 Pulldown box: Ignore Pulldown checked,
check Buffer back/Ahead: 9, 9

setmtmode(5)
Last=ffdshow_source()
setmtmode(2)
LimitedSharpenFaster(strength=11)
LimitedSharpenFaster(strength=11)
distributor()

Queue & Output tab
Queue output samples checked

Output tab
rgb32 checked
high quality yv12 to rgb conversion checked

rgb conversion tab
ycbcr: itu-bt 601
high quality yv12 to rgb conversion checked
Dithering checked
contrast: standard
Output levels: Tv/Projector

__________________________________

MPC clsid, newest version

vmr9 renderless
ffdshow audio and video decoders.

__________________________________

http://thumbnails9.imagebam.com/4186/c1905941854223.gif (http://www.imagebam.com/image/c1905941854223)
http://thumbnails16.imagebam.com/4186/af6ddb41854227.gif (http://www.imagebam.com/image/af6ddb41854227)

Link to see pictures of the stats. In case the picture host is too slow or goes kaput. (http://www.mediafire.com/?miv4dndzim2)

edit,
I'm using a stock speed E6600 cpu with 2 Gb ram, ddr2 I think.

alph@

12th July 2009, 14:02

Jeremy,thanks for rectification of the link

Jeremy Duncan

23rd July 2009, 15:07

src (http://www.mediafire.com/?djz11jcinjj)
dlls (http://www.mediafire.com/?mi1wrmynvw1)

\\\\ What is different about these dll's than the other SEt builds you munkeyed around with?: July 22, 2009

This is second build on July 22. No, now it's july 23 2009.
What did I do?
I found much to my surprise the project wasn't calling all the files in the src folders. So I added those then spent some time optimizing the project settings, making sure mt.dll was made right and then posted them here.
I was going to use upx.exe to shrink the dlls but it didn't work like before, so I didn't shrink the file size this time.

Works pretty good though. :)

SEt's src has missing files in the src project as well so just to let you know.
For instance mt.h isn't in his src project but it's in the src core folder. I think it was mt.h anyway?

Some files in the include libs wern't there either.
I dunno how they weren't there, all this time since I started on making this dll way back when I din't check the project to make sure and now I find this out and I'm gobsmacked stupified.
Anyway it's fine now though. :cool:

G_M_C

6th August 2009, 09:52

So, not beeing an expert at all, i just ask this (probably dumb) question;

How do i migrate to you MT version?
- I download the stuff in the first post of this thread (duh)

But;

- Do I uninstall my previous version of avisynth and install yours (i'm not on 2.5.8 yet) ? Or do i install regular Avisynth 2.5.8 first, and then replace the avisynth.dll with yours ?
- Where do i put MT.dll exactly ? The normal plugin directory ?
- am i then set to use it ? Or do i need the other patches to (like the directshow-patch) ?

buzzqw

6th August 2009, 12:47

afaik
install 2.5.8
substitute the avisynth dll in windows\system32 folder
ADD the mt.dll in windows\system32 folder
done.

BHH

BigDid

6th August 2009, 18:31

afaik
install 2.5.8
substitute the avisynth dll in windows\system32 folder
ADD the mt.dll in windows\system32 folder
BHH
Hi,

MT.dll is an avisynth dll and goes with others in the avisynth "plugin" folder. Other infos from Buzz are ok :)

Jeremy Duncan made a quick troubleshoot guide on 1st page but the install infos could also be usefully added, see:
http://forum.doom9.org/showthread.php?p=1246719#post1246719

Did

Jeremy Duncan

7th August 2009, 05:42

Jeremy Duncan made a quick troubleshoot guide on 1st page but the install infos could also be usefully added, see:
http://forum.doom9.org/showthread.php?p=1246719#post1246719

Did

Ok, all done.

G_M_C

7th August 2009, 16:41

Thanks all :)

Will do the upgrade (from 2.5.6) this weekend !

leeperry

11th August 2009, 12:20

Will do the upgrade (from 2.5.6) this weekend !
be warned that your plugins have to be recompiled w/ the new 2.5.8 avisynth code...otherwise it will crash randomly. I'm back on 2.57.

Gavino

11th August 2009, 13:43

be warned that your plugins have to be recompiled w/ the new 2.5.8 avisynth code...otherwise it will crash randomly. I'm back on 2.57.
Where did you read this?
If it's true, it's a serious error in the production of 2.5.8 MT.
It should never be necessary to recompile plugins unless there is a major change in the interface. That's the whole point of plugins.

SEt

11th August 2009, 13:53

Due to not thread-safe code in avisynth.h plugins indeed should be recompiled if you want stability with MTMode, but it affects Avisynth 2.5.7 just as bad as 2.5.8.

Gavino

11th August 2009, 14:00

Ah, OK, so it's not that an incompatibility has been introduced, it is actually fixing a bug that was in 2.5.7 MT?

SEt

11th August 2009, 14:29

Bug that was in all versions of avisynth.h because no one thought about threading at the time it was written. That means that all existing plugins are potentially unstable with MTMode until recompiled.

I'd say it's serious design error to put logic in avisynth.h if we want extensibility with simple to maintain backward compatibility.

leeperry

11th August 2009, 16:49

oh ok...well my scripts(LSF/GrainFactory3/rgb3dlut) work perfectly fine in 2.57, and crash randomly in 2.58 :(

tedkunich

11th August 2009, 17:32

oh ok...well my scripts(LSF/GrainFactory3/rgb3dlut) work perfectly fine in 2.57, and crash randomly in 2.58 :(

Do your sources contain an audio stream? I found that having an audio stream cause many random crashes with all flavors of MT. Evoking KillAudio() on the source took care of almost all of my crashes.

T

leeperry

11th August 2009, 18:10

I use it only in ffdshow video in MT("___",4) mode, does it matter :confused:

tedkunich

11th August 2009, 23:29

I use it only in ffdshow video in MT("___",4) mode, does it matter :confused:

Couldn't tell you - I have never used ffdshow. You could test the audio theory by adding the KillAudio() function at the beginning of the script (before the first MT call) and see if it resolves your issues. For me, I process video offline, so I can work around the audio issue.

T

leeperry

12th August 2009, 01:47

ok thanks for the tip, I might try it someday.

but 2.57 works fine actually....I might run some benchmarks in VDUB to see whether 2.58 is slighty faster :)

Gavino

12th August 2009, 09:48

Couldn't tell you - I have never used ffdshow. You could test the audio theory by adding the KillAudio() function at the beginning of the script (before the first MT call) and see if it resolves your issues.
As I understand it, when using the Avisynth filter in ffdshow, the audio is not processed by the script anyway, only the video.

Tom Keller

16th August 2009, 06:28

Hmmm... for me this mt avisynth.dll has some problems with DVDRebuilder Pro. In one click mode the encoding wont start... and when starting the encoding process manually, DVDRebuilder crashes after a while with the "old":
Run-time error '9': Subscript out of range.
... error. And i didn't use any MTMode setting at all :( ...

After going back to the regular avisynth.dll, everything worked fine again.

Jeremy Duncan

17th August 2009, 07:48

leeperry,

I deleted the line that might have been causing the incompatibility you were experiencing. Try the new dll's I made today and see if that works with the code you want to use in ffdshow now. And Gavino is right about the audio in ffdshow avisynth.

Tom Keller,

I read your post and made some new dll's you can try. They are in the first post.

Revgen

17th August 2009, 09:31

One thing TSP always did with me when he was developing it was to give me a debug version that created a text file after every process. I would send him the text file after I experienced the bug and he'd make changes.

Jeremy Duncan

17th August 2009, 09:45

I remade the avisynth.dll I wrote about in post #193. All I changed was I shrunk it using upx.exe. The src is the same, I have re-uploaded the src and dlls in the first post. :)

Tom Keller

18th August 2009, 22:15

Thanks for taking the time!

Sadly the problems with DVDRebuilder are still there. But now (after i had some time for testing) it seems, like they are related to only one combination of a particular disc + avisynth mt + last DVDRebuilder version :confused: . If i change one part of that combination, everything works fine:
i tried two different dvds + avisynth mt + last DVDRebuilder => no problem
i tried the "bad" disc + regular avisynth + last DVDRebuilder => no problem
i tried the "bad" disc + avisynth mt + old DVDRebuilder => no problem
So (luckily) it's obviously not a common problem related to your avisynth.dll, but more of a bad fluke...

Atak_Snajpera

1st September 2009, 23:12

tiny request:
could you add MT after Avisynth?
http://img15.imageshack.us/img15/2255/captureltr.png

This would allow me to easly detect if user has regular or multithreaded version of avisynth

Gavino

2nd September 2009, 00:01

tiny request:
could you add MT after Avisynth?
This would allow me to easly detect if user has regular or multithreaded version of avisynth
It's a good idea, but you would still have to allow for version 2.57 MT, which is already out there without this distinguishing mark.

IanB

2nd September 2009, 08:42

Unofficial versions like this probably should have the "SpecialBuild" or "PrivateBuild" fields of the "StringFileInfo" resource filled out. These fields are for just such a purpose.

Gavino

2nd September 2009, 10:31

@Atak_Snajpera

If you are using Avisynth as a library (via the API), you can detect if it is the MT version by checking whether the SetMTMode function exists:

if (env->FunctionExists("SetMTMode")) ...

Jeremy Duncan

12th September 2009, 04:02

I updated the avisynth.dll and the src. Links are in the first post.
I also updated the instructions to build the dll at the bottom of the first post.

What changed? I fixed the bug Gavino reported using the code he provided to fix the bug, and I made the name change atak snapjera requested.

Gavino

12th September 2009, 08:55

I fixed the bug Gavino reported using the code he provided to fix the bug
(I take it this refers to the audio cache bug.)

Thinking about the MT implications of this led me to have a look at the source code of CacheMT::GetAudio.
I see that it is the same as Avisynth 2.57 and does not include the changes made (to Cache) in Avisynth 2.58. Ironically, this also means that it does not suffer from the bug (when SetMTMode is used), but really CacheMT::GetAudio should be the same as Cache::GetAudio.

Jeremy Duncan

12th September 2009, 17:31

Interesting. I wonder if it would be faster if it has the 2.5.8 code in the cachemt?

I updated the dll and src links in the first post.

Gavino

12th September 2009, 23:08

I wonder if it would be faster if it has the 2.5.8 code in the cachemt?
Most scripts would show no difference, since the audio cache only comes into play if the same section of audio is accessed more than once (eg when mixing channels).

The main reason for making them the same is for consistency and ease of future maintenance. In the longer term (Avisynth 2.6?), it might be better to derive Cache and CacheMT from a common parent class and put the audio code in that parent.

thewebchat

29th September 2009, 02:01

This is probably a dumb question, but how does AviSynth MT behave when no instances of MT or SetMTMode have been called? Is it functionally equivalent to normal AviSynth?

cweb

29th September 2009, 19:20

I'm getting odd behaviour when I use SetMTMode before directshowsource

SetMtMode(2,2)
video=directshowsource("00003.ts").KillAudio()

My source is converted from my camera's hdvideo (50p).

If I put the SetMtMode after the directshowsource all is fine.
Otherwise I get some strange jerkiness or repeats of previous parts of the video throughout..
I will try to prepare a sample for you as soon as I can.

Mediainfo reports the following on my source ts file (not sure why it's saying NTSC, I think it should say PAL!).

Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Duration : 6mn 25s
Bit rate : 13.6 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16/9
Frame rate : 50.000 fps
Standard : NTSC
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.296
Stream size : 626 MiB (92%)

saint-francis

29th September 2009, 20:11

I'm getting odd behaviour when I use SetMTMode before directshowsource

SetMtMode(2,2)
video=directshowsource("00003.ts").KillAudio()

My source is converted from my camera's hdvideo (50p).

If I put the SetMtMode after the directshowsource all is fine.
Otherwise I get some strange jerkiness or repeats of previous parts of the video throughout..
I will try to prepare a sample for you as soon as I can.
)

SetMTMode (2) doesn't work with DirectShowSource. That is the classic example of SetMTMode (2) and DSS. You're lucky it completed encoding. The reason you don't have the issues when you put it after DSS is because it isn't getting called. If you use SetMTMode you have to begint he script with it. You can change between modes during the script but you need to begin with it.
What you need to do is begin the script with SetMTMode (3) and after DSS is called use mode 2. I have found that mode 3 causes havoc with some other filters I usually use.

BigDid

30th September 2009, 00:13

... but how does AviSynth MT behave when no instances of MT or SetMTMode have been called? Is it functionally equivalent to normal AviSynth?
Hi,

I had already verified that (with a 2.58 avisynth-mt.dll) there was nearly no difference scripting no MT or scripting with setmtmode(2).
Here is a more complete test that confirm there is no or very little speed difference between the different scripting exception being the MT() mode.
I use last SET avisynth MT 2.58 dll:
http://forum.doom9.org/showthread.php?p=1301410#post1301410
A slow dual-core with avisynth 2.58 mono or MT dll
Script is mpeg2source+ crop+lanczosresize+
#( the Setmtmode or MT scripting is inserted here when needed)
fft3dfilter(plane=4, sigma=1, bt=4).lsfmod()

1/ 2.58 Mono-dll => 7,25 fps
2/ 2.58 MT-dll, no MT scripting => 7,19fps
3/ 2.58 MT-dll, setmtmode(2) => 7,15fps
4/ 2.58 MT-dll, MT("...") => 10,19 fps

Conclusion being: for a marginal gain, if you own a single core, stick to avisynth 2.58 mono dll. If you own a multiple core, use the 2.58 MT dll and try to get the MT() mode to work ;)

Nota: anybody with a quad-core wanting to redo these simple tests is welcome cause mileage may vary.

Did

Edit: the conclusion applied to the question in the above post gives the following answer: don't worry with the setmtmode(2) it should not be quicker than normal scripting IF you have the avisynth 2.58 MT dll.

aegisofrime

1st October 2009, 02:11

MT() Breaks some filters, like TGMC for example. Tried and tested on my side. For TGMC SetMTMode(2,4) on my Phenom II X4 955 along with a Distributor() at the end of the script gives me a very nice boost.

Gavino

1st October 2009, 08:25

... along with a Distributor() at the end of the script gives me a very nice boost.
Doesn't Distributor() get added automatically? (see here (http://avisynth.org/mediawiki/MT_modes_explained))
What effect does adding another one have?

Bluedeep

1st October 2009, 18:26

Thank's for this version ;)

Do you accept donations?

Jeremy Duncan

1st October 2009, 19:11

Thank's for this version ;)
Your welcome.

Do you accept donations?

No.

BigDid

3rd October 2009, 22:14

... For TGMC SetMTMode(2,4) on my Phenom II X4 955 along with a Distributor() at the end of the script gives me a very nice boost.
Hi,

Glad for you but that doesn't give any numbers for comparison!?

Did

thewebchat

4th October 2009, 04:45

To do parallel temporal processing, would it be reasonable to do something like this?
StackVertical(SelectEven,SelectOdd)
MT("filter",2,0)
Interleave(Crop(last.width,0,0,0-last.height/2),Crop(last.width,last.height/2,0,0))

Or maybe something like this?
AssumeFieldBased
Weave
MTi("filter")
SeparateFields
AssumeFrameBased

Jeremy Duncan

6th October 2009, 12:59

thewebchat,

I couldn't tell you since I don't use that code.

Everybody,

I have updated the src and avisynth.dll and linked to them in the first post.

aegisofrime

6th October 2009, 16:00

Hi,

Glad for you but that doesn't give any numbers for comparison!?

Did

My bad, wasn't keeping track of this thread.

As TGMC does take a while for the FPS numbers to more or less "settle down", I waited until 1 minute of processing to do a measurement.

Without Distributor()

loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrainSSE3.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RepairSSE3.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\nnedi.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-25.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\MT.dll")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\TGMCAlpha_3.avsi")

SetMTMode(2,4)
DGDecode_mpeg2source("F:\Raws\Test.d2v",info=3,idct=5)
TempGaussMC_Alpha3(2, 1, 1, EdiMode="NNEDI2")

FPS: 5.89

With Distributor at the end,

loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrainSSE3.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RepairSSE3.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\nnedi.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-25.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\MT.dll")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\TGMCAlpha_3.avsi")

SetMTMode(2,4)
DGDecode_mpeg2source("F:\Raws\Test.d2v",info=3,idct=5)
TempGaussMC_Alpha3(2, 1, 1, EdiMode="NNEDI2")

Distributor()

FPS: 14.1

Edit: I would like to clarify that the above results are with the pre-rendering job on MeGUI. Interestingly, if encoded with x264 @ CRF21 (that is, pre-rendering mode turned off), the speed difference shrinks to around 7 FPS for non-distributor and 7.5 FPS for Distributor O.o

I believe this is due to x264 actually being a bottleneck... Before anyone asks, the reason why I use pre-rendering is that I have noticed some filters require it. FFT3DGPU gives me crap when I do a TGMC 1 pass encode...

Gavino

6th October 2009, 19:22

October 6, 2009
I updated some files in the src, core folder. I got the new ones from SEt's 2.6 src. I read the bug fix he made in that 2.6 thread of his today and so decided to make a new dll with the fix and thought it would be cool to include other mt files from his src so I did.
I forget which ones though.
Do you realise how lame that sounds?
Don't you understand the importance of software configuration management (http://en.wikipedia.org/wiki/Software_configuration_management) to a project like this?

Guest

6th October 2009, 19:26

Don't you understand the importance of software configuration management (http://en.wikipedia.org/wiki/Software_configuration_management) to a project like this? If you followed this thread from the beginning you would know the answer to that question.

Jeremy Duncan

7th October 2009, 01:38

Do you realise how lame that sounds?
Don't you understand the importance of software configuration management (http://en.wikipedia.org/wiki/Software_configuration_management) to a project like this?

I know which files but I didn't want to be specific and say certain ones.

Here is the list I made in this link (http://forum.doom9.org/showthread.php?p=1306028#post1306028):
core folder

avisynth_c.cpp
cache.cpp
cachemt.cpp
main.cpp
mt.cpp
mt.h
softwire_helpers.cpp

I know it's not softwirehelpers. I think I tried main but that didn't work. One of the mt, I think mt.cpp didn't work. And I think avisynth_c didn't work either.
That leaves cache, cachemt and one of the mt files I ported from the 2.6 src to my 2.5.8 build.

The cachemt didn't work so I had to splice the new code into my old code and so it's a mix.

Arshad07

20th October 2009, 00:08

I'm getting an error while using MT although i've got c++ installed;

Error :
this application has requested the Runtime to terminate it in an unusual way

Please contact the applications support team for more information

http://i38.tinypic.com/iei2ow.jpg

Jeremy Duncan

21st October 2009, 20:58

Groucho2004

21st October 2009, 22:15

I know it's not softwirehelpers. I think I tried main but that didn't work. One of the mt, I think mt.cpp didn't work. And I think avisynth_c didn't work either.
That leaves cache, cachemt and one of the mt files I ported from the 2.6 src to my 2.5.8 build.

The cachemt didn't work so I had to splice the new code into my old code and so it's a mix.

Priceless.

You should really put a warning in front of your download links saying that you have no clue about software development and source control and that you mix code from various versions randomly.

You seem to be under the impression that downloading and installing a Visual Studio trial version instantly gives you the knowledge required to understand the code you're attempting to compile.

Jeremy Duncan

21st October 2009, 23:09

Priceless.

You should really put a warning in front of your download links saying that you have no clue about software development and source control and that you mix code from various versions randomly.

You seem to be under the impression that downloading and installing a Visual Studio trial version instantly gives you the knowledge required to understand the code you're attempting to compile.

I won't do as you ask. If people want to try it then they can.

I posted this build not so it can be all things to all people but that it can work for me in ffdshow, using the avisynth code I put in ffdshow avisynth tab.
I was very fortunate to have SEt's help in the process.

The gnu asks that my personal build be posted for a few years so I have to post it and here in this forum is as good as any place.

If this build doesn't work for you then go try somebody elses build, or use tsp's official builds. :thanks:

Groucho2004

21st October 2009, 23:26

I won't do as you ask. If people want to try it then they can.

Fair enough, I wasn't expecting you to do that anyway.

aegisofrime

22nd October 2009, 02:08

For what it's worth, Jeremy's builds work fine for me. For some strange reason, Set's builds makes my encoding processes drop to 0 FPS after a while :/

SEt

23rd October 2009, 09:56

For some strange reason, Set's builds makes my encoding processes drop to 0 FPS after a while :/
And of course you used my latest 2.6 build and not some random old one?

aegisofrime

23rd October 2009, 13:21

And of course you used my latest 2.6 build and not some random old one?

Yup. I'm using the 2009.09.19 version. :/

Arshad07

20th December 2009, 03:19

Hey jeremy, how should i multithread this script

AVCSource("C:\BD\VZ.dga")
crop( 0, 130, 0, -130)
Spline64Resize(1920,816) # Spline64 (Sharp)
YLevels(1, 1, 250, 0, 255)
Tweak(hue=0, sat=1, bright=0, cont=1.02, coring=true, sse=false)
HDRAGC(min_sat=0.1,max_sat=5.9,coef_sat=2.5)
DeGrainMedian(limitY=4, limitUV=6, mode=3, interlaced=false, norow=false)
LSFmod(Smode=3,Lmode=1,ss_x=1.0,ss_y=1.0,strength=80)

Atak_Snajpera

25th December 2009, 23:07

did you try SetMTMode(2,0) above AVCSource?

Arshad07

26th December 2009, 19:29

^ Didnt work unfortunately :(

Atak_Snajpera

26th December 2009, 22:27

http://avisynth.org/mediawiki/MT_support_page#SetMTMode.28.29_Mode

actarusfleed

3rd January 2010, 21:27

Hi Jeremy,
my question is very simple: Can we use LSF with your avisynth.dll ?

SetMTMode(2,8)
multinum=2
multiden=1
mode=2
spar=0
pel=1
blkh=16
blkv=16
ffdShow_source()
super=MSuper(pel=pel,hpad=blkh, vpad=blkv, levels=4)
backward_vec1=MAnalyse(super, isb=true, blksize=blkh, blksizev=blkv, searchparam=spar, plevel=2, levels=4)
forward_vec1=MAnalyse(super, isb=false, blksize=blkh, blksizev=blkv, searchparam=spar, plevel=2, levels=4)
MBlockFps(super, backward_vec1, forward_vec1, num=FramerateNumerator(last)*multinum, den=FramerateDenominator(last)*multiden, mode=mode)
distributor()

When I install the DLLs that this script needs I install your avisynth.dll library in the folder "system32" in windows.

http://www.mediafire.com/?o1dccmm1l1t

The same thing happens when I've to install LSF.

So my question is: Is there a avisynth.dll that goes right for LSF and Motionflow script together?

Thank you,
actarus.

Jeremy Duncan

10th January 2010, 13:53

dlls. Updated january 10, 2010. These were compiled using the windows 7 sdk so it may be more compatible with windows 7. (http://www.mediafire.com/?zy2xm2ejvzg)

hydra3333

7th February 2010, 09:04

I'm not sure what to do. I want to try out a 2.5.8 MT ... however
i) I read on various threads that Jeremy Duncan has issues understanding what he's doing with code (noted in a few places) and therefore I can't really trust his versions
ii) SET's version here http://forum.doom9.org/showthread.php?t=148117 has a range of issues as mentioned in the 1st post and subsequent posts in that thread

Anyone care to comment on experiences with reliabilty of each version as at Feb 2010 ?

cweb

7th February 2010, 09:12

crasus

8th February 2010, 23:28

I would love to hear if somebody tried any of these two version with the latest MCTemporalDenoise and if there are any advices regarding a proper usage.

As far as I understand untill know, fft3dGPU should be disabled in the script and fft3d used instead.

The script I'd like to use :

TDeint(order=1, mtnmode=3)
Crop(16,58,-24,-86)
BicubicResize(640,384,0,0.5)
MCTemporalDenoise(settings="very high", twopass=false, useTTmpSm=true, sharp=false, adapt=false, deblock=true)
greyscale()

All sugestions welcomed. Cheers!

n0an

11th February 2010, 22:08

Awesome work! :)

Jeremy Duncan

5th March 2010, 03:53

Awesome work! :)

:thanks:

burfadel

28th March 2010, 08:26

Is there any relevance between the work done with Avisynth-MT x64 and the 32 bit avisynth?
http://forum.doom9.org/showthread.php?p=1374605#post1374605

osgZach

28th March 2010, 21:22

Relvance? In what way? They are independent projects. In particular JoshyD's is focused on the move to an x64 encoding pipe, and once that is stable probably some improvements if possible.

Jeremy's seems focused on providing multi-threaded support on the x32 side of things.. Although most feel he has no idea what he is doing (I have no opinion and have not tried his builds). But this particular project will likely be rendered obsolete once Avisynth 2.6 comes out.

Gannjunior

8th April 2010, 01:31

Hi,

i'm trying to use MT in this script:

SetWorkingDir("d:\avs_plugins\AviSynthPlugins\")
LoadPlugin("MT.dll")
Loadplugin("d:\avs_plugins\warpsharp.dll")

LoadPlugin("SangNom.dll")
LoadPlugin("average.dll")
LoadPlugin("Degrainmedian.dll")
Loadplugin("removegrain.dll")
LoadPlugin("Repair.dll")
LoadPlugin("gradfun2db.dll")

LoadPlugin("DGAVCDecode.dll")
LoadPlugin("DGDecode.dll")

loadplugin("fft3dfilter.dll")
loadplugin("hqdn3d.dll")
LoadPlugin("convolution3d.dll")
LoadPlugin("undot.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("mt_masktools-26.dll")
LoadPlugin("TTempSmooth.dll")

import("d:\avs_plugins\denoisers\MCTemporalDenoise.v1.4.08.avsi")
import("d:\avs_plugins\denoisers\GradFun2DBmod.v1.5.avsi")
import("LSFmod.v1.9.avsi")
LoadPlugin("GradFun2DB")

LoadPlugin("D:\Program Files (x86)\StaxRip\Applications\AviSynth plugins\DGAVCDecode.dll")

AVCSource("L:\test_5d2\MVI_0135 temp files\MVI_0135.dga")
MCTemporalDenoise(settings="high")

I tried to use SetMTmode() in different way but with no success.

How could I set MT in the correct way to use all my i-920 cores in the script above?

Thanks in advance

ciao!

osgZach

10th April 2010, 18:20

All I see is a LoadPlugin() for MT.dll

Where did you attempt to SetMTMode and how did you call it?

Gannjunior

10th April 2010, 18:25

before MCTtemporal...

could you help me modify my script adding it in the correct place of the script?

thanks!

osgZach

11th April 2010, 00:40

Honestly I'm not that experienced with StMTMode.. Most people know a lot more than me..

Something real basic you could try is this..

SetMTMode(5,0) # put this BEFORE AVCSource - 5 = mode 5 (recommended for source filters). 0 = auto detect threads I believe. You define threads once and only ever change the MODE from then on.

Then after your AVCSource but Before MCTTemporal - SetMTMode(2)

That is one very basic way to try it. I have seen some other examples with a bit more code than that though, so hopefully someone better than me will come along and help.. I am used to using the MT filter on a single line instead of threading the whole script.

prokhozhijj

24th May 2010, 09:21

OS: Windows 7 64-bit.
CPU: Intel Core 2 Quad 9505.
RAM: 4Gb
Coder: x264, v.1592 32-bit.
Avisynth: 2.5.8 with dlls from this theme.
Source video resolution: 720x576
MVTools: v.2.5.10 (also tried 2.5.9)

I tried to use script listed below with different numbers of threads and different volume of memory.
With number of threads less than 5 - CPU load is no more than 50%.
With SetMemoryMax=2048Mb - CPU load is no more than 50%.
With number of threads more than 4 and SetMemoryMax=1200Mb - scripts hangs with module name error mvtools2.dll.

Could anybody help me with this problem?

Script looks like this:

SetMemoryMax(1200)
SetMTmode(5,8)

DGDecode_mpeg2source("G:\video\_new\ub_s\s 3\d3\encode\d3_1.d2v", idct=3, info=3)
AssumeTFF()

SetMTmode(2)

crop(10,68,-18,-64)

#######################################
# TempGaussMC
#######################################
Import("D:\arh\media\edit\video\_Filters\TempGaussMC\TempGaussMC_beta2u.avsi")
clip=TempGaussMC_beta2u(EdiMode="nnedi2",qual=3,tr2=2,lossless=-1)

clip=clip.SRestore(frate=25)

return clip

Didée

24th May 2010, 17:09

With number of threads less than 5 - CPU load is no more than 50%.

That's normal. You have an HT CPU - 4 physical cores, 8 "logical" cores. When 4 computational intensive threads are running, they will be assigned to the 4 physical cores. Taskmanager will show 50% load because only 4 of the 8 present cores are used. However, the real load in fact is much higher: when the 4 physical cores are already "maxed out", then the additional 4 virtual cores would not give you another 50% of performance. In practice, they could give you some 5%-20% of additional performance (depending on many things). A realistic number is +10%.

With number of threads more than 4 and SetMemoryMax=1200Mb - scripts hangs with module name error mvtools2.dll.

You are in 32bit application land, and your whole processing chain is hitting the "not more than 2GB memory per application" limit.
TGMC needs quite some memory even single-threaded. Now, with some uber-simplification just to make understanding more easy, using SetMTMode(mode,#threads) is quite similar to running TGMC #threads times in parallel. Say that singlethreaded TGMC requires 400MB RAM. Now multiplicate that by 8 threads, and you have a problem. (Yes, I know that SetMTMode in reality uses less ressources.)

Add to that that you're encoding directly to x264, where x264 by itself can easily require anything from 500MB to 1 GB or 1.5GB of RAM, depending on settings. (RC-lookahead plays a major role.)

Alltogether, that's lots of memory that is required .... and since for 32bit applications only 2GB are allowed, it's just too much.

The possibilities are

- stick with SetMTMode(2,4)

- or: make a lossles encoding first, then feed that into x264 (get x264 memory requirement out of the game, so Avisynth has more memory available)

- or: switch to 64bit Avisynth & x264_x64.

In any case, reduce that overly huge SetMemoryMax. It only controls the frame cache of Avisynth, and you really don't need that much. The more frame cache you specify, the less memory is available for the actual script.

My "best guess" is: if you have it running with SetMTMode(2,4), then stick with that. That's about as much as you'll get from TGMC on a CPU with 4 physical cores. You might even consider to specify *less* threads for x264. When the input contains the TGMC turtle, powered by 4 threads already, then it should be safe to reduce x264 to e.g. threads=4. It's default is 12 threads (on a 4-Core with HT), and that won't do much good in this case. 4 threads should be enough to slip into the little free space of Avisynth threads. Anything more will only add unnecessary overhead, for no actual benefit.