View Full Version : MT 0.7(+custom avisynth)a filter to run filters multithreaded. Usefull for SMP or HT
halsboss
20th November 2008, 09:11
Thanks. The SetMTMode I'd thought just changed the mode back and forth (and I tended to have them at the start of each block of code, mostly snipped out of that sample)... and I was quite taken with the concept of MT, using it wherever I could since it was supposed to retain temporal position. Will give it a try. Still unsure why a scene change should cause the shudder.
Oh, and it used to be quite a speedy script too, by comparison :) Pity it didn't work as I'd hoped.
Source Frames: 4355
original (borked) MT script best profile,fox1 matrix, encoding time: 0:02:56 (176.41 s) fps: 24.7
non-MT script best profile,fox1 matrix, encoding time: 0:03:56 (236.00 s) fps: 18.5
merlin7777 script best profile,fox1 matrix, encoding time: 0:03:24 (204.48 s) fps: 21.3
Adub
20th November 2008, 10:48
Did my edit fix your problem? If it did, you may be able to squeeze some more speed out of that script, with some minor tweaks here and there.
halsboss
20th November 2008, 11:05
Yes, thanks Merlin777, it did appear to fix it.
Here's an example of the issue showing out of order frames by a scene change, for that possible bug in MT/HCenc (it's possible it is the script, though... anyone spot the script error?)
3 images with MT
http://rapidshare.com/files/165589313/mt2420.jpg
http://rapidshare.com/files/165589314/mt2421.jpg
http://rapidshare.com/files/165589315/mt2422.jpg
http://rapidshare.com/files/165589313/mt2420.jpg
http://rapidshare.com/files/165589314/mt2421.jpg
http://rapidshare.com/files/165589315/mt2422.jpg
and 3 images with NO MT
http://rapidshare.com/files/165589316/nomt2420.jpg
http://rapidshare.com/files/165589317/nomt2421.jpg
http://rapidshare.com/files/165589318/nomt2422.jpg
http://rapidshare.com/files/165589316/nomt2420.jpg
http://rapidshare.com/files/165589317/nomt2421.jpg
http://rapidshare.com/files/165589318/nomt2422.jpg
seggitek
26th November 2008, 22:30
Hello guys. I'm trying to figure out this MT thingy.
it is rather safe because only one thread is used so it makes no sense only to use mode 5 alone but it should be used for only part of the script that doesn't work with lower modes like mvtools.
Since rev 0.5, MT() internally calls SetMTMode(5) and restores the old mode afterwards so you don't have to add SetMTMode(5) before MT() and restore the old mode after
Does this mean that the original MT functionality (which splits a frame up into several pieces for several threads) is no longer available?
http://avisynth.org/mediawiki/upload/7/79/MTexample.jpg
Could this be the reason, why I experience absolutely no speedup when encoding to XviD (using VirtualDubMod)?
Sagekilla
26th November 2008, 23:07
If your filter chain is just mt("blur(1)",threads=2), you shouldn't expect any realistic speedup. It runs so fast on its own that MT'ing it provides no practical benefit.
Adub
26th November 2008, 23:11
The split frame processing still exists. That's what MT does. SetMTMode I believe splits up by whole frames.
seggitek
26th November 2008, 23:22
If your filter chain is just mt("blur(1)",threads=2), you shouldn't expect any realistic speedup. It runs so fast on its own that MT'ing it provides no practical benefit.
Hehe sorry. That is not my real filter chain. The image is copied from the AviSynth wiki. My filter chain is this one:
# Number of threads for multithreaded encoding
mt_count = 4
# PLUGINS
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\MaskTools.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\Repair.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\RemoveGrain.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\FFT3DFilter.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\mvtools\mvtools.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\ChromaShift.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\VInverse.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\gradfun2db.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\mt_masktools-25.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\TTempSmooth.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\AddGrainC.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\Cnr2.dll")
LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\TIVTC.dll")
#LoadPlugin("E:\MyProgies\Ripping\GordianKnot\AviSynthPlugins\VScope.dll")
# IMPORT
Import("E:\MyProgies\Ripping\GordianKnot\AviSynthIncludes\MCTemporalDenoise.v1.0beta2.avsi")
Import("E:\MyProgies\Ripping\GordianKnot\AviSynthIncludes\LimitedSharpenFaster.avsi")
Import("E:\MyProgies\Ripping\GordianKnot\AviSynthIncludes\GrainFactory3.avsi")
Import("E:\MyProgies\Ripping\GordianKnot\AviSynthIncludes\FixChromaBleeding.avsi")
# Load AVI source clip
AviSource("J:\Ripping\MasqueOfTheRedDeath-1989\capture.avi", true, "RGB24", fourCC="HFYU")
# IVTC
ConvertToYV12()
tfm(pp=7, cthresh=8, chroma=true).tdecimate()
Vinverse()
# Shift chroma info left by 2 pixels
MT("ChromaShift(C=-2)", mt_count, 2)
# DENOISING
MT("FFT3DFilter(sigma=3,plane=3,bt=5)", mt_count, 24)
MCTemporalDenoise(settings="medium",chroma=true,stabilize=true,GPU=false)
MT("""Cnr2("xxx", 4, 5, 255)""", mt_count, 24) # Remove chroma noise
# Trimming & Cropping
crop(0, 6, -4, -0)
MT("Spline36Resize(512, last.height)", mt_count)
MT("Spline36Resize(last.width, 384)", mt_count, splitvertical=true)
# Correct Basic Video settings
MT("""ColorYUV(off_y=-15, gain_y=+22, cont_v=-12.8, cont_u=-51.2, opt="coring")""", mt_count)
MT("Tweak(bright=0, cont=1, hue=+4.5, sat=0.95, coring=false)", mt_count)
# Add grain
MT("GrainFactory3(g1str=4, g2str=5, g3str=16, g1shrp=30, g2shrp=40, g3shrp=50)", mt_count, 24)
MT("FadeIO2(180)", mt_count)
The split frame processing still exists. That's what MT does. SetMTMode I believe splits up by whole frames.
I thought so too, but then I read this:
Since rev 0.5, MT() internally calls SetMTMode(5) and restores the old mode afterwards so you don't have to add SetMTMode(5) before MT() and restore the old mode after
And as we know from the AviSynth wiki page:
SetMTmode: ... to enable temporal (that is more than one frame is processed at the same time) multithreading. Mode 5 is the slowest (slower than not using SetMTMode) but should work with all filters that don't require linear frameserving (that is the frames come in order: frame 0,1,2,...,last).
Which should mean this, right?
http://avisynth.org/mediawiki/upload/3/30/SetMTexample.jpg
That's why I am confused.
Sagekilla
27th November 2008, 04:42
You do know you can do a huge chunk of code with triple quotes for MT, right? ;)
seggitek
27th November 2008, 10:00
You do know you can do a huge chunk of code with triple quotes for MT, right? ;)
Yes, I saw that opportunity. I can only use that if I need the same amount of frame overlapping for every filter. Which is not the case. :)
I'm still thinking that MT does not do anything. It calls SetMTMode(5) which is the slowest solution, even slower than not using MT. What sense does this make?
Here are some encoding times for the above script:
VirutalDubMod/Xvid using no MT at all: 18 hours
VirutalDubMod/Xvid using MT() only (= above script): 18 hours
VirutalDubMod/Xvid using SetMTMode(2) only: 16 hours
:confused:
Can you verify my following thoughts?
AviSynth multithreading has basically nothing to do with multithreading XviD or x264.
You can do one of the following 4:
1.) NO Avisynth MT + NO XviD MT (standard encoding)
2.) Avisynth MT + NO XviD MT
3.) NO Avisynth MT + XviD MT
4.) Avisynth MT + XviD MT
NO Avisynth MT + XviD MT is basically the same as using Avisynth MT + NO XviD MT with SetMTMode() in AviSynth, because they both result in temporal multithreading.
AviSynth MT + XviD MT is quite nonsense, because it uses multiple threads for creating XviD frames whereas every XviD thread in addition is split up into another threads at the level of AviSynth.
seggitek
29th November 2008, 14:45
Here are some encoding times for the above script:
VirutalDubMod/Xvid using no MT at all: 18 hours
VirutalDubMod/Xvid using MT() only (= above script): 18 hours
VirutalDubMod/Xvid using SetMTMode(2) only: 16 hours
:confused:
After reading the first about 10 pages of this thread I found the problem. I didn't know that you have to call SetMTMode() at the very beginning of your script even if you are only using MT(). :devil:
Now it looks like this:
VirutalDubMod/Xvid using no MT at all: 18 hours
VirutalDubMod/Xvid using MT() only (= above script): 16 hours
VirutalDubMod/Xvid using SetMTMode(2) only: 16 hours
Speedup is about 10%. Quite dissapointing. Maybe something is still wrong. :eek:
Boulder
29th November 2008, 14:49
You don't have to call SetMTMode if you use only MT().
seggitek
29th November 2008, 15:54
You don't have to call SetMTMode if you use only MT().
That would make sense. Thanks you. So this limited speedup is all, because of XviD?
Sagekilla
29th November 2008, 18:04
It's possible. You have some really slow filters running though (FFT3DFilter, MCTemporalDenoise, GrainFactory). There's also a lot of temporal dependenices for the first two, so MT'ing them efficiently is difficult.
seggitek
29th November 2008, 22:24
There's also a lot of temporal dependenices for the first two, so MT'ing them efficiently is difficult.
I'm currenctly encoding with HuffYUV and it's as "slow" as XviD. This should mean that it has nothing to do with XviD but with my filter chain's "MTability". :(
halsboss
2nd December 2008, 14:18
When I use this script and alternate between the MTi line and the one under it, I get different results with what HCEnc thinks is the vertical size !.
SetMTmode(mode=5,threads=1) # start with mode=5 forAVIsource http://forum.doom9.org/showthread.php?p=1067216#post1067216
SetMemoryMax(256)
AviSource("G:\HDTV\capt\capt-type1.08-11-30_20-39.00.avi", audio=false)
AssumeFPS(25)
AssumeBFF()
original=LAST
# snipped processing , just for testing
# for MTi info refer http://avisynth.org/mediawiki/MT#Technical_info
MTi("original").AssumeBFF() #HC tells me this is 720x1152
#original.AssumeBFF() #HC tells me this is 720x576
Converttoyv12(interlaced=true)
SetPlanarLegacyAlignment(True)
Distributor() # use this when using HC and SetMTmode, per http://forum.doom9.org/showthread.php?p=1063622#post1063622
The doco at http://avisynth.org/mediawiki/MT#Technical_info says
* MTi() that creates two threads and let each thread process one field before combining them like this avs function
function PseudoMTi(clip c,string filter)
{
a=eval("c.AssumeFieldBased().SeparateFields.selecteven()."+filter)
b=eval("c.AssumeFieldBased().SeparateFields.selectodd()."+filter)
interleave(a,b).weave()
}
like the other pseudoscript a and b are executed in parallel. Note that only two threads are created so it will only use two (virtual) cores.
What am I doing wrong ?
Gavino
2nd December 2008, 14:35
Your "original" is not a filter, but a variable.
Replace "original=LAST" by:
function original(clip c) { return c }
halsboss
2nd December 2008, 15:03
Oh. Thanks. Swapping between the two L1 lines confirmed I get different size results for each.
original=LAST
L1 = MTi("original.MVDegrain1i2_insideMTi(doAGC=FALSE)")
#L1 = MTi("last.MVDegrain1i2_insideMTi(doAGC=FALSE)")
L1
function AGCiEmbedded(clip srcclp) {
inpclp = srcclp
#inpclp=inpclp.HDRAGC(coef_gain=1.0, coef_sat=1.0) # default. +coef_gain=brighter decrease to limit. +coef_sat=more saturation
#inpclp=inpclp.HDRAGC(coef_gain=0.1, coef_sat=1.0) # default. +coef_gain=brighter decrease to limit. +coef_sat=more saturation
#inpclp=inpclp.HDRAGC(coef_gain=0.2, coef_sat=1.0, corrector=0.8, reducer=2.0) # default. +coef_gain=brighter decrease to limit. +coef_sat=more saturation
#inpclp=inpclp.HDRAGC(coef_gain=0.2, min_gain=0.1, max_gain=1.0, coef_sat=1.0, corrector=0.8, reducer=2.0) # default. +coef_gain=brighter decrease to limit. +coef_sat=more saturation
#inpclp=inpclp.HDRAGC(coef_gain=0.2, min_gain=0.1, max_gain=1.0, coef_sat=1.0, corrector=0.8, reducer=2.0, black_clip=0.5) # default. +coef_gain=brighter decrease to limit. +coef_sat=more saturation
inpclp=inpclp.HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)
#inpclp=inpclp.HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=1.0, corrector=0.8, reducer=2.0, black_clip=1.0)
#inpclp=inpclp.HDRAGC(coef_gain=0.1, min_gain=0.2, max_gain=1.0, coef_sat=1.0, corrector=0.8, reducer=2.0, black_clip=1.0)
return inpclp
}
function MVDegrain1i2_insideMTi(clip srcclp, int "blksize", int "overlap", int "dct", bool "doAGC") {
doAGC=default(doAGC,TRUE)
# AssumexFF() must have been done prior to calling this function
blksize=default(blksize,8) # # 4, 8 or 16 ( default is 8 ). Larger blocks are less sensitive to noise, are faster, but also less accurate.
overlap=default(overlap,2) # overlap value (0 to 4 for blksize=8) Must be even and less than block size
dct=default(dct,0) # use dct=1 for clip with light flicker
fields=srcclp # FIELDS ALREADY SEPARATED BY MTi SO DON'T DO HERE
super = fields.MVSuper(pel=2, chroma=true, sharp=2) # half-pixel accuracy of the motion estimation
backward_vec2 = super.MVAnalyse(isb = true, delta = 1, blksize=blksize, overlap=overlap, dct=dct, chroma=true)
forward_vec2 = super.MVAnalyse(isb = false, delta = 1, blksize=blksize, overlap=overlap, dct=dct, chroma=true)
fields=fields.MVDegrain1(super, backward_vec2,forward_vec2,thSAD=400,plane=4)
doAGC ? fields.AGCiEmbedded() : fields
# FIELDS WILL BE RE-WEAVED by MTi SO DON'T DO IT HERE
}
I'd thought "original=LAST" was creating a clip variable I could use, like the "L1=" lines were... Can you please point me somewhere which explains the difference ? as they look the same to me.
Gavino
2nd December 2008, 15:33
Oh. Thanks. Swapping between the two L1 lines confirmed I get different size results for each.
original=LAST
L1 = MTi("original.MVDegrain1i2_insideMTi(doAGC=FALSE)")
#L1 = MTi("last.MVDegrain1i2_insideMTi(doAGC=FALSE)")
L1
I'd thought "original=LAST" was creating a clip variable I could use, like the "L1=" lines were...
It does, but the string parameter to MTi has to represent a filter called without an explicit clip and is evaluated inside Mti.
Both your L1 lines are wrong, the second one works by accident because "last" is not the value at the point of calling MTi, but the value inside MTi when the string is evaluated.
What you actually want is
L1 = original.MTi("MVDegrain1i2_insideMTi(doAGC=FALSE)")
halsboss
3rd December 2008, 12:58
Yes, thankyou, that seems to clear that up. Now for a strange one...
In the script below, the L1, L2, L3 items work fine (un-commenting out , re-commenting-out) but L4 doesn't and throws the error message
Script Error: Invalid arguments to function "HDRAGC"
I hadn't expected that error, since L3 worked OK and is functionally equivalent, and L2 works and is functionally equivalent too. Any ideas on why the error occurs ?
original=LAST
#L1 = original.SeparateFields().HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0).Weave()
#L2 = original.MTi("HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)")
#L3 = original.SeparateFields()
#L3e = L3.SelectEven().AGCiEmbedded()
#L3o = L3.SelectOdd().AGCiEmbedded()
#L3 = Interleave(L3e,L3o).Weave()
L4 = original.MTi("AGCiEmbedded()")
#L1
#L2
#L3
L4
function AGCiEmbedded(clip srcclp) {
inpclp = srcclp
# other processing
inpclp=inpclp.HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)
return inpclp
}
Gavino
3rd December 2008, 15:09
Very odd. I too would have expected it to work.
What happens if you change the function to
function AGCiEmbedded(clip srcclp) {
return srcclp.HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)
}
(Clearly this should make no difference but something strange is happening somewhere.)
halsboss
3rd December 2008, 16:48
Hmm, no success until I tried L6 and L7 - both of which work whereas L4 and L5 don't. Not sure why.
SetMTmode(mode=5,threads=1) # start with mode=5 forAVIsource http://forum.doom9.org/showthread.php?p=1067216#post1067216
SetMemoryMax(256)
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-xxx\AGC.dll")
AviSource("G:\HDTV\capt\capt-type1.08-11-30_20-39.00.avi", audio=false)
AssumeFPS(25)
AssumeBFF()
original=LAST
#L1 = original.SeparateFields().HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0).Weave()
#L2 = original.MTi("HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)")
#L3 = original.SeparateFields()
#L3e = L3.SelectEven().AGCiEmbedded()
#L3o = L3.SelectOdd().AGCiEmbedded()
#L3 = Interleave(L3e,L3o).Weave()
#L4 = original.MTi("AGCiEmbedded()")
#L5 = original.MTi("Gavino()")
#L6 = original.AssumeBFF().MTi("Gavino()")
L7 = original.AssumeBFF().MTi("AGCiEmbedded()")
#L1
#L2
#L3
#L4
#L5
#L6
L7
function Gavino(clip srcclp) {
return srcclp.HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)
}
function AGCiEmbedded(clip srcclp) {
inpclp = srcclp
# other processing
inpclp=inpclp.HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)
return inpclp
}
Gavino
3rd December 2008, 18:00
Curiouser and curiouser. In principle, they should all behave the same.
Perhaps it's a threading/timing problem within MTi.
halsboss
4th December 2008, 07:50
this works too
original=LAST.assumebff()
L8 = original.MTi("AGCiEmbedded()")
L8
Gavino
4th December 2008, 12:04
And is the failure always the same - 'Invalid arguments to function "HDRAGC" '?
That suggests that 'srcclp' is not a clip, but if that's the case I would expect 'Invalid arguments to function AGCiEmbedded' instead and the function would never be called. :confused:
What happens if you replace HDRAGC by something else?
(Perhaps even a dummy function with the same interface.)
I suspected a threading problem but I have had a quick look at the source code of Mti and it looks like this bit (setting up the parallel filter chains) is single-threaded. Can anyone familiar with the internal workings of MT shed some light on what is going on?
halsboss
4th December 2008, 14:05
And is the failure always the same - 'Invalid arguments to function "HDRAGC" '? yes, it is.
:confused: It sort of seems like minor data corruption or omission about remembering xFF setting when a clip variable hasn't had an explicit AssumexFF() and when it gets fed into MTi. When a clip variable has an AssumexFF() applied to it, then it seems to follow though into MTi OK.
Fizick
4th December 2008, 18:41
What if you remove this first line:
SetMTmode(mode=5,threads=1)
?
seggitek
4th December 2008, 22:08
SetMTMode() place this at the first line in the avs file to enable temporal (that is more than one frame is processed at the same time) multithreading. MTi() that creates two threads and let each thread process one frame before interleaving them.
Does this mean that MTi is the same as SetMTMode(..., threads=2) with the only difference that MTi enables mutlithreading only for the filter passed to it?
MTsource() that are used to run source filters multithreaded.
What are source filters? :confused:
thetoof
4th December 2008, 22:40
What are source filters? :confused:
Avisource, mpeg2source, whateversource
Gavino
5th December 2008, 00:32
Does this mean that MTi is the same as SetMTMode(..., threads=2) with the only difference that MTi enables mutlithreading only for the filter passed to it?
No.
SetMTMode: more than one frame is processed at the same time.
MT/MTi: different parts of the same frame are processed at the same time (and then joined together).
Gavino
5th December 2008, 16:00
@halsboss
Can you consistently reproduce your problem?
I tried (using the latest MT and special Avisynth) and was unable to do so. Everything worked as it should.
Is it possible that your failures were done with the function having an optional clip parameter?
function AGCiEmbedded(clip "srcclp") { ...
That would be an inappropriate function to pass to MTi and would produce the error you saw.
halsboss
5th December 2008, 22:56
Hi and thanks for looking at it. Post 1021 http://forum.doom9.org/showpost.php?p=1219886&postcount=1021 was a snipped version of the the actual script, no quotes in
function AGCiEmbedded(clip srcclp) {
It was consistently reproducible across reboots. It's a .DV source, and the latest ffdshow codec although that shouldn't make any difference. Avisynth v 2.57 tsp MT version 5, build:Mar 1 2007. No special s/w, a fairly clean PC with the latest h/w drivers and all MS patches and Trend 2008 internet security, I'm not one for installing a lot of junk :) How can I edit out a 1-sec part of the .AVI to load that too ?
I'll check on the latest download of HDRAGC and try it again.
halsboss
5th December 2008, 23:24
That's got me. It failed across reboots then. Now the script below works !! And it looks the same to me as the above. Nothing changed in the meantime except that Trend internet security updated itself and I had to recreate the script below.
I guarantee that I swapped back and forth between L5,L6 and L7,L8 etc a number of times to check it and got the error in one and not the other. I'l terribly upset about it.
SetMTmode(mode=5,threads=1) # start with mode=5 forAVIsource http://forum.doom9.org/showthread.php?p=1067216#post1067216
SetMemoryMax(256)
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-xxx\AGC.dll")
AviSource("G:\HDTV\capt\capt-type1.08-11-30_20-39.00.avi", audio=false)
AssumeFPS(25)
AssumeBFF()
original=LAST
#L1 = original.SeparateFields().HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0).Weave()
#L2 = original.MTi("HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)")
#L3 = original.SeparateFields()
#L3e = L3.SelectEven().AGCiEmbedded()
#L3o = L3.SelectOdd().AGCiEmbedded()
#L3 = Interleave(L3e,L3o).Weave()
#L4 = original.MTi("AGCiEmbedded()")
L5 = original.MTi("Gavino()")
#L6 = original.AssumeBFF().MTi("Gavino()")
#L7 = original.AssumeBFF().MTi("AGCiEmbedded()")
#original=LAST.assumebff()
#L8 = original.MTi("AGCiEmbedded()")
#L1
#L2
#L3
#L4
L5
#L6
#L7
#L8
function Gavino(clip srcclp) {
return srcclp.HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)
}
function AGCiEmbedded(clip srcclp) {
inpclp = srcclp
# other processing
inpclp=inpclp.HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=0.75, corrector=0.8, reducer=2.0, black_clip=1.0)
return inpclp
}
Gavino
6th December 2008, 00:05
That's got me. It failed across reboots then. Now the script below works !! And it looks the same to me as the above. Nothing changed in the meantime except that Trend internet security updated itself and I had to recreate the script below.
If you're quite sure about that, then it looks like the worst sort of bug - a randomly occurring one. :eek:
Memory corruption, uninitialised data, timing dependency, etc.
I doubt that the nature of your source file or even the version of HDRAGC is a factor, since the error in question is produced at 'compile-time' by the Avisynth script interpreter (no frames have yet been requested) and the evidence suggests it never gets as far as entering HDRAGC.
The problem possibly lies in the modifications to the parser for the MT version of Avisynth. Did you try Fizick's suggestion of removing SetMTMode altogether?
halsboss
6th December 2008, 00:54
Yes, I am sure. I really can't believe it. I'll be testing it every day for a while. I'll try the setmtmode removal and see what happens. Next time I have an anomalous encounter I'll test it out on a second PC.
EDIT tried with and without setmtode, all works fine every time. Still can't believe it.
seggitek
6th December 2008, 20:06
No.
SetMTMode: more than one frame is processed at the same time.
MT/MTi: different parts of the same frame are processed at the same time (and then joined together).
Are you sure? The first page says "MTi() that creates two threads and let each thread process one frame before interleaving them. ".
Gavino
6th December 2008, 21:03
Are you sure? The first page says "MTi() that creates two threads and let each thread process one frame before interleaving them. ".
No, it says "let each thread process one field before interleaving them", a field of course being half a frame.
MTi is like MT, except that the frames, instead of being split in half vertically or horizontally, are separated into fields.
A very good pictorial description of the differences between SetMtMode and MT can be found here (http://avisynth.org/mediawiki/MT_support_page#Differences_between_MT.28.29_and_SetMTMode.28.29).
For MTi, the picture would be different because of what I just said, but the principle is the same.
Adub
8th December 2008, 09:43
Okay, I am a little unsure about posting this here, but I have discovered a "bug". The reason I use quotes is I am, again, a little unsure about the circumstances.
I originally discovered it while converting a Blu ray to DVD. I indexed the source m2ts using DGAVCindex, and created an avs file containing this:
#setmtmode(2)
avcsource("main movie.dga")
crop(0,140,0,-140)
Spline36resize(720,480)
Notice the comment on setmtmode? This is because, when I uncomment it, and drop the file into MPC, the screen flashes a little green, starts playing the file for around 3 seconds and then I get this:
http://i34.photobucket.com/albums/d125/Merlin7777/MTerror.png
Two error windows pop up as you can see.
It took a me a little while, but I did narrow it down. It seems the problem lies with DGAVCIndex, and it partner dll. When I load a file indexed with DGAVCindex, and use Setmtmode(), I get the crash. This is immediately apparent when HD material is used.
On SD material, it is a little more isolated, but if you job around on the seek bar, it happens as well.
I do not know the exact cause of the error, or which program is at fault. So I thought I would post it here to start out.
This is on Windows XP SP3 x86, stock Q6600, 4gb ram.
Gavino
8th December 2008, 14:54
Here's an odd thing. Run this script
function f(clip c) {
global n = n+1
return c
}
SetMTMode(1, 3)
global n = 0
BlankClip()
MTi("f()")
Subtitle((string(n))
and you will find that n=4, showing the function f is called four times.
It's not surprising it is called more than once, as that is what MTi() is advertised to do, but I would expect n=2.
The result is independent of the parameters passed to SetMTMode - again, to be expected since MT is documented as always setting MT mode temporarily to 5. But removing the SetMTMode altogether produces the 'expected' result n=2.
(Calling f directly instead of via MTi gives n=1, independent of SetMTMode settings.)
If the MTi line is changed to MT("f()", k) for any integer k, the function is called 2*k times instead of the expected k.
I'm not sure if this is a bug or a feature, but it's certainly surprising.
It may or may not have anything to do with the problem reported by halsboss (post #1021), but at least it shows that strange things can happen with user functions and MT/MTi when SetMTMode is also used.
Fizick
8th December 2008, 17:40
Merlin7777,
report to author of avcsource.
Adub
8th December 2008, 20:01
Okay, I'll send him a PM.
Sagekilla
8th December 2008, 20:07
@Gavino, if I had a to wager a guess I'd say that using MTi(f(c), threads) will evaluate function f(c) twice, once for the top fields, once for the bottom fields, that's why you get 2*k.
Gavino
8th December 2008, 20:30
@Gavino, if I had a to wager a guess I'd say that using MTi(f(c), threads) will evaluate function f(c) twice, once for the top fields, once for the bottom fields, that's why you get 2*k.
MTi doesn't have a threads parameter, it always has exactly two threads, one for the top field and one for the bottom. That's why I expected n=2 in my example.
MT has the threads parameter, but here fields are irrelevant. The image is split into k parts and each is processed by its own thread, so I would expect n=k, not 2*k.
And when SetMTMode is removed, you do indeed get n=2 in the first case and n=k in the second one. So the effect is something to do with the interaction between MT/MTi and SetMTMode.
Adub
11th December 2008, 06:04
http://forum.doom9.org/showthread.php?p=1221788#post1221788
Can anyone confirm this behaviour?
ajp_anton
12th December 2008, 17:27
I have the script
a=avisource("a.avi")
b=avisource("b.avi")
stackhorizontal(a,b)
How can I do the avisources in separate threads? Whatever I try to do with MT, it only uses one of my two cores and runs at near half real-time.
IanB
14th December 2008, 05:06
Not sure the current engine can actually do this.
But experiment with this style :-SetMTmode(mode=5,threads=2)
a=AviSource("a.avi")
b=AviSource("b.avi")
SetMTmode(mode=2)
InterLeave(a, b)
StackHorizontal(SelectEven(), SelectOdd())You need to make sure each AviSource is hit with contiguous frame requests, but you want the 2 instances to be run in parallel. The InterLeave filter in MTMode 2 might just achieve this.
halsboss
31st December 2008, 01:26
Now that avisynth 2.5.8 is released http://forum.doom9.org/showthread.php?p=1229749#post1229749 what does this mean for MT and the MT-enabled version of avisynth ?
leeperry
31st December 2008, 02:09
Now that avisynth 2.5.8 is released http://forum.doom9.org/showthread.php?p=1229749#post1229749 what does this mean for MT and the MT-enabled version of avisynth ?
hopefully AvisynthMT will be updated :cool:
halsboss
5th January 2009, 00:38
I'd thought the following code would start 1-thread and then goes 4-threaded for the "working part", but it doesn't.
SetMTmode(mode=5,threads=1) # start with mode=5 forAVIsource http://forum.doom9.org/showthread.php?p=1067216#post1067216
SetMemoryMax(256)
# load plugins
MPEG2Source("G:\HDTV\1\test-1m.d2v",info=0,ipp=true,cpu=6)
AssumeFPS(25)
AssumeTFF()
# PURE VERSION PER http://forum.doom9.org/showthread.php?p=1185790#post1185790
SetMTmode(mode=2,threads=4) # mode=2 for temporal multi-threading (interleaved frames)
Global NewHeight=576
Global NewWidth=720
SeparateFields()
Shift = (GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
E = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
O = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
Weave()
Converttoyv12(interlaced=true)
SetPlanarLegacyAlignment(True)
Distributor() # use this when using HC and SetMTmode, per http://forum.doom9.org/showthread.php?p=1063622#post1063622
Tests with the HCenc log reveal it seems to stay one-threaded - the cpu and elapsed times stay the same when the 1st SETMTMODE is threads=1 vs no SETMTMODE statements (@ fps=12.4). Conversely, all threads=4 makes it a lot quicker elapsed time... at some cpu time cost, but who cares about that (@ fps=18.5).
Am I expecting too much for it to swap numbers of threads "on the fly" ?
LaTo
5th January 2009, 09:02
In the first post:
threads - number of threads to use. Set to 0 to set it to the number of processors available. It is not possible to change the number of threads other than in the first SetMTMode. Default value 0.
:p
halsboss
5th January 2009, 12:19
Oh. Missed that. Thanks.
rkalwaitis
17th January 2009, 19:07
TSP,
I have had success with MT and other filters, but I am experimenting with MC_Spuds. The settings I use allow me about 2.50fps. Then I remembered MT. So an attempt to apply your tool to the script gave me a response that I needed avisynth 2.6 or the mod version. Links? I tried the mod from your avisynth filters collection and it did not work for me. Do I keep the old avisynth.dll in the directory too.
So I tried with no avail. So I went on to do the Script without mt and noticed that I lost about 1.5fps, so now I was processing at 1.0fps roughly. I dont mind slow encoding, but there was no reason for the loss. I unistalled the MT_07.dll package and gained my extra 1.5fps back. I don't understand why the filter affects the script if it is not called.
which version of your MT may work with MC_Spuds_Mvt.avs?
Thanks for all the great things you give us all to tinker with.
K:thanks:
halsboss
20th January 2009, 09:00
snip.
duckyy
20th January 2009, 09:24
Hey,
I'm a very n00b at AVS :P
I own a Q6600 and want to use AVS for HD playback post-processing (LSF and GF at first)
I've installed AVS 2.57 and MT 0.7 to use them in ffdshow realtime.
First I just installed 2.57 and called Info() in ffdshow and it showed info (so far so good).
Then I replaced avisynth.dll in teh sys32 dir and added MT.dll in the plugins dir. I called MT("Info()",4), it crashed. Same with simple Info().
I'm using that new MPC that doesn't freeze when you seek. But I tried also KMP and it simply didn't load ffdshow (replaced by CoreAVC)...
I'm using the very latest ffdshow xxl. Could that be the reason of the crash? Maybe their MT workaround is somewhat incompatible with MT 0.7?
Maybe another call?
~bT~
20th January 2009, 10:42
^ version()
duckyy
20th January 2009, 11:43
Thanks!
Will post tonight when I'm back from work.
duckyy
20th January 2009, 17:16
AviSynth 2.57, build:Dec 31 2006 http://thumbnails15.imagebam.com/2418/a8737124177471.gif (http://www.imagebam.com/image/a8737124177471)
It's crashing again.
edit: solved my problem using 2.6.
thx to pbmtp on HCFR.
halsboss
22nd January 2009, 10:56
Sorry, I'm a little confused about the working of SetMTmode in certain situations, ie around MVtools' mvanalyses and MVdegrains.
With setmtmode(mode=2,threads=4) I gather it splits up consecutive frames and farms them off to separate threads - Does that then muck up Fizick's tools like mvanalyses and mvdegrains which are supposed to compare consecutive frames ? Can someone please confirm what is the case ?
If that is so, could MT() be the workable alternative I suppose ?
thetoof
22nd January 2009, 15:19
No.
MT separates the frames spatially, which is more likely to screw up your motion vectors calculation (if something moves from a part of the image that belongs to one thread to another, it won't be calculated).
However, with mvt2, there were a lot of stability fixes for setmtmode and because of the reason above, this is the way to go. It will of course use more memory than simple mvdegrains.
rkalwaitis
22nd January 2009, 22:24
Ducky,
Can I have the link to Avisynth 2.6 please.
halsboss
23rd January 2009, 04:13
with mvt2, there were a lot of stability fixes for setmtmode and because of the reason above, this is the way to go. It will of course use more memory than simple mvdegrains.
So, just to confirm,
setmtmode(mode=?,threads=4) is supposed to split off consecutive frames and pass these frames to separate threads, each of which separately runs the plugins specified (like mvanalyse, degrain, etc) on the (now non-consecutive, eg 1 in 4) frames it receives -
and that doesn't muck up the mvanalyses etc (which I gather rely on consecutive frames) because ?
cyberbeing
23rd January 2009, 04:24
Can I have the link to Avisynth 2.6 please.
If you are talking about the incomplete/unstable Avisynth 2.6 pre-alpha Wilbert built back in 2006, it can be found in this thread:
http://forum.doom9.org/showthread.php?t=114643 :search:
For something more recent, and possibly more broken, you would have to build it yourself from source.
thetoof
23rd January 2009, 04:29
What I understood is that the frames will be analysed 4 times (running 4 mvxxx in parallel), which is the big advantage of the mt branch of mvtools (1 multithreaded analysis used for 1 multithreaded call of mvdegrain). Anyone correct me if I'm wrong.
oh, and just to be sure you got that, setmtmode(mode=2, thread=whatever works best for you) should be used for mvt.
halsboss
23rd January 2009, 06:01
OK, that got me. The Wiki explanation/pictures http://avisynth.org/mediawiki/MT_support_page#Differences_between_MT.28.29_and_SetMTMode.28.29 shows consecutive frames getting farmed off to independent threads - which seems to imply (especially with 4 threads) that anything which relies on consecutive or near consecutive frame comparisons won't be getting what it thinks it is ? It'll get every 4th frame if you have threads=4, by the looks.
This further explanation of the SetMTmode (especially mode 2) http://avisynth.org/mediawiki/MT_modes_explained shows the separate threads processing separate frames ... which did nothing to dispel my fear on the effects on MV stuff.
Still confused on whether setMTmode plays nicely with the MV stuff (I'd like to stick with Fizick's gear rather than the "multi" stuff)
thetoof
23rd January 2009, 06:20
Other way to explain, mvdegrain2 example:
Thread 1 : process frame 330 - analyse frame 328,329,330,331,332 / process frame 334 - analyse frame 332,333,334,335,336
Thread 2 : request frame 331 - analyse frame 329,330,331,332,333 / process frame 335 - analyse frame 333,334,335,336,337
Thread 3 : request frame 332 - analyse frame 330,331,332,333,334 / process frame 336 - analyse frame 334,335,336,337,338
Thread 4 : request frame 333 - analyse frame 331,332,333,334,335 / process frame 337 - analyse frame 335,336,337,338,339
Return frame 330 (t1) + 331 (t2) + 332 (t3) + 333 (t4) and so forth
(and of course when I say frame x, it means "motion vectors from requested frame to frame x")
At least, that's what I think it does. (Logical assumption)
Therefore, it works "normally" except that the analysis is done in each threads (the same calculations can be done multiple times in different threads)
Is that clearer?
halsboss
23rd January 2009, 09:38
Thankyou. Trawling back through pages, I noticed http://forum.doom9.org/showthread.php?p=1108192#post1108192 where posts 832-837 and thereabouts refer to mvtools, where example scripts are shown.
rkalwaitis
23rd January 2009, 18:11
Cyberbeing, this was all the information that was given to me about it.
2.6 from pbmtp on HCFR. Is this the incomplete and unstable one built by Wilbert?
Ill use search next time and try using the incomplete and problematic programs before asking someone for the link to the ones that worked.
Thanks
rkalwaitis
25th January 2009, 19:13
Is it Necessary to put SetMT Mode twice in this script? One more time above the MCTemporalDenoise line?
Ive noticed that many people use set mode multiple times for various dlls. I do understand that different dlls react differently to varous setmodes or may not even work.
Do I have to put setmode for each filter used even if both of them may be a setmode2 dll?
SetMTMode(2,0)
AVISource("C:\Users\baba\Desktop\VTS_01_1.avi", audio=false)
#deinterlace
Converttoyv12()
#resize
#denoise
Import("C:\Users\baba\Desktop\MCTemporalDenoise\Deblock_QED.avs")
Import("C:\Users\baba\Desktop\MCTemporalDenoise\LSFmod.v1.3.avsi")
Import("C:\Users\baba\Desktop\MCTemporalDenoise\MCTemporalDenoise.v1.1.24.avsi")
MCTemporalDenoise(settings="medium", gpu=false)
jeffy
25th January 2009, 19:32
http://avisynth.org/mediawiki/MT_modes_explained
http://avisynth.org/mediawiki/MT_support_page
jeffy
25th January 2009, 19:33
Do I have to put setmode for each filter used even if both of them may be a setmode2 dll?
No, it is valid until another SetMTMode call.
halsboss
26th January 2009, 02:59
They say use mode=5 as the 1st line before the avisource or whatever and then another setmtmode, say 2, after that.
rkalwaitis
26th January 2009, 21:17
Ill Try that halsboss. I tried taking my source and doing my resize and deinterlacing to a lossless avi. I used lagarith. Set the avi to YV12 and added the audio stream I wanted. Ran it through VirtualDub. 35-40fps. Then I run the avi as script again through Virtualdub with only my cleanup (ex MCTemporalDenoise()). Gives me another boost of about 1.2-1.5fps, which takes hours off of an encode. So the first 30-45min pass to lossless is a good trade off and saves me time. I never would of thought about it until I noticed different resizers caused significant slowdowns on encoding. Bicubic seems to be the fastest. Lazsco seems slower.
but ill try mode 5 ont tope and then mode 2 above my denoiser.
Thanks
halsboss
26th January 2009, 22:30
OK. You could try mode=2 just after your avisource if there's other things you do before your denoiser...
Alexandros
28th January 2009, 12:15
Is there any way to speedup this simple script using MT?
avisource("Source1.avi",false)
Lanczos4Resize(720,340).Addborders(0,70,0,70)
AssumeFPS(23.976,false)
MT works on 2.5.8?
thanks!
thetoof
28th January 2009, 14:45
http://avisynth.org/mediawiki/MT_support_page
Ctrl + F resize
The latest MT build is based on 2.5.7
leeperry
28th January 2009, 14:49
MT works on 2.5.8?
nope :(
and I've PM'ed the OP, he never got back to me....so we'll have to wait for someone else to update it I guess :o
buletti
28th January 2009, 19:47
I think there are many people which are hesitating to switch to 2.5.8 because there is no multithreading enabled avisynth.dll available. I guess the MT.dll of version 0.7 might still work for 2.5.8 but the patched avisynth.dll is missing... :(
halsboss
30th January 2009, 03:42
It's a show-stopper for me. The elapsed-time savings benefits of setMTmode with it's multi-threading are just way way way too good to forego.
ikarad
8th March 2009, 17:04
I would like to known if Decomb (inverse telecine) can be multithread with avisynth-mT?
halsboss
19th April 2009, 08:22
:) 3 months later and it's still a show-stopper. Anyone know tsp's position ?
Boulder
19th April 2009, 09:35
You might want to try SEt's v2.5.8 MT build: http://forum.doom9.org/showthread.php?t=144852&page=2
halsboss
31st May 2009, 01:08
Thanks Boulder, thought I'd patiently await tsp for a bit longer. Any news ?
BigDid
31st May 2009, 18:59
Hi,
None that I know.
I use the 2.58 set without more issues than with the 2.57 package, Adub made a download package, ready to use, you may want to give it a try:
http://forum.doom9.org/showthread.php?p=1286353#post1286353
Did
halsboss
19th July 2009, 03:30
Thanks. No official word from TSP ?
Revgen
23rd July 2009, 07:59
TSP hasn't visited this site since April 30 2009.
On top of that, he has repeatedly said that until Avisynth 2.6 is released with the official MT implementation that he already submitted, then he won't work on it anymore.
Judging by how long it took for 2.5.8 to be released, 2.6 is probably going to take awhile.
elmarikon
7th October 2009, 20:03
Hi Guys!
I am using MT a lot, and I was wandering, if anyone has an idea, how to multithread immaavs (http://forum.doom9.org/showthread.php?t=135928) image writer...
I have a dual 8 core PC, which now makes a speed of about 1 - 2 fps, but is just using like 10% of the processor(s)
I was trying a lot, but nothin' worked..:-(
any ideas?
All the best so far!
BigDid
7th October 2009, 22:01
Hi,
Please go back to this thread:
http://forum.doom9.org/showthread.php?p=1332460#post1332460
MT 0.7 for avisynth 2.57 is quite obsolete, even if partly used in avisynth MT 2.58 or MT 2.6.
Did
halsboss
8th October 2009, 09:25
MT 0.7 for avisynth 2.57 is quite obsolete, even if partly used in avisynth MT 2.58 or MT 2.6.
Hmm, checked out the 2.5.7 -> 2.5.8 changelog and there's quite a lot. I still use TSP's MT version of 2.5.7 because it works and has been reliable for me. Thought about non-TSP MT 2.5.8 which some have used, but I didn't gain a lot of confidence from the threads discussing that so I left it alone. So I'm still with TSP's MT version of 2.5.7, obsolete or not... I can't live without multithreading :)
The dev thread http://forum.doom9.org/showthread.php?t=149113 mentions 2.6 alpha releases so I'll keep checking there.
BigDid
8th October 2009, 20:05
Hi,
I should have said avisynth 2.57 (with or without MT) is quite obsolete...
MT for 2.58 is quite stabilized and works well (at least for me with 2 cores and xvid encoding). I know there are some issues for multicores and x264.
Stable-MT for 2.6 is awaited, but it seems MT has been rated low on priorities by the 2.6 developpment team.
SET is releasing some MT-binaries that has to be tested before intensive usage and are behind the mono/main releases.
Did
levi
8th October 2009, 22:25
My experience has been that this MT 0.7 is the only one that can make use of my quad core i7 based turbo (hyperthreaded) zeon CPU. I tried a few 2.5.8 / 2.6 versions & they all just end up hanging / crashing.
MT 0.7 on the other hand runs (for example) x264 encodes of HDTV captures @ 100+ FPS
varied
13th October 2009, 18:43
Hi there!
I often compare different results of a filter this way:
...
a=last.filter(1)
b=last.filter(2)
c=last.filter(3)
d=last.filter(4)
StackVertical(StackHorizontal(a, b), StackHorizontal(c, d) )
...
So I was wondering if I could somehow apply MT here to have 4 threads. Or is that impossible?
Thanks in advance!
thewebchat
13th October 2009, 21:09
Why not just MT each filter? It's not like StackHorizontal/Vertical uses up much CPU time anyway.
varied
14th October 2009, 20:34
Thanks for taking Your time suggesting me that, but I already use that approach when dealing with filters which don't use motion estimation or something similar. Oh, and my concern wasn't Stack* filters, but four instances of the same filter with different parameters
So the answer is no then.
And :thanks:
Jeremy Duncan
19th October 2009, 03:04
I tried a few 2.5.8 / 2.6 versions & they all just end up hanging / crashing.
Try the new ones: link (http://www.mediafire.com/?kghxrwtzmrx)
hydra3333
3rd December 2009, 09:20
I was hoping to multi-thread this by putting "SetMTmode(mode=2,threads=4)" just before the Addborders, but when I do that it spits with invalid parameter in AddBorders... any suggestions ?
SetMTmode(mode=5,threads=4) # start with mode=5 forAVIsource http://forum.doom9.org/showthread.php?p=1067216#post1067216
SetMemoryMax(128)
-------------------------------------------------------------------------------------
# Plugins were loaded here
-------------------------------------------------------------------------------------
Import("C:\Program Files\AviSynth 2.5\LimitedSharpenFaster.avs")
Import("C:\Program Files\AviSynth 2.5\dcwresize.avsi")
#Import("C:\Program Files\AviSynth 2.5\DeHalo_alpha.avsi")
Import("C:\Program Files\AviSynth 2.5\Deblock_QED_MT2.avs")
#Import("C:\Program Files\AviSynth 2.5\YLevels.avsi") # from http://forum.doom9.org/showthread.php?p=525465#post525465
# -------------------------------------------------------------------------------------
#
FRAMERATE=25
WIDTH=704
HEIGHT=576
#
# Use AVISource for .AVI files
# per this thread http://forum.videohelp.com/topic363395.html#1934100
AviSource("G:\DVD\CAPT\capt-1997-05-25-ffd1.avi", audio=false)
AssumeFPS(25)
AssumeTFF()
#
# Now, assume the capture had 12 cropped off the borrom - add 12 to the bottom now
Addborders(0, 0, 0, 12)
#
# From http://avisynth.org.ru/mvtools/mvtools2.html#examples
#
function MDegrain1i2(clip source, int "overlap", int "dct") {
overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker
fields=source.SeparateFields() # separate by fields
super = fields.MSuper()
backward_vec2 = super.MAnalyse(isb = true, delta = 2, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, overlap=overlap, dct=dct)
fields.MDegrain1(super, backward_vec2,forward_vec2,thSAD=400)
Weave()
}
function MDegrain2i2(clip source, int "overlap", int "dct") {
overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker
fields=source.SeparateFields() # separate by fields
super = fields.MSuper()
backward_vec2 = super.MAnalyse(isb = true, delta = 2, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse(isb = true, delta = 4, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse(isb = false, delta = 4, overlap=overlap, dct=dct)
fields.MDegrain2(super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400)
Weave()
}
#
mdegrain1i2(4,0)
#mdegrain2i2(4,0)
#
# If black and white movie, use these
#Limiter()
#Greyscale()
# If GAMMA needs adjusting, do so here
#Levels(0, 1.15, 255, 0, 255, coring=false)
########
#Convolution3D(0, 3, 4, 3, 4, 2.8, 0)
#Convolution3D(0, 6, 10, 6, 8, 2.8, 0)
#Convolution3D(0, 32, 128, 16, 64, 10, 0)
#Convolution3D(0, 32, 128, 32, 128, 10, 0)
#Convolution3D(1, 32, 128, 32, 128, 10, 0) #blur more for very very bad
#FFT3DFilter(sigma=2.5, plane=4, sharpen=1.0, degrid=1.0, interlaced=true)
#FFT3DFilter(sigma=3, sharpen=1.0, degrid=1.0, interlaced=true)
#FFT3DFilter(sigma=4, plane=0, sharpen=1.0, degrid=1.0, interlaced=true) # luma first
#FFT3DFilter(sigma=8, plane=3, sharpen=1.0, degrid=1.0, interlaced=true) # chromas next with more filtering
# http://forum.doom9.org/showthread.php?p=1084125#post1084125
# DegrainMedian, it gets a huge boost at least when wrapped inside an MT call
# http://forum.doom9.org/showthread.php?p=1109515#post1109515
# DegrainMedian benefits much more from using MT than using SetMTMode
#DeGrainMedian(limitY=5,limitUV=7,mode=0,interlaced=true)
# mode=1 Lesser but strong grain removal, on top
#DeGrainMedian(limitY=2,limitUV=3,mode=1,interlaced=true)
#DeGrainMedian(limitY=2,limitUV=3,mode=1,interlaced=true)
#DeSpot(interlaced=true)
#DeSpot(median=false, interlaced=true, seg=2, show=0) # SAFE
#DeSpot(median=false, interlaced=true, seg=0, show=0) # seg=0 means STRONG
#DeSpot(p1=35, p2=14, mthres=25, interlaced=true) # UP the limits before it's considered noise
#
# HDRAGC *can't* be used inside MT or AGC will be calculated differently in each slice
#HDRAGC(coef_gain=0.1, min_gain=0.1, max_gain=0.5, coef_sat=1.0, corrector=0.8, reducer=2.0, black_clip=1.0)
#HDRAGC()
#
SeparateFields() # separate by fields
#Lanczos4Resize(clip clip int target_width, int target_height)
Lanczos4Resize(704, last.height()) # resize the width only from 720 to 704
LimitedSharpenFaster(smode=4,strength=100)
Weave() # separate by fields
#
#ScriptClip("""subtitle("Clip Frame " + string(current_frame),size=25)""")
Converttoyv12()
SetPlanarLegacyAlignment(True)
# Distributor() should only be used when loading the script into applications which talk to avisynth directly
# e.g. HC and MeGUI. If the program opens the .avs file as an avi file (like virtualdub/mod, x264, xvid_encraw etc.)
# then you don't need (and shouldn't have) the distributor call at the end.
# http://forum.doom9.org/showthread.php?p=1136518#post1136518
##### "HC uses custom avisynth routines, you have to add Distributor() to the end of the script."
Distributor() # use this when using HC and SetMTmode, per http://forum.doom9.org/showthread.php?p=1063622#post1063622
# http://forum.doom9.org/showthread.php?p=1067589#post1067589
# ChangeFPS(Last, Last, True) makes fast scripts faster and slow scripts slower !!
#ChangeFPS(Last, Last, True) # use this when using HC and SetMTmode, per http://forum.doom9.org/showthread.php?p=1064118#post1064118
Dogway
30th January 2010, 04:52
Is there anyway to make this multi-threaded? I have read many many threads and the more I read the more I get lost. Ive seen some codes for mvanalyse, but I dont know how to make it work with mvmask, average, maskedmerge, etc All I get is jumpy frames once in a while.
## MVDegrain3
source = last
pred = source
backward_vec3 = pred.MVAnalyse(isb = true, delta = 3, chroma=false,pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
backward_vec2 = pred.MVAnalyse(isb = true, delta = 2, chroma=false,pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
backward_vec1 = pred.MVAnalyse(isb = true, delta = 1, chroma=false,pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec1 = pred.MVAnalyse(isb = false, delta = 1, chroma=false,pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec2 = pred.MVAnalyse(isb = false, delta = 2, chroma=false,pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec3 = pred.MVAnalyse(isb = false, delta = 3, chroma=false,pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
maskp1 = mvmask(kind=1, vectors=forward_vec1, ysc=255).UtoY()
maskp2 = mvmask(kind=1, vectors=forward_vec2).UtoY()
maskp3 = mvmask(kind=1, vectors=forward_vec3).UtoY()
maskp4 = mvmask(kind=1, vectors=backward_vec1, ysc=255).UtoY()
maskp5 = mvmask(kind=1, vectors=backward_vec2).UtoY()
maskp6 = mvmask(kind=1, vectors=backward_vec3).UtoY()
maskf = average(maskp1, 0.25, maskp2, 0.25, maskp3, 0.25, maskp4, 0.25, maskp5, 0.25, maskp6, 0.25).Spline36resize(source.width, source.height)
smooth = pred.fft3dfilter(bw=16, bh=16, ow=8, oh=8, bt=5, sigma=4, plane=0,ncpu=2)
source2 = maskedmerge(source, smooth, maskf)
source3 = source2.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=400,idx=3)
source3
MT("""ttempsmooth(maxr=7)""",4,2)
hydra3333
30th January 2010, 05:57
Well, (nothing to do with multithreading) it's the "older" mv mvtools. have a look at the download page for the new tools and function names.
kool
30th January 2010, 17:58
Hi,
Can some one point me to right version for my platform, I'm using Win 7 64-bit Intel i7 CPU and Avisynth 2.5.8. I have found so far this (http://forum.doom9.org/showpost.php?p=1286353&postcount=77) and this (http://forum.doom9.org/showpost.php?p=1362209&postcount=233) build but I don't know which one to use, or if there is other one please point me to it as well.
Thanks in Advance.
cweb
30th January 2010, 20:53
Hi,
Can some one point me to right version for my platform, I'm using Win 7 64-bit Intel i7 CPU and Avisynth 2.5.8. I have found so far this (http://forum.doom9.org/showpost.php?p=1286353&postcount=77) and this (http://forum.doom9.org/showpost.php?p=1362209&postcount=233) build but I don't know which one to use, or if there is other one please point me to it as well.
Thanks in Advance.
I use SET's build (http://forum.doom9.org/showthread.php?t=148782), which works for me better than the last one you linked to. YMMMV I'm using 32-bit Win7 on amd.
kool
30th January 2010, 22:17
isn't that for Avisynth 2.6? I'm using 2.5.8
hydra3333
31st January 2010, 06:03
Depends what you want in the way of stability.
I'm sticking with 2.5.7 and TSP's "proper" and fully proven MT0.7 multi-threaded.
Since there are few (if any) proven 64 bit plugins etc the 32 bit would seem to be "it". Read up on the threads about later builds (especially MT stuff) and then cross your eyes and wonder why you would take the risk over something proven workable - risk vs benefit... what specifically would a new version give you, if anything, apart from potential hassles ?
kool
31st January 2010, 08:25
hmn, So here which installer I must use Avisynth 2.5.8 and replace the avisynth.dll with the one in post 1 or Avisynth 2.5.7 ?
hydra3333
31st January 2010, 09:15
Well, I am no expert and just stick with the easy reliable stuff. I'd still like to see someone post on specific benefits of the newer version(s).
I would venture a guess that since MT0.7 is 2.5.7 based, it may be safest to install avisynth 2.5.7 and replace the the DLL with the MT0.7 anisynth.dll according to its instructions.
If you're using some filters like Fizick's MVtools2 etc, don't forget to follow his instructions re d/l and copying 32bit fftw3.dll into Windows\System32 (or equiv 32bit folder on 64 bit o/s) - Make sure you have the right versions. If I recall, the d/l is somewhere on here http://www.fftw.org/install/windows.html however I vaguely recall an issue with a new version of it, so maybe check on Fizick's site to check it out.
Some other plugins may require the right C++ 2005/2007 runtimes - here's a couple of Microsoft links to the end-user installs for those runtimes -
http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en
I'm unsure about the Win7 validity of those, you may like to search microsoft yourself to ensure they're the latest.
In some cases you might also need to source the latest versions of msvcp71.dll and msvcr71.dll and copy those into Windows\System32 (or equiv 32bit folder on 64 bit o/s).
Dogway
2nd February 2010, 14:19
Well, (nothing to do with multithreading) it's the "older" mv mvtools. have a look at the download page for the new tools and function names.
I dont know what's wrong with the code. I took it from here http://avisynth.org/mediawiki/Denoisers and adapted it to MvDegrain3. Mvtools is one thing that I struggle to understand, there are too many functions with many flags.
isnt there an easy standard heavy MvDegrain3 script? The MvTools download page only shows MvDegrain2 examples with MvAnalyse and then the function MvDegrain. I wonder if thats a lazy script or better ones are possible (smarter).
Anyway, I will have a look on the MvTools thread, although Im afraid everything has to do with the other functions.
hydra3333
2nd February 2010, 14:39
I dont know what's wrong with the codehave a look at the NEW sources ... functions MVxxxx are replaced by Mxxxx ... http://avisynth.org.ru/mvtools/mvtools2.html
isnt there an easy standard heavy MvDegrain3 script? The MvTools download page only shows MvDegrain2 examples with MvAnalyse and then the function MvDegrain. I wonder if thats a lazy script or better ones are possible (smarter).
Anyway, I will have a look on the MvTools thread, although Im afraid everything has to do with the other functions.
Some commented-out roughie examples which might work:-
#progressive-only MSUPER/MDegrain1 for use with SetMTMode(2)
#super = MSuper(pel=2,chroma=true)
#backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=8, overlap=4, chroma=true)
#forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=8, overlap=4, chroma=true)
#MDegrain1(super, backward_vec1,forward_vec1,thSAD=400,plane=4)
#
#progressive-only MSUPER/MDegrain2 for use with SetMTMode(2)
#super = MSuper(pel=2,chroma=true)
#backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=8, overlap=4, chroma=true)
#backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=8, overlap=4, chroma=true)
#forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=8, overlap=4, chroma=true)
#forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=8, overlap=4, chroma=true)
#MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,plane=4)
#
#progressive-only MSUPER/MDegrain3 for use with SetMTMode(2)
#super = MSuper(pel=2,chroma=true)
#backward_vec3 = MAnalyse(super, isb = true, delta = 3, blksize=8, overlap=4, chroma=true)
#backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=8, overlap=4, chroma=true)
#backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=8, overlap=4, chroma=true)
#forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=8, overlap=4, chroma=true)
#forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=8, overlap=4, chroma=true)
#forward_vec3 = MAnalyse(super, isb = false, delta = 3, blksize=8, overlap=4, chroma=true)
#MDegrain3(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=400,plane=4)
Dogway
2nd February 2010, 15:14
Thanks a lot. Right now I was just reading about that of Mvtools2 and msuper stuff. This is more complete so its helpful, now theres no need for motion compensation or mask? Im talking from my ignorance, just trying to stick to an useful script and dont tweak much.
I saw on the thread a similar script starting with a sharpener, I dont know the "usefulness" of it.
Anyways its a starting point. I will try to develop from it on the mvtools thread. thank you.
src = last
shrp = src.msharpen()
src_super = src.MSuper()
shrp_super = shrp.MSuper(levels=1)
bv3 = MAnalyse(src_super, isb=true, delta=3, overlap=4)
...
hydra3333
3rd February 2010, 09:46
Those are questions for the thread on MVtools, not MT ...
Dogway
15th February 2010, 09:44
Thanks hydra, I have improved quite a bit since then.
Now I have some questions on MT.
I would like to know if theres a way to use Deen with MT; if it isnt what other filter does a similar function? Now Im using SetMTmode(5) with it, but it slows down the script very much.
Another question. Right now Im dealing with a Avisynth 2.5.7 and MT 0.7 on a Windows 7 x64, 4 cores. And I can only make work the cpu to 25%, but If I use MT("filter") It works up to 100%. Is there any info about this? Some incompatibility with certain CPU's?
hydra3333
15th February 2010, 10:19
Sorry, never used Deen. With a Q9450 4-core, I always use SetMTmode(mode=5,threads=4) as the 1st line (before any Opens) and then SetMTmode(mode=2,threads=4) just after any Open and AssumexFF and AssumeFPS statements. I also use Distributor() as the last line in the script.
# Distributor() should only be used when loading the script into applications which talk to avisynth directly
# e.g. HC and MeGUI. If the program opens the .avs file as an avi file (like virtualdub/mod, x264, xvid_encraw etc.)
# then you don't need (and shouldn't have) the distributor call at the end.
# http://forum.doom9.org/showthread.php?p=1136518#post1136518
##### "HC uses custom avisynth routines, you have to add Distributor() to the end of the script."
Distributor() # use this when using HC and SetMTmode, per http://forum.doom9.org/showthread.php?p=1063622#post1063622
SetMTmode works quite differently to MT function, please refer to the wiki for examples of that (also be careful with interlaced material).
I have a Q9450 4-core with 4Gb, 2 sata disk arrangement, and venerable XP, where the input is from one disk and the output is to the other (to maximise throughput) and I have almost never see 100% cpu utilization (hovers 50%-75% depending).
I am encoding with HCenc023, what are you using ? Is it a limitation in your encoder ? After that, I'm out of ideas.
Dogway
15th February 2010, 10:38
I do the same as you, but I use Megui. I think I dont need the Distributor since I have no problems opening them in the previewers.
I normally use MT() for certain filters only as tnl, or other heavy ones, as SetMTmode goes quite nice. Thanks for the help, I will try to do some more tests.
hydra3333
15th February 2010, 11:00
OK. Don't forget to use a good "overlap" if you're using the MT function since it splits up the picture to process :) Why not test Distributor() and see if it helps ? I wouldn't know, but hey if you come up a winner you'd be really happy.
Oh, if you're doing 2-pass encoding then you'd expect enormous elapsed times since your script is being processed twice (unless megui is smart and uses the lossless file approach). If you do it by hand, consider using the lossless file approach (for hcenc023, remember to put 2 or more spaces after the relevant keyword in HC's .ini file if you use one). You need looots of free disk space.
Dogway
15th February 2010, 11:06
This is how I use it. MT("""tnlmeans(ax=3,ay=3,az=8,sx=2,sy=2,bx=1,by=1,sse=true)""",4,2), Im not sure but 4 is the overlap right? and 2 threads. or the other way around? Help says overlap is in case I have artifacts on the borders, so I set margin.
I will try Distributor() then, although my system goes pretty good, the real problem was on a friend's, but I will give it a chance anyway.
Gavino
15th February 2010, 11:20
I do the same as you, but I use Megui. I think I dont need the Distributor since I have no problems opening them in the previewers.
If you don't call Distributor() when using an application that requires it, the script will still open without problems, but you will lose the benefit of the multi-threading.
Also, because of the different ways that SetMTMode() and MT() work (see here (http://avisynth.org/mediawiki/MT_support_page#Differences_between_MT.28.29_and_SetMTMode.28.29)), you may not get full core utilisation with SetMTMode - a lot depends on the individual filters and their frame access patterns.
Dogway
15th February 2010, 11:29
I will add it in expect to dont get any errors.
Normally I only use a few filters, for MVtools and Masktools (mostly) and everything else I use SetMTMode(2), I have only used MT() for tnlmeans and ttempsmooth, but this last one I think is outdated, right?
Thanks for the guidance Gavino, I had already saw that, normally I copy what trustful users post in the scripts, as I havent found a list with the prefered method in which filter to use.
hydra3333
15th February 2010, 22:51
please see this.
When using SetMTMode, Distributor() is the function which co-ordinates the multiple threads and provides a coherent output stream. When using Avisynth via the VfW interface, it is called automatically at the end of the script.
However, for applications that bypass the VfW interface and talk directly to Avisynth (such as hc), it is necessary to call it explicitly instead. Calling it when not required is a bad idea, as is failing to call it when required, so you need to know what method your Avisynth client application uses to communicate with Avisynth.
and this
Par.ex., I see people sometimes use Distributor(), sometimes not, and I have no clue what's the deal ...
In any case, multithreading of TGMC (so that it's worthwhile) is pretty difficult, because of the complexity of its processing chain.
MT() should be possible, but will worsen the motion search.
SetMTMode probably is a bad idea, because it requires too much ressources. (Having multiple dredges instead of one doesn't help much when it's still only one truck to take the excavation - you can only load so much onto one truck, no matter how many dredges.)
Best bet probably is to use the multithreaded MVTools of josey_wells (though it's the old v1.9 branch) ... using several cores to spread the computational effort for one frame, that's reasonable. Opposed to SetMTmode, which basically means to run TGMC {cores}-times in parallel, which is likely to fail.
In any case, this is the wrong thread for that topic.
If only a tiny fraction of the manpower & ingenuity that's going into x264 would go into MVTools, and Avisynth's/MVTools's multithreading ... <dreams>
Dogway
12th March 2010, 06:10
Hello again, now Im getting crashes in my script, and the reason is using SetMTmode with MT, I tried commenting the MT line and no problem. But what can I do? I do need TGMC and srestore in multithreading, and well tnlmeans too as it is slow as hell. I tried writting setMTmode(5) before the MT, and it crashed too. Im not sure what can I try now
SetMTmode(5)
setmemorymax(768)
DGDecode_MPEG2Source("source.d2v")
SetMTmode(2)
ColorMatrix(dest=2,hints=false,interlaced=true,threads=2)
AssumeFPS(30000,1001)
tempgaussmc_beta2(2,2,3,EdiMode="NNEDI2", qual=3)
SRestore(frate=23.976)
MT("""tnlmeans(ax=11,ay=10,az=4,sx=2,sy=2,bx=1,by=1,h=1.0,a=0.5,sse=true)""",4,2)
DeHalo_alpha(rx=1.3, ry=1.3, darkstr=0.4, brightstr=1.0, ss=1.0, lowsens=50,highsens=65)
LSFmod(defaults="slow", strength=20, edgemode=0)
hydra3333
12th March 2010, 07:54
Both SetMTmode and MT used in the same script ? wow a glutton for punishment :)
Dogway
12th March 2010, 08:53
lol, well I already know "that" is the problem, I made my homework :D . Its just what workaround there is for this?. I have managed to use both in other scripts without crashing, and tnlmeans without MT is just double long looooooong time. tnlmeans MUST be multithreading, but Im unsure it can work with SetMTmode(2) alone nicely, if I dont remember wrong.
Edit: Definetly not, tnlmeans consumes double the time with setmode than MT. Maybe wrapping my other filters with MT? Although I dont know which of them work nice with this (I know TGMC doesnt).
Edit2: Ok LSFmod seems to have problems with setmtmode too, although some users could run it, and being faster than MT. TGMCbeta2 lost the MT flag (Maybe due to old MTMasktools not being v2.0?). In case its transcendent, the errors Im getting are Visual c++ x264 errors. Reasons are the same, the multithreading, but some inconsistencies could deal any better with any certain version of visual c++ or net framework?
I think Ill be moving to this thread: http://forum.doom9.org/showthread.php?t=153030&page=2
hydra3333
12th March 2010, 12:19
Er I don't understand what you say. SetMTmode already makes it multi-threaded - then, on top of that, you split up the frames into bits and further multi-thread process those too with one filter (that's what MT does)... I'm not sure you're actually achieving much more by using MT instead of just leaving that off and relying on the setMTmode alone.
Dogway
12th March 2010, 12:52
the wiki says that using MT autoactivates mode5, so you dont do anything on top(but I have tried to manually setmode5 too just in case). Certain filters work better with the MT routine, this one (tnlmeans) being one of them. Just tested it on a still: 1:37s with MT, 3:16 with setmode2.
Edit: Also relating to my previous post SetMTmode does work with MT, see here (http://forum.doom9.org/showthread.php?p=803360#post803360). But it doesnt in my script. Any other reason is discarded because it does work if I remove the tnlmeans line or the MT portion of it. I have also updated both visual c++ and net framework to be safe on that side. Just for further conviction, I revised my script again (although it was already behaving as I said) and made some modfications, but everything is the same. So there must be something with the dll`s or my x264 settings in conflict with MT:
x264-rev1471-nl-hrd.exe --profile high --preset veryslow --tune animation --psy-rd 1.0:0.0 --pass 2 --bitrate 4000 --stats ".stats" --thread-input --threads 2 --deblock -1:-1 --bframes 8 --b-pyramid 0 --scenecut 30 --ref 16 --chroma-qp-offset -2 --no-mbtree --me tesa --merange 16 --aq-mode 0 --no-fast-pskip --sar 10:11 -o "output.mp4" "script2.avs"
Leinad4Mind
9th June 2010, 19:40
How can this filter accept spline64resize? It would be great to incorporate him.
Best Regards.
Gavino
9th June 2010, 20:07
Since Spline64Resize was not introduced until Avisynth 2.5.8, you need to use a version of MT derived from this later Avisynth.
Lyle_JP
13th June 2010, 08:26
How can this filter accept spline64resize? It would be great to incorporate him.
Here's why it can't be done, (and here's how to do it anyway):
MT splits your video into multiple smaller videos to be processed in individual threads. None of these threads can see "the whole picture", so filters that need to see the whole image to work properly (like decimate) can't be used inside of MT (well, you can use them anyway sometimes, but you'll get weird results). A resizer can't work in two directions with MT because any overlap value can't be compensated for after resize, so the images can't ever be stitched back together properly. Even with no overlap, MT still just won't let you do it.
However, if you only plan to resize in one direction, then as long as you let MT divide the image parallel to the direction you're resizing (and as long as you stick to only 2 threads or use no overlap), you can use spline64resize inside of MT with no errors.
Let me give you examples.
EXAMPLE A: A DVD encoded 4:3, following Rec.601 standards, to be resized only in a horizontal direction (note the cropping should be done outside of MT()):
DGMPGSource("blah.d2v")
deinterlacing goes here
crop(8,0,-8,0)
MT("""
your massive denoising script here
spline64resize(640,248)""",2,8)
This yields a video with a 640x480 aspect ratio. The first number in the spline 64 statement is whatever horizontal aspect ratio I'm resizing to, and the second number is half the height plus the overlap value. You cannot use more than two threads and still use overlap however, because the center segments will have overlap on two edges and therefore be of different width than the edge sections which only have overlap on one side.
EXAMPLE B: 16:9 DVD to be cropped to 2.36:1 and resized vertically:
DGMPGSource("blah.d2v")
deinterlacing (if any) goes here
crop(0,60,0,-60)
MT("""
your massive denoising script here
spline64resize(180,304)""",4,splitvertical=true)
This outputs a video with a 720x304 resolution. Here the first number is always 720 divided by the number of threads. No overlap has been used in this example. The second number is the desired height to scale to. Note the splitvertical statement; this is to reorient which direction MT splits up the video, so that it is the same direction as the resizing. Although this example shows that you can use this trick with more than two threads as long as there is no overlap, using no overlap with most denoising scripts is a bad idea, and it will usually leave behind lines on your picture. If you did use overlap here, the math would be 720 /2 + overlap for the first value, and threads would of course be 2.
Edit: Oh yes, and as the poster mentions above, you do need the MT version of Avisynth 2.5.8 or better.
Gavino
13th June 2010, 11:15
EXAMPLE A: A DVD encoded 4:3, following Rec.601 standards, to be resized only in a horizontal direction
...
MT("""
your massive denoising script here
spline64resize(640,248)""",2,8)
This yields a video with a 640x480 aspect ratio. The first number in the spline 64 statement is whatever horizontal aspect ratio I'm resizing to, and the second number is half the height plus the overlap value. You cannot use more than two threads and still use overlap however, because the center segments will have overlap on two edges and therefore be of different width than the edge sections which only have overlap on one side.
That's a neat trick, but it's completely unnecessary. You can just use
MT("""
...
spline64resize(640,height())""",2,8)
This doesn't require working out the segment height and will work for any number of threads, not just 2.
Similarly, for your second example (vertical resize), use
MT("""
...
spline64resize(width(),304)""",4,splitvertical=true)
To resize both horizontally and vertically, do the two parts in separate MT commands, eg:
MT("xxxresize(640, height())")
MT("xxxresize(width(), 304)", splitvertical=true)
Lyle_JP
13th June 2010, 12:02
That's a neat trick, but it's completely unnecessary. You can just use
MT("""
...
spline64resize(640,height())""",2,8)
This doesn't require working out the segment height and will work for any number of threads, not just 2.
Similarly, for your second example (vertical resize), use
MT("""
...
spline64resize(width(),304)""",4,splitvertical=true)
To resize both horizontally and vertically, do the two parts in separate MT commands, eg:
MT("xxxresize(640, height())")
MT("xxxresize(width(), 304)", splitvertical=true)
Wow. Cool. :thanks:
spider1
13th June 2010, 15:50
I put this line @ the begining of the script setMTmode(2,8), but avisynth doesn't not recognize this function.. any suggestions or idea why.. Thanks.
pbristow
14th June 2010, 19:46
Spider1: You have to be using an MT version of AVisynth, The basic version doesn't have it. See the first post in this thread.
Leinad4Mind
19th June 2010, 03:41
Since Spline64Resize was not introduced until Avisynth 2.5.8, you need to use a version of MT derived from this later Avisynth.
And where can I get that MT version?
Forget it... Found it. :p
Lyle_JP
19th June 2010, 21:10
And where can I get that MT version?
Forget it... Found it. :p
For anyone else looking:
http://forum.doom9.org/showthread.php?t=148117
telmoMRC
26th October 2010, 18:43
hey guys any idea why MT does not work with win7 x 64 ???
Usedocne
27th October 2010, 01:15
It does work with Win7 (x64). Make sure that you have extracted the two files in the MT_07.zip to the following places:
avisynth.dll goes in the Windows/SysWOW64 folder.
MT.dll goes in your AviSynth 2.5/plugins folder.
Lyle_JP
27th October 2010, 01:36
It may not work if you're using MeGUI. 32 bit MeGUI still tries to use 64 bit x264 on Win 7, so it runs two processes; 32 bit avs4x264 (this handles the 32 bit Avisynth stuff) which pipes video to 64 bit x264. But avs4x264 only runs in one thread and is incompatible with MT.dll. I think the way to solve this is to delete the 64 bit version of x264 from the megui\tools\x264\ folder. That forces 32 bit MeGUI to use a completely 32 bit program chain and eliminates the need to use avs4x264.
Or you can go the other way and make everything 64 bit, but that will limit you on filters.
asarian
28th October 2010, 08:54
2)
5) The basic difference is that mt() splits and sends both pieces of the frame to two copies of each filter, while setmtmode() says "give me 3, oh and run 4 while you're at it" on the assumption that the next frame is probably going to be needed, without splitting anything. I have no idea how smart the frame decision part is though. Some mt modes will try to use the same copy of the filter, some will create new ones. (That should explain why #4 isn't needed.)
Then, if I read you correctly, SetMTMode is actually not well suited for a script like MCTemporalDenoise, as I don't want one thread working on the current frame, and another on the next, but rather have two threads each working on a half of the current frame, and then have both proceed to the next frame.
Please, correct me if I'm wrong.
Usedocne
28th October 2010, 17:51
Have you read this (http://avisynth.org/mediawiki/MT_support_page)? It might clear things up a bit.
telmoMRC
28th October 2010, 21:29
thanks guy´s but whit friend help i could not get working as it should be
i also try whit AvisynthMT 2.5.8 and encode speed is is even slower
edit- i don´t use MEGUI i only use cmd commands
platov
26th November 2010, 16:13
Hello
I create stereopair from 2 videostreams
I use here such script
-----------------------------------
LoadPlugin("DGAVCDecode.dll")
LoadPlugin("H264StereoSource.dll")
Frames=232607
Frames=Frames-50
MovieL=AVCSource("left.dga")
MovieR=H264StereoSource("decoder.cfg", Frames)
MovieLR=StackHorizontal(MovieL, MovieR).trim(0, Frames)
MovieLR=MovieLR.LanczosResize(1920,1080)
return MovieLR
-------------------------------------------
My processor of 4 kernels with frequency 2.83 is used on 40 %
of employment at the first pass and 60 % at the second pass
It is established Avisynth_258.exe
I have added MT.dll In a folder C:\Program Files\AviSynth 2.5\plugins
Has replaced avisynth.dll In a folder C:\Windows\System32
In the beginning of a script has added
---------------
SetMTMode (2,0)
----------------
x264.exe It does not wish to be started
Help please to write correctly AVS a script
Zep
27th November 2010, 18:37
Hello
I create stereopair from 2 videostreams
I use here such script
-----------------------------------
LoadPlugin("DGAVCDecode.dll")
LoadPlugin("H264StereoSource.dll")
Frames=232607
Frames=Frames-50
MovieL=AVCSource("left.dga")
MovieR=H264StereoSource("decoder.cfg", Frames)
MovieLR=StackHorizontal(MovieL, MovieR).trim(0, Frames)
MovieLR=MovieLR.LanczosResize(1920,1080)
return MovieLR
-------------------------------------------
My processor of 4 kernels with frequency 2.83 is used on 40 %
of employment at the first pass and 60 % at the second pass
It is established Avisynth_258.exe
I have added MT.dll In a folder C:\Program Files\AviSynth 2.5\plugins
Has replaced avisynth.dll In a folder C:\Windows\System32
In the beginning of a script has added
---------------
SetMTMode (2,0)
----------------
x264.exe It does not wish to be started
Help please to write correctly AVS a script
try this:
SetMTMode (5,0)
LoadPlugin("DGAVCDecode.dll")
LoadPlugin("H264StereoSource.dll")
Frames=232607
Frames=Frames-50
MovieL=AVCSource("left.dga")
MovieR=H264StereoSource("decoder.cfg", Frames)
SetMTMode (2,0)
MovieLR=StackHorizontal(MovieL, MovieR).trim(0, Frames)
MovieLR=MovieLR.LanczosResize(1920,1080)
return MovieLR
if that doesn't help you could try a few other things like adding
Distributor()
to the very end.
platov
27th November 2010, 20:34
Thanks
sekhar_co
17th January 2011, 06:21
I have no idea about the Avisynth MT so please clarify me what script should i do?
My Avisynth version: AviSynth 2.5.8
Processor: AMD Athlon 64x2 Dual Core Processors 4200+ 2.21GHz
Ram: 1GB DDR2
Graphics: Nvidia 8500GT
Sorry for my bad english.
halpern
8th February 2011, 00:15
I downloaded MT 0.7. I am using MeGUI on a Windows 7 x64 machine. I installed the MT.dll in the avisynth plugin directory. I then installed the avisynth.dll into the SysWOW64 directory. When I try to load the avs script it says that it "cannot load avisynth.dll". What am I doing wrong?
luke83
25th February 2012, 20:43
I have used MT yesterday for the first time: it's awsome! It has increased the FPS of my script from 8-9 to 16 and the time needed has gone from 1 hour to 35-40 minutes O_O
Before, my CPU (Intel E8400 3Ghz Dual Core duo) went to 52-54% max, now it arrives to 98-100%. RAM is full a bit over half (2,15 full with 4GB)
This is my avs script relatives to Lupin 2nd Season
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\multicore_plugin\MT.dll")
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\Anime\RemoveGrain 1.0b\RemoveGrainSSE3.dll")
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\Anime\FluxSmooth-1.1b\Release\FluxSmooth.dll")
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\Anime\MSharpen.dll")
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\Anime\Anti-aliasing\UnFilter.dll")
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\Anime\Anti-aliasing\SangNom.dll")
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\Decomb.dll")
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\dgindex\DGDecode.dll")
SetMTMode(1,2)
DGDecode_mpeg2source("K:\Temp\Temp Megui\VTS_01_PGC_01_VOBID_003_CELLID_001_1.d2v", info=3)
LoadPlugin("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
SetMTMode(2)
# Deinterlacer
AssumeTFF().Telecide(guide=1).Decimate(mode=1,threshold=2.0)
# Spatial Denoiser
RemoveGrain(mode=2).RemoveGrain(mode=2)
# Cropper
crop( 10, 2, -12, -6)
# Temporal Denoiser
FluxSmoothT(temporal_threshold=7)
# Resizer
Spline16Resize(704,528) # Spline16 (Neutral)
# Sharpener
MSharpen(threshold=10, strength=100,mask=false, highq=true)
# Anti-aliasing
Import("K:\Documents and Settings\Luca\Documenti\Software\Video Editing\MeGUI_0.3.5\tools\avisynth_plugin\Anime\Anti-aliasing\AAA.avs")
AAA()
At the first time, I've used the MTi notation but the interlacing didn't work good (some frame with, others without) and the AAA (Anime Anti Aliasing) function too.
Now I tried SetMTMode notation and the result is equal to the version without multicore (that is perfect, don't worry :D ). In fact I have discovered that MT simple notation divides the same frame in two parts, instead of SetMTMode that processes a full frame. In this way AAA function works good and the interlacing too.
However I have a dubt: Does FluxSmooth work good with multicore? In fact it is a temporal denoiser which needs of 3 frame (previous frame, frame processed, next frame). If a frame is processed in 2 different threads, how can fluxsmooth find differences between the frames?
I asked it because I couldn't notice difference between monocore and multicore version of FluxSmooth :)
In this case or when I want to disable MT for a function, what mode I have to use? I tried 5 and 6 but it gave me error. Zero doesn't exist. So what? Thanks in advance and sorry for my english. I'm italian :)
EDIT:
one more question: I read on support page that Mpeg2Source require Mode 1. Is DGDecode_mpeg2source the same or I have to use Mode 5?
At the moment I'm using Mode 1 and all works good (sgrat sgrat XD).
Same question about colormatrix: it works good with mode 1, but I feel safer using mode 2. Is it right?
Bloax
26th February 2012, 17:49
Might want to use this one (http://forum.doom9.org/showthread.php?t=148782) instead, since it's more mature and stuff.
And yes, FluxSmooth ought to behave just fine.
Oh, and there shouldn't be a big difference between mode 1 and 2, except for the higher memory usage of 2. (For the bonus of being compatible with lots of plugins.)
bcn_246
3rd November 2012, 00:05
Is there any way tsp (or somebody else, the source code is provided) could edit this (MT v0.7) for use with AviSynth v2.6 (alpha 3). At the moment 2.6 supports MT using SetMTMode(... but can't use this DLL's MT(filter(.... (throws up a version incompatibility error).
Only thing stopping me from moving from 2.5.8 at the moment, SetMTMode(... is far slower than MT(...
TIA
Ben
martin53
15th December 2012, 11:36
MT v0.7 with AviSynth v2.6 throws up a version incompatibility error
I'd like to support that request. Same issue here.
aldix
11th January 2014, 00:47
Finally got MT.dll working for my set-up. However, for the life of me I can't make it work with MVTools.
Relevant script snip:
src=last
src_sup=src.MSuper(pel=1,sharp=2,rfilter=2)
shp=src.SeeSaw(nrlimit=0, nrlimit2=99, bias=55, sstr=1.25, Spower=2, Szp=10, Sdamplo=3, SdampHi=16, Slimit=99, sootheT=0, sootheS=0).mergechroma(src)
shp_sup=shp.MSuper(pel=1,sharp=2)
bv2=MAnalyse(src_sup,isb=true,delta=2,overlap=4,truemotion=false,search=5,sadx264=4,lambda=500,chroma=true)
bv1=MAnalyse(src_sup,isb=true,delta=1,overlap=4,truemotion=false,search=5,sadx264=4,lambda=500,chroma=true)
fv1=MAnalyse(src_sup,isb=false,delta=1,overlap=4,truemotion=false,search=5,sadx264=4,lambda=500,chroma=true)
fv2=MAnalyse(src_sup,isb=false,delta=2,overlap=4,truemotion=false,search=5,sadx264=4,lambda=500,chroma=true)
src.MDegrain2(shp_sup,bv1,fv1,bv2,fv2)
How could wrap this with MT so that it actually works? It gives either 'invalid arguments' error or secondary vectors having incorrect width error.
I can't understand what's going on nor does there seem to be any information on the web.
I'd really appreciate a reply, thanks.
Groucho2004
11th January 2014, 02:26
How could wrap this with MT so that it actually works? It gives either 'invalid arguments' error or secondary vectors having incorrect width error.
I can't understand what's going on nor does there seem to be any information on the web.
I'd really appreciate a reply, thanks.
As an example, here is something I used successfully a loooong time ago with 2.5.7 and MT():
function RemoveNoise2MT(clip video, int "threshold")
{
threshold = default(threshold, 300)
last = video
MT("sc = MSuper()
backward_vector2 = MAnalyse(sc, isb = true, delta = 2, blksize = 16, overlap = 4, truemotion = false)
backward_vector1 = MAnalyse(sc, isb = true, delta = 1, blksize = 16, overlap = 4, truemotion = false)
forward_vector1 = MAnalyse(sc, isb = false, delta = 1, blksize = 16, overlap = 4, truemotion = false)
forward_vector2 = MAnalyse(sc, isb = false, delta = 2, blksize = 16, overlap = 4, truemotion = false)
MDegrain2(sc, backward_vector1, forward_vector1, backward_vector2, forward_vector2, thSAD = threshold)", threads = 4, overlap = 20)
return last
}
aldix
11th January 2014, 03:13
Hmm, yeah... thanks, but I don't know how it could help me, it's essentially the same example MVTools tutorial offers for MT.dll use.
What I require is somewhat more complex, does MT.dll not fasciliate that or what?
Groucho2004
11th January 2014, 11:43
Hmm, yeah... thanks, but I don't know how it could help me, it's essentially the same example MVTools tutorial offers for MT.dll use.
What I require is somewhat more complex, does MT.dll not fasciliate that or what?
Your question was about making MVTools work with MT() and I gave you a working example.
However, your problem seems to be invalid parameters to SeeSaw which has nothing to do with MT().
I suggest you read up on the documentation for SeeSaw.
aldix
11th January 2014, 14:32
Lol, what invalid parameters? Now suddenly something that has worked all this time is invalid? I even got the same kind of config from Doom9, to boot.
My question was precisely how to make MVTools work with my example which has two super clips etc. Then you gave me a vanilla example with only one, just like in MVTools docs.
But nvm, thanks for nothing.
As usual, I'll think about it / look at it until I figure out what's wrong. Was mistaken in taking my problem here.
aldix
11th January 2014, 17:43
As always, figured it out on my own, with the magnificent help of one old post by Didee (as per usual ;) )
And BS on SeeSaw options being invalid :D
Groucho2004
11th January 2014, 18:02
And BS on SeeSaw options being invalid :D
Hm, I tried your exact SeeSaw line and it gave me the same errors.
Was mistaken in taking my problem here.As always, figured it out on my own
Why do you post questions here at all?
I guess it's a perfect reflection of your character that you're not sharing your solution.
aldix
11th January 2014, 18:48
Yes. I'm all bad but getting an incomplete answer to a perfectly fine question is all honky-dory. And I figured I'd ask the experts because I was stumped. But as always, experts are rude and dismissive,
hence my disappointed response.
For the record, search Doom9 for denoise-stabilization and you'll see that this use of SeeSaw is perfectly good and any errors you might encounter most likely stem from your setup.
I can't even imagine what error(s) you're getting but given that you're overall extremely vague (to say the least) and unforthcoming (reflective of your character, perhaps?) I can't offer any useful/helpful input either.
For the sake of clearing the air, fix turned out to be extremely simple - had to use full syntax (threads=4, overlap=8, splitvertical=false) and then wrapping everything within MT worked.
Don't ask me why this made any difference (I'm not a programmer nor a technical person and doing video encoding as hobby, hence my knowledge is mostly that of patchwork), but thankfully got the clue, as I noted, from an old post of Didee the master.
MichaelRow
19th May 2014, 14:55
Is it worked with AviSynth 2.6 alpha 5? Seems that mt.dll can't be loaded.
Groucho2004
19th May 2014, 16:27
Is it worked with AviSynth 2.6 alpha 5?
No, won't work.
MichaelRow
20th May 2014, 03:32
No, won't work.
Thanks for the info.
AFAIK, there is an unofficial builds called avisynth 2.6MT.
My questions are:
1) Is it as stable as the official builds?
2) Have this builds already included the mt() in avisynth.dll?
Groucho2004
20th May 2014, 09:53
Thanks for the info.
AFAIK, there is an unofficial builds of avisynth called avisynth 2.6MT, and it can use mt by replacing the avisynth.dll.
My questions are:
1) Is it as stable as the official builds?
2) Have this builds already included the mt in avisynth.dll?
SEt's 2.6 MT versions don't have the "MT()" function any more. Instead, you have to use "SetMTMode()". The difference is explained here (http://forum.doom9.org/showthread.php?p=954342#post954342).
As for stability - people have different experiences ranging from "doesn't work at all" to "rock solid". It depends on many factors like plugins used, number of threads, memory usage, etc.
You just have to try it.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.