Avisynth 2.5.8 MT

[SEt]

Note: Not maintained anymore, use Avisynth 2.6 builds instead.

Version 2009.07.12
Compiled dlls: http://www.mediafire.com/file/nnbngf...isynth258MT.7z
Sources: http://pavelsx.googlepages.com/avisynth258MT_src.7z

Build is statically linked with runtime library, so you don't need to install any VisualStudio runtime for it to work.

Changes:

• threading fixes
• code cleanup (for loop scope conformance,...)
• added hack to allow C plugin to identify itself as cache
• fixed minor memory leak

Known problems:
Multithreaded caching is quite bad what results in eating all memory and crashing after that. Workarounds:

• split script into several parts and process them one by one
• reduce number of used threads (in SetMTMode or MT)
• try different SetMemoryMax values, the more isn't always the better, i often get good results at 512 or 1024

There should be no crashes due to threading, but if you still experience not 'not enough memory' crashes with MT or correct SetMTMode - rebuild offending plugin with avisynth.h from these sources.


interaction with ffdshow:

patched ffdshow.ax revision 2975: http://www.mediafire.com/file/jz2jyluzzny/ffdshow.7z
patched ffdshow.ax revision 3173: http://www.mediafire.com/file/ntnnnz0hyxy/ffdshow.7z
patch: http://pavelsx.googlepages.com/ffds_avs_patch.diff

Patch fixes incorrect timestamps, redice crashes on stop, reduce memory usage a bit.

For using SetMTMode in ffdshow you must uncheck 'Add ffdshow video source', start your script with something like

SetMemoryMax(512)
SetMTMode(3,4)
ffdshow_source()
SetMTMode(2)

and end with

SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

'Buffer ahead' value should be at least 'source_frames_ahead_for_result_frame' + 'number_of_threads', so for example for MDegrain2 with 8 threads it should be 10+.

[juGGaKNot]

Originally Posted by SEt

Compiled dlls: http://www.mediafire.com/file/ybbzty...isynth258MT.7z

A small tutorial one how to use ? simple script

avisource
converttoyv12(pc.601)

[leeperry]

hi SEt, does it work w/ the sample I sent you? coz this one gives a DrWatson error on XP SP3 related to the "avisynth" component of fffdshow.

there's also some crazy memory leaks on 4 threads w/ AddGrainC 1.4 in Avisynth MT 2.57, if you could fix them that'd be really awesome! but 2.57 works fine w/ AddGrainC 1.1, so I dunno who's at fault tbh.

can you please submit your ffdshow changes to the SVN?

[Adub]

AddGrain has had memory leak issues in the past, most of which were resolved but I think that there were one or two left over. Didee and neuron2 know more about them.

Edit: Also, SEt, is this a different (more up-to-date) version than what you posted in the earlier thread?

[SEt]

juGGaKNot, i don't understand you.

leeperry, it does work with your sample and filters with 4 threads and SetMemoryMax(512) - i get memory usage ~1.8Gb. Since you haven't posted your script - you have to figure out yourself correct SetMemoryMax and max number of threads to fit in 2Gb.

ffdshow changes are not required and far from beautiful, so i'd leave them as is for anyone who want to apply them. Only recompilation of ffdshow.ax is required - you can use other dlls from other builds of the same revision.

Adub, it's updated version - changelog is relative to my previous one. What looks like 'huge memory leak' is actually the way multithreaded cache works in 2.5.8 - it can stop somewhere below 2Gb and everything will be fine or it won't and something will crash due to end of address space.

[Adub]

Great, thanks for the info. Can I ask what you did with Directshowsource.dll and TCPDeliver.dll?

[SEt]

Just rebuilt with new header so they are more thread-safe.

[Leak]

Originally Posted by SEt

[...]
interaction with ffdshow:

patched ffdshow.ax revision 2975: http://www.mediafire.com/file/ie1yetdxj0m/ffdshow.7z
patch: http://pavelsx.googlepages.com/ffds_avs_patch.diff

Patch fixes incorrect timestamps, redice crashes on stop, reduce memory usage a bit.

It's not that I don't believe you, but what incorrect timestamps are you talking about here? Your patch doesn't even go near timestamp calculation, unless I'm missing something...

np: Yage - 1st Calling (Future Sound Of London - By Any Other Name)

[SEt]

Incorrect timestamps are fixed by disabling passFirstThrough associated code that breaks them. Try yourself: add '#DEBUG' as first line in ffdshow avisynth script, enable debug messages and see debug output by DbgView. In "[?] TimgFilterAvisynth: Looked up frame X, using frame Y" X should be the same as Y for correct timestamps.

[leeperry]

Originally Posted by SEt

leeperry, it does work with your sample and filters with 4 threads and SetMemoryMax(512) - i get memory usage ~1.8Gb. Since you haven't posted your script - you have to figure out yourself correct SetMemoryMax and max number of threads to fit in 2Gb.

well I set it to 64mb
but you can try to use AddGrainC 1.4 on 8 threads and it will leak memory like crazy using 2.57 and won't obey SetMemoryMax()

AddGrainC 1.1 works fine, no leak.

I'll try your new build

[leeperry]

ok, indeed my sample works now w/ your new MT.dll+avisynth.dll

now, using this simple script w/ the latest icl10 ffdshoow build from xvidvideo.ru in KMPlayer in XP SP3 :

SetMemoryMax(64)
MT("AddGrainC()",8)

that's AddGrainC 1.1 :



first value is CPU load, second is RAM usage, and third is pagefile usage.

and now AddGrainC 1.4 :



I've put all the builds(+source) from 1.0 to 1.4 here....in case you have any idea what's going wrong : http://www.megaupload.com/?d=BOKPFX19

leaks start at 1.2, so between 1.1 and 1.2 something went wrong w/ MT

I already mentioned it to foxyshadis, but never got a reply

I'm not sure whether there's any point that I try your ffdshow mod, because SetMTMode() doesn't work too well w/ HR+Reclock...it seems to be asynchronous or something..

[juGGaKNot]

Originally Posted by SEt

juGGaKNot, i don't understand you.

Its avisynth 2.5.8 so i can use it to feed x264 frames no ?

Or is it for other use ?

[Leak]

Originally Posted by SEt

Incorrect timestamps are fixed by disabling passFirstThrough associated code that breaks them. Try yourself: add '#DEBUG' as first line in ffdshow avisynth script, enable debug messages and see debug output by DbgView. In "[?] TimgFilterAvisynth: Looked up frame X, using frame Y" X should be the same as Y for correct timestamps.

Hmmm... it's been a while since I last worked on the timestamp calculation, but I'll take a look at it this weekend - but I'd rather fix it completely instead of taking out passFirstThrough...

[Adub]

Originally Posted by juGGaKNot

Its avisynth 2.5.8 so i can use it to feed x264 frames no ?

Or is it for other use ?

Uh, yes. Although you have always been able to feed x264 frames. With any Avisynth version. I don't really know why you are asking a question with such an obvious answer.

[juGGaKNot]

Originally Posted by Adub

Uh, yes. Although you have always been able to feed x264 frames. With any Avisynth version. I don't really know why you are asking a question with such an obvious answer.

Well do i have to change anything in the script to use mt ? or just copy the dll ?

Originally Posted by juGGaKNot

A small tutorial one how to use ? simple script

avisource
converttoyv12(pc.601)

[onesloth]

Originally Posted by juGGaKNot

Well do i have to change anything in the script to use mt ?

http://avisynth.org/mediawiki/MT

[Jeremy Duncan]

SEt,

What did you do to the softwire, soundtouch, pfc code in your src?

[SEt]

Just some code cleanup as said tn the first post.

[leeperry]

I'm using the first build you posted, and sometimes KMP crashes while opening and windows tells me that it doesn't have enough virtual memory...this never happened w/ 2.57

how can I help to pinpoint the hypothetical memory leak exactly?

[Jeremy Duncan]

Originally Posted by leeperry

I'm using the first build you posted, and sometimes KMP crashes while opening and windows tells me that it doesn't have enough virtual memory...this never happened w/ 2.57

how can I help to pinpoint the hypothetical memory leak exactly?

Try my build. If it works it's just SEt's project settings not the code.

Then SEt can fine tune his debugging.

I know the poject settings can affect the stability of the dll's.