New toy: MVTools version with true motion compensation

[Fizick]

EDITED: Please post here MVTools DEVELOPMENT questions only.
Use other threads for USAGE questions, for example:
http://forum.doom9.org/showthread.php?t=84770
---------------------------------------------------------

I at last build new version of MVTools plugin for local motion estimation and compensation.
It is experimental alpha version. The number is 0.9.10.
Manao says, "Go ahead!".
I am afraid, i go to some side (offside ? :))

News:
Added some true motion (smoothed) estimation options to MVAnalyse
Added function MVFlow for per-pixel motion compensation
Added function MVInter for motion interpolation (very experimental)

More info:

Some new parameters of MVAnalyse are mostly for true motion estimation. Some block may be not so similar to sample blocks, but motion field will be more coherent, instead of some random vectors distribution. It is important for motion interpolation.

lsad: SAD limit for lambda using. Local lambda is reset to 0 for vector predictor with greater values. Default=400 (was introduced and fixed internally since v0.9.7). Larger values (about 1000) are recomended for true motion.

pnew: penalty to SAD cost for new candidate vector. New vector SAD (cost) must be better than predictor on this value to be accepted. Default=0. Values about 100 are recomended for true motion.

plen: penalty factor (similar to lambda) for vector length. to prevent chaotic long vectors. Default=0. Values about 100 are recomended for true motion.

plevel: penalty factors (lambda, plen) level scaling mode. Default=0. Value=0 - no scaling, 1 - linear, 2 - quadratic dependance from hierarchical level size. Note, that vector length is small at lower level.

MVFlow

MVFlow (clip, clip "vectors", float "time", int "mode", int "idx")

Do a motion compensation of the frame not by blocks (like MVCompensation), but by pixels. Motion vector for every pixel is calculated by bilinear interpolation of motion vectors of currect and neibour blocks (according to pixel position). It means that the pixels pointed by the mvs in the reference frame will be moved (flow) along the vectors to reach their places in the current frame. This flow motion compensation does not produce any blocking artifactes, but sometimes can create very strange deformed pictures :). True motion estimation is strongly recomended for this function. Motion compensation may be full or partial (at intermediate time).

time: percent of motion compensation (default=100.0, full compensation), define time moment between reference and current frame.

mode can be either 0 ( default ), or 1.
mode=0 - fetch pixels to every place of destination. It is main producing mode.
mode=1 - shift pixels from every place of source (reference). It is debug (learning) mode with some empty spaces (with null intensity). It may be used for occlusion mask creation.

idx works the same way as idx in MVAnalysis.



MVInter

MVInter (clip, clip "mvbw", clip "mvfw", float "time", int "mode", int "thres", int "idx")

Motion interpolation function. Very experimental (alpha version). It is not the same as MVinterpolate function of older MVTools verion. It uses backward "mvbw" and forward "mvfw" motion vectors to create picture at some intermediate time moment between current and next frame. It uses moved blocks from both frames, some combinations of motion vectors, and masked averaging to prevent various artefactes (blockiness, occlusions). The used occlusion mask is cleaned, expanded and smoothed. True motion estimation is strongly recomended for this function.

time: interpolation time position between frames (in percent, default=50.0, half-way)

mode can be either 0 ( default ), or some number, currently from 1 to 15, they are mostly for learning and experimenting. :).
0 - some main (best) production mode, complex interpolation method;
1, 2 - forward or backward shift ;
3, 4 - occlusion mask of forward or backward shift ;
5, 6 - forward or backward fetch;
7 - MC fetched average;
8 - static median;
9 - dynamic median;
10 - use shifted pixels if not occlusion, otherwise use fetched forward;
11 - fetch forward masked by shift backward;
12 - fetch backward masked by shift forward;
13 - time weigthed combination of 11 and 12;
14 - common occlusion mask;
15 - mode 13 mixed with simple time average by occlusion mask, it is mode=0 currently.

thres: threshold for count of occlusions per block for mask binarization (default = blocksize*blocksize/4)


Download link:
http://www.avisynth.org/fizick/mvtools/

ATTENTION: Experimental version, do not use it for real work!
But try :)

[scharfis_brain]

I'll try it. especially for the Standards conversion stuff :)

I'd like to see a mvtools version that supports the YUY2 colorspace.
May I hope for this, or is it hopeless?

Cause building mocomped deinterlacing with proper chroma handling is impossible with YV12. So the current mvbob() still uses simple motion adaption for the chroma handling.

[Mug Funky]

oooh! must try this at once! thanks for your work :)

i'll edit this post with feedback rather than take up forum real estate...

[edit]

no surprise here, but sharp luma changes tend to throw this off a tad (a hand with a cigarette lighter flashing is what i'm looking at atm). mvflow looks really good though. very promising already.

[edit 2]

scharfi beat me to it, but there's also a rounding error on the luma plane (i ignored the chroma error by just putting "greyscale" after everything).

@ scharfi: are we running the exact same script here? :)

[edit 3]

take this for now:

yv12lut(yexpr="x 1 +",uexpr="x 1 +",vexpr="x 1 +",y=3,u=3,v=3)

[scharfis_brain]

possible bugs found:
- mvinter-ed frames are greenish compared to the non interpolated frames. probably a rounding error.

- no chroma interpolation with mvinter?

[mg262]

Looking very interesting! I already had a script at hand to compare Motion against MVTools, so I plugged this in and played with it. The compensated frame is closer to the reference than Motion, although Motion produces a slightly smoother vector field (both as one might expect). MVTools produces fewer blocks, and with MVFlow I couldn't see any artefacts at all on the short clip I was playing back (I didn't try looking at stills).

I'm looking forward to playing with the (impressively many) interpolation modes. Thank you for the new version, Fizick!

[scharfis_brain]

this source seems to be pain for mvinter() http://tinyurl.com/7kxrb

I prepared it by bobbing an scaling to 704x576 and then applied motion interpolation.

[Fizick]

scharfis_brain,
YUY2 wiil be very useful, when somebody implement it. :)
But there are many parts in code where siple relation /2 for croma width and heigth is assumed :(
I think about intermediate solution: Analyse YV12 clip, get vectors, but compensate YUY2 (or planar YV16).
But thus we can not use half-pel.
By the way, I forgot to say, that half-pel "npel=2" is not implemented for MVFlow and MVInter.
Also I forget to say, that vector component values vx, vy must be not above 127 for MVFlow (I use 1 byte arrays for interpolation)
Rounding error is quite possible. (division to 255 or 256 ?)

And what do you want to say about your 704x576 clip?

- no chroma interpolation with mvinter?
Really? May be I forget to implement (uncomment) it? Must check it, wait.

So, probably i will prepare bugfixed version soon.
(without new features).

Mug Funky,
yes, sharp luma changes is very bad for MVTools.

mg262,
most modes are not disabled specially for you :)


Manao (or somebody else),
I remember you (or somebody else :) )say about interpolation, that all avisynth resizers is not correct for MVTools :)
Not centered?
For MVFlow, I need in interpolation of small array (vx or vy) (one value per block) to full frame.
Currently I use very code of fast SimpleResize avisynth plugin by Tom Barry. How I can correct interpolated results to be consistant with MVTools? Shift it to left and top by half-block?

[Manao]

that all avisynth resizers is not correct for MVTools When I said not correct, it was related to the fact that SAD computation for block matching are made in the interpolated plane only. So, basically, if you use bilinearresize to compute halfpel, and if you search halfpel position, the SAD will be computed between the halfpel plane and the current block ( without considering the 3 other halfpel planes ). So you can use avisynth's resizers ( you just have to ensure that the pel plane is preserved, which can be done ), but you've got afterwards to reorganize the data into planes in order SAD computations to be efficient.

In the MVTools, in hpel, it works like this :X 1 X 1 X 1 X 1 X 1
2 3 2 3 2 3 2 3 2 3
X 1 X 1 X 1 X 1 X 1
2 3 2 3 2 3 2 3 2 31 is interpolated by averaging both its horizontal neighbours, 2 both its vertical neighbours and 3 its 4 four neighbours. The 1 to the right of an X correspond to the vector (0.5,0), and so on. I hope it'll answer your second question.

[Fizick]

New version 0.9.10.1
Fixed bug with chroma and luma small changes in MVInter (rounding error).
Vector interpolation in MVFlow and mask in MVInter are correct now (due to fixing bug in SimpleResize).

http://www.avisynth.org/fizick/mvtools/

ToDO: pel=2 in MVFlow ?

[Fizick]

I prepared occlusion mask function, but probably the best its place is MVMask.
So, i want replace boolean "showsad" parameter to integer "mode"
and robably will change SAD normalization factor and gamma.
By the way, MVMask has some bug in top of picture,
so i will change its interpolation code to modified SimpleResize (bilinear too).

[Mug Funky]

about SAD and mvmask:

with true motion, SAD can be very high even if the motion is perfectly predicted (luma change on an object for example). is there a good (fast) metric that can tell you "motion accuracy" or "motion confidence" so we can use that for a mask? this would make interpolation much safer as we'd have a good way to tell if there's likely to be artefacts and use weighted blending in those cases.

btw, i've been using mvinter to get the opposite of "film look"... it's amazing how well it works even at this early stage.

[edit]

also, would motion-searching an edge-mask rather than the actual clip make it more immune to luma changes? or would that just mung up other things?

[edit 2]


oh, btw, last night when i was doubling the framerate of some film and re-interlacing, i noticed memory usage became quite excessive after about 10000 frames worth - like 1.2 gigs of system RAM and 1.4 gigs of virtual memory while encoding with QuEnc. i can post my script, but i should "minimise" it first to eliminate unnecessary stuff.

[Fizick]

Mug Funky,
Suggested occlusion measure is a good (fast) metric that can tell you "motion accuracy" or "motion confidence" so we can use that for a mask.
I detect bad blocks (occlusion) due to rupture, tensile. If left neibour has vector x coordinate lesser than current block, then we have some tension, gap here (potentially empty space which will be filled by some strange pixels).
I count sum of absolute gaps values for 4 neibours.
After normalization and resizing we have occusion mask.

New kind parameter defines kind of mask in MVMask function.
Mode kind=0 creates motion mask from the motion vectors' length.
kind=1 allows to build a mask of the SAD values instead of the vectors' length (like old showsad).
kind=2 allows to build a occlusion mask (bad blocks due to rupture, tensile).

Scpipt to blur problem (blocky) areas of compensated frame with occlusion mask:

vectors = source.MVAnalyse(isb = false, lambda = 1000)
compensation = source.MVCompensate(vectors) # or use MVFlow function here
# prepare blured frame with some strong blur or deblock function (we use resiser for blur for example):
blured = compensation.BilinearResize(width/4, height/4).BilinearResize(width,height)
badmask = source.MVMask(vectors, ml=100, kind = 3)
overlay(compensation,blured,mask=badmask) # or use more fast MaskedMerge function of MaskTools plugin

Download:
http://www.avisynth.org/fizick/mvtools/

2. using edge mask was discussed previously (by Manao in MVTools thread). We lost too many info for algorithm used (SAD comparing). But we can try to use external image intensity stabilizer, such as my DeFlicker (global only). May be some internal correction can be implemented later (for example by using additional cycle with some block intensity variation). But it may result in some errors. I do not know now.
Threre are no ideal method, and never will be.

try get clear memory leakage condition, and i (and manao ?) will try cure it.

[Mug Funky]

cool, thanks. i'm just playing with it now.

would it be possible to allow "time" to have negative values? or would that be stupid?

[Fizick]

What is the most strong deblocking filter? I want to use it with mask with strong settengs, but internal deblock is too weak :)

[Manao]

What ? Too weak ? You're meaning Deblock(q=51) is too weak ? Somehow, I don't wanna know what you want to deblock :p

[Didée]

What is the most strong deblocking filter? I want to use it with mask with strong settengs, but internal deblock is too weak :)
With time, I've come to the conclusion that deblocking filters are not too well suited to repair artefacts from erroneous compensation. Simple as that.

In case your goal is to do something like


http://img430.imageshack.us/img430/6901/mcreference7gz.th.jpg (http://img430.imageshack.us/my.php?image=mcreference7gz.jpg) --> http://img430.imageshack.us/img430/6082/mccompensation0aj.th.jpg (http://img430.imageshack.us/my.php?image=mccompensation0aj.jpg) --> http://img430.imageshack.us/img430/1171/mccompensationpp7ex.th.jpg (http://img430.imageshack.us/my.php?image=mccompensationpp7ex.jpg)


then I already gave a suggestion (http://forum.doom9.org/showthread.php?p=732664#post732664). :)

[Fizick]

I am not afraid to kill details in good regions, since i will use occlusion mask for it.

[Fizick]

Didée,
Thank for suggestion, but it is not real solution:
when we make compensation (forward) from previous to current frame for denoising, we can not use current frame as reference for repair :).
But it may be used when we make time interplolation, however it will not so good as in your example due to time (and spatial) shift.

[Didée]

Didée,
Thank for suggestion, but it is not real solution:
when we make compensation (forward) from previous to current frame for denoising, we can not use current frame as reference for repair :).
Oh, we can not? Pity ... but then, what's your explanation for my example?

It's not fully clear to me at all times, if (or when) you are speaking about direct compensation (compensate neighbor frame to match the current [reference] frame), or about interpolation (create a new [artificial] intermediate frame between neighbor frame and current frame.)

For the case of direct compensation, I'm pretty sure the method can be used ... because I've it actually working in a denoiser framework that's drawing a long nose to most others ;) (and that also delivered above example).

As opposed to the case of interpolation ...
But it may be used when we make time interplolation, however it will not so good as in your example due to time (and spatial) shift. ... where I can't see how that method should work at all.
For the case of compensation, it does work because we're using 100% of a vector's length, and at *that* position we *do have* a reference that can be used for repairing: just the current frame. However for interpolation, at the position of, say, 50% of a vector's length, we're in free air ... *there*, there is nothing that could be used for repairing.

[Fizick]

For the case of direct compensation, I'm pretty sure the method can be used ... because I've it actually working in a denoiser framework that's drawing a long nose to most others ;) (and that also delivered above example).
[quote]
You MAY use any method :)
But i think, we must use information from one frame only when direct full compensation.
What you made it is post-processing.
But if we will use this "cured" compensated frame for noise reduction, it will have exactly same pixels values in this cured regions as current frame. Strange denoising.

But we can use post-processing with repair.

I think, that we firstly need in best possible true compensation.


[QUOTE=Didée]
As opposed to the case of interpolation ...
... where I can't see how that method should work at all.
For the case of compensation, it does work because we're using 100% of a vector's length, and at *that* position we *do have* a reference that can be used for repairing: just the current frame. However for interpolation, at the position of, say, 50% of a vector's length, we're in free air ... *there*, there is nothing that could be used for repairing.
Yes, but sometimes (in some regions) we do not have any good information, so even not-compensated frame blending (locally only, with smooth occlusion mask) is good (best of availiable). It is not simple problem.
We must think and try.

[Fizick]

By the way, when i try to increase speed of MVTools, i found that "searchparam" of MVAnalyse is really =2 by default. The documentation says, that it is =1.

[Didée]

Hah, interesting finding about searchparam's default! :)

What you made it is post-processing. Yes. As is deblocking.


But if we will use this "cured" compensated frame for noise reduction, it will have exactly same pixels values in this cured regions as current frame. Strange denoising.
Fizick, did you actually *look* at my sample? Ideally with switching forth-back between "source" and "compensated(PP)", at some 200% or 400% zoom?

[Fizick]

I understand, that is is not full pixels equivalence, but we must not use it anyway :)

[Didée]

"We must not" ?? Which god has decided so?

If you think the result will be better with using some UltraSmearyMegaBlurryDeblocking for that purpose, well, I won't hold you back from doing so :)


But I'll tell you the findings I've come to so far, in respect to denoising:

When using a broad repair for badly compensated blocks, then at best you'll only be able to flatten down the block's content ... together with the detail that might have been in before. But things might even get worse, since the content of the "bad" block might happen to be completely unrelated, in which case deblocking will not help, but create a smeary mess.

However when repairing with Repair(reference,4) plus alittle additional sharpening, you effectively get the content of the original block, BUT with a sort of "noise-of-its-own". That's because the bad block's pixels might be brighter or darker than those of the original block, which is a random relation. Then, sharpening the rather flat result of Repair(4) thereof will recreate a reasonable representation of the original block from the compensated-and-repaired one, but with "another kind" of noise. And this is perfectly suited for denoising.

But let's stop the arguing, do whatever you consider to be the best. I've dropped my point (to not get accused of "hiding the miracles" somewhen later), and - penultimate argument - it is already working on my side, rather nicely.

[Fizick]

let's stop.

[Fizick]

v.0.9.11.1 (Released 06.11.2005)
Added half-pel support to MVFlow.
Increased quant limit to 60 in DeBlock for very strong deblocking.
Corrected documentation.

http://www.avisynth.org/fizick/mvtools/

[scharfis_brain]

is it possible for you to add a motion blurrer based on mvFlow() ?
possible parameters like
blurlength: 0 - no blur ; 0.5 blur for the half the duration of a frame; 1 - blur for the duration of one frame ; 2 - blur over the duration of 2 frames
precision: 1 - do nothing; 2 - two pixels; 10 - pixels etc...

maybe you could leave out the precision parameter, if you are drawing lines of 'blurlength' (vectorlength*blurlength) instead of pixels, so there would never occur any ghosting.

[Fizick]

scharfis_brain,
I will think about blur.
Now MVFlow is used mstly for compensation.
I have a plan to add motion interpolation (bi-directional and masked), probably MVFlowInter function.

About your request about YUY2. You do not get me answer, do you need in YUY2 motion estimation or in YUY2 compensation only?

[scharfis_brain]

I'd be glad, if you could implement the YUY2 space:)

Estimation can be done in YV12 space. (of course, YUY2 would be a nice-to-have, too :) )
But for compensation YUY2 is a must, when dealing with field-stuff.

[sh0dan]

Really great to see the features I miss in this great tool. I do however get deallocation crashes using this script:

highquality=true
source=last
vectors_b = source.MVAnalyse(isb = false, lambda = 1000, pel = (highquality) ? 2: 1)
vectors_f = source.MVAnalyse(isb = true, lambda = 1000, pel = (highquality) ? 2: 1)
inter12=mvinter(source, vectors_f, vectors_b, time=12.0, thSCD2=70, thSCD1=100)
inter25=mvinter(source, vectors_f, vectors_b, time=25.0, thSCD2=70, thSCD1=100)
inter75=mvinter(source, vectors_f, vectors_b, time=75.0, thSCD2=70, thSCD1=100)
inter88=mvinter(source, vectors_f, vectors_b, time=88.0, thSCD2=70, thSCD1=100)
interleave(source,inter12,inter25,inter75,inter88)
temporalsoften(2,255,255,5,2)
selectevery(5)

Source is 624x352. (This is btw a very good motion blur)

Regarding YUY2, using YV16 in 2.6 will probably be easier since it's planar. There are however a lot of "width / 2" and "height / 2", instead of the PVideoFrame->GetRowSize(PLANAR_U) & PVideoFrame->GetHeight(PLANAR_U), which will make adding new colorspaces harder.

[Manao]

YUY2 or YV16 will be the same, since internal data will need to be planar anyway ( nobody in their right mind would work on interleave data for ME / interpolation / compensation ).

I can do the YUY2 adaptation. Not quite yet ( I'll be rather busy till sunday ), but after that, I'll have some free time. It's "almost" "just a matter" of changing "nHeight / 2" by "nHeightUV" ( I won't use the PvideoFrame->*, because width & height are needed at initialization time anyway, and because the core is made as much as possible to be independant from avs 2.5 ).

[mg262]

FWIW, kassandro wrote some Planar2Interleaved and Interleaved2Planar functions that might save you a little time here. I think they're part of RemoveGrain.

[Fizick]

Manao,
We must use not-squared blocks for YUY2 (YV16) chroma (4x8 ?)

sh0dan,
I will try to find a bug.
But I reaaly want to remove MVInter and replace it by MVFlowInter tomorrow. :)

[Fizick]

v0.9.12
Added MVFlowInter function. MVInter function will be removed in next release (it is worse).
Changed scale of ml parameter for kind=2 of MVMask to more optimal default.
Fixed small bug in Bilinear.asm (strange pixels near right border for pel=2).

[Mug Funky]

mvflowinter is looking good! just upconverting something to 100fps to check it out.

it'd be cool to have an mvfps style function though - trying to calculate appropriate time values for turning 60/1.001 fps to 50 fps is doing my head in. i was thinking about doing it with a scriptclip, but i'm sure disaster lies in that direction.

[scharfis_brain]

59.94 <-> 50 conversions can be made easily by calculating approx 300 fps (59.94*5) or exactly 300 fps (50*6) and then do changefps afterwards.
the remaining stutter of the 1000/1001 thing can be neglected, cause it will only be a 'stutter' of 1/300 sec.

[scharfis_brain]

I am running in big trouble with mvflowinter()

loadplugin("d:\x\mvtools0912.dll")
loadplugin("d:\x\tdeint.dll")
loadplugin("d:\x\DGDecode.dll")

#load interlaced video
mpeg2source("D:\FORUM\castellandw\PALMPEG2Clip.d2v",cpu=4)

i=tdeint(mode=1,type=3,link=0,mthreshl=7,ap=25)

vf=mvanalyse(i,isb=false,blksize=4,lambda=1000,lsad=1000,pnew=100,plen=0,pel=2)
vb=mvanalyse(i,isb=true ,blksize=4,lambda=1000,lsad=1000,pnew=100,plen=0,pel=2)

a17=mvflowinter(i,vb,vf,time=16.7,ml=100)
a20=mvflowinter(i,vb,vf,time=20.0,ml=100)
a33=mvflowinter(i,vb,vf,time=33.3,ml=100)
a40=mvflowinter(i,vb,vf,time=40.0,ml=100)
a50=mvflowinter(i,vb,vf,time=50.0,ml=100)
a60=mvflowinter(i,vb,vf,time=60.0,ml=100)
a67=mvflowinter(i,vb,vf,time=66.7,ml=100)
a80=mvflowinter(i,vb,vf,time=80.0,ml=100)
a83=mvflowinter(i,vb,vf,time=83.3,ml=100)

#interleave(i,a20,a40,a60,a80).changefps(50) # NTSC2PAL
interleave(i,a17,a33,a50,a67,a83).changefps(59.94,linear=false) #PAL2NTSC

It immediately closed VDub on open without any error message.

when I commented out the lines a20, a40, a60, and a80 it ran for a while but closed VDub after approx 50 frames linear acces after jumping to a random time in the video file.

but nontheless, the interpolation results are pretty good. A little bit lesser wobbling on occlusions and it is read for usage in an standards conversion script.

btw.: can you code in an error protection for appearing and vanishing logos and subtitles? Cause mvflowinter makes a funny kind of interpolation out of it ;)

[Fizick]

scharfis_brain,
what is your system config?

Some words about 1.001:
Internally i use time not as float but as byte integer, so gradations are from 0 to 256.

[scharfis_brain]

My system configuration:
AthlonXP 1600+ with 768MB RAM
running WindowsXP SP2
and currently AVS 2005-May-05 without plugin-autoloading

[Fizick]

Firstly try remove unused a20, a40, a80 lines.
At construction stage MVFlowinter creates huge arrays.
MVTools eat many memory generally.
Also try latest more stable AViSynth.

I must ask Manao, why 10 frames per mvclip is created.
And why MVtools strore compensated frames (large!) in vector clips. In my opinion, we must compensate in various Compensation functions. For example in MVDlow I do not use pre-compensation info. Also often it is better to estimate pre-filtered clip, but compensate original source. So, probably mode=0 in MVompensate is almost unusable. What anybody think about it?

[AVIL]

Hi all,

From Fizick's previous post:

Also often it is better to estimate pre-filtered clip, but compensate original source. So, probably mode=0 in MVompensate is almost unusable.

I agree completely with that. Pre-filtering clip to MVanalyse i.e. with convolution3D gives more accurate orginal compensated frames .

[Manao]

The reason for the 10 frames was for buffering purposes. I wanted to avoid recomputations at all cost, and I didn't trust avisynth's cache at that time.

The frames are kept interpolated because, since I made the interpolation during the analysis, I can reuse it during the processing.

Finally the compensation occurs in the analysis because it's there that it is the most efficient from a cpu cache point of view. Just after the ME, the block that will be used as compensation is in the cache. No need to recompute it, you just have to fetch it.

[mg262]

Manao,

I thought about this one. How about:

-- analyse giving only motion vectors
-- compensate using motion vectors
-- joint analyse/compensate function for efficiency... outputs compensated picture only

It doesn't involve significant code duplication (even with multiple compensation methods), because we have templates available.

[Manao]

But compensation is computed only if downstream filters use it. And processing filters might need as well the MVs ( and they don't cost a lot to be written anyway ).

At the moment, downstream filters say what are their need :
* compensation Y, U, V
* block variance
* block average luma
* reference block average luma

And the analysis filter computes the values needed by all the downstream filters that'll use its output. That way, values get computed only once, and where they are the most effective : in the analysis part, when everything is already in the cpu cache.

[mg262]

Ah -- clever! I didn't realise the output was adaptive in that way. How do the downstream filters communicate with the analyse filter?

[Manao]

There's an object linked to the analysis filter that is written in the videoinfo.nchannels. It allows to send the analysis filter some information.

Ugly, hackish, yet, since I'm using a RGB colorspace to write mv / picture data, I figured that overriding the number of audio channels was no big deal.

[Fizick]

Manao, mg262,
In my opinion, you (we) must create some common (general) format of vector clip for MVTool.dll and Motion.dll. (some version specific parameters may be too, of course).
It will be useful some SuperAnalyze in MVTolls and SmartCompensate in Motion and vice versa!
So we will must not duplicate every compensation-interpolation routine.
That is why I ask for simplification of vector clip format in MVtools.

[mg262]

It seems easiest to write two conversion functions. I would not want to lose the flexibility to change format, and I imagine Manao would not want to lose efficiency. The current Motion format is certainly going to change (hence having both MotionVector and CompressedMotionVector in the code I sent you, so the change can be applied transparently). But it is temporarily as follows:

Motion vectors are stored in the luma of a YV12 VideoFrame, width equal to the original frame, 1/8 the height (rounded up to be even). Each 8x8 block has a 8 byte motion vector, x and y as 16:16 fixed point integers.

I tested 4 byte motion vectors (2x 14:2), but the speed up due to cache effects was slightly smaller than the slowdown due to unpacking. I may use this anyway to save memory. I will certainly switch away from YV12, probably to Y8.

[Fizick]

mg262,
why you do not want make me happy :(
Please, consider to make new vector format more compatible with basic part of format of MVTools. For example: vector component vx, vy and SAD (as in MVTools).
Some standart part of format can be fixed, and more complex and specific parts can placed to some reserved placed or behind them.

In future i will prefer create my own plugin, used motion vectors (basic part of them)from both your plugins.

New version 0.9.12.1 (Released 12.11.2005)
Added experimental MVFlowFps function.
Disabled MVInter function.
Temporary changed size of internal frames buffer from 10 to 3 for memory usage decreasing. Speed must be tested for complex scripts.

[Didée]

Quick & ugly test, by just replacing MVT-0.9.11 with MVT-0.9.12.1. Script uses analysation of -4 ... +4 frames, and does 2 times compensation (1x preprocessed input, 1x original input). "idx" & Co. are optimized to not do more than what's needed (hopefully).

memory usage: drop by 15 MB (270 MB vs. 285 MB, Vdub as a whole, Windoze task manager)

effective speed: drop by ~7% (130 frames/min vs. 140 frames/min in Vdub preview).

[mg262]

Fizick,

There are many reasons; this is the quickest to explain: I need a very compact format (e.g. to allow cacheing of many motion vectors) so I am thinking of four bytes per vector; what you suggest seems like twelve bytes per vector. 3x overhead...

[Manao]

We could deinterleave sad from mvs in the MVTools. Furthermore, having a header saying how the content is organized would help. But I don't see the point in caching many motion vectors. That won't speed up a filter as soon as it needs to do some processing.

In the header, we could have the following data :
* colorspace
* width of the analysed clip
* height of the analysed clip
* block width
* block height
* mv precision
* direction of the analysis ( forward / backward )
* number of frames between the analysed frame and the reference
* payload id
* payload size
* padding to align to 16

Then we would have the motion vectors ( each coordinate on a 16 bits signed integer ), and the payload ( which could contain all the data needed by MVTools but not by Motion )

[mg262]

But I don't see the point in caching many motion vectors. That won't speed up a filter as soon as it needs to do some processing.The method I am using in Motion is recursive; computing the motion vectors for frame 50 requires the motion vectors for frame 49, which requires the motion vectors for frame 48, which... motion vectors for frame 1, which requires the motion vectors for frame 0. Some methods of dealing with issues raised by this require caching many motion vectors.

In order to use the motion vectors in MVTools, you need to compute whatever additional information is requested by filters; so you need to run them through a conversion filter to generate this. What is the difficulty with having that filter read motion vectors in the Motion format and write them in the MVTools format?

[Fizick]

Didée,
Thanks for test. It was pel=1 or pel=2?


mg262,
but you do not write any header info. and do not output the SAD.
O.K. Forget about it now. May be, when you impement more functions, you will need in more complex format. we will return to this topic.

[Didée]

Ah, I tend to forget that pel=1 does exist ;) Tests were with pel=2, blksize=16, searchparam=3.

Strangely, decreasing number of compensated frames to -3 ... +3, speed seemed to drop a little more, to about ~90% of MVT 0.9.11 (142 frames/min vs. 160 frames/min). However the script *is* complex, so the exact reasons might be in the darks. But atleast it seems the changes didn't make things faster.

***

Another thought:
Could sort of mimicking the "inter4v" mode of mpeg-4 codecs make sense? Because, while small blocksizes (8 or even 4) sometimes deal better with moving edges, and mostly better with occlusion areas, the large blocksize 16 seems much more reliable when large, uniform areas are moving. The wish to get the best of them both sometimes is coming up ...
Or is this, in some way, already lying inbetween the new parameters you've added to mvanalyze? I'm not fully clear about these, and it's hard to see & understand what's happening _during_ the process of motion search, when you're looking "from outside" and only see the end result.

[Fizick]

is it possible for you to add a motion blurrer based on mvFlow() ?
possible parameters like
blurlength: 0 - no blur ; 0.5 blur for the half the duration of a frame; 1 - blur for the duration of one frame ; 2 - blur over the duration of 2 frames
precision: 1 - do nothing; 2 - two pixels; 10 - pixels etc...

maybe you could leave out the precision parameter, if you are drawing lines of 'blurlength' (vectorlength*blurlength) instead of pixels, so there would never occur any ghosting.

v0.9.12.2 (Released 13.11.2005)
Added experimental precise but slow MVFlowBlur function as scharfis_brain asked.
Temporary changed size of internal frames buffer to 5.

Parametersof MVFlowBlur are almost as you asked:

blur: blur time interval between frames (in percent, default=25.0)
prec: blur precision in pixel units. Maximal step between compensated blured pixels. Default =1 (most precise).

But it is simple (without occlusion mask yet) and slow.

[Fizick]

Didée,
you say about variable block size at motion estimation stage?
it is hardly.

[Fizick]

v0.9.12.3 (Released 14.11.2005)
Fixed bug for croma for width not divisible by 16 in MVMask (introduced in v0.9.11).
Some speed optimizing of MVFlowFps.
Reset size of internal frames buffer to original value 10. Try various versions.

[sh0dan]

Fizick, your work is such a big improvement over the earlier versions! It's still quite buggy, but it shows so much potential!

Bugs observed in new functions:

MvFlowFPS ml = 0 -> division by zero.
MvFlowBlur blur > 100 -> occational access violation.

The docs are very hard to read. I call out to everyone who understand them, and have the time, to help out in creating good tutorials and docs.

[Fizick]

sh0dan,
I will add parameters bound checking.

About docs. It is more hard item. Soon I will create Russian doc. May be it will be more readeable (for those who understand Russian) :)

Or you say about Manao's part of doc too?

[sh0dan]

@Fizick: The doc section wasn't as much aimed at you, as it was to some helpful soul wishing to help out. This is a great package, but it still requires solid code and very good documentation. I'm sure you can help with the solid code, as you've already turned Manaos basecode into something very useful!

I think the concepts and parameters are difficult to understand, and even harder to control. This is not a design problem as such, but it requires a lot more documentation to be easy to use. Compare it to Telecide. A "simple" function, but it still it requires massive documentation to ensure that it's useable. MvTools are rather fast becoming just as useful.

Maybe it would be a good idea to open a section on avisynth.org?

[Fizick]

May be some parameters can be renamed or rescaled, but I do not want to do it (and do not want ask Manao to do it) without really big needs (as I do for "showsad"), to not broke existing scripts.

[Fizick]

v0.9.12.4 (Released 15.11.2005)
Changed type of ml parameter in MVMask, MVFlowInter, MVFlowFps from int to float.
Added bound check of ml, time, blur parameters.
Small possible bug fixed (emms).
Partially updated documentation. But I am not sure that sh0dan requested exactly such updating :). It is still not user guide but functions reference.

[videoFred]

Hello Fizick,

MVFlowFps works very very fine :)
I did some first tests on this slow (600mgz) machine.

No blocks anymore!
But sometimes 'rubber' artifacts like with Motion Perfect.

I used this script:

Loadplugin("MVTools.dll")
Loadplugin("Depan.dll")
Loadplugin("fft3dfilter.dll")
Loadplugin("degrainmedian.dll")


source=avisource(film).assumefps(16).converttoYV12()
clipC=DeGrainMedian(source,limitY=5,limitUV=10,mode=2)
clipD=FFT3DFilter(clipC,sigma=2,sharpen=1.0)

backward_vectors = clipD.MVAnalyse(isb = true, lambda = 1000, lsad=1000, pnew=50, pel=2)
forward_vectors = clipD.MVAnalyse(isb = false, lambda = 1000, lsad=1000, pnew=50, pel=2)
frameclip=MVFlowFps(clipD,backward_vectors, forward_vectors, num=25, den=1, ml=100)

mdata=DePanEstimate(frameclip,trust=0)
stab=DePanStabilize(frameclip,data=mdata,cutoff=1.0)

stab

Now I must test it at home on my fast (3Ghz) machine.
I think it's gonna run faster than the original MVTools :cool:

And I'm gonna compare MVConvertFps with MVFlowFps.

But I do not understand the use of the 'den' parameter??? :eek:
I mean, 'num=50, den=2' is the same as: 'num=25, den=1'
Both are giving me a result file with 25fps.
What's the difference?

I have another question, too:
Dynapels Videoscope tells me ALL the frames are originals!
This means MVFlowFps and MVConvertFps creates complete new frames, right?




Fred.

[foxyshadis]

There is no difference, FpS always = num/den. For PAL it's not so important, but with NTSC it has to be num=30000, den=1001 because both are integer values. (Any other franctional fps the same.)

[Fizick]

videoFred,
thanks!
I am very interested in old 8mm film conversions too.

1)If you want, some frames will be old, when you set fps relation to some simple relation.
For example, you can change source fps from 16 to 16.66666 (=50/3) so way:
AssumeFps(50,3)

2) Yes, MotionPerfect probably uses similar algo.

MVFlowFps is experinental. DePan gives more stable result.

As a workaround, we can try use block overlap.
Try this my function:



loadplugin("blockoverlap.dll")
loadplugin("mvtools.dll")

function OverlapFps(clip source, int "num", int "den", int "ml", int "blksize", float "kernel", int "lambda", bool "chroma", int "pel", int "thSCD1", int

"lsad",int "pnew")
{
# Overlapped block motion fps conversion by shifted clips processing and windowed blending
# Fizick, 2005
# Uses MVTools v0.9.12.4 plugin by Manao & Fizick
# Uses BlockOverlap v0.2 plugin by Fizick
# source clip must have YV12 format,
# all other parameters are optional
# new fps = num/den
num=default(num,25) # numerator
den=default(den,1) # denominator
ml=default(ml,100) # mask scale
blksize=default(blksize,8)
kernel=default(kernel,0.5)
lambda=default(lambda,2000) # vector smooth
chroma=default(chroma,true) # use chroma
pel=default(pel,2) # pixel precision
thSCD1=default(thSCD1,300) # scenechange threshold
lsad=default(lsad,2000) # lambda SAD limit
pnew=default(pnew,50) # penalty new
add = (blksize>=8) ? blksize : 8
vecF = source.MVAnalyse(blksize=blksize, isb = false, lambda = lambda, chroma=chroma, pel=pel, lsad=lsad, pnew=pnew,idx=101)
vecB = source.MVAnalyse(blksize=blksize, isb = true, lambda = lambda, chroma=chroma, pel=pel, lsad=lsad, pnew=pnew,idx=101)
comp = source.mvflowfps(mvbw=vecB, mvfw=vecF, num=num, den=den, ml=ml, thscd1 = thscd1, idx=1)
shifted = source.addborders(blksize/2,blksize/2,add-blksize/2,add-blksize/2) # diagonal shift by half of block
vecFshifted = shifted.MVAnalyse(blksize=blksize, isb = false, lambda = lambda, chroma=chroma, pel=pel, lsad=lsad, pnew=pnew,idx=102)
vecBshifted = shifted.MVAnalyse(blksize=blksize, isb = true, lambda = lambda, chroma=chroma, pel=pel, lsad=lsad, pnew=pnew,idx=102)
compshifted = shifted.mvflowfps(mvbw=vecBshifted, mvfw=vecFshifted, num=num, den=den, ml=ml, thscd1 = thscd1, idx=102)
compshiftedback = compshifted.crop(blksize/2,blksize/2,blksize/2-add,blksize/2-add) # remove shifting borders
ov = BlockOverlap(comp,compshiftedback,xblksize=blksize, yblksize=blksize, kernel=kernel)
return ov
}

source=avisource("film.avi")
source.overlapFps(num=50, den=1)



It is not perfect too.
May be i will try to average not pixels, but its vectors in next MVTools versions.

P.S. Please, do not ask mg262, "did he ever try blockoverlap?" :)

[videoFred]

videoFred,
thanks!
I am very interested in old 8mm film conversions too.

Me too... I do nothing else...
I do not even have a digital video cam, except my filmtransfer camera :)


For example, you can change source fps from 16 to 16.66666 (=50/3) so way:

Yes, I understand... 18,75 must be possible, too.

I'm gonna try blockoverlap, too.
No, I'm not gonna ask mg262 :scared:

But Depan after MVFlowFps works realy great!
Have you tried this? It's almost perfect!
I use the stand alone Depan for this..
Maybe it could be even faster with MVDepan?

I also noticed FFT denoising before MVFlowFps is not good.
Then MVFlowFps gives duplicate frames, why?

Soon I'm gonna post some MVFlowFps example clips on my website.

Fred.

[Fizick]

videoFred,
If MVtools duplicates frames, threafore it detect a scenechange. Try to increase thSCD1 parameter to about 500.

[videoFred]

Fizick,

Thank you, I try this, too.

First tests on my HP pavillion (3ghz):
Original files progressive 1024x768 Hyffyuv.
script: Resizing-frame rate conversion-denoising-stabilising-cropping.

Script speed with old MVTools MVconvertFps: 1-2fps
Script speed with your MVFlowFps: 2-3fps :cool:

At play speeds from 15-16-18fps, converted to 25fps, almost no visible artefacts while playing on most files. Very smooth zooming and panning and general motion.

With some files even extreme slow motion is possible (1fps!!)
So Alpha version is already very useful for me. :)

Fred.

[Fizick]

v.9.13 (Released 20.11.2005 )
Added truemotion preset to MVAnalyse.
Added experimental MVFlowFps2.
Change interpolated vector rounding method in all MVFLow... functions.
Edited documentation a little.

Probably i can put it to Avisynth usage MVtools topic now.
http://forum.doom9.org/showthread.php?t=84770
Al least i take a some its develipment pause in any case.

[johnmeyer]

Unable to get 9.13 to run. I get the following error:

AVISynth open failure:
Evaluate: System exception - Access violation

The line on which this is reported is the line with MVFlowfps.

Here's the script:

loadplugin("c:\Program Files\AviSynth 2.5\plugins\kerneldeint140.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools.dll")

AVISource("J:\Senior Video Tribute (do not erase)\Video\Video Highlights (JHM)\Baseball\Baseball-0013 - 000.avi")

assumebff()
changespeed(4, 1)

function changespeed(clip a, float factor, int th)
{

ord = getparity(a) ? 1 : 0
f=a.kerneldeint(order=ord, sharp=false, twoway=false, threshold=th)
e=a.separatefields.trim(1,0).weave.kerneldeint(order=1-ord, sharp=false, twoway=false, threshold=th)
g=interleave(f,e).assumeframebased
h=converttoyv12(g)


vec_back = h.MVAnalyse(isb = true, lambda = 1000, lsad=1000, pnew=50, pel=2)
vec_forw = h.MVAnalyse(isb = false, lambda = 1000, lsad=1000, pnew=50, pel=2)
MVFlowFps(vec_back, vec_forw, num=30, den=1, ml=100, idx=1)
converttoyuy2()
assumefps(30,true)
separatefields()
(ord==0) ? selectevery(4,0,3) : selectevery(4,1,2)
weave()
}

[videoFred]

You forgat your source clip:
It must be: h.MVFlowFPS(etc...)
or: MVFlowFPS(h, etc...)

Fred.

[Didée]

Not really related, but still:

Instead of that "interleave-two-times-kerneldeint"-thingy, why not simply use LeakKernelBob() instead? Less script code, faster operation, same result ...

[Fizick]

johnmeyer,
I hope your problem now solved (thanks videoFred).

To all:
This thread is for programming questions only now.

For MVTools usage please post to other thread:
http://forum.doom9.org/showthread.php?t=84770

[johnmeyer]

u forgat your source clip
-----------------
johnmeyer,
I hope your problem now solved (thanks videoFred).
-----------------------

Thanks videoFred. I was so excited, I started working on this as soon as I read about the new version -- way past my bedtime.

Yes, it works fine now.

[Neil Lee]

Below is the example in MVTOOL1.0 Documentation:

======================================
To denoise with pel = 2, efficiently :

backward_vec2 = source.MVAnalyse(isb = true, lambda = 1000, delta = 2, pel = 2, idx = 1)
backward_vec1 = source.MVAnalyse(isb = true, lambda = 1000, delta = 1, pel = 2, idx = 1)
forward_vec1 = source.MVAnalyse(isb = false, lambda = 1000, delta = 1, pel = 2, idx = 1)
forward_vec2 = source.MVAnalyse(isb = false, lambda = 1000, delta = 2, pel = 2, idx = 1)
return source.MVDenoise(backward_vec2,backward_vec1,forward_vec1,forward_vec2,tht=10,thSAD=300)
===========================================


I was thinking instead of using (delta>1), why not just
add motion vectors between adjacent frames?
(Don't know how MVanalyse work internally, maybe this is it?)

Say I want MotionVector(Frame1,Frame4), I would rather
have a function to ADD motion vectors of adjacent frames.

MV14 = MV12 + MV23 + MV34

This way you won't ignore additional info you can get in Frame2,Frame3

Let's say you have a fast moving object, It's hard to find any
matching patterns between Frame1 and Frame4, it's out of search range.
But you'll have a better chance to find it in adjacent frames,
and then you just add them up ..)

Don't know if there's any precision issue for adding Motion Vectors,
How about use it as a secondary method for finding unmatched blocks?

.

[Fizick]

Neil Lee,
Thanks for interesting question.
Generally, there are many known ways to do motion estimation and compensation in special literature.
I am not Manao, who implemented it so way. But IMHO, current way:
1. Easy internally to implement.
2. Do not accumulate estimation error (mismatching). Not motion vector precision, but similarity (correspondense) of matched blocks by intensity (SAD).
3. Quite good vector MV13 can be found if some occlusion in frame 2 may prevent matching motion MV12 and MV23.

But I see advantage of your suggestion: It can results in more fast motion estimation when you use both delta=1 and delta>1 in complex scrips.
(we will estimate only delta=1 and have all deltas from it).

[Manao]

Don't be afraid of high motion. The motion estimation is done first on subsampled pictures, where even high motion in easy to catch.

Anyway, you can already try your idea if you want, with mvcompensate(mode=1) : mvs1 = source.mvanalyse()
mvs2 = source.mvanalyse(delta=2)
comp1 = source.mvcompensate(mvs1)
comp2 = comp1.mvcompensate(mvs1, mode = 1)
comp3 = source.mvcompensate(mvs2)
return interleave(source, comp1, comp2, comp3)

[Isochroma]

Thanks for all the work on your motion compensated denoiser! It performs very well indeed...

I am wondering about an inconsistency in the syntax of your mvdenoise example...

backward_vectors2 = source.MVAnalyse(isb = true, lambda = 1000, delta = 2)
backward_vectors1 = source.MVAnalyse(isb = true, lambda = 1000, delta = 1)
forward_vectors1 = source.MVAnalyse(isb = false, lambda = 1000, delta = 1)
forward_vectors2 = source.MVAnalyse(isb = false, lambda = 1000, delta = 2)
return source.MVDenoise(backward_vectors1, backward_vectors1, forward_vectors1, forward_vectors2, tht = 10, sadt = 300)

how are the parameters of mvdenoise arranged? backward_vectors1 is duplicated, while backward_vectors2 is not used? Your documentation does not provide enough syntax information for me to determine whether your example contains a mistake.

I'm interested in using the >2 frame denoise feature introduced in 0.9.9.1, but because I can't figure out the syntax, how would I write the script?

Also, clarification on the nature of the parameters, ie. clip, clip mvs [,...] ... is clip the current frame, and clip mvs a comma-delimited sequence of motion-vector variable names? Does their order matter?

Finally, the sadt argument causes an error stating that the function does not support it. I have installed the 0.9.9.1 version and am using the documentation from that version as written... any ideas?

Thanks!

[Mug Funky]

the docs are out of date for that one...

btw, i think the backward vectors 1 being used twice looks like a typo to me.

[Fizick]

Isochroma,
this thread is about new MVTools versions AFTER 0.9.9.1.
All these typos are corrected in v1.0.
Please, be not so lazy to read the thread first.

[Neil Lee]

True Motion too Agressive?

Hi Fizick/Manao,

It seems that TrueMotion is sensitive to noises a bit too much,
I have some videos with absolute fixed background, but even
a few noise in between will cause it to think the background
is moving, a very large area is affected.

What's even stranger, is that when I strip the video down to it's
edges, a cartoon-like video with a near noise-free background, it
still thinks the background has movements. (default settings)

Looks like a slight of movement/noise will affect a large static area
if there's no distinctive lines in between to seperate them.

Maybe a gradient detection(compare) will help preventing this?
Or imploy a temporal vector trembling threshold/smoother to
eliminate incoherent small vectors trembling along the time axis..?

----- using the sample code with truemotion on ---------
source=converttoyv12(source)
vectors = source.MVAnalyse(isb = false,truemotion=true)
return source.MVShow(vectors)
---------------------------------------------------------

original vid (1M) (http://dabadee.hypermart.net/mvtool/original.avi)

edge only vid (1M) (http://dabadee.hypermart.net/mvtool/edges.avi)

vectors vid (1M) (http://dabadee.hypermart.net/mvtool/vectors.avi)

http://dabadee.hypermart.net/mvtool/original.jpg

http://dabadee.hypermart.net/mvtool/edges.jpg

http://dabadee.hypermart.net/mvtool/vectors.jpg

original vid (1M) (http://dabadee.hypermart.net/mvtool/original.avi)

edge only vid (1M) (http://dabadee.hypermart.net/mvtool/edges.avi)

vectors vid (1M) (http://dabadee.hypermart.net/mvtool/vectors.avi)

[Isochroma]

I must apologize - after checking the new 1.0 documentation, that typo was fixed... but my syntax questions remain. Does the order of the motion vector parameters matter? Could you provide an example of the syntax for 3- or 4-frame denoising using MVDenoise?

[Fizick]

Isochroma,
IMHO, any order. This function was implemened by Manao. I never use it.
Try use forum search (old MVTools thread).
And please post your "usage" question in other thread (in "usage" forum).
http://forum.doom9.org/showthread.php?p=749503

Current thread is about "development".

[Isochroma]

Oops, posted in wrong thread again! Indeed, the parametric order doesn't seem to matter so much.

[Fizick]

Neil Lee,
probably i must restore zero vector predictor preference (Now i give some penalty to it). It is dilemma.
But do you try to tweak advanced truemotion parameters, for example decrease pnew to 0?
I will try your video later.

[scharfis_brain]

Fizick, here http://rapidshare.de/files/3042060/buga-2.avi.html you can download a clip, which totally seems to cunfuse mvanalyse. I never puts out any motion vectors!

avisource("buga-2m.avi").assumebff()
bob()
converttoyv12()
backward_vec = MVAnalyse(isb = true)
last.mvshow(backward_vec)

[videoFred]

Nice chickens :)

I found out lowering the contrast and brightness of the MVAnalyse clip brings the motion vectors back.

tweak(bright=-20,cont=0.4)

I tried it with your clip, it works!

Fred.

[scharfis_brain]

yeah, lowering contrast or blurring the source bringing back the vectors.

but both are NO option.

[Fizick]

scharfis_brain,
1. You can use different clips for analysing and compensation.
2. 30 MB is too much for my dial-up.

[scharfis_brain]

1) I know. But I will not modify existing scripts, that are working extremely well with all other sources. plus: lowering contrast and/or sharpness will degrade motion estimation, won't it?

2) how much will be acceptable?

[Didée]

a clip, which totally seems to cunfuse mvanalyse. ...
backward_vec = MVAnalyse(isb = true)
Last time I checked, there were some more parameters available for MVAnalyze ;) ... probably you'd have to adjust some of them. Seems like this clip forces high SADs because of its sharpness, or something like that (can't check out right now).
The possible characteristics of possible sources are without any limits - you can't expect the default values to work out on just everything.

[scharfis_brain]

you can't expect the default values to work out on just everything.
Why not? I could have lived with inaccurate motion vectors, but NO vectors at all is not acceptable at all.

Last time I checked, there were some more parameters available for MVAnalyze ... probably you'd have to adjust some of them. Seems like this clip forces high SADs because of its sharpness, or something like that
So which parameters need to be altered then?

[Didée]

Poking in the blue: thSCD1 (prhps thSCD2 too) are good candidates. Could be that the clip constantly causes SADs that overflow thSCD1=300. Try 9999. Perhaps lsad/pnew play a role too, not sure about that.

Does the behaviour change when simply giving "blksize=16" or "4" ?

[scharfis_brain]

setting thscd1 on the compensation functions to 9999 helps! thanks.

does it hurt to leave it 9999 all the time?
eg. in mvbob?

[Didée]

Well, you loose MVTools' ability to detect scenechanges, so it'll compensate "over" the SCs, no matter how crappy the result. For MVbob it shouldn't matter much, because of the corrector it's using.

[Fizick]

For my (analog, noisy) sources I always use thSCD1=400 or 500.
BTW, today I will release new bugfixed version (memory leakage).
I can also change default thSCD1=400 if you (and Manao) will not protest against it.

[Fizick]

New MVTools 1.0.1 (Released 24.12.2005 by Fizick).
Fixed memory leakage bug in MVAnalyse with global motion (thanks to AI for report - probably nobody else used MVTools for real long encode :) )
Removed penalty for zero vector predictor in MVAnalyse (was introduced in v1.0).
Changed chroma=true as default in MVAnalyse.

I am still did not change thSCD1 default (compatibility ...).
But IMHO it must be block-normalized value (about 5 to 6).

[AI]

I used - I add 21 jobs - every 10 000 frames *.xx.avi :cool:
(for reload MVTools)

[Fizick]

My "to do" list:
1. Overlapped blocks motion estimation for using with MVFlowXXX
2. YUY2 colorspase

[WorBry]

Howdy Folks,

For conversion of (mvbob) 50fps sources to 25fps, I’ve been using the following script, a slight modification of Scharfis_Brain's mvfpsscd function:

function mvfpsscd(clip i, float fps, int "oversample", int "blurradius")
{
blurradius=default(blurradius,1)
oversample=default(oversample,1)
j=i.temporalsoften(2,4,5,2)
fwd=mvtools0962_mvanalyse(j,isb=false,sx=4,sy=4,lambda=4000)
bwd=mvtools0962_mvanalyse(j,isb=true,sx=4,sy=4,lambda=4000)
mv=i.mvtools0962_mvconvertfps(bwd,fwd,fps=fps*oversample).deblock()

global mv= (oversample>1) ? mv.temporalsoften(blurradius,255,255,mode=2).selectevery(oversample,0) : mv
global ch=i.changefps(fps) #. subtitle("ch")

global msk0=ch.duplicateframe(0).reduceby2().reduceby2().motionmask(thsd=255,y=3,u=1,v=1)
global msk1=msk0.trim(1,0)
global msk2=msk0.trim(2,0)
global msk3=msk0.trim(3,0)

f0=scriptclip(ch,"""sc""") #.subtitle(string(a0)+" "+string(a1)+" "+string(a2))""")
f1=f0.frameevaluate("""sc= (sc2 || sc1) ? ch : mv""")
f2=f1.frameevaluate("""sc2=( (a2 > (a1*5+25)) && (a2 > (a3*5+25)) ) ? true : false""")
f3=f2.frameevaluate("""sc1=( (a1 > (a0*5+25)) && (a1 > (a2*5+25)) ) ? true : false""")
f4=f3.frameevaluate("a3=averageluma(msk3)")
f5=f4.frameevaluate("a2=averageluma(msk2)")
f6=f5.frameevaluate("a1=averageluma(msk1)")
f6.frameevaluate("a0=averageluma(msk0)")
}

avisource("C:\mvbobbed 50fps.avi")
ConvertToYV12()
mvfpsscd(25,oversample=16,blurradius=4)
#

The oversample and blur radius settings, as suggested by Scharfis, produce a superbly smooth film effect, but the processing is extremely slow (7 hours for a 5 min clip on my AMD XP2800 rig). The new MVFlowFPS and MVFlowBlur functions would seem to offer a faster method, but I am not entirely clear about the ‘num’ and ‘den’ parameters. Specifically;

1. For a 50fps to 25fps conversion, with a basic setting of num=25, den=1, does MVFlowFPS simply select the original (even) frames or synthesize new frames at 25fps?

2. If new frames are created, does increasing the ‘num’/’den’ values proportionately (50/2, 100/4, 200/8 etc) achieve over-sampling (like mvfps) or have no overall effect on the motion quality?

3. Also, how should MVFlowFPS and MVFlowBlur be used together? I’m assuming:

a=avisource("C:\mvbobbed 50fps.avi").ConvertToYV12()
backward_vec = a.MVAnalyse(isb = true, truemotion=true, pel=2, idx=1)
forward_vec = a.MVAnalyse(isb = false, truemotion=true, pel=2, idx=1)
b= a.MVFlowFps(backward_vec, forward_vec, num=25, den=1, ml=100, idx=1)

backward_vectors = b.MVAnalyse(isb = true, truemotion=true, pel=2, idx=1)
forward_vectors = b.MVAnalyse(isb = false, truemotion=true, pel=2, idx=1)
return b.MVFlowBlur(backward_vectors, forward_vectors, blur=15, idx=1)

Is this correct? (I’m using the latest MVTools v1.0.1 with default chroma=true)

Thanks a lot.

[scharfis_brain]

Why do poeple think about 'converting' 50 fps to 25 fps this weird way?

mvbob().selecteven() will do this job.
(selecting evedy 2nd frame)

[WorBry]

Scharfis_Brain,

Because the motion produced by selecteven() is not very smooth, at least with my DV sources which were all shot with automatic shutter speed (Sony DCR-PC115E). Maybe using a fixed 50fps shutter speed would improve this?

However, I am getting excellent results with your mvfps(scd) function and the oversample/blurradius settings you recommended:

http://forum.doom9.org/showthread.php?p=735419#post735419

I was simply wondering whether the same could be achieved more quickly with MVFlowFPS and MVFlowBlur. From my initial tests however MVFlowFPS (alone) tends to produce some flickering, much like SelectEven, which led me to ask whether, in converting 50fps to 25fps, MVFlowFPS selects even frames anyway.

Thanks.

[scharfis_brain]

Ahh, you want to get motionblur. Cinematic film usually gets exposed 50% the time of the duration of one frame (50% shutter = 1/48 sec with 24 fps).

There mainly are two ways to achieve filmlike motionblur depending on the shutter speed of your source video. Filmlike motionblur means 50% shutter again which is 1/50 sec with PAL-Video (Speedup Filmtransfers, too)

a) if the shutter speed is
1/100 ; 1/150 ; 1/200 or 1/250 sec then it is useful to interpolate the framerate to
2x50 ; 3x50 ; 4x50 or 5x50 fps and afterwards blend together
2 ; 3 ; 4 or 5 Frames and then select every
4th ; 6th ; 8th or 10th frame to return to 25 fps.

This method will produce high quality motionblurring. I obviously becomes slower the shorter the shutter speed is. You could do this even with 1/1000 sec shutter but this won't be useful, cause it would be slow.

b) if you have such a short shutter like 1/1000 sec, it is better to use mvflowblur() and do selecteven() afterwards.

[WorBry]

Thanks Scharfis,

All my archived DV sources were shot in automatic mode, so the shutter speed was probably quite variable. Tried mvflowblur().selecteven() as you suggested. The motion is certainly smoother than selecteven() alone, but none of the alternative methods I've tried match mvfpsscd for motion and image quality, particularly after conversion to MPEG4. The next best method I've found so far is using mvflowfps to interpolate the framerate to 400fps and then performing an average ''temporal merge'' (of luma and chroma) over 16 frames. It gives good fluidity of motion and the encoding is considerably faster than mvfpsscd, but it just doesnt achieve the same look as a good motion blur. Is there any prospect of a faster ''mvfps-like'' function that provides the same options for oversampling and blur?

Thanks.

[Fizick]

WorBry,
Current thread is about MVTools "development".
Please post here your suggestion or bugs reports.
Please post your "usage" question in other thread (in "usage" forum).
http://forum.doom9.org/showthread.php?t=84770&page=9&pp=20

[scharfis_brain]

provide the following:
a) the unprocessed source video (a snipplet of it. NO recompression! at last a few seconds)
b)the script using
- mvfpsscd
- mvflowblur
- 400fps mvflowfps
c) one (the same!) special image of your choice each for the methods with
- mvfpsscd
- mvflowblur
- 400fps mvflowfps
The screenshot should be taken from the middle of the sample video you'll provide.


I need these things to clarify what exacly is your wish.
Thanks.

[WorBry]

Fizick. I receive your point.
Scharfis, I'll correspond with you privately on this. However, I've had to pack my PC away for a few days whilst moving apartment.
Cheers.

[Neil Lee]

Neil Lee,
probably i must restore zero vector predictor preference (Now i give some penalty to it). It is dilemma.

Wow, TrueMotion is absolutely amazing after removing penalty
for zero vector predictor, I find that if you feed it with interlaced
video, TureMotion can become a very good tool for deinterlace.

Of all the de-interlacer I've used, none can do a better job in identifying
moving areas, Most of all, they can't handle a moving gradient area, they all
think it's static, thus leaving a bunch of scattered comb-like residual.

Maybe we can utilize MVMask and Masktool and do a "truemotion de-interlacing",
to help removing unwanted extra residual, Think create a 100% de-int clip and
then mask 2 clips using vector data..) But since I've just started to learn
avisynth, maybe someone wanna give it a shot first?

.

[foxyshadis]

mvbob does just that. ;) Newest version uses mvflow.

[Revgen]

where is the newest one?

[sh0dan]

I have a rather small request: A filter to extract statistical data for conditional filters. I had a short look at MvShow, and it seems like it wouldn't be that much to implement:

Example of code (in GetFrame):

double mean = 0;
for ( int i = 0; i < mvClip.GetBlkCount(); i++ )
mean += mvClip.GetBlock(0, i).GetSAD();

env->SetGlobalVar("mv_avg_sad", AVSValue(mean / nBlkCount));

another could be:

double mean = 0;
[for each block in Y plane] {
x = plane.getXlength();
y = plane.getYlength();
mean += sqrt(x*x+y*y);
}
mean /= scale * nBlkCount;
env->SetGlobalVar("mv_avgY_length", AVSValue(mean));


I imagine a command like MvStats(video, vectors,.....) that would pass through video untouched. It could then set a number of variables that could be used by other filters.

[foxyshadis]

Sorry revgen, scharfis linked to it here (http://forum.doom9.org/showthread.php?p=757259#post757259).

[akoten]

Ahh, you want to get motionblur. Cinematic film usually gets exposed 50% the time of the duration of one frame (50% shutter = 1/48 sec with 24 fps).

There mainly are two ways to achieve filmlike motionblur depending on the shutter speed of your source video. Filmlike motionblur means 50% shutter again which is 1/50 sec with PAL-Video (Speedup Filmtransfers, too)

a) if the shutter speed is
1/100 ; 1/150 ; 1/200 or 1/250 sec then it is useful to interpolate the framerate to
2x50 ; 3x50 ; 4x50 or 5x50 fps and afterwards blend together
2 ; 3 ; 4 or 5 Frames and then select every
4th ; 6th ; 8th or 10th frame to return to 25 fps.

This method will produce high quality motionblurring. I obviously becomes slower the shorter the shutter speed is. You could do this even with 1/1000 sec shutter but this won't be useful, cause it would be slow.

b) if you have such a short shutter like 1/1000 sec, it is better to use mvflowblur() and do selecteven() afterwards.
My problem is that (maybe only in my case) the clip coming out of mvbob() is not usable as input to a subsequent mvanalyse() which is necessary for mvflowblur() or any other motion blur algorithm. Almost none of the motion is being detected and where it's not detected the "behaviour" of the resulting clip is MUCH worse than with a simple "merge(even,odd)".

However, mvbob() works perfectly, so my idea was to use the motion vectors from there. I just tried that but I must admit that I gave up very soon because I was not sure where and how it would be best to integrate the motion blur routines in "mvbob.avs".

Can you help? Maybe a new version of mvbob() with a switch named "smooth" (default="true" for compatibility)?

regards
AKo

P.S. I use "mvflowblur() with "blur=100", because I think that together with selecteven() this is the only way to achieve 50% shutter time on the resulting 25fps movie. Am I right? It's just because I found other posts here that claim values like 15, 50 or the like...

[Didée]

My problem is that (maybe only in my case) the clip coming out of mvbob() is not usable as input to a subsequent mvanalyse() which is necessary for mvflowblur() or any other motion blur algorithm. Almost none of the motion is being detected and where it's not detected the "behaviour" of the resulting clip is MUCH worse than with a simple "merge(even,odd)".
This sounds pretty much like "idx desease". Read carefully the MVTools documentation about the "idx" parameter. In a nutshell, I explained it here (http://forum.doom9.org/showthread.php?p=775411#post775411) (well ... at least I tried to ;) ).

I'm not fully sure how MVBob currently handles the idx parameter ... if it's still the same way that I hacked it in some time ago :o, then it's a hardcoded value - which could be an explanation for the poor results you get.

BTW, an at least halfway safe way of using idx in such a way that no conflicts occur, while still having the benefit of using explicit idx values to spare ressources, is done by initiating and up-counting a global variable for this purpose. Look at the MVNR_simple2 (http://home.arcor.de/dhanselmann/_stuff/MCNR_simple2.rar) script I had once posted - there idx is handled in that way. However it's needed that all involved filters or functions refer to that global counter, else it won't work.

(Should note that this wasn not my idea ... I once saw krieger200? doing it this way, and had the BINGO! effect.)

The other option is to not use idx at all ... which is no problem, as long as your machine has at least 4 GB of RAM installed ... :eek:

[akoten]

One thing to clarify:
I convert a DV source clip to MJPEG using mvbob(). Then I load this MJPEG in another VDub and try to put motion blur to it. This is because I get "low memory" crashes with mvbob all the time (even having 2,5GB of RAM!). So "idx" of mvbob currently can't interfere with the motion blur script.

I think I even tried to have different idx for mvanalyses and mvflowblur in this script (by accident while playing around with all kinds of parameters in mvanalyse, but will need to confirm this in the evening).

AKo

[krieger2005]

I think there is somewhere a bug in the MVTools. When i use complex scripts with MVTools and load the same script more the one time after some times it crashes with low-memory... However, since i use in such much different filters it could be also something other. I can live with that "crashes". And that the MVTools produce that crashes is only a speculation of myself (Maybe i should make a test with different versions... hm...)

[AI]

I think there is somewhere a bug in the MVTools. When i use complex scripts with MVTools and load the same script more the one time after some times it crashes with low-memory... However, since i use in such much different filters it could be also something other. I can live with that "crashes". And that the MVTools produce that crashes is only a speculation of myself (Maybe i should make a test with different versions... hm...)
use version 1.0.1+ (http://bag.hotmail.ru/mvtools/MVTools-v1.0.3.zip) ?

1.0.1 (Released 24.12.2005 by Fizick)

* Fixed memory leakage bug in MVAnalyse with global motion (thanks to AI for report).

[akoten]

use version 1.0.1+ (http://bag.hotmail.ru/mvtools/MVTools-v1.0.3.zip) ?

I also read this thread, but I tried with both 1.0.0 and 1.0.3, both behave the same. Maybe it's another leakage bug that was fixed there.

I'm VERY sure, that one of the tools used in mvbob has a leakage bug. Too many indicators point to this one and only conclusion.

[krieger2005]

I use the newest official version, so 1.0.3.

[Fizick]

I am still did not get memory leakage.

But I returned :)

1)I create a new site (mirror) http://avisynth.org.ru

2)MVTools v1.1.1 is released for download. Thanks to all who supported!
v1.1 (non-public build 9.01.2006 by Fizick)
Quite large revision (beta). New option for overlapped block motion estimation in MVAnalyse for usage in MVFlow, MVFlowInter, MVFlowFps for improved motion compensation.
Lookup tables for motion interpolation.
Small correction of displacement value in MVFlowFps2.
v1.1.1 (16.02.2006 by Fizick)
Removed DeBlock and Corrector filters (will be separate plugins)
Documented old MVSCDetection function.
Cleaned project from unused source files.

3)And New beta version MVTools 1.2 with YUY2 support is developed, it is available for registered users.

[sh0dan]

MVTools 1.2 with YUY2 support is developed
Do you unpack to an internal planar format?

That would be great, since it would make 4:4:4 and 4:2:2 planar formats a breeze for AviSynth 2.6.

[Fizick]

sh0dan,
Yes, I unpuck to internal planar 4:2:2 format (currently in draft, slow, without assembler).
So YV16 support will be trivial.

BTW, I missed your old MvStats suggestion. I will look to it.

[sh0dan]

You can grab the MMX assembler from the 2.6 sources here:

http://cvs.sourceforge.net/viewcvs.py/avisynth2/avisynth/src/convert/Attic/convert_planar.cpp?view=markup&rev=1.1.2.19&sortby=date&only_with_tag=avisynth_2_6

Look for "conv422toYUV422" and "convYUV422to422". Width must be mod 8, but you already have the C-code for fallback.

[Fizick]

It seems, there is stiil some bug with overlap mode in v1.1.1. At least it produces strange results.

sh0dan,
I add mmx convert in next beta, but it gives 3 percent speed only.

About MVStats: fixed names of global variables are not very good, consider two MVanalyse for example.
May be integer type function like MVAveregeSAD(vector) will be better?

[Fizick]

Today: Soviet Red Army Day!

Released MVTools 1.2.1:
Fixed bug of v1.2,
Speed restored,
mmx YUY2 conversion (from avisynth 2.6 function by sh0dan)
But it seems, overlap mode still does not work properly

[Boulder]

Thanks for the YUY2 support, it's very useful for my captures :)

I'd donate but unfortunately student's monthly income can barely pay the rent and bills..not to mention food :(

[Richard Berg]

Can you release the separate plugin with Corrector & DeBlock? Corrector especially is needed for MvBob.

[Fizick]

Richard,
I released them two days ago :)
(at my new site)

[Fizick]

Boulder,
In any case, your test results and suggestions are welcomed!

[Fizick]

Richard,
Sorry, that day I forgot to add a link to it!
Fixed now.

[Fizick]

sh0dan,
Do not forget fix a bug with frame shift in convertYUY2 function at avisynth 2.6 cvs!
I fixed it in released MVTools v.1.2.2

[scharfis_brain]

mvtools.dll (even the old one without YUY2 support) isn't downloadable anymore.
is this intended?

[Fizick]

scharfis_brain,
probably you use wrong (old) site.
see my signature :)

[scharfis_brain]

I know. But the download link redirects to your old site, which doesn't contain the download anymore. So I am trapped into an endless loop....

If I missed something, please tell me the exact clicks step by step starting from you new stie here: http://avisynth.org.ru/

thanks!

[Fizick]

At avisynth.org.ru click "Fizick's plugins for avisynth" in right (English) part of table,
at new opened page (fizick.html) search and click "mvtools" in table, at opened mvtools.html see last link at page bottom.

May be, your browser cache problem? Try refresh at every step.

Somebody else has some trouble?
I download mvtools right now :)

[scharfis_brain]

see last link at page bottom.

That was the problem. I didn't expect the Download at the bottom of the page!

Mabye the word "download" at the top of the is a little bit misleading...

[Fizick]

O.K., I shall update top link too.

[Boulder]

sh0dan,
I add mmx convert in next beta, but it gives 3 percent speed only.

I'm not 100% sure if you're talking about the same thing, but kassandro's SSETools contains functions called Interleaved2Planar and Planar2Interleaved which are needed if you use any function from the latest RemoveGrain or Repair dlls with YUY2 data.

He apparently hasn't released the sourcecode for SSETools as he calls the latest version preliminary, but as he hasn't been active anywhere lately, you might want to ask him if he could share the code which is supposed to be highly optimized.

[Fizick]

Boulder,
3 percent is for total MVTools speed (MMX conversion itself is faster and quite good optimized).

SSETools uses special packed format for storing YUY2 planar in ordinary YUY2 clip. But new avisynth 2.6 will be use separate format for it. It seems as more pespective. Wait.

[KillNoise]

Ever thought of implementing fast subpixel ME by fitting the subpixel resolution vector to the SAD-curvature samples calculated at integer vector positions ?
Instead of interpolating an intermediate 2x resoution "blow-up" image to perform the search at half-pixel positions, you have to search only in the original size image to find the SAD minimum integer position, then approximate the subpixel position from the values of SAD-minimum and its 4 (or 8) neighbours.
Searching blocks in lower resolution saves a lot SAD-calculations, making ME much faster. Curve-fit approximation of the block vectors (yielding resolution of 1/2-pixel or beyond) can be implemented fast and easy. (If you doubt, ask me to go into detail.)

[Fizick]

I released new MVTools version 1.3.0 (beta?)
Implemented overlapped block motion compensation to MVCompensation(mode=1).
Changed default to mode=1 in MVCompensation as the most universal.
Added sharp subpixel interpolation method for pel=2.
Fixed bug for blksize=16 with YUY2.
(To-do list: assembler SSE speed optimization for new compensation and interpolation methods.)

[scharfis_brain]

would it be possible to implement edge directed internal sampling to increase subpixel accuracy over the linear subpixel accuracy?

[Fizick]

Did you try set sharp=1?

[scharfis_brain]

No I didn't I was just asking.

[Fizick]

Answer: Yes, it is possible to imlement any pixel interpolation. :)
Really I firstly want to add Wiener interpolation. But "true" Wiener (local adaptive) is complex. So, I implement sort of invariant Wiener 6 taps interpolation (do not know why :)).

Coeffs= (1; -5; 20 ; 20; -5; 1)/32

About edge-directed. Really Manao used horizontal, vertical and diagonal bilinear interpolation.

[Didée]

Hey, a big Thank-You, Fizick. Block overlapped compensation is doing a very good job, and the sharp interpolation comes nice, too. :)


- One bug discovered:

An error is thrown when compensating after "padding(x,y)":
vectors = source .padding(4,4) .mvanalyse( [parameters] )
comp = source .padding(4,4) .mvcompensate(vectors, [parameters]) .crop(4,4,-4,-4)
will give "MVTools: MVCompensate does not have a named parameter 'truemotion' / 'blksize' / 'pnew' " etc.pp. :confused:
I noticed this when just plugging MVT 1.3.0 into a script where a manual block overlapped ME+MC is done. Probably no big deal, since padding() isn't documented, hence not used very much. Still, it's not exactly the expected behaviour ...


- A question:

"sharp" interpolation can only be specified in MVAnalyse(). Now, in case if compensation is done with new interpolation:
vectors = source_1 .mvanalyse( sharp=1, idx=a )
comp = source_2 .mvcompensate( vectors, idx=b, mode=1 )
will MVCompensate also use sharp interpolation (reckognizing some flag, or whatever, in the vector clip), or will it use normal bilinear interpolation?


- Question / Suggestion:

Compairing the block overlapped estimation + compensation with the scripted approach I tried, your method seems clearly superior in, say, 80% to 90% of the problematic areas. (Darn you! :D ) However, there are some percent left. ;)

What I tried was a different method, more kind of a "best match":

- create vectors on orignal, and on padded original
- create compensations with both vectors
- weight both compensations acc. to their amount of difference to the original (including some 8x8-block-restricted spatial blurring of all three clips)

It seems feasable that in areas where compensation #1 shows an obvious bigger difference to the original than compensation #2, the weighting of compensation #1 should be reduced (and vice versa).

Does your block summation method already include something like this? If not, it could be worth a try.

[dirio49]

Help

i have no idea how to use it

can somebody post a sample working script with everythink that is need?

thanks

[johnmeyer]

can somebody post a sample working script with everythink that is need?
What exactly are you trying to do? And, what part don't you understand?

[dirio49]

I went to the site and don't really understand what to do?

i just want to try it out in some low bitrate encode

1500 avg bitrate..

I want to try motion blur.

thanks


EDIT:

@Fizick

sorry thanks for pointing it out

[Fizick]

Didйe,
1. edges processing is not implemented. I never used "padding" command. Will look later.

2. MVCompensate use same (sharp) interpolation (reckognizing some flag in the vector clip) in mode=1 and mode=0.

3. your suggestion is interesting, but it may produce some blocking.
One of aims of my current overlapped procesing is deblocking.
Will try strives for perfection later. :)


drio49,
MFlowblur?
But please post your "usage" questions to "usage" forum:
http://forum.doom9.org/showthread.php?t=84770

[Fizick]

Didйe,
I disabled external "Padding" function since MVTools v.1.1.1.
We do not need in external double-sided padding (but only bottom and right).
Now I simply fill it by source pixels.
Try use addborders or mirrorborders as a workaround now.
May be I will implement better padding internally some time.

[Chainmax]

Would there be any way to make MVTools work with tsp's multithreaded version of Avisynth?

[Pookie]

Only if you buy Fizick a dual core system to debug the new code with....:D

Have you looked at Motion by mg262/clouded? It isn't as sophisticated, but it might work with MT Avisynth.

[Didée]

Use 2 PCs to process 1st/2nd half of the source. Very stable solution, and available right now.

If short of a 2nd PC, you can simulate it like this: first do the 1st-PC's part, then do the 2nd-PC's part, and join both parts afterwards. :p :D
[*running man*]

[Fizick]

You also may try run two AVS (two part of file) in separate threads :)

Seriously, some time I will look to it. I am afraid I firstly must remove all IDX, but it will run slower. :)

[Chainmax]

That's good to hear, and your suggestion is actually a pretty good idea. Take your time, good things do tend to take lots of time :).

[Revgen]

@Chainmax,

If you really want to run MVtools in Dual-CPU, make sure to get a big HDD and encode 2 avs files to lossless. I always do this with MVBOB. I then encode after I'm done. The process is alot faster. The speed increase for me is about 70%.

[TSchniede]

But it is not that straight-forward, mvbob for example can only be used in one encoding at a time unless you specify different idx values for every thread. With the new 1.5 mvtools and the 2x-clip it's probably easier.
Most of the time it works using different idx-values for each thread, but avisynth tends to mix different values of the same variable name, so better no reuses of the same name. Tracking these bugs is very difficult (only sporadically visible).