MVTools without idx

[Fizick]

I found, that sadx264=-1 (i.e. old) in MVAnalyse is faster option than sadx264=0 (default, auto) in v2.0.9.1 (unlike v1.X)
So, some problem with alignment.
Please somebody with modern computer confirm it.

[Fizick]

Silence.
BTW, I take back my confirmation of a big slowdown of v2.0.9.1: I stupidly used wrong version of TemporalDegrain for comparison (and had slowdown even with disabled MVAnalyse-MVDegrain :) !
(too many is floating around, and all use wrong type of sigmas for some reason BTW...).
Where is its forum thread?
http://avisynth.org/mediawiki/Temporal_Degrain



But small (not very clear) slowdown (<5%) due to some introduced checking will be removed in next version.

[Fizick]

well, new version 2.0.9.2 without any external changes :cool:
But (i hope) it is faster a little. :devil:
please report.


Nearest plan: more accurate motion search. (No various block sizes yet). For bad SAD blocks (only!) we repeat a search at finest level with large radius, probably with UMH or even ESA.
:eek:
This way some small objects would not be skipped by hierarhy.
I already implemented it, but some tuning and merging is needed (I am switched to SVN), and I am not very excited with new parameters names badSAD, badradius :)

[mikeytown2]

Here's an idea for more accurate FPS conversions: Incorporate vcmohan's WaterShed. I don't even know where to begin but it segments the pic for coloring, maybe tracking of thoes segments will help FPS conversions. Just trying to give you more ideas; something different from the typical blocks that are used in image processing.
http://avisynth.org/vcmohan/WaterShed/Watershed.html

[Adub]

Hmm... would it be possible to transplant x264's motion search code into MVtools? The reason I ask is it is already available, well tested, and probably pretty damn optimized as well. Since you mention UMH and ESA, of which x264 has had for a long time.

[Fizick]

Merlin7777,
i take them from x264 :) (with some modification). But they are not so good for true motion and big vectors.

[Fizick]

about speed, I wonder why rearranging pSrc[3] with other declarations in PlaneOfBlocks.h give 4% slowdown....

[thetoof]

(Better don't try that with full-HD stuff...)I can see no difference in speed between the two scripts.

Use MVSuper(...,levels=1) if you do not MVAnalyse it (second and third item in your script).
Is the correct usage of levels=1 like this?
pref = source.denoiser
prefsuper = pref.MVSuper(settings)
sourcesuper = source.MVSuper(levels=1,settings)
vecs = mvanalyse(prefsuper,settings)
source.mvdegrainx(sourcesuper, vecs)
I found, that sadx264=-1 (i.e. old) in MVAnalyse is faster option than sadx264=0 (default, auto) in v2.0.9.1 (unlike v1.X)
So, some problem with alignment.
Please somebody with modern computer confirm it.
About 5% speed increase here. Q6600 2.4 Ghz (no setmtmode or mt) 4GB RAM

Where is its forum thread?
It was developed in the very grainy (http://forum.doom9.org/showthread.php?t=132310) thread, though it's not its "official" thread...

But (i hope) it is faster a little. :devil:
please report.Didn't do exhaustive testing, but I noticed a 4-8% speed increase.Nearest plan: more accurate motion search. (No various block sizes yet). For bad SAD blocks (only!) we repeat a search at finest level with large radius, probably with UMH or even ESA.
:eek:
This way some small objects would not be skipped by hierarhy.
I already implemented it, but some tuning and merging is needed (I am switched to SVN), and I am not very excited with new parameters names badSAD, badradius :)
Looking forward to it! :cool:

[Fizick]

About 5% speed increase here. Q6600 2.4 Ghz (no setmtmode or mt) 4GB RAM


What sadx264 option is faster?


Well , v2.0.11.1 is released. I am not sure about status, probably alpha.

I tested wide search with badSAD=1000 for the clip with a ball (some user sent it to me): http://rapidshare.com/files/154452839/video.avi.html

seems, ball is better now.

[thetoof]

sadx264=0

edit: I'll run more tests for the sadx264
Also, you didn't answer my question about the usage of levels=x to speed up super clips that won't be mvanalysed.

[Fizick]

Your usage levels=1 is correct. (you do not MVAnalyse this super clip).

[Naito]

Well , v2.0.11.1 is released.

http://avisynth.org.ru/mvtools/mvtools-v2.0.11.2.zip -> "404 Not Found: The requested URL /mvtools/mvtools-v2.0.11.2.zip was not found on this server."

Can this someone confirm?

EDIT: Confirmed within the MVTools v1 Thread (http://forum.doom9.org/showthread.php?p=1210771#post1210771).

EDIT2: Thanks Fizick :)

[Fizick]

Yes, i can :(
Fixed :)

[Delerue]

Fizick, last night I tried to watch a 2 hours movie with MVFlowFPS using pel=2 and it crashed in a random moment (can't reproduce it when I want...). I changed to pel=1 and it didn't crash once. I don't know if it has anything to do, but until this new version (2.x.x.x) MVTools never crashed like this. The problem is that until now I never tried pel=2, hehehe. Is there any way to debug this kind of crash?

Also, any idea when blend=false will be released? :)

Thanks

[Fizick]

Delerue, it is not informative without at least version information. try various 2.0.x, and additionally control memory usage.

blend=false version will be soon :).

[Fizick]

Released v2.1.0 (build 140)
MVFlowFps, MVBlockFps, MVFlowInter: added blend parameter for ChangeFps-like mode at scene changes
MVFlowFps, MVBlockFps: more safe for big nominator and denominator.

[Mug Funky]

[edit] nm, i'm with stupid - forgot all about mvsuper

i'm getting errors :(

"MVAnalyse: wrong super clip (pseudoaudio) parameters"
script:

qtinput("blackmagic 10-bit.mov",mode=1,raw="v210")

converttoyv12()

vf=last.mvanalyse()
last

[Delerue]

Delerue, it is not informative without at least version information.

Always the last, always. :D

try various 2.0.x, and additionally control memory usage.

Ok.

blend=false version will be soon :).

Well, already released, ahn? Perfect! Thank you very much. ;)

[Fizick]

Delerue, what was "the last" exactly (to produce crash)?

[Delerue]

Delerue, what was "the last" exactly (to produce crash)?

Well, when I told you that the last version was 2.0.11.2.

[Fizick]

it is bad news if will be confirmed. :(

[superuser]

For MVtools 2 version: How do we use outfile param for MVAnalyze. These were the thoughts that had came to mind when had seen that param in documentation: More of was thinking if running two or more pass encode, in past pass can we have MVAnalyze write vectors to a output file and in second pass the output file to which vector information were written. This can help speed up MVDegrain'x' and others utility functions which uses MVAnalyse

Did search on MVTools 1 thread and found this post: http://forum.doom9.org/showpost.php?p=1075333&postcount=560 for which Fizicks already had answered. Thought will bring this up as if this functionality if not implemented can be incorporated (MVRead)

Also tried 2.1.0 MVDegrain'x' speed wise better thn 2.0.9.1 and have not seen system crash till yet which had twice when using 2.0.9.1

[Fizick]

fixed MVBlockFps (left border) in v2.1.1 and v1.11.4.5

[Shon]

mvtools it is a revolutionary thing, I do not understand many people which consider that it only a usual plug-in and in it there is nothing especial. That it it has made MANY THANKS to the Fizick that!

[AVIL]

@Shon

The art of understand the point of view of the others is a skill difficult to obtain. Despite or this I also greatly appreciate mvtools plugin and Fizick efforts.

[Fizick]

Revolutionary? But it has long history of evolution! :)

BTW, I (not intentionally! :) ) changed default search method to Hex in v2.1.1.
Now I consider to return default to Diamond in v2.1.2. But not sure. Any opinions about v2.1.1 results of motion search?

[Shon]

Mvtools2 Does movements much more smoothly, but artefacts became more,
and in mvtools1 them it is visible in one places, and in the second version they appear in other scenes.
Strangely enough but trimension DNM (windvd) in such difficult scenes cannot make interpolation.http://i423.photobucket.com/albums/pp313/Shon198/mvtools1.jpghttp://i423.photobucket.com/albums/pp313/Shon198/mvtools2.jpg

[Fizick]

I try figure the difference of vectors v2.x from v1.x :

v2.0.9.2 and above always check (calculate SAD) the hierarhycal predictor,
but v1.x does not test it, if the predictor vector is same as already checked zero vector or global motion vector.
(these special vectors have some penalty pzero if pzero>0, but hierarhycal predictor has not any penalty).
So, zero predictor is more stable in v2 (other vectors have pnew penalty and lambda penalty).
Comment: It is not the "the only possible way", and I almost forgot about this change :), but it is implemented so.

v2.0.11 and above have new hexagon search method (=4) as default insted of Logariphmic (=2) due to some mess.
Comment: same as above.

Anyway, these difference are not very big, and I am wonde so big changes at your pictures.
what versions and script do you use? (short clip?)

[Delerue]

Shon, you're using MVFlowFPS, right? Try to use this two parameters (with version 2.x):

ThSCD1=350, blend=false

Put this inside the call of MVFlowFPS function. Example:

super = source.MVSuper(pel=2)
backward_vec = MVAnalyse(super, blksize=8, overlap=0, isb = true, search=3)
forward_vec = MVAnalyse(super, blksize=8, overlap=0, isb = false, search=3)
source.MVFlowFps(super, ThSCD1=350, blend=false, backward_vec, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source))

blend=false -> doesn't blend (mix) at scene changes, but...
ThSCD1=350 -> when ThSCD1 isn't changed, the default value is '400', and with some similar consecutive scenes (as yours), MVFlowFPS 'thinks' that's the same scene, so it mess everything. You can try other values besides '350'. I'm still testing it, and '350' seems to be better than '400'. The problem is that it's almost impossible to find a perfect value, because lowering 'ThSCD1' value mess with fast scene, and higher values mess with similar consecutive scenes. I can't remember what TrimensionDNM does in these situations (although I remember TrimensionDNM as a very good motion estimation algorithm), but maybe Fizick can think in a better solution to this problem.

[morsa]

Just to let you know that the new 2.x branch is really a big step forward in stability.
I can't say much about image quality (yet) but I hope to find out in coming days.

Amazing work.Congrats!! :D

[Fizick]

Delerue,
yes this dumb threshold ThSCD1 is not very clever. May be some adaptive or relative (to several previous frames) wolid be better. Who knows.
Suggestions?

[Terranigma]

Any chance we can see an 8x2 blocksize ?

[Fizick]

Terranigma, I have no it in my "to do" list.

EDIT: "no" is not "now" but "not" . sorry.

[Terranigma]

Terranigma, I have no it in my "to do" list.

OK Cool. Thanks! :D

[Delerue]

Delerue,
yes this dumb threshold ThSCD1 is not very clever. May be some adaptive or relative (to several previous frames) wolid be better. Who knows.
Suggestions?

It's hard to think in a solution that doesn't kill the CPU, hehehe. Serious, to me the real problem is performance. Otherwise, you could try to search a group of pixels in X frames behind and forward, and search it in the whole frame, and if this search returns something, than we're probably in the same scene. Well, but that's what you said with 'relative (to several previous frames)', right? :)

[Fizick]

no, i say about comparing SAD not to constant, but some floating value, dependent on history.

[AVIL]

@Fizick

a) A question about the values of mvmask(kind=3 or 4). When pel>1, the vector components are fractionary and will be rounded or the value are multiplied by pel or what?

b) About ThSCD1.

Perhaps using relative differences instead absolute differences could make predictions more robust against noise.

Another idea is to use difference of SAD's.

If a scene is stationary then succesive block sads are near to zero. Difference is (almost) constant between a frame and the next.

If the scene is panning blocks sad are higher but probabily constants in value across frames. Differece is again constant between a frame and the next.

In a scene change, block sad will be simillar to the previous frame one and very different than the next.

[Fizick]

a) from the doc: "...in pel units". So, in halfpel units for pel=2. for example, 25 halfpels, exactly as founded by search. Not rounded.

[AVIL]

I'll see now. Thanks and sorry.

[Fizick]

Shon,
After more deep digging, I found that v2.0.11 and above use wrong scaling of LSAD (and BadSAD) for non 8x8 blocks.
It is fixed in released v2.2.1

[Naito]

Suggestion: Offical renaming to "mvtools2.dll" to avoid confusion with the v1-Branch.

[Shon]

Fizick
Thanks, became now much better!:thanks:
blksize=32x16 well works, if still that I will notice I will necessarily inform!:)

[Fizick]

Naito,
it is worth to consider.

[AVIL]

Version 2.2.1 crashes with yuy2 clips, even with simple scripts:

setmemorymax(256)

Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\ssetools.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\mvtools2.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\nnedi.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\yadifmod.dll")


x0=avisource("Bautizo veronica.avi").assumetff()
y=x0.nnedi(field=3)
x=x0.Yadifmod(mode=1,edeint=y)

s=x.MVSuper()

vf1y=s.MVAnalyse(delta=1,isb=false,truemotion=true)

x.mvcompensate(s,vf1y,thSAD=350)


In planar form don't crashes but image is distorted
Converting clip to YV12 make dissapear le problem.

[Fizick]

AVIL,
what older version (if any) worked fine?

[AVIL]

2.1.1 works fine

[Fizick]

confirmed the bug at scanechanges

[LaTo]

Bug report:
chroma=false in MVSuper produces black output in MVDegrain (with plane=0)...

MVSchroma= #true or false

mvs=MVsuper(last, chroma=MVSchroma)

v1b=MVanalyse(mvs, isb=true, delta=1, chroma=false)
v1f=MVanalyse(mvs, isb=false, delta=1, chroma=false)

MVdegrain1(last, mvs, v1b, v1f, plane=0)
With MVSchroma=true it's okay, but MVSchroma=false it's bugged

[Fizick]

LaTo,
fixed in v2.2.2

Naito,
I am not sure about renaming to MVTools2.dll and coexisting with v1.x mvtools.dll (in plugin folder)
please discuss.

[LaTo]

LaTo,
fixed in v2.2.2
Thanks!