SlowMo: Simple slow motion, using interpolation

[StainlessS]

Very nifty scripting
I'de swap it all to have a smile like your Mani :D

[StainlessS]

OK, nuther tester.
Added all args to higher level funcs, Added SearchParam args and changed defaults slightly, seems to me that old SearchParam = 0 (recalc=2) might be a NOP (not sure how implemented).
Should SearchParam be based on current MAnaylse/Recalc OverLap ??? (search==3=Exhastive search, where SearchParam=Radius and square side=2*Radius+1).

here mod:

Function ChangeFrameRate(clip c,Bool "Blend",Bool "Flow",Int "Num",Int "Den",
\ Bool "Prefilter",Bool "Chroma",Bool "Chroma1",Bool "Chroma2",
\ Int "BlkSize",Int "Recalc",
\ Int "OverLap",Int "OverLap1",Int "OverLap2",
\ Int "SearchParam",Int "SearchParam1",Int "SearchParam2",
\ Int "thSAD1",Int "thSAD2",
\ Float "Flow_ml",
\ Int "Block_Mode"
\ ) {
# Req MvTools2 v2.7.1.22+ for FINAL Overlap>0
Blend = Default(Blend,False) # Avoid blends at scene change (copy previous frame)
Flow = Default(Flow,True) # If True, Use MFlowFps instead of MBlockFps
n=Default(num,0) d=default(den,0) valid=(n>0 && d>0) n=(!valid)?c.FramerateNumerator*2:n d=(!valid)?c.FramerateDenominator:d # Default=doublerate
Prefilter=Default(Prefilter,True)
Chroma = Default(Chroma ,True)
Chroma1 = Default(Chroma1,True)
Chroma2 = Default(Chroma2,True)
BlkSize = Default(BlkSize,16)
Recalc = Default(Recalc,1) # 0 -> 2.
Assert(0 <= Recalc <=2,"ChangeFrameRate: 0 <= ReCalc <= 2")
Overlap = Default(Overlap ,4)
Overlap1 = Default(Overlap1,2)
Overlap2 = Default(Overlap2,0)
SearchParam = Default(SearchParam ,Recalc==2?3:2) # MAnalyse default (as John's default) = 2 (presume MRecalculate same, not doc'ed)
SearchParam1 = Default(SearchParam1,Recalc==2?2:1) # Search==3=Exhaustive search, where SearchParam=Radius, square side = 2*Radius+1
SearchParam2 = Default(SearchParam2, 1 ) # From above, SearchParam of 0, seems like might be useless NOP (not sure).
thSAD1 = Default(thSAD1,100) # MRecalculate default is 200
thSAD2 = Default(thSAD2,100) # ditto
Flow_ml = Float(Default(Flow_ml,200.0)) # MFlowFPS default is 100.0
Block_Mode = Default(Block_Mode,0) # 0 (Fastest, default) -> 5(debug)
super = c.MSuper(pel=2, hpad=BlkSize, vpad=BlkSize,rfilter=4,Levels=(0<Recalc)?1:0) # MRecalculate needs only 1 Level, MAnalyse needs all Levels
MAnal = (Prefilter) ? c.RemoveGrain(22).MSuper(hpad=BlkSize, vpad=BlkSize) : Super
bv = MAnal.MAnalyse(isb=true, chroma=Chroma, blksize=BlkSize, OverLap=OverLap , search=3, searchparam=SearchParam, badrange=(-24), plevel=0)
fv = MAnal.MAnalyse(isb=false, chroma=Chroma, blksize=BlkSize, OverLap=OverLap , search=3, searchparam=SearchParam, badrange=(-24), plevel=0)
bv = (0<ReCalc)?MRecalculate(super, chroma=Chroma1, bv, blksize=BlkSize/2, Overlap=OverLap1, search=3, searchparam=SearchParam1, thSAD=thSAD1):bv
fv = (0<ReCalc)?MRecalculate(super, chroma=Chroma1, fv, blksize=BlkSize/2, Overlap=OverLap1, search=3, searchparam=SearchParam1, thSAD=thSAD1):fv
bv = (1<ReCalc)?MRecalculate(super, chroma=Chroma2, bv, blksize=BlkSize/4, Overlap=OverLap2, search=3, searchparam=SearchParam2, thSAD=thSAD2):bv
fv = (1<ReCalc)?MRecalculate(super, chroma=Chroma2, fv, blksize=BlkSize/4, Overlap=OverLap2, search=3, searchparam=SearchParam2, thSAD=thSAD2):fv
Return (!Flow)
\ ? c.MBlockFps(super, bv, fv, num=n, den=d, Blend=Blend, mode=Block_Mode)
\ : c.MFlowFps(super, bv, fv, num=n, den=d, Blend=Blend, ml =Flow_ml)
}

Function MulRate(clip c,Bool "Blend",Bool "Flow",int "mul",Bool "ILeave",
\ Bool "Prefilter",Bool "Chroma",Bool "Chroma1",Bool "Chroma2",Int "BlkSize",Int "Recalc", Int "OverLap",Int "OverLap1",Int "OverLap2",
\ Int "SearchParam",Int "SearchParam1",Int "SearchParam2",Int "thSAD1",Int "thSAD2",Float "Flow_ml",Int "Block_Mode") {
Function MulRate_EvS(String s,int n,int mul) {
s="SelectEvery("+String(mul)+","+String(n)+")"+((s!="")?","+s:s)
# RT_DebugF("s='%s'",s,name="MulRate: ")
return (n>1)?MulRate_EvS(s,n-1,mul):s
}
c
mul=default(mul,2)
Ileave=Default(Ileave,True)
ChangeFrameRate(Blend,Flow,c.FramerateNumerator*mul,c.FramerateDenominator,Prefilter,Chroma,Chroma1,Chroma2,BlkSize,Recalc,
\ OverLap,OverLap1,OverLap2,SearchParam,SearchParam1,SearchParam2,thSAD1,thSAD2,Flow_ml,Block_Mode)
(ILeave&&mul>=2) ? Eval("Interleave(c,"+MulRate_EvS("",mul-1,mul)+")") : NOP
Return Last
}

Function DoubleRate(clip c,Bool "Blend",Bool "Flow",Bool "ILeave",
\ Bool "Prefilter",Bool "Chroma",Bool "Chroma1",Bool "Chroma2",Int "BlkSize",Int "Recalc", Int "OverLap",Int "OverLap1",Int "OverLap2",
\ Int "SearchParam",Int "SearchParam1",Int "SearchParam2",Int "thSAD1",Int "thSAD2",Float "Flow_ml",Int "Block_Mode") {
return c.MulRate(Blend,Flow,2,ILeave,Prefilter,Chroma,Chroma1,Chroma2,BlkSize,Recalc,
\ OverLap,OverLap1,OverLap2,SearchParam,SearchParam1,SearchParam2,thSAD1,thSAD2,Flow_ml,Block_Mode)
}

Function SlowMo(clip c,Bool "Blend",Bool "Flow", int "mul",Bool "ILeave",
\ Bool "Prefilter",Bool "Chroma",Bool "Chroma1",Bool "Chroma2",Int "BlkSize",Int "Recalc", Int "OverLap",Int "OverLap1",Int "OverLap2",
\ Int "SearchParam",Int "SearchParam1",Int "SearchParam2",Int "thSAD1",Int "thSAD2",Float "Flow_ml",Int "Block_Mode") {
c
MulRate(Blend,Flow,mul,ILeave,Prefilter,Chroma,Chroma1,Chroma2,BlkSize,Recalc,
\ OverLap,OverLap1,OverLap2,SearchParam,SearchParam1,SearchParam2,thSAD1,thSAD2,Flow_ml,Block_Mode)
Return Last.assumefps(c.FrameRateNumerator,c.FrameRateDenominator)
}


Client

AVISource("D:\SlowMoTester.mkv.AVI")

#DoubleRate(ILeave=True,Recalc=1)

SlowMo(mul=2,iLeave=True,ReCalc=1) # Double framecount, Interleave (replace with) original frames every even frame, 1 instance of MRecalculate.


EDIT: Mani, Blend only matters at scene change (1st frame of scene NOT blended, copied from End Of Scene frame, when Blend=False).

[manolito]

Thanks for the update, but IMO it's still not completely there yet...

Test result:
http://www16.zippyshare.com/v/b0eFhc3u/file.html

I only judge the result by the warping artifacts on those vertical edges of the grill to the right of the clip. John Meyer's result has fewer artifacts.

I kept all the defaults for JM and for your script. Encoding by X264 at CRF 20.

I also simplified your script to be just an FPS converter because this is all I need:

Function StainlessS_fps(clip c, float "fps") {
# Req MvTools2 v2.7.1.22+ for FINAL Overlap>0
fps = default(fps, 25.000)
fps_num = int(fps * 1000)
fps_den = 1000
Blend = False # Avoid blends at scene change (copy previous frame)
Flow = True # If True, Use MFlowFps instead of MBlockFps
Prefilter = True
Chroma = True
Chroma1 = True
Chroma2 = True
BlkSize = 16
Recalc = 1 # 0 -> 2.
Assert(0 <= Recalc <=2,"ChangeFrameRate: 0 <= ReCalc <= 2")
Overlap = 4
Overlap1 = 2
Overlap2 = 0
SearchParam = Recalc==2?3:2 # MAnalyse default (as John's default) = 2 (presume MRecalculate same, not doc'ed)
SearchParam1 = Recalc==2?2:1 # Search==3=Exhaustive search, where SearchParam=Radius, square side = 2*Radius+1
SearchParam2 = 1 # From above, SearchParam of 0, seems like might be useless NOP (not sure).
thSAD1 = 100 # MRecalculate default is 200
thSAD2 = 100 # ditto
Flow_ml = Float(200.0) # MFlowFPS default is 100.0
Block_Mode = 0 # 0 (Fastest, default) -> 5(debug)
super = c.MSuper(pel=2, hpad=BlkSize, vpad=BlkSize,rfilter=4,Levels=(0<Recalc)?1:0) # MRecalculate needs only 1 Level, MAnalyse needs all Levels
MAnal = (Prefilter) ? c.RemoveGrain(22).MSuper(hpad=BlkSize, vpad=BlkSize) : Super
bv = MAnal.MAnalyse(isb=true, chroma=Chroma, blksize=BlkSize, OverLap=OverLap, search=3, searchparam=SearchParam, badrange=(-24), plevel=0)
fv = MAnal.MAnalyse(isb=false, chroma=Chroma, blksize=BlkSize, OverLap=OverLap, search=3, searchparam=SearchParam, badrange=(-24), plevel=0)
bv = (0<ReCalc)?MRecalculate(super, chroma=Chroma1, bv, blksize=BlkSize/2, Overlap=OverLap1, search=3, searchparam=SearchParam1, thSAD=thSAD1):bv
fv = (0<ReCalc)?MRecalculate(super, chroma=Chroma1, fv, blksize=BlkSize/2, Overlap=OverLap1, search=3, searchparam=SearchParam1, thSAD=thSAD1):fv
bv = (1<ReCalc)?MRecalculate(super, chroma=Chroma2, bv, blksize=BlkSize/4, Overlap=OverLap2, search=3, searchparam=SearchParam2, thSAD=thSAD2):bv
fv = (1<ReCalc)?MRecalculate(super, chroma=Chroma2, fv, blksize=BlkSize/4, Overlap=OverLap2, search=3, searchparam=SearchParam2, thSAD=thSAD2):fv
Return (!Flow)
\ ? c.MBlockFps(super, bv, fv, num=fps_num, den=fps_den, Blend=Blend, mode=Block_Mode)
\ : c.MFlowFps(super, bv, fv, num=fps_num, den=fps_den, Blend=Blend, ml=Flow_ml)
}

The slowdown to half speed was done by "AssumeFPS(framerate / 2)" before calling the script.


Even if johnmeyer is adamant in requesting to find optimal parameters for every source, these params so far have given me the best results for every source I have tried. I experimented a lot using different values for block size and overlap, but the result was either the same or it was worse.

The remaining artifacts in my test clip using JM's script are probably not avoidable. At least I tried, but I could not get a better result.

And the StainlessS script is just a little bit worse. The new test script did not make any difference to the previous one BTW.
What does this comment mean?
Req MvTools2 v2.7.1.22+ for FINAL Overlap>0
Is the FINAL Overlap == Overlap2 ? The reason I ask is that I have to use the latest Fizick version of MVTools2, PinterF versions do not run on my machine.


Cheers
manolito

[StainlessS]

What does this comment mean?

Is the FINAL Overlap == Overlap2 ? The reason I ask is that I have to use the latest Fizick version of MVTools2, PinterF versions do not run on my machine.


In non pinterf version, Overlap cannot be non zero in vectors used in MBlockFPS, ie from final MRecalculate, or from MAnalyse if MRecalculate not used at all.
So, script will probably fail with your version MVTools if Flow=False.
[EDIT: Except if set Recalc=2, where Overlap2 defaults 0, OR if you set relevant OverlapN=0].

http://forum.doom9.org/showthread.php?p=1785781#post1785781

Also if you wanted easy interface but with all defaults could have created stub eg (untested)

Function Manolito_fps(clip c, float "fps") { fps=default(fps,25.0) num=int(fps*1000) Return ChangeFrameRate(c,num=num,den=1000) }


EDIT: For stub using eg Recalc=0 and Overlap=0, then just create new stub using non defaults, calling
ChangeFrameRate(..., Recalc=0,OverLap=0)

[StainlessS]

Mod of the fabled jm_fps, modded by Manolito and again a little by this humble soul.

JohnFPS.avs

Function JohnFPS(clip c,Val "num", int "den",int "Sharp",int "rFilter",Int "BlkSize",int "Search",int "dct",Float "ml",Int "Mask",Bool "Blend") {
/*
https://forum.doom9.org/showthread.php?p=1847109#post1847109
Motion Protected FPS converter script by JohnMeyer from Doom9
Slightly modified interface by Manolito, and a smidgen more by ssS.
Requires MVTools V2 and RemoveGrain
Also needs fftw3.dll in the System32 or SysWOW64 folder for Dct values other than 0
Specify FrameRate using num (Numerator) and den (Denominator)
num only, eg num=25.0, FrameRate = 25.0 FPS
num & den, eg num=24000 den=1001, FrameRate = 23.976 FPS (Both should be type Int).
neither specified FrameRate = Double input framerate.
*/
def = num.Defined ? (den.Defined ?1:0) : (!den.Defined) ? 2 : -1 # 0=NumOnlyDef, 1=BothDef, 2=NoneDef, -1=DenOnlyError
Assert(0<=def,"JohnFPS: Cannot specify framerate using den only")
# Rate=num : Rate=num/den : Rate=DoubleRate
n=(def==0) ? Round(num * 1000): (def==1) ? Int(num) : 2*c.FrameRateNumerator
d=(def==0) ? 1000 : (def==1) ? den : c.FrameRateDenominator
Sharp = Default(Sharp,1) # MSuper default = 2
rFilter= Default(rFilter,4) # MSuper default = 2
BlkSize= Default(BlkSize,16) # Manalyse default 8, Maybe 32 for HD
Search = Default(Search,3) # Manalyse default 4
dct = Default(dct,0) # Manalyse default 0, 1=Slow
ml = Default(ml,200.0) # MFlowFps default 100.0
Mask = Default(Mask,2) # MFlowFps default 2
Blend = Default(Blend,False) # MFlowFps default True
prefilt = c.RemoveGrain(22)
super = c.MSuper(hpad=16,vpad=16,levels=1,sharp=Sharp,rfilter=rFilter) # One level is enough for MRecalculate
superfilt= prefilt.MSuper(hpad=16,vpad=16,sharp=Sharp,rfilter=rFilter) # All levels for MAnalyse
bv = superfilt.MAnalyse(isb=true ,blksize=BlkSize,overlap=4,search=Search,dct=dct)
fv = superfilt.MAnalyse(isb=false,blksize=BlkSize,overlap=4,search=Search,dct=dct)
bv = super.MRecalculate(bv,blksize=8,overlap=2,thSAD=100)
fv = super.MRecalculate(fv,blksize=8,overlap=2,thSAD=100)
return c.MFlowFps( super,bv,fv,num=n,den=d,blend=Blend,ml=ml,mask=Mask)
}

EDIT: Update, add Blend arg.

One day they will sing the ballad of JohnFPS (unfortunately, the hero always dies in a horrible & painful way, well you cant have everything I suppose).

[Sparktank]

Can't wait to check out these mods.

Always looking for something new and fun :)

[manolito]

@ StainlessS

Nice mod you posted, I played a little bit with it, these are my 2 cents:

1. You exposed a lot more MVTools parameters in the function. Nice for users who like to play, I certainly don't need this.

2. The way you enabled either a float FPS value as a param or using int params for num and den is very nifty. This will make both camps happy. I really tried to break it, but I couldn't. Hats off...

3. Unsure about the "BadRange" param. I did a few conversions with the default "Search=3", either using "BadRange=-24" or omitting the BadRange parameter. The conversion results were bit identical in all cases, so I assume that MVTools is smart enough to use "-24" by default if "Search=3" is specified.


I also found that there are differences in the output depending on the method which gets used for specifying the target frame rate. Probably just rounding errrors, but still...

Using either
JohnFPS(60000/1001)
or
JohnFPS(60000, 1001)

results in very different outputs. I cannot say if one looked better than the other, but the method using num and den is definitely considerably faster.


Cheers
manolito


OT:
Your advice to not forget to bring my brolly for my recent motorcycle trip to Scotland was unjustified. Only great weather, no rain or drizzle at all. This was my third Scotland trip, and I never got wet up there... :D

[StainlessS]

BadRange,
Was little addition just before posting,based purely on docs suggestion, no harm to either remove or leave as is.

JohnFPS(60000/1001)
I hope you did something in test like

JohnFPS(60000/Float(1001))
JohnFPS(Float(60000)/1001)
JohnFPS(60000.0/1001)
JohnFPS(60000/1001.0)


but the method using num and den is definitely considerably faster.

Did not really expect that, but good to know (I tend to use num, den myself).

OT, you lucky lucky lad :)

[StainlessS]

Post #55 Update. Remove BadRange, added MFlowFPS Blend arg (defaulted false, EDIT:MFlowFPS default is true).

[manolito]

I hope you did something in test like

JohnFPS(60000/Float(1001))
JohnFPS(Float(60000)/1001)
JohnFPS(60000.0/1001)
JohnFPS(60000/1001.0)


No, I didn't. And this is exactly what I want to avoid no matter what. I do not want to have to specify a variable type when calling the function. This is just too prone to errors.

What if I change "Val" to "Float" in the function declaration for "num"? I think this should not break anything, but then you are the AviSynth wiz, not me... :D


Cheers
manolito

[StainlessS]

Val makes it explicit that the accepted type is variable, using Float would (as of v2.60) force type to float(even when client provided int), I did not want that.

An integer divided by an integer, produces an [EDIT: truncated] integer (BAD in this case)


Colorbars.killaudio.BilinearResize(320,240)
x=60000/1001
y=60000/1001.0
subtitle("x="+String(x)+" : y="+string(y))


https://s20.postimg.cc/6ccrfp8el/div.jpg (https://postimages.org/)

EDIT: So internally in function,
if provided with num arg as num=60000/1001.0, n=59940, d=1000,
whereas num=60000/1001, n=59000, d=1000 (wrong by nearly a whole frame per second).

EDIT:
I do not want to have to specify a variable type when calling the function. This is just too prone to errors.
But you do want to provide the correct arguments. Specifying float is not the requirement, but if its a floating point framerate that is required then you need to specifiy a floating point argument, not doing so is not just 'prone to errors', it is an error.

If you have previously generally not understood the 'Interger divide' thing, then you had best check all of your scripts for similar integer divide errors.

EDIT: Also this is WRONG, Float(60000/1001), is already wrong answer before converting to float.
Float / integer, and Integer / Float, both produce a float result (the integer is converted to float before divide), same with addition, subtraction, and multiplication.

[Sparktank]

This is awesome work!
I love it when mad scientists come together.

I am definitely going to start using this cript for converting videos.

SVP is fine for watching movies.
But this collaberated work is really what I'm looking for when converting clips of my favorite movies.

[manolito]

Alright Master StainlessS, I checked it, and of course you are right. :stupid:

I falsely assumed that AviSynth would parse an expression like "float(60000/1001)" from left to right and automatically treat the int arguments as float. But obviously it works the other way around. The integer division is executed first, and only then the truncated result is converted to float. I don't like it...


Cheers
manolito

[wonkey_monkey]

I falsely assumed that AviSynth would parse an expression like "float(60000/1001)" from left to right and automatically treat the int arguments as float. But obviously it works the other way around. The integer division is executed first, and only then the truncated result is converted to float. I don't like it...

It's perfectly cromulent. There is only one argument to float(), which is the value 60000/1001. And that is an integer, because you are dividing an integer by an integer, and so it is expected that you want to do integer division.

[StainlessS]

It's perfectly cromulent.
Nice to see that you are keeping abreast of the 'hip' new words entering dictionary, good man.
(I took it to mean something connected to eg 'Cromwellian' ).

assumed that AviSynth would parse an expression like "float(60000/1001)" from left to right and automatically ...
Most languages work in the same sort of way. If [B]Float is a function then whatever is in the parenthesis is the argument and without
any manipulation/substitution, if Float were to be implemented via parser, then as arg is in parenthesis, it would be evaluated prior to float conversion, both ways would produce same result. It would not be a very good idea for parsers to make assumptions about what is required.
EDIT: When doing mixed type arithmetic, one of the types has to be converted to the other (least precise to most precise) so
that you are not eg dividing apples by oranges [eg 60000/1000.0 ===>>> 60000.0/1001.0], and the result is that of the most precise type.I don't like it...
Get used to it :)

EDIT: To below: Now you are just showing off :)

[wonkey_monkey]

Nice to see that you are keeping abreast of the 'hip' new words entering dictionary, good man.


I'm always trying to embiggen my vocabulary.

[StainlessS]

OT
David, As noted elsewhere, TWriteAVI v2.0 (to x64) requires a CPP/ASM/Intrinsic programmer, I was just thinking maybe that
project might be right up your Straße [any thoughts ?].

EDIT: I saw somewhere that you were writing an assembler for x86.

EDIT: TWriteAVI v2.0, is an incredibly useful plug, and if implemented in x64 could be used as starting point for
many projects, eg Video Capture and the like. Even a plain C implementation of the ASM would be a huge plus.

[wonkey_monkey]

I'll take a look, but I probably won't be able to do anything. Where is the ASM in the source code? Off the top of my head, I can't think of a good reason for such a thing to need it...

[manolito]

Most languages work in the same sort of way. If Float is a function then whatever is in the parenthesis is the argument and without
any manipulation/substitution, if Float were to be implemented via parser, then as arg is in parenthesis, it would be evaluated prior to float conversion, both ways would produce same result. It would not be a very good idea for parsers to make assumptions about what is required.

Get used to it :)


Probably I am too much used to "simpler" languages which DO make assumptions about what the user wants.. :devil:
Like AutoIT which only offers the Variant type.

With this code:
#include <MsgBoxConstants.au3>
MsgBox($MB_SYSTEMMODAL, "Division", "60000/1001 = " & 60000/1001)

you get the following result:
http://i64.tinypic.com/sv5q1j.jpg


Cheers
manolito


//EDIT//
I also remember my old Turbo Pascal days where I learned right from the beginning to use "/" instead of "div" to get the "correct" result from an integer division. BTW who said that the result of a divsion between 2 integers has to be an integer again? Every second-grader knows that 3/2 is NOT 1, it is 1.5. This is just common sense, and I don't care what some old language designers once thought.

[StainlessS]

You have been told, ... learn :)

Bit messed up at the mo, will come back.

[manolito]

You have been told, ... learn :)


That's what I'm always trying to do...

Still not convinced, though. After an extended research session my conclusion is that a lot of this has historical reasons. At the time the C language was designed computers normally did not have a separate FPU, so a design goal was to keep integer math and floating point math strictly separate.

In our special case this means that the expression 60000 / 1001 is evaluated first with no regard to its outside encapsulation. The only way to get a float result is to type cast at least one of the operands to float.

I tried to analyze the "num" parameter in order to find a "/" character in it and then act accordingly. No chance, the input for my "FindStr" command always was the already evaluated integer value.

A nice summary can be found here:
https://en.wikipedia.org/wiki/Division_(mathematics)#Of_integers


So I prefer languages which will output the "correct" results for integer divisions, and in most cases this will be a float value. This is what an unsuspecting programmer like me would expect, just like the second-grader who is asked what the result of "3 / 2" is. If he answers "1" he will have failed the test.


Cheers
manolito

[StainlessS]

@DavidHorman,

OK, have converted TWriteAVI to VS2008 (fixed some vs2008 warnings):- https://forum.doom9.org/showthread.php?t=172837

Files with ASM embedded in CPP files

FastWriteStream.cpp // EDIT: was wrongly FastWriteStream.h
cpuaccel.cpp
misc.cpp
tls.cpp (disabled)


I'll take a look, but I probably won't be able to do anything. Where is the ASM in the source code? Off the top of my head, I can't think of a good reason for such a thing to need it...

Well, maybe you just want to create some test AVI files, TWriteAVI Included demo makes in one of the demos, 1000 test AVI's, you try doing that by hand.
Or, maybe create pre-processed QTGMC file, auto write to Lossless encoded AVI, and then continue script using the lossless as input.

Or Maybe you use SoundOut to produce audio file on disk, only problem is it is not available till some time later, with
ForceProcessWAV, is available on disk on return from function.

TWriteAVI's usefulness is limited only by your imagination :)

Have Supplied todays update version with full VS 2008 project files, even for x64 (which dont compile due to ASM presence).

Also added VERSION resource in todays update. [Right click, view Properties on dll]

[StainlessS]

So I prefer languages which will output the "correct" results for integer divisions, and in most cases this will be a float value. This is what an unsuspecting programmer like me would expect, just like the second-grader who is asked what the result of "3 / 2" is. If he answers "1" he will have failed the test.


Well you make some good points,
However, I like the way that AVS script works, (maybe because I'm a C and MC68000 ASM programmer), and it is perfectly acceptable to me that int / int produces an int, anything else is 'taking liberties' in my view. AutoIt's way of doing things is a little bit awkward and probably due to everything being a variant, it can sometimes be a problem to restrict AutoIt from making assumptions about what it required.
Anyways, it dont matter what either of us prefers, we have to stick with the language as it is, and not as we might like it to be,
but feel free to bellyache about it :)

EDIT:
the second-grader who is asked what the result of "3 / 2" is. If he answers "1" he will have failed the test.
1 remainder 1, might also be an acceptable answer.

[wonkey_monkey]

Well, maybe you just want to create some test AVI files, TWriteAVI Included demo makes in one of the demos, 1000 test AVI's, you try doing that by hand.
Or, maybe create pre-processed QTGMC file, auto write to Lossless encoded AVI, and then continue script using the lossless as input.

Or Maybe you use SoundOut to produce audio file on disk, only problem is it is not available till some time later, with
ForceProcessWAV, is available on disk on return from function.


I meant "why would it need inline ASM" - it didn't strike me as the kind of case that would need hand-optimised code.

[StainlessS]

OT, moved to TWriteAVI thread:- https://forum.doom9.org/showthread.php?p=1847647#post1847647