Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 9th October 2018, 23:47   #61  |  Link
zorr
Registered User
 
Join Date: Mar 2018
Posts: 93
Quote:
Originally Posted by Seedmanc View Post
Ok, so I gave it a try, here are the impressions.
Thanks, much appreciated.

Quote:
Originally Posted by Seedmanc View Post
however Avstimer always returned time of 9999999ms.
That may not be the fault of Avstimer. The optimizer sets this value as the timing result when the SSIM is invalid (that is, zero). It's done that way in order to keep the invalid results out of pareto front (an invalid result might be faster than any other result and stay in the pareto front due to being the fastest). You could check what Avstimer really returns by running the script manually (in VirtualDub or Avsr for example) and see what's inside the perFrameResults.txt. Paste it here as well, maybe there are more clues as to what is wrong.

Quote:
Originally Posted by Seedmanc View Post
I suppose that made the optimization task much less efficient, because where I expected it to take tens of minutes for 10 720p frames in 3 runs, it took 15 minutes for the first run, 2.5 hours on second and 1.5 hours on third. I ran it with algo "mutation" and 100 iters. My system is Core i5 2550k OC'd to 4.3GHz, 16Gb RAM
That's a large variation in runtime but not entirely unexpected. Even without dct=1 there are some very slow parameter combinations and if the optimizer stumbles upon one of those it might keep trying the slow ones if they happen to give good results. So most likely at least some results in the pareto front were using those slow combinations and mutating them resulted in mostly slow combinations. This could be verified looking at the log files or visualizing them.

Quote:
Originally Posted by Seedmanc View Post
Here's a script I used, modified from what you offered in the other thread:
I tried it and after swapping the source and result files found it worked just fine.

Quote:
Originally Posted by Seedmanc View Post
A few notes:
1) I dropped the RemoveGrain call since my sources are CGI and clean enough already.
Good call, removing extraneous parameters will help the optimizer.

Quote:
Originally Posted by Seedmanc View Post
2) The FrameEvaluate you use doesn't seem to be the native one, as it complained that it doesn't have the argument "args". It worked when I installed GScript, you might want to add that to the list of dependencies.
Sorry about that, I have ScriptClip installed and used its syntax there and forgot to remove the "args". It's not actually necessary and works just fine without it.

Quote:
Originally Posted by Seedmanc View Post
3) Shouldn't the optimizer params description for DCT include the D flag, since, much like the searchAlgo param, it is "non-linear" and we can't make assumptions about the value and effect? I put the flag there.
That's true, I added the dct parameter later and didn't really think it through. Yes, it should have the D flag.

Quote:
Originally Posted by Seedmanc View Post
The results were confusing.

I can see some tendencies when analyzing the logs manually, sorting by the SSIM so there's that at least. Visually, however, I can't say it looks better than what the hand-picked parameters provide, but that's to be expected from a first attempt with a low iter count.
Yes, maybe that denoising example gave a little too rosy picture of the process. That truly is a toy problem compared to MVTools and 100 iterations will not get you very far here. I am currently running a test with 5000 iterations and 5 runs.

Quote:
Originally Posted by Seedmanc View Post
I think the large search space (22 parameters) might have affected it too.
Yes, there's a thing called the curse of dimensionality. Searching in a high dimensional space is much more difficult than doing it in a low dimensional space. The script I gave is perhaps too brutal, my goal is to make an easier one with smaller search space once I have found the smaller subspace where the good results can be found.

Quote:
Originally Posted by Seedmanc View Post
Maybe I should leave the truemotion tuning to later and first try to see what more common set of parameters this tool can generate to compare with the manually tuned ones. Then once I have the good params fixed, I can have it experiment with truemotion.
That's a very reasonable idea. You can go even further and just search around some settings you know are good.

Quote:
Originally Posted by Seedmanc View Post
Another question I wanted to ask, is there a way to estimate the amount of time/iters/population required for a certain amount of tunable script parameters involved? I don't really understand much the math involved, but I have a feeling that either the population size or the iters count should scale up with the parameter count somehow.
I would love to have that kind of estimation but alas I don't know how to calculate it. But it totally makes sense that increasing the iters / population is needed for larger parameter count. The current default values were determined using a script with 22 parameters so they should work quite well with your script.

Quote:
Originally Posted by Seedmanc View Post
Seeing how the first run took 15 minutes while the second one 2.5 hours it means not every run will even attempt to cover all parameters involved, since obviously the first one omitted the slowest stuff like DCT 4. But then you said Mutation algo can work with population 1.
I believe the dct=4 has been tried but for some reason was not better than what was in the pareto front at the time. That could be simply because at the same time some other parameter was also mutated and that one brought the quality down more than dct=4 brought it up. Search the logs for dct=4 to be sure.

Quote:
Originally Posted by Seedmanc View Post
I assume, if we were using brute-force instead of metaheuristics, then for every new parameter introduced (or a value added to a list of possible values for existing parameters) the total combination amount would double. Is there a way to roughly estimate the effect of parameter addition here?
We can calculate the number of possible combinations by multiplying the number of allowed values of each parameter. For example with

Code:
super_pel = 2 # optimize super_pel = _n_ | 2,4 | super_pel
super_sharp = 2 # optimize super_sharp = _n_ | 0..2 | super_sharp
super_rfilter = 4 # optimize super_rfilter = _n_ | 0..4 | super_rfilter
there are 2*3*5 = 30 combinations. Doing the math for your script we get 2*3*5*9*8*30*60*20001*19993*257*3*17*3*2*9997*47*2*2*2*10*300*3 = 4 136 285 698 342 782 746 022 144 000 000. Not every one of those combinations is valid though.

Last edited by zorr; 9th October 2018 at 23:58. Reason: Calculated combinations was 900 times too small
zorr is offline   Reply With Quote
Old 10th October 2018, 00:06   #62  |  Link
zorr
Registered User
 
Join Date: Mar 2018
Posts: 93
Quote:
Originally Posted by Groucho2004 View Post
There's no reason whatsoever to link a current binary against these ancient 7.x DLLs which cause nothing but grief.

zorr, post your current project, I'll have a look.

I posted makefiles with the modified code which have the correct compiler and linker settings which you can use to build the DLLs from the command line.
Uploaded it here. Thanks!
zorr is offline   Reply With Quote
Old 10th October 2018, 00:14   #63  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Posts: 3,896
Quote:
Originally Posted by zorr View Post
Uploaded it here. Thanks!
The avstimer.dll you have in your "Release" directory is not the same as the one you posted before. It also has the correct VC2015/2017 dependencies.

Edit: Checked the time stamp on the first one you posted - It's Kassandro's DLL from 2005.

Last edited by Groucho2004; 10th October 2018 at 00:20.
Groucho2004 is offline   Reply With Quote
Old 10th October 2018, 00:29   #64  |  Link
zorr
Registered User
 
Join Date: Mar 2018
Posts: 93
Quote:
Originally Posted by Groucho2004 View Post
The avstimer.dll you have in your "Release" directory is not the same as the one you posted before. It also has the correct VC2015/2017 dependencies.

Edit: Checked the time stamp on the first one you posted - It's Kassandro's DLL from 2005.
I guess I only added the missing x64 version. Is that one using the correct dependencies as well?
zorr is offline   Reply With Quote
Old 10th October 2018, 00:33   #65  |  Link
zorr
Registered User
 
Join Date: Mar 2018
Posts: 93
Plugins package with SSIM and AvsTimer has been updated, hopefully with a more functional 32bit AvsTimer.
zorr is offline   Reply With Quote
Old 10th October 2018, 00:47   #66  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Posts: 3,896
Quote:
Originally Posted by zorr View Post
Plugins package with SSIM and AvsTimer has been updated, hopefully with a more functional 32bit AvsTimer.
All good now.
Groucho2004 is offline   Reply With Quote
Old 10th October 2018, 02:43   #67  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,982
Quote:
There's no reason whatsoever to link
True, so long as there is source, otherwise, ...

Unfortunately, not everyone is willing to go to the bother of compiling Ye Olde stuff, even if source does exist.

Above link has been there for several years I think, not altogether a bad idea to have access to such when required. (EDIT: not needed in this case when
there is someone as affable as Ye Olde G2K4 )
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 10th October 2018 at 02:55.
StainlessS is offline   Reply With Quote
Old 10th October 2018, 08:06   #68  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Posts: 3,896
Quote:
There's no reason whatsoever to link
Quote:
Originally Posted by StainlessS View Post
True, so long as there is source, otherwise, ...
Well, the word "link" usually implies that the source is present...
Groucho2004 is offline   Reply With Quote
Old 10th October 2018, 18:44   #69  |  Link
Seedmanc
Registered User
 
Join Date: Sep 2010
Location: Russia
Posts: 76
The new avstimer reports time correctly, thanks.

Some other ideas to add, previously it was mentioned that some parameter combinations might have no effect on time or SSIM, but what if we knew for sure what those combinations are, it would be nice to be able to mark them as such so the optimizer could skip them. For example, in MSuper the sharp parameter is only for pel>1, it won't raise an error otherwise but it'll be a waste of time.
Regarding the ConvertToYV24, can you give an example what kind of parameter combinations would be unsuitable for YV12 so this becomes necessary? It slows down the processing considerably, so I'd like to get rid of that.

Another thing, the badRange parameter of MAnalyze says that we need to use positive values for UMH search and negative for exhaustive. Unfortunately it does not disclose why, however it doesn't raise an error anyway. But the FPS for negative values is almost a half of what's achieved for positive ones (when you set badSAD to 0 so the wide search is always invoked, not a real-life scenario, but might happen a lot during the search). In SVP a similar parameter is described as using an adaptive radius when negative to save time, claiming it takes about 2/3 of time for a similar result, but it seems we have the opposite here. Anyway, how would we describe it in the settings to use negative values when searchAlgo is 3?

Finally, I wonder about the temporal parameter. The readme says it's incompatible with setMTmode, however the new mvtools have the MT parameter inbuilt and on by default, do we know if it should be disabled for temporal? Again, it doesn't raise errors, the output looks differently but then it also does look differently when disabling MT for temporal=false as well. Really, the readme should be updated there.


To comment on your post about the runs vs iters, you said,
Quote:
I don't have a good answer on how many runs are enough. If you can only run N iterations should you run for example three runs with N/3 iterations or eight runs with N/8 iterations? More iterations is better but more runs is also better, to a point.
. But judging from the example where you ran a script for 100, 200 500 and 2000 iterations, the key was to see how the results stabilize among multiple runs, converging to a single set of parameters and resulting SSIMs/times. Hence, multiple runs are only used to check if the process has stabilized enough, but multiple iterations are the requirement for that stabilization. In best case all you'd need is 2 runs and a large amount of iters to see if the results became close to each other. I use 3 since it's the lowest amount from which you can already calculate both the average and the median.
If I'm correct about that all we need to figure out is how to scale population count over the increasing search space. What configuration is more likely to try the largest subset of the search parameters, the high-iter low-pop or the vice-versa?

Last edited by Seedmanc; 10th October 2018 at 21:30.
Seedmanc is offline   Reply With Quote
Old 11th October 2018, 00:24   #70  |  Link
zorr
Registered User
 
Join Date: Mar 2018
Posts: 93
Quote:
Originally Posted by Seedmanc View Post
Some other ideas to add, previously it was mentioned that some parameter combinations might have no effect on time or SSIM, but what if we knew for sure what those combinations are, it would be nice to be able to mark them as such so the optimizer could skip them.
Using the dependency definitions (min / max / filter) we can guarantee that the optimizer will not try certain combinations. It doesn't really matter what the purpose is (in some cases to avoid completely invalid combinations, in some cases to avoid doing useless work).

Quote:
Originally Posted by Seedmanc View Post
For example, in MSuper the sharp parameter is only for pel>1, it won't raise an error otherwise but it'll be a waste of time.
You could define it like this:

Code:
super_pel = 2 # optimize super_pel = _n_ | 1,2,4 | super_pel
super_sharp = 2 # optimize super_sharp = _n_ | 0..2 ; max:super_pel 1 == 0 2 ? | super_sharp
Translation: if super_pel is 1 then then the maximum value of super_sharp is 0, otherwise it is 2. But note that in your script super_pel only has values 2 and 4 so in this case all the values of super_sharp are valid. My experience so far has been that the best results pretty much always use super_pel=4, may not be worth your time to try the other values unless you're also optimizing for speed.



Quote:
Originally Posted by Seedmanc View Post
Regarding the ConvertToYV24, can you give an example what kind of parameter combinations would be unsuitable for YV12 so this becomes necessary? It slows down the processing considerably, so I'd like to get rid of that.
The error message you get is "MAnalyse: wrong overlap for the colorspace subsampling for divide mode". Looking at the MVTools source I was able to gather that it's triggered when overlap is not divisible by xRatioUV (or overlapv is not divisible by yRatioUV). And the xRatioUV is 2 for YUY2 and (1 << vi.GetPlaneWidthSubsampling(PLANAR_U)) for other formats. Assuming you convert to YV12 instead (which is needed for the SSIM anyway) then you can avoid the error by making the overlap values divisible by 4. Like this (filter dependency is no longer needed so I removed that):

Code:
overlap=0	# optimize overlap=_n_ | 0,4,8,12,16,20,24,28,32 ; max:blockSize 2 / | overlap
overlapv=0 # optimize overlapv=_n_ | 0,4,8,12,16,20,24,28,32 ; max:blockSize 2 / | overlapv
You could also avoid the speed penalty by preprocessing the video to YV24 and use that instead. It might still be slower than processing YV12 but at least you don't pay the price of conversion every time. And also consider the cropping idea, that can give you a significant speed increase.

Quote:
Originally Posted by Seedmanc View Post
Another thing, the badRange parameter of MAnalyze says that we need to use positive values for UMH search and negative for exhaustive. Unfortunately it does not disclose why, however it doesn't raise an error anyway.
I think this means that using negative values selects the exhaustive algorithm and using positive values selects the UMH algorithm for this wide search, independently on what is used in the first search. Btw I didn't even realize you can use negative values, I guess I now have to test those too.

Quote:
Originally Posted by Seedmanc View Post
Anyway, how would we describe it in the settings to use negative values when searchAlgo is 3?
You could use the min and max dependencies. Or the filter, you can do pretty much anything you could think of with that one.

Quote:
Originally Posted by Seedmanc View Post
Finally, I wonder about the temporal parameter. The readme says it's incompatible with setMTmode, however the new mvtools have the MT parameter inbuilt and on by default, do we know if it should be disabled for temporal? Again, it doesn't raise errors, the output looks differently but then it also does look differently when disabling MT for temporal=false as well. Really, the readme should be updated there.
I don't know more than you about this, if Pinterf is around maybe he could clarify. But it strikes me odd that the result would be different when temporal is disabled and MT is on/off. That could be a bug.

Quote:
Originally Posted by Seedmanc View Post
But judging from the example where you ran a script for 100, 200 500 and 2000 iterations, the key was to see how the results stabilize among multiple runs, converging to a single set of parameters and resulting SSIMs/times. Hence, multiple runs are only used to check if the process has stabilized enough, but multiple iterations are the requirement for that stabilization.
I was just showing off. It's rare that you can make the results converge to the exact same values. When that does happen though it's a strong indicator that we've found the optimal result. In a more realistic scenario the iteration counts are always insufficient to make the results converge in that way. There may be some parameters with the same values (like super_pel=4) but many others are different, some wildly.

There is another reason to do multiple runs. The beginning of the search usually "locks" the search into a certain corner of the search space and it may never get out of that within the iteration count. So it could be that you get significantly better result in one out of say, 10 runs. If you only ever do 3 runs maybe you'll never get to that lucky corner. Here's a recent example:

Code:
Run 1 best: 9.790725 2130 rmgrain=12 super_rfilter=1 blockSize=8 searchAlgo=3 searchRange=1 
searchRangeFinest=7 lambda=2213 LSAD=2744 plevel=2 overlap=0 globalMotion=true badSAD=9559 
badRange=34 meander=false temporal=false trymany=false dct=1 maskScale=2
Run 2 best: 9.787563 1210 rmgrain=19 super_rfilter=1 blockSize=8 searchAlgo=1 searchRange=1 
searchRangeFinest=3 lambda=3931 LSAD=19316 plevel=2 overlap=0 globalMotion=false badSAD=2770 
badRange=13 meander=true temporal=true trymany=false dct=1 maskScale=2
Run 3 best: 9.790011 1510 rmgrain=19 super_rfilter=1 blockSize=8 searchAlgo=3 searchRange=1 
searchRangeFinest=4 lambda=2629 LSAD=1684 plevel=2 overlap=0 globalMotion=true badSAD=9831 
badRange=10 meander=true temporal=false trymany=false dct=1 maskScale=2
Run 4 best: 9.789404 1190 rmgrain=19 super_rfilter=0 blockSize=8 searchAlgo=1 searchRange=1 
searchRangeFinest=2 lambda=2142 LSAD=2679 plevel=2 overlap=0 globalMotion=true badSAD=9558 
badRange=45 meander=true temporal=false trymany=false dct=1 maskScale=2
Run 5 best: 9.788453 1220 rmgrain=8  super_rfilter=0 blockSize=8 searchAlgo=1 searchRange=1 
searchRangeFinest=3 lambda=3432 LSAD=6410 plevel=2 overlap=0 globalMotion=true badSAD=4531 
badRange=4 meander=true temporal=false trymany=false dct=1 maskScale=1
There are three results below 9.79 and two above it. If you're unlucky you'll get those below 9.79 results in your three runs. These results were run with 5000 iterations, the differences are larger with a smaller iteration count.

Quote:
Originally Posted by Seedmanc View Post
In best case all you'd need is 2 runs and a large amount of iters to see if the results became close to each other. I use 3 since it's the lowest amount from which you can already calculate both the average and the median.
Maybe you're right. It's a tough call because we're talking about probabilities here. So if you do *this*, then *that* happens with a certain probability, but not always. One could do a large number of runs and then using that data calculate what are the odds for a certain result using N runs. But I think it also depends on the particular script and how difficult it is to optimize.

Quote:
Originally Posted by Seedmanc View Post
If I'm correct about that all we need to figure out is how to scale population count over the increasing search space. What configuration is more likely to try the largest subset of the search parameters, the high-iter low-pop or the vice-versa?
Strictly speaking there is no difference, the number of iterations defines how large the searched subset is (as the optimizer never tries duplicates within one run). But I guess you're asking how to get the widest possible subset. For that question the high population should do better in terms of how wide the search is but it's going to do less mutations of the best result and therefore might end up with a worse result than a smaller population. The "mutation" algorithm with population 1 is the most narrow search possible, it simply keeps the best result and mutates it until one of the mutations is better. If you just want to make the search wider, you can do that also by cranking up the mutation amount and count.

Last edited by zorr; 11th October 2018 at 00:42. Reason: Added suggestion to use mutation count / amount
zorr is offline   Reply With Quote
Old 12th October 2018, 18:25   #71  |  Link
Seedmanc
Registered User
 
Join Date: Sep 2010
Location: Russia
Posts: 76
Two problems, one is that after I modified the script to disable YV24 conversion, limit the sharp parameter and introduce the negative badRange (didn't work with -50..50 values so I added a boolean flag according to which I do or do not multiply the range by -1), the script started crashing, complaining that "MflowFps can't work in reentrant multithreading" even though I didn't touch anything MT-related. While I do have MT versions of Avisynth 2.6 and Avisynth+ installed I do not call setmtmode or prefetch in either but it crashes in both randomly, I'm lucky if I manage to get one run finished.

I used to get this error before AvsOptimizer sometimes too, usually when switching between multiple heavy scripts in Avsp editor, but it was a rare occurrence. Before I edited the script I managed to run it overnight totalling in over a thousand iterations without a problem. If it didn't work right away I'd consider that launching two upsampling operations in succession like we do here might've been the culprit.

Here's my script as of now:

Quote:
TEST_FRAMES = 10
MIDDLE_FRAME = 600

# original framerate
FPS_NUM = 30
FPS_DEN = 1

# source clip
Asrc=FFmpegSource2("c:\Hibikin - Watashtachi wa Zutto... Deshou (AVS test video 60fps 720p 10bit CRF0).mkv",threads=1 ).assumefps(60)
Asrc=Asrc.trim(0,60*30-9)+Asrc.trim(60*40+60*60+9,0)
asrc.selecteven
AssumeFPS(FPS_NUM, FPS_DEN)

#return last

# needed for some parameter combinations
#ConvertToYV24()

orig = last

mt=true #happens without this parameter as well since mt is true by default, just introduced it for later use


super_pel = 2 # optimize super_pel = _n_ | 1,2,4 | super_pel
super_sharp = 2 # optimize super_sharp = _n_ | 0..2 ; max:super_pel 1 == 0 2 ? | super_sharp
super_rfilter = 4 # optimize super_rfilter = _n_ | 0..4 | super_rfilter
super_render = MSuper(pel=super_pel, sharp=super_sharp, rfilter=super_rfilter, orig, mt=mt )

blockSize = 12 # optimize blockSize = _n_ | 4,6,8,12,16,24,32,48,64 ; min:divide 0 > 8 2 ? ; filter:overlap 2 * x <= | blockSize
searchAlgo = 3 # optimize searchAlgo = _n_ | 0..5 D | searchAlgo
searchRange = 4 # optimize searchRange = _n_ | 1..30 | searchRange
searchRangeFinest = 4 # optimize searchRangeFinest = _n_ | 1..40 | searchRangeFinest
lambda = 16000 # optimize lambda = _n_ | 0..20000 | lambda
lsad=400 # optimize lsad=_n_ | 8..20000 | lsad
pnew=0 # optimize pnew=_n_ | 0..256 | pnew
plevel=0 # optimize plevel=_n_ | 0..2 | plevel
overlap=4 # optimize overlap=_n_ | 0,4,8,12,16,20,24,28,32 ; max:blockSize 2 / | overlap
divide=2 # optimize divide=_n_ | 0..2 ; max:blockSize 8 >= 2 0 ? overlap 4 % 0 == 2 0 ? min | divide
globalMotion = true # optimize globalMotion = _n_ | false,true | globalMotion
badSAD = 2000 # optimize badSAD = _n_ | 4..10000 | badSAD
badRange = 24 # optimize badRange = _n_ | 2..50 | badRange
negBadRange = false # optimize negBadRange = _n_ | false,true | negBadRange
meander = true # optimize meander = _n_ | false,true | meander
temporal = false # optimize temporal = _n_ | false,true | temporal
trymany = false # optimize trymany = _n_ | false,true | trymany
dct = 0 # optimize dct = _n_ | 0,2,3,4,5,6,7,8,9,10 D | dct

delta = 1
useChroma = true

resultBadRange = (negBadRange ? -1 : 1)*badRange
bv = MAnalyse(super_render, isb = true, blksize=blockSize, search=searchAlgo, searchparam=searchRange, pelsearch=searchRangeFinest,
\ chroma=useChroma, delta=delta, lambda=lambda, lsad=lsad, pnew=pnew, plevel=plevel, global=globalMotion, overlap=overlap ,
\ divide=divide, badSAD=badSAD, badrange=resultBadRange, meander=meander, temporal=temporal, trymany=trymany, dct=dct, mt=mt)
fv = MAnalyse(super_render, isb = false, blksize=blockSize, search=searchAlgo, searchparam=searchRange, pelsearch=searchRangeFinest,
\ chroma=useChroma, delta=delta, lambda=lambda, lsad=lsad, pnew=pnew, plevel=plevel, global=globalMotion, overlap=overlap ,
\ divide=divide, badSAD=badSAD, badrange=resultBadRange, meander=meander, temporal=temporal, trymany=trymany, dct=dct, mt=mt)



threshold = 10000
maskScale = 100 # optimize maskScale = _n_ | 1..300 | maskScale
mask_fps = 2 # optimize mask_fps = _n_ | 0..2 | mask_fps
inter = orig.MFlowFPS(super_render, bv, fv, num=FPS_NUM*2, den=FPS_DEN, mask=mask_fps, ml=maskScale, thSCD1=threshold )

# return this to look at the clip with doubled framerate
#return inter

fps_only = inter.SelectOdd()

# second pass
super_render2 = MSuper(pel=super_pel, sharp=super_sharp, rfilter=super_rfilter, fps_only )
bv2 = MAnalyse(super_render2, isb = true, blksize=blockSize, search=searchAlgo, searchparam=searchRange, pelsearch=searchRangeFinest,
\ chroma=useChroma, delta=delta, lambda=lambda, lsad=lsad, pnew=pnew, plevel=plevel, global=globalMotion, overlap=overlap,
\ divide=divide, badSAD=badSAD, badrange=resultBadRange, meander=meander, temporal=temporal, trymany=trymany, mt=mt)
fv2 = MAnalyse(super_render2, isb = false, blksize=blockSize, search=searchAlgo, searchparam=searchRange, pelsearch=searchRangeFinest,
\ chroma=useChroma, delta=delta, lambda=lambda, lsad=lsad, pnew=pnew, plevel=plevel, global=globalMotion, overlap=overlap,
\ divide=divide, badSAD=badSAD, badrange=resultBadRange, meander=meander, temporal=temporal, trymany=trymany, mt=mt)
inter2 = fps_only.MFlowFPS(super_render2, bv2, fv2, num=FPS_NUM*2, den=FPS_DEN, mask=mask_fps, ml=maskScale, thSCD1=threshold )
fps_only2 = inter2.SelectOdd()


delimiter = "; "

inter_yv12 = fps_only2#.ConvertToYV12()
orig_yv12 = orig#.ConvertToYV12()

# for comparison original must be forwarded one frame
orig_yv12 = trim(orig_yv12,1,0)

inter_yv12 = inter_yv12.Trim(MIDDLE_FRAME - TEST_FRAMES/2 + (TEST_FRAMES%2==0?1:0), MIDDLE_FRAME + TEST_FRAMES/2)
orig_yv12 = orig_yv12.Trim(MIDDLE_FRAME - TEST_FRAMES/2 + (TEST_FRAMES%2==0?1:0), MIDDLE_FRAME + TEST_FRAMES/2)
last = inter_yv12

global total = 0.0
global ssim_total = 0.0
global avstimer = 0.0
frame_count = FrameCount()
FrameEvaluate(last, """
global ssim = SSIM_FRAME(orig_yv12, inter_yv12)
global ssim_total = ssim_total + (ssim == 1.0 ? 0.0 : ssim)
""", args="orig_yv12, inter_yv12, delta, frame_count")

# NOTE: AvsTimer call should be before the WriteFile call
AvsTimer(frames=1, type=0, total=false, name="Optimizer")

# per frame logging (ssim, time)
resultFile = "c:\avsoptim\results\perFrameResults.txt" # output out1="ssim: MAX(float)" out2="time: MIN(time) ms" file="c:\avsoptim\results\perFrameResults.txt"
WriteFile(resultFile, "current_frame", "delimiter", "ssim", "delimiter", "avstimer")
WriteFileIf(resultFile, "current_frame == frame_count-1", """ "stop " """, "ssim_total", append=true)

return last
The second thing is that limiting iterations by time is rather loose, apparently because it does not include the time spent on generating populations, so where I set it to 3 runs with 3 hours it went for 3:05, 3:20 and over 4 hours on last run. Not very convenient when you expect it to be done in the morning.

Also, for some reason sensitivity estimation is always marked as N/A in the log, even if I try to pass -sensitivity true. It would be interesting to see which parameters are more important.
Seedmanc is offline   Reply With Quote
Old 12th October 2018, 21:14   #72  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Posts: 3,896
Quote:
Originally Posted by Seedmanc View Post
Two problems, one is that after I modified the script to disable YV24 conversion, limit the sharp parameter and introduce the negative badRange (didn't work with -50..50 values so I added a boolean flag according to which I do or do not multiply the range by -1), the script started crashing, complaining that "MflowFps can't work in reentrant multithreading" even though I didn't touch anything MT-related. While I do have MT versions of Avisynth 2.6 and Avisynth+ installed I do not call setmtmode or prefetch in either but it crashes in both randomly, I'm lucky if I manage to get one run finished.
Run "avsmeter avsinfo -log" and post the log file. Use pastebin or similar to post the log.
Groucho2004 is offline   Reply With Quote
Old 12th October 2018, 23:36   #73  |  Link
zorr
Registered User
 
Join Date: Mar 2018
Posts: 93
Quote:
Originally Posted by Seedmanc View Post
Two problems, one is that after I modified the script ... the script started crashing, complaining that "MflowFps can't work in reentrant multithreading" even though I didn't touch anything MT-related. While I do have MT versions of Avisynth 2.6 and Avisynth+ installed I do not call setmtmode or prefetch in either but it crashes in both randomly, I'm lucky if I manage to get one run finished.
I used to have a similar problem when I ran with a high resolution source, it was because the script was running out of memory. With

Code:
SetMemoryMax(2048)
the problem went away. I tried your script again and didn't have any problems, but I'm using a low resolution source.

Quote:
Originally Posted by Seedmanc View Post
Here's my script as of now:
I like the way you implemented the positive / negative badRange. It's pretty much the way I would have done it, separating the algorithm into its own parameter.

Quote:
Originally Posted by Seedmanc View Post
The second thing is that limiting iterations by time is rather loose, apparently because it does not include the time spent on generating populations
Yes, the mutation algorithm had such a flaw. It should be fixed now in the latest 0.9.5-beta.

Quote:
Originally Posted by Seedmanc View Post
Also, for some reason sensitivity estimation is always marked as N/A in the log, even if I try to pass -sensitivity true. It would be interesting to see which parameters are more important.
The mutation algo is not quite as fully featured as the others, it's missing the sensitivity estimation at the moment. I will add it in the next version. It's probably not going to happen during this weekend though, I'm moving tomorrow and about to start renovating the new house...

Last edited by zorr; 12th October 2018 at 23:55. Reason: Added info about testing the script
zorr is offline   Reply With Quote
Old 13th October 2018, 00:12   #74  |  Link
Seedmanc
Registered User
 
Join Date: Sep 2010
Location: Russia
Posts: 76
Groucho2004, here are the logs: https://pastebin.com/trPLFs2w (primary setup with avs2.6), https://pastebin.com/TjdMquUr (secondary setup with avs+). For some reason it complains about the absence of fft3w lib in the latter, even though mvtools dct modes work fine.

zorr, thanks for the memory suggestion and the time fix, I'll try to run it overnight now with those. I wonder if it would be possible to use the 3Gb or 4Gb limits reliably since I'm on 64bit OS. SEt says it requires the patching of the runner app (avsr in our case) for support, I assume it applies regardless of MT usage, does avsr have that?
Seedmanc is offline   Reply With Quote
Old 13th October 2018, 02:12   #75  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Posts: 3,896
Quote:
Originally Posted by Seedmanc View Post
Groucho2004, here are the logs: https://pastebin.com/trPLFs2w (primary setup with avs2.6), https://pastebin.com/TjdMquUr (secondary setup with avs+). For some reason it complains about the absence of fft3w lib in the latter, even though mvtools dct modes work fine.
Remove avstp.dll from your plugins directory and see if it still crashes.

As for fft3w - Just ignore it for now.
Groucho2004 is offline   Reply With Quote
Old 13th October 2018, 02:56   #76  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,982
W10

Code:
[CPP 2.5 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins+\avstimer.dll  [2018-10-07]    # 2.5 Plugin in Plugins+ folder
C:\Program Files (x86)\AviSynth+\plugins+\ffms2.dll  [2013-05-21]       # 2.5 Plugin in Plugins+ folder

[CPP 2.6 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins\avstimer.dll  [2018-09-11]     # see above. (earlier plug is v2.6, later 2.5 ?????? )
C:\Program Files (x86)\AviSynth+\plugins+\mvtools2.dll  [2.5.11.22]     # Plugins/+ mixup with below
C:\Program Files (x86)\AviSynth+\plugins\mvtools27.dll  [2.7.31.0]      #   ditto
EDIT: Presumably, the only plugz that should be in plugins+ should be those that use avs+ colorspaces, or functionality.
EDIT: The 'hazy' part is standard v2.6 plug with standard VERSION 6 header, versus avs+ VERSION 6 Header,
ie should avs+ VERSION 6 header but without avs+ colorspace or functionality be in + or standard plugins (?).
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 13th October 2018 at 08:23.
StainlessS is offline   Reply With Quote
Old 13th October 2018, 03:21   #77  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Posts: 3,896
Quote:
Originally Posted by Seedmanc View Post
I wonder if it would be possible to use the 3Gb or 4Gb limits reliably since I'm on 64bit OS. SEt says it requires the patching of the runner app (avsr in our case) for support, I assume it applies regardless of MT usage, does avsr have that?
avsr is LAA (Large Address Aware). Patching is only necessary when the application is not built with that linker switch (VirtualDub, for example).

Besides, since there is a 64 bit version of the Optimizer, why not use that?

Lastly, why would you use SEt's ancient Avisynth MT? AVS+ is quite stable, has a 64 bit version, uses less memory and, from my experience, has better MT support.

Last edited by Groucho2004; 13th October 2018 at 03:25.
Groucho2004 is offline   Reply With Quote
Old 13th October 2018, 12:18   #78  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Posts: 3,896
Quote:
Originally Posted by StainlessS View Post
EDIT: Presumably, the only plugz that should be in plugins+ should be those that use avs+ colorspaces, or functionality.
EDIT: The 'hazy' part is standard v2.6 plug with standard VERSION 6 header, versus avs+ VERSION 6 Header,
ie should avs+ VERSION 6 header but without avs+ colorspace or functionality be in + or standard plugins (?).
I too think that in order to earn the hallowed privilege to reside in the "+" directory, plugins should support AVS+ colour spaces and/or register their own MT modes.

There's no reason to use any other header for 2.6 plugs than the one that comes with AVS+ which is fully backward compatible with classic AVS.

Last edited by Groucho2004; 13th October 2018 at 12:21.
Groucho2004 is offline   Reply With Quote
Old 14th October 2018, 12:53   #79  |  Link
Seedmanc
Registered User
 
Join Date: Sep 2010
Location: Russia
Posts: 76
So, after much suffering (because nothing helped against the crashes, not even running it on 64bit avs+) I figured out to take a look at the intermediate avs scripts generated by the optimizer to find what has brought it to its knees. https://pastebin.com/bgUELWu6 this one crashes 100% of the time, can you tell what the problem is?
I'll save you time, it's the combination of pel 4, blocksize 8 with overlap 4, divide > 0 with large search radius and (surprise!) removal of ConvertToYV24. What does it have to do with MT? Well I don't know, ask the mvtools maker about their error reporting style.
Further testing revealed that for pel 4 it is enough to have search radius of 4 to cause error, with pel 2 it takes around 12 and I couldn't reproduce it for pel 1. While I admit that having a search radius larger than block size seems strange it doesn't cause an error for YV24 or divide 0 / pel 1. What's more weird is that unlike the chroma subsampling violation it does not necessarily raise an error right away, sometimes it happens in the middle or at the end of the script, sometimes it's not the MT error but some random access violation. Moreso, setting chroma to false doesn't help (but converting to YV24 still does even then). Nothing in the readme has prepared me for this.
Worst thing I don't even know how to report it, the thread has been abandoned for months.

I guess more filters/minmaxes are in order, but with the current notation it's hard to figure out how to write them. Set divide to 0 when blocksize is 8 and overlap 4 and pel > 1.


In a way, Optimizer can be used as an automated plugin testing tool, since it tries out so many parameter combinations and reveals all kinds of bugs and readme inconsistencies.
Also, zorr, you might want to link you large explanative posts from this thread in the first post, now that the discussion took off it'll be more difficult to find them later.

Last edited by Seedmanc; 14th October 2018 at 13:27.
Seedmanc is offline   Reply With Quote
Old 14th October 2018, 16:36   #80  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,982
Quote:
Originally Posted by Seedmanc View Post
Also, zorr, you might want to link you large explanative posts from this thread in the first post, now that the discussion took off it'll be more difficult to find them later.
Can I also suggest that all non-beta versions be linked in first post only and not in temporal posts.

Seems that the [EDIT: forum] spell checker works again, been missing for some time (or maybe its because I'm on W7_64 at the moment, instead of XP32/64).
[EDIT: Or maybe spell check is via current version of Firefox for W7, and no longer supported for last for XP FireFox v52.xx ESR]
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 15th October 2018 at 00:45.
StainlessS is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 08:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.