Avisynth 2.6 MT

[SamKook]

Is curious, I dont get this error if I remove the line: SetMTMode(x,y). O_O.

Try with SetMTMode(5,4) instead of 6,4 for the first one. I don't remember if mode 6 is stable or not, but I chose to use 5 myself instead so there probably was a good reason.

[qyot27]

This was covered with a big discussion in another thread (I think it was the 2.6a4 thread? maybe it was the 2.6 MT thread) - if you're using SEt's MT build, you are not using the official 2.6a5. Only one avisynth.dll is used at any one time, and if you're using SEt's, the avisynth.dll is SEt's, not the official one. If you switch back and forth between them and it happens in both, then that's one thing, but if it only happens when SEt's is used, that's something to report over in the 2.6 MT thread, not here.

Remember, mind your dlls.

[Overdrive80]

I get this error (access violation) too, using the latest AviSynth 2.6 alpha 5 and SEt's MT. It didn't ever happen before.
To me the error seems to occur quite randomly upon loading scripts. Sometimes I reload the script in VirtualDub (F2 Key) and get the error, then I reload again and it works... Sometimes it's there 10 times in a row. Sometimes it won't stop. I cannot nail it down to a specific script line.

I have the same problem with vdub.

Try with SetMTMode(5,4) instead of 6,4 for the first one. I don't remember if mode 6 is stable or not, but I chose to use 5 myself instead so there probably was a good reason.

I try mode 6 because with 5 get this error too.

This was covered with a big discussion in another thread (I think it was the 2.6a4 thread? maybe it was the 2.6 MT thread) - if you're using SEt's MT build, you are not using the official 2.6a5. Only one avisynth.dll is used at any one time, and if you're using SEt's, the avisynth.dll is SEt's, not the official one. If you switch back and forth between them and it happens in both, then that's one thing, but if it only happens when SEt's is used, that's something to report over in the 2.6 MT thread, not here.

Remember, mind your dlls.

Ok, please moderators, could move this part of thread to MT´s SEt (http://forum.doom9.org/showthread.php?t=148782) for not disturb to some users. Thanks and excuse me.

[Guest]

Ok, please moderators, could move this part of thread to MT´s SEt (http://forum.doom9.org/showthread.php?t=148782) for not disturb to some users. Thanks and excuse me. Done and bumped. :)

[SEt]

The first thing that comes to mind: memory consumption. How much virtual memory the process allocated when you see that crash?
And the N'th time: source filters should use MTMode 3 by default.

[LigH]

Regarding your 64-bit Windows and system32 vs. SysWoW64:

Yes, you should use the 32-bit AviSynth MT, which will be put into C:\Windows\SysWoW64; but the 32-bit AviSynth MT will only be used by a 32-bit application. A 64-bit application will try to use a 64-bit (original) AviSynth in C:\Windows\system32. But 64-bit AviSynth is notorious for being unstable and not having many 64-bit plugins available. And I don't remember a 64-bit AviSynth MT to exist.

To use a 64-bit application (e.g. a 64-bit build of the x264 encoder) together with a 32-bit AviSynth MT, you have to use a 32-bit piping tool (e.g. avs4x264mod) which takes the video output from the 32-bit AviSynth MT and forwards it into the 64-bit x264 via a file pipe. Regarding VirtualDub, you should run a 32-bit version of it.

[Overdrive80]

The first thing that comes to mind: memory consumption. How much virtual memory the process allocated when you see that crash?
And the N'th time: source filters should use MTMode 3 by default.

If I use MTMode 3, directly vdub crash. For this reason, I had used MTMode 5 or 6, until now.

Memory consumption was between 1000-1024 mb.

Regarding your 64-bit Windows and system32 vs. SysWoW64:

Yes, you should use the 32-bit AviSynth MT, which will be put into C:\Windows\SysWoW64; but the 32-bit AviSynth MT will only be used by a 32-bit application. A 64-bit application will try to use a 64-bit (original) AviSynth in C:\Windows\system32. But 64-bit AviSynth is notorious for being unstable and not having many 64-bit plugins available. And I don't remember a 64-bit AviSynth MT to exist.

To use a 64-bit application (e.g. a 64-bit build of the x264 encoder) together with a 32-bit AviSynth MT, you have to use a 32-bit piping tool (e.g. avs4x264mod) which takes the video output from the 32-bit AviSynth MT and forwards it into the 64-bit x264 via a file pipe. Regarding VirtualDub, you should run a 32-bit version of it.

I dont use avisynth 64bits neither virtualdub 64 bits. I use version 32 bits of SEt, virtualdub 32 bit and plugins of 32 bits. I dont use filters neither programs of differents arquitectures. Only use OS of 64 bits because I have 6GB ram.

EDIT: Crash virtualdub: http://pastebin.com/qbFs2Q7c

[SEt]

You are crashing inside AVIReadStream::Read, no idea why though. And it looks like 2013.03.09 version – have you tried 2013.09.28?

[ultim]

VirtualDub may crash after F2 because wrong COM model is used. Avisynth MT requires CoInitializeEx(nil, COINIT_APARTMENTTHREADED) not COINIT_MULTITHREADED - memory leak is occured when create a new DirectShow graph instead of old used. Use Windmotion PlayEdit instead. It has memory use indicator and correctly frees old DirectShow graph.

You have too many trim and complex scripts. It produces too many cache entries and memory usage, so you probably have 2GB memory limit override. There is no checks at all.

I'm not very familiar with COM, so maybe somebody can help me out. What if I deleted the COM initilaization inside AVs+ core, and left that task completely to the host application? Would that break existing apps? Or would it have any other disadvantages?

[Overdrive80]

You are crashing inside AVIReadStream::Read, no idea why though. And it looks like 2013.03.09 version – have you tried 2013.09.28?

Nop, I am using 2013.03.09 version because in win 8.1 would get ramdom BSOD. I try this version in this system.

VirtualDub may crash after F2 because wrong COM model is used. Avisynth MT requires CoInitializeEx(nil, COINIT_APARTMENTTHREADED) not COINIT_MULTITHREADED - memory leak is occured when create a new DirectShow graph instead of old used. Use Windmotion PlayEdit instead. It has memory use indicator and correctly frees old DirectShow graph.

You have too many trim and complex scripts. It produces too many cache entries and memory usage, so you probably have 2GB memory limit override. There is no checks at all.

Ok, when I remove of file´s head:

SetMemorymax(1024)
SetMtMode(3,4)

Not occurs any crash even use SetMTMode(2) in below lines of script.

Thanks.

[Boulder]

When you remove the SetMTMode line, you also disable multithreading.

[Overdrive80]

Bad way for complex scripts. In some cases we need 2 threads and even complete disable threading to prevent 2GB memory limit. Try to decrease thread count first then decrease memory by /2 before you get stable values.

But very best way is to divide your complex script for two or more separately scripts and pipe them or create temporary file using UtCodec or other encoder.
Or do not use Avisynth MT...

Thanks, I think that will not use MT.

[Dogway]

But very best way is to divide your complex script for two or more separately scripts and pipe them

how do you pipe-concatenate 2 or more scripts on chain? I haven't seen this yet. Or did you mean filtering in parallel?

[innocenat]

You can do TCPSource/TCPDeliver across two scripts though, bit it's kinda hackish.

[martin53]

You can do TCPSource/TCPDeliver across two scripts though, bit it's kinda hackish.

To my experience, if one script is called from a x86 viewer app, then they share a common 2GB memory space. Does one of the scripts (the delivering one supposedly) with the TCPDeliver approach have its own 2GB memory???

[innocenat]

To my experience, if one script is called from a x86 viewer app, then they share a common 2GB memory space. Does one of the scripts (the delivering one supposedly) with the TCPDeliver approach have its own 2GB memory???

Use it from two different application, or multiple instance of single optimization. Have you read about TCPServer (sorry, it's not TCPDeliver, I remember it wrong)? You can even do it over two different machine.

[real.finder]

Overdrive80

try to remove SETMTmode(6,4) and use SoraThread or ThreadRequest after source call, then use Setmtmode, like:-


LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")

avisource("E:\DB Movies\DSSD10372\Pelicula 02\Funi\0. Srestore.avi").ThreadRequest(10, 5) # or SoraThread

#Ajuste inicial de frame count
last=trim(44,0)

#Ajuste de metrica
last=trim(0,18571)++trim(18571,18571)+trim(18572,0)
last=trim(0,18572)++trim(18504,18504)++trim(18504,18505)++trim(18573,0)
last=trim(0,18575)++trim(18575,0)
last=trim(0,18576)++trim(18568,18570)++trim(18577,0)
last=trim(0,18578)++trim(18578,18579)++trim(18580,0)
last=trim(0,18580)++trim(18580,18580)++trim(18580,18580)++trim(18581,0)
last=trim(0,18582)++trim(18574,18574)++trim(18574,18574)+trim(18583,0)
last=trim(0,18584)++trim(18564,18564)++trim(18564,18564)++trim(18564,18564)++trim(18585,0)
last=trim(0,18587)++trim(18563,18563)++trim(18563,18563)++trim(18563,18563)++trim(18588,0)
last=trim(0,18590)++trim(18557,18557)++trim(18557,18557)++trim(18557,18557)++trim(18557,18557)++trim(18557,18557)++trim(18557,18557)++trim(18591,0)
last=trim(0,18596)++trim(18625,18631)++trim(18597,0)
last=trim(0,18596)++trim(18597,18597)++trim(18597,0)
last=trim(0,18606)++trim(18606,0)
last=trim(0,40993)++trim(40944,40972)++trim(40998,0)
b=trim(58600,58600)
last=trim(0,58600)++b++b++b++b++b++b++b++b++b++b++b++b++b++b++b++trim(58601,0)
last=trim(0,58615)++trim(58624,58642)++trim(58624,0)
last=trim(0,framecount()-132)

Setmtmode(2)

spline36resize(720,480,src_left=8, src_top=0, src_width=-5, src_height=0)

#Para controlar el aspect ratio: .subtitle(string(last.aspect_error(8,0,-6,-0))) Antes del crop

###################################
# FILTRADO #
###################################

original=last

>>>>>>>>>>>>>>>> etc...


and if you want to use all memory of your system try mp_pipeline

SEt, try add GetProcessMemoryInfo memory checks to Avisynth buffer memory allocate code to prevent new cache item create after 2GB or 3GB if LARGEADDRESSAWARE is used. It may fix 50% Avisynth MT crashes.

Yes, after the new cache in Alpha 5 (2013.09.28 build), there are many problems of stability

[Overdrive80]

Overdrive80

try to remove SETMTmode(6,4) and use SoraThread or ThreadRequest after source call, then use Setmtmode, like:-

[CODE]
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")

avisource("E:\DB Movies\DSSD10372\Pelicula 02\Funi\0. Srestore.avi").ThreadRequest(10, 5) # or SoraThread



Thank you, I will try it.

[MichaelRow]

I've got a problem about MT. I don't know how to let MT make full use of my computer since the CPU is at about 50% capacity.
Here's the script:
SetMTMode(2,8)
SetMemoryMax(1300)
source=LWLibavVideoSource("D:\04.m2ts")
denoised=source.SMDegrain(thSAD=200, thSADC=50, prefilter=0, tr=3, plane=4, RefineMotion=true)
line=denoised.mt_edge("min/max").mt_deflate()
debanded=denoised.GradFun3(radius=17,radiusc=17,thrc=0.35,thr=0.35, smode=2)
Final=mt_merge(debanded, source, line, luma=true)
return Final

[LigH]

Not sure if it applies here, because it should not really be the bottleneck; just in general: It is recommendable to run the *Source plugin with MT mode 3 or 5 (depending on the specific decoder) and switch to mode 2 afterwards, so the decoder is only called once, not as many times as threads are used. Especially when the decoder itself may be multithreaded.
SetMemoryMax(1300)
SetMTMode(3,8)
source=LWLibavVideoSource("D:\04.m2ts")
SetMTMode(2)
# ...

Also check if the encoding process makes use of the pagefile. Not very likely if you have enough RAM, nevertheless that would be a serious bottleneck if it was the case.

[Boulder]

My guess is that SMDegrain is quite complex so it's not very efficiently split between different threads.

[Groucho2004]

I wonder if "yuv4mpegpipe" adds the necessary Distributor() call. If not, the frames would probably be piped single threaded into x264.

[SamKook]

I know avs2pipemod which is similar doesn't add distributor() so I'd say it's likely the problem.

[qyot27]

I wonder if "yuv4mpegpipe" adds the necessary Distributor() call. If not, the frames would probably be piped single threaded into x264.
The libavformat AviSynth demuxer (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avisynth.c) (which is what would be responsible for it, rather than yuv4mpegpipe) has no special-casing for MT builds, so no.

[MichaelRow]

Thank you all
Not sure if it applies here, because it should not really be the bottleneck; just in general: It is recommendable to run the *Source plugin with MT mode 3 or 5 (depending on the specific decoder) and switch to mode 2 afterwards, so the decoder is only called once, not as many times as threads are used. Especially when the decoder itself may be multithreaded.
SetMemoryMax(1300)
SetMTMode(3,8)
source=LWLibavVideoSource("D:\04.m2ts")
SetMTMode(2)
# ...

Also check if the encoding process makes use of the pagefile. Not very likely if you have enough RAM, nevertheless that would be a serious bottleneck if it was the case.
It doesn't improve much. As for RAM, there's 800M of 4G free.


My guess is that SMDegrain is quite complex so it's not very efficiently split between different threads.
Not. SMDegrain() is a simple funtion based on MDegrain, and it can work well with other filters when going mutithread.


I wonder if "yuv4mpegpipe" adds the necessary Distributor() call. If not, the frames would probably be piped single threaded into x264.
I know avs2pipemod which is similar doesn't add distributor() so I'd say it's likely the problem.
The libavformat AviSynth demuxer (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avisynth.c) (which is what would be responsible for it, rather than yuv4mpegpipe) has no special-casing for MT builds, so no.
Yes, that's the problem. When using x264(32bit) to open avs script and encode, the CPU Occupancy can reach 90% and above, but half of the occupancy when use ffmpeg(32bit) piping to x264(64bit). I don't know much about Distributor() and libavformat AviSynth demuxer, and could you describe how to solve the problem when piping in detail? Thanks again.

[Groucho2004]

I don't know much about Distributor() and libavformat AviSynth demuxer, and could you describe how to solve the problem when piping in detail?
Try this script:


SetMemoryMax(1300)
SetMTMode(3,8)
source=LWLibavVideoSource("D:\04.m2ts")
SetMTMode(2)
denoised=source.SMDegrain(thSAD=200, thSADC=50, prefilter=0, tr=3, plane=4, RefineMotion=true)
line=denoised.mt_edge("min/max").mt_deflate()
debanded=denoised.GradFun3(radius=17,radiusc=17,thrc=0.35,thr=0.35, smode=2)
mt_merge(debanded, source, line, luma=true)
GetMTMode(false) > 0 ? Distributor() : last

[qyot27]

EDIT: I was too slow, but anyway...

If the application (in this case, ffmpeg) doesn't automatically add Distributor(), then the user has to add it themselves, at the end of their script.

Whether the pipe will end up playing a role here, I don't know.

[MichaelRow]

Try this script:


SetMemoryMax(1300)
SetMTMode(3,8)
source=LWLibavVideoSource("D:\04.m2ts")
SetMTMode(2)
denoised=source.SMDegrain(thSAD=200, thSADC=50, prefilter=0, tr=3, plane=4, RefineMotion=true)
line=denoised.mt_edge("min/max").mt_deflate()
debanded=denoised.GradFun3(radius=17,radiusc=17,thrc=0.35,thr=0.35, smode=2)
mt_merge(debanded, source, line, luma=true)
GetMTMode(false) > 0 ? Distributor() : last


It does work,but ffmpeg (as well as avs2yuv) would crash with a error message "ffmpeg has encountered a problem and needs to close" several minutes after the encoding begin.

Whether the pipe will end up playing a role here, I don't know.

Seems that your concern is well-founded.

[Groucho2004]

It does work,but ffmpeg (as well as avs2yuv) would crash with a error message "ffmpeg has encountered a problem and needs to close" several minutes after the encoding begin.
You're probably running out of memory. Reduce the number of threads.
Check how much memory your script needs with this tool (https://forum.doom9.org/showthread.php?t=165528).

To maximize available memory for the frame serving and encoding on a 64 Bit OS you should use a pipe tool that has the "LARGEADDRESSAWARE" linker flag set and pipe the output to a 64 Bit version of x264. This way the frame server can allocate almost 4 GB.

[Doom9]

7 posts from the tail end were removed because they intermixed technical arguments with personal and went on to violate the forum rules. Cleaning them up would've required significant rewrites that would most likely have fundamentally changed what the posters meant to say - so in order not to put words in anybody's mouth, I removed the entire exchange (as per the moderator rules all content is still here, just invisible).
And I'd like to remind everybody that this is a forum for technical discussion, not personal bickering and attacks. If you don't agree with somebody on a technical level, you need to back up your argument with facts, not just dismiss somebody's opinion off hand as invalid, pointless, or whatever other term you can find to infuriate the guy on the other line.
Also, we have an established way to settle disagreements and it's not duking it out here in the forum.

Sorry for the OT post.

[GMJCZP]

I have problems using VSFilter, the subtitles sometimes display wrong. I have found it by using SetMTMode. To remedy this (apparently working) I had to use this:

.
.
.
SetMTMode (5,2) #already used in source filters (!), use 5 or 3 is indifferent
TextSub (...)
SetMTMode (2,2) #already used in others filters
.

What I can do for normal operation with vsfilter?

I'm using the latest versions of avisynth and set mt. Thank you.

[SamKook]

If the change you made fixed it, then it simply means that vsfilter doesn't support MT mode 2 properly so you can either do what you did or change to another subtitle renderer.

BTW, you should only specify the number of threads to use the first time with SetMTMode so the second call should only be SetMTMode(2).

[GMJCZP]

If the change you made fixed it, then it simply means that vsfilter doesn't support MT mode 2 properly so you can either do what you did or change to another subtitle renderer.

BTW, you should only specify the number of threads to use the first time with SetMTMode so the second call should only be SetMTMode(2).

I ran what I did, I can confirm. I hope someone will serve this.

Yes, only put SetMTMode (2) is sufficient, Thanks. Hopefully people VSFilter check that error.

[Seedmanc]

Which Avisynth 2.6 am I supposed to use with spatial MT("")? It keeps telling me that I need to use 2.6 or 2.5.7mod, but I do have 2.6 already I think (the alpha one), while 2.5.7 is too old for me. I need spatial MT because temporal introduces too much lag for realtime processing.

[Groucho2004]

Which Avisynth 2.6 am I supposed to use with spatial MT("")? It keeps telling me that I need to use 2.6 or 2.5.7mod, but I do have 2.6 already I think (the alpha one), while 2.5.7 is too old for me. I need spatial MT because temporal introduces too much lag for realtime processing.
The last version that supports the MT() plugin is this one (http://forum.doom9.org/showthread.php?t=148117).

[GMJCZP]

I do not know if anyone has happened to use SetMTMode that processing speed decreases. Is it possible to happen?

[Groucho2004]

I do not know if anyone has happened to use SetMTMode that processing speed decreases. Is it possible to happen?
I could probably come up with a script that would achieve that but have not tried yet.
Disregarding some or all hints/instructions from the first post is a good point to start.

[GMJCZP]

@ Groucho2004

Aside from scientific research (which never hurts, :thanks: ), I said it because it is happening to me without looking!

I usually use two scripts, one for heavy duty with Lagarith and the other for final work with debanding (due to clean in the first script) and I had the rude awakening that it was better to run without SETMTMode.

Fortunately I managed to purify itself and the second script worth using MT but I still have problems with the first. In this process, as happened with penicillin, discovered inadvertently a Deblock_QED small correction:

Here (http://forum.doom9.org/showthread.php?p=1697386#post1697386)

I notice that the FPS (in VirtualDub / VirtualDubMod) are more stable without SetMTMode, instead FPS with him is a seesaw of madness.

[Groucho2004]

I notice that the FPS (in VirtualDub / VirtualDubMod) are more stable without SetMTMode, instead FPS with him is a seesaw of madness.
Extreme fluctuations in processing speed are normal with Avisynth MT. All that matters is the average speed. A good insight as to how your script behaves can be provided with AVSMeter (http://forum.doom9.org/showthread.php?t=165528).

[LigH]

It will certainly depend on the specific MT mode. There are source filters which work well with one MT mode because their decoders are programmed very clean and stable (e.g. using only a local set of variables to be independent from the calling environment, a.k.a. "re-entrant"), and others which require a different MT mode because they are not well prepared for working in a multi-threaded environment and need to be protected from their copies in other threads. In case of AviSource, even different VfW codecs may behave more or less convenient, up to a point where they only work reliably with a sequential request of frames.

Therefore, or furthermore, it may help to use Preroll(#) – an additional frame buffer, similar to RequestLinear(), to avoid the decoder jumping backwards if several threads work with frame numbers of a larger distance.

[GMJCZP]

Groucho2004, LigH, thanks for your comments.

Groucho2004, I have not used your program, sooner or later I will use.

LigH, did not know the Preroll function but do not know exactly how it works, I am ashamed to say that looked more like an intruder in my script as a function.

But finally I found the reason why it took more time of processing using SetMTMode: RemoveGrainSSE2.dll
If you are using RemoveGrainSSE3.dll everything is solved, the reason why SSE2 is used because it seemed to read that could cause crashes.
I took it out because if you import a function that calls the dll, but do not use it then you would realize ever, so my second script refined worked fine.

Mystery solved and as the ending music is heard "Scooby Doo, Where are you" ...


Final note: I actually solved two mysteries, If using K-Lite is better installing separately Xvid of Jawor. K-Lite_Codec_Pack_1080_Mega active postprocessing by default, affecting the image and probably increasing the processing time of AviSource.

[LigH]

In general, never use "Codec Packs". Install only the codecs or filters you really need, only from the original author (if possible; or from trustworthy archives). Some codec packs are not completely legal; some codec packs even alter Windows interna which may have side effects, even after uninstalling them.

Just for playback, there are only few formats LAV Filters do not yet support. And for processing AVIs via VfW, you will only need very few additional codecs; ffdshow still contains a lot of VfW decoders. And L-SMASH Works can handle AVIs too, to make VfW nearly obsolete for decoding.

Preroll() will get the video decoded several frames ahead in sequential order and buffers a range of decoded frames. This helps avoiding a decoder to have to go backwards, which often means it has to decode the whole sequence from a previous keyframe to the current position. Backward jumps in a decoder may happen when a video is processed with multiple threads, and one thread is ahead of another.

[GMJCZP]

I've had two crashes due to use first SSE3 and then version of RemoveGrain 1.0pre. I think the SS2 he used was that of Vit.
Now I'm trying RGTools, just to see if it does not hang, but tp7 says the results are almost identical to the previous versions, so I do not want to use. If please recommend me while SetMTMode functional stable version, that is, it does not slow down the processing.

LigH, I will see with lavfilters (nevcairiel). ffdshow still have updates?
What is Lsmash? Sorry for my ignorance.

About Preroll() in which part of the script goes, what then of SetMTMode(2)? Without parameters?

Update: Other crash more, with rgtools, but the message of error now says about frfun3d. I need help.

[Boulder]

It could be that the script just is too complex and it's going to be almost if not impossible to make it work with multithreaded Avisynth.

There are ways around that - split encode into multiple parts and encode them simultaneously as lossless intermediate files in single threaded mode, then combine them in the script for the final processing (debanding in your case). If you use MVTools2, use cretindesalpes's build as it is internally multithreaded. This process is what I always do with my QTGMC stuff.

[TurboPascal7]

Now I'm trying RGTools, just to see if it does not hang, but tp7 says the results are almost identical to the previous versions, so I do not want to use.

There is absolutely no reason to use RemoveGrain over RgTools unless you want exact script compatibility (some parameters like "cache" are not implemented). The minor rounding differences will not affect your output in any significant way (and might as well make it better). And it should work with any MT mode up to 1.

[GMJCZP]

@TurboPascal7:
Your observation clarifies my doubts, thanks.

@Boulder:
In recent years I have always used MVTools cretindesalpes's builds. Using your recommendation now I all went well, in fact that we discussed with AnimeIVTC and had already tried before, and thank you very much again.

Indeed, the crashing problem is perhaps because of its complexity. When used removegrainSSE2 slowed the process, causing the system to feel less committed than without SetMTMode, so not hung.

I was able to run the second script in MT without problems, but my concern now why that dll caused that MT was slower. In addition, there will be no other solution than the Boulder?

Note: simultaneously I used option RGBA in Lagarith for test and avoid more banding, this will cause more instability that YV12?

[LigH]

Converting forth and back between RGB(A) and YUV (any variant) in only 8 bit resolution will probably cause rounding errors and even introduce banding.

L-SMASH Works (http://forum.doom9.org/showthread.php?t=167435) is a project by VFR maniac which uses LAV Filters as splitters and decoders for AviSynth and VapourSynth; pseudo-mathematical similarity relation:

(DirectShow) ffdshow : LAV Filters ~ (AviSynth) FFMS2 : L-SMASH Works

FFMS2 has some known problems with MPEG related containers, explicitly prefers MKV; L-SMASH Works supports many containers without issues and even has specific support for ISO Media containers (a family which MOV and MP4 belong to).

There is only marginal "development" for ffdshow anymore, if at all...

And by the way, you still did not document which MT mode you preferred. There are differences between SetMTMode(2) or SetMTMode(3) or SetMTMode(5) or SetMTMode(6)... and different *Source filters should possibly be used with a different MT mode, e.g. DGDecNV may not work well in mode 2 due to its access to a decoder chip. Switching the MT mode after calling the *Source filter is quite common.

Regarding Preroll(), search this forum for threads containing "preroll requestlinear". This should return a few examples, comparing both (Preroll is native to the AviSynth MT kernel; RequestLinear is included in TIVTC). Either should follow the *Source function immediately, parameters will control the range of cached frames around the currently processed frame.

[GMJCZP]

Converting forth and back between RGB(A) and YUV (any variant) in only 8 bit resolution will probably cause rounding errors and even introduce banding.

Is better YV12, confirmed.

L-SMASH Works (http://forum.doom9.org/showthread.php?t=167435) is a project by VFR maniac which uses LAV Filters as splitters and decoders for AviSynth and VapourSynth; pseudo-mathematical similarity relation:

(DirectShow) ffdshow : LAV Filters ~ (AviSynth) FFMS2 : L-SMASH Works

FFMS2 has some known problems with MPEG related containers, explicitly prefers MKV; L-SMASH Works supports many containers without issues and even has specific support for ISO Media containers (a family which MOV and MP4 belong to).


Thanks for the information.


And by the way, you still did not document which MT mode you preferred. There are differences between SetMTMode(2) or SetMTMode(3) or SetMTMode(5) or SetMTMode(6)... and different *Source filters should possibly be used with a different MT mode, e.g. DGDecNV may not work well in mode 2 due to its access to a decoder chip. Switching the MT mode after calling the *Source filter is quite common.

Regarding Preroll(), search this forum for threads containing "preroll requestlinear". This should return a few examples, comparing both (Preroll is native to the AviSynth MT kernel; RequestLinear is included in TIVTC). Either should follow the *Source function immediately, parameters will control the range of cached frames around the currently processed frame.

I use SetMTMode(5), SourceFilters, SetMTMode(2), generally.
The problem for me, and if it helps with MT, which is part of the script and how parameters is used Preroll(). I have not got examples, perhaps because I now internet is difficult to use for long. :(

[LigH]

Here (http://forum.doom9.org/showthread.php?p=1629239#post1629239) is an example by IanB: "Preroll(video=25, audio=10.0)" (video in frames, audio in seconds).

BTW, Selur (author of "Hybrid") reports (http://forum.doom9.org/showthread.php?p=1631414#post1631414) that "Preroll(100)" (100 frames video, no specific value for audio) uses less RAM than "RequestLinear(rlim=50,clim=50)"; so there are two more examples (I am not sure if this syntax works). Just try different forms and values, and see if it affects speed and stability. Remember it needs more RAM for its own buffer, so you may have to reduce the demands of multithreaded parts slightly, e.g. reduce the number of threads a bit below the number of CPU cores.

RequestLinear is verbosely documented in an own text file inside the TIVTC (http://avisynth.nl/index.php/TIVTC) archive (TIVTCv105.zip (http://bengal.missouri.edu/~kes25c/TIVTCv105.zip)); Preroll is briefly documented in the AviSynth Wiki (http://avisynth.nl/index.php/Preroll).

[GMJCZP]

Thanks. Apparently you would like this:

SetMTMode (5)
Source ()
Preroll (arguments, play with option video)
SetMTMode (2)