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

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.