Motion Compensation

[scharfis_brain]

manao, is it possible, to create a function, that returns a float value of the currently present motion?

i.e. summarizing the vectors lenghts of the largest, moving object?

this would help, detecting framedrops, skips and duplications.

it also may help setting the fieldorder automatically...

[Manao]

violao : you're right, but since it took more time to code, I prefered implement the easy version, i.e. the mean. I'll put that on my TODO list.

scharfi : yes, it's easy, but what do you want exactly ? The mean of the length of the motion vectors ? The median ? If not, what else ?

[scharfis_brain]

I'll try to explain

imagine a constant horizontal scrolling video.

origonal
Frames: A B C D E F G H I J K L

now, frame F gets dropped:

Frames: A B C D E E G H I J K L

this means, the (simplified) output of the wished function should be:

Frames: A B C D E E G H I J K L
output: 1 1 1 1 1 0 1 1 1 1 1 1

another more weird sample:

a frame gets dropped, but isn't replaced with is predecessor. It is replaced with any of the previous frames:

Frames: A B C D E A G H I J K L
output: 1 1 1 1 1-5 1 1 1 1 1 1

as you can see, the dropped frame F gets replaced with A, this means, the output of my wished function should be the (at least) inverse of the previous value.

the calculation method of the length of those vectors, seems to be irrelevant for this kind of detection, I think....

What do you think?

[Manao]

Alright, so you need the vector, not its length. It's not hard to do, it will be in the next release. But I wonder if this can't already be done with the Global Motion Compensation tools made by Fizick.

[vinetu]

An idea for 2 pass motion compensation process.

Lets assume the source is progressive.

1.upsize the source x2 using some advanced resizer (Smart_resize_filter or Didee's iiP or similar)

2.aplly the best denoiser on the upsized source (don't know which exactly)
-the targed is almost perfectly denoised and stabilized (without flickering) picture

3.apply some advanced sharpener filter (VirtualDub MSU Smart Sharpen Filter for example)
-the target is to produce an almost extremely contrast picture (looking like synthetic one)

4.run MVTools over that "synthetic" source,calculate needed data and save it in a "1-pass.log" file

5. 2-pass process - run it again over original (not enhanced) source,taking in mind scaling x2

Is it possible in theory ?


P.S. I'm not familiar with MVTools yet... :)

Best Regards!

[Manao]

It's possible in theory. No need to upscale I think ( anyway, MVTools can work at subpel precision ). But it would need be able to export motion vectors to a file, which isn't yet in the TODO list ( but since it interests a lot of people, it will soon get there I think ).

Now, I don't think results will be far better than without preprocessing.

[vinetu]

Now, I don't think results will be far better than without preprocessing.

Let's hope it could be :)

Thank You!

[Fizick]

Vinetu:
For noisy source (also luma flicker, blotch, etc), pre-cleaning must give more regular vectors. But why to write vectors to file?

Manao:
I stil hope that you will release not only forward, but full backward compensation as general using function.

[Manao]

I think you can have it by using the following trick : source.duplicateframe(1).reverse().mvshow(cm = true).reverse()(I didn't invert it, I first saw it on a scharfi's script)

Hence, you'll be able to wait the next release in which it'll be possible.

Edit : oh, and the "file" idea : most codec still need two passes to work, that's why I was speaking of outputting it to a file. Anyway, as soon as I defined a structure to store the motion vectors data, it won't matter whether I output it in a file or in an array in order other filters to use it (i.e. client / server as you're doing with depan )

[vinetu]

...But why to write vectors to file?

Finaly I think that the only necessary thingy to
improve MVectors detection is to split the input video
stream in 2 -one for proccesing and another for MVectors analysis.
This second stream could be resized,denoised,sharpened,luma-chroma stabilized
and even slightly blured ...I'll try soon if this "preprocessing" can help.

So generally there is no need for 2-passes...

But now I see another usefull trick :
at 1-pass you can load a completely different "reference" file and save MVectors.log and then
at 2-pass load the "video" file and procces it in relation to "reference" file...

I don't know yet where this could be used,but it's sound intriguing for SpecialFX compositing...

Best Regards!

[Fizick]

Vinetu:
Yes, 2 streams (clips)!

[vinetu]

Fizick you win! for now the count is 2:0 :)

But here is come the next situation:
1.you made a 1-pass metrics and save them in a "YourFavoritMovie.MVectors"
2.open that file in a MVectorsEditor.exe (a dreamed application) and correct some MVectors here and there...
3.watch the movie in 100Hz (another dreamed thing- a DirectShow filter which will read the values from *.MVectors
and process (interpolate) the picture in real time) ...

too many dreams here? ;)

Best Regards!

[Fizick]

As I know (and even tried ones upon a time :devil: ),
1 and 2 is realized in Retimer
http://www.realviz.com/products/rtpro/index.php
But manual editing is not very interesting work.

About 3. Seems, MC is realized in modern TV (by hardware).

But what if I say, that good old film restoration (with MC, filtering, etc) is produced in about 1 fps in software (by 1 CPU).
Probably, we also need in some hardware signal processing chips.
May be, videocard chip?

(It is not my dreams, but some dilettant's thinking).

Best regards!

[scharfis_brain]

I found out, that mvinterpolate(el=1,bl=1) is a simply null transform.

and mvinterpolate (el=0.75,bl=0.75) doesn't do 0.75 fwd compensation. it does a 0.25 back compensation instead.

for the things, I want to do, I need a full compensated frame.
Only the underlying frame may be the frame towards is compensated to.

this means, el=bl=1 will shift the movie temporally by 1 frame, but all frames are compensated fully by one frame.

[Manao]

I found out, that mvinterpolate(el=1,bl=1) is a simply null transform.

and mvinterpolate (el=0.75,bl=0.75) doesn't do 0.75 fwd compensation. it does a 0.25 back compensation instead.Yes, but that's the wanted behavior. It isn't meant to motion compensate, it is meant to interpolate. So the compensation of each frame is weighted by the distance ( in time ) from the interpolation to the frame.

Hence, if you do 'el = bl = 1.0', the filter will build 2 frames, but when merging, they'll be weighted by 0 and 1 respectively, so only one will be kept.

Also, the filter interpolates between the current and the previous frame. So there's no forward compensation possible. ( except reversing the clip ). And 'bl = el = 0.75' does a 0.75 backward interpolation.

To motion compensate, use MVShow(mc = true) instead.

@all : I'm currently working on the core of the set of filters. I've cleaned the code, I'm now using optimized copy functions ( from avisynth's code ), the type of search can now be chose ( four methods implemented : one time search, N step search, logarithmic search ( aka diamond ) and exhaustive search ).

[violao]

Originally posted by Manao
@all : I'm currently working on the core of the set of filters. I've cleaned the code, I'm now using optimized copy functions ( from avisynth's code ), the type of search can now be chose ( four methods implemented : one time search, N step search, logarithmic search ( aka diamond ) and exhaustive search ).

Manao, have you seen this: Correlation Based Search Algorithms for Motion Estimation (http://amp.ece.cmu.edu/Publication/Deepak/Pcs99.pdf)

Might give you some new ideas :cool:

[scharfis_brain]

I tried to use mvshow(...) for full compensation, but its output was (who wonders) crappy

Could you code something like this ? :

http://home.arcor.de/scharfis_brain/ffc.png

That should handle hidden areas fairly well in theory

[Tuesday]

Hey, I'm not an experianced programmer or anything...but doesn't xvid have a rather well developed motion seach/detection/prediction engine ticking over somewhere in its core?

maybe some of their code would be useful, being open-source an all :)

if im entirely wring then just ignore me and i apologise for meddling in matters beyond my understanding :)

[Fizick]

I try to use motion compensation. It work quite good!
But there are often many blocks on picture.
Probably, the better will be compensate not block, but pixels (every or may be only from such bad blocks),
with motion vectors calculated by some interpolation data from current and neighbors blocks.

[Manao]

@violao : thank you, however, the algorithms described is this article are slower than the one I use, and not really better I guess.

@Scharfi : what do you want to do ? Compensating or interpolating ? Hidden areas while compensating aren't an issue, whereas while interpolating they are.

Your example describes the behavior of MVDenoise ( without the missing area filling, since there are none to do ).

The result of full motion compensation is indeed crappy ( well, mostly blocky in fact ), but it was meant to be that way. I'll add parameters in order it to be tweaked ( the way Fizick is describing )

@Tuesday : indeed, XviD ME is good, that's why I used its principle in the first place ( diamond search, and spatial prediction ).

@Fizick : that may be done, I'll add it to the to do list.

@all : the client / server part is working now. I'm now looking how to write vectors to a file, which means I'll have to compress them ( you wouldn't like a vector file weighting 15 GB :rolleyes: ). I've coded a huffman tree, which would reduce it to 500 MB - 1 GB. The funny part is, if I ever add a DCT / iDCT code somewhere, I'll almost make a codec out of it :D

Without kidding now, the client / server was a good idea. It makes the job for people who want to write filters a lot easier. They should have anymore to compile my whole code.

I'll try to release it during the week ( I still have to update documentation ) but without the 'saving vectors to file' part ( that one will definitely be tricky )

[scharfis_brain]

I try to build a full motion compensated deinterlacer.
Everything I tried so far has big issues.

fieldsequence:
A C E G I <-top field
b d f h j <-bottom field

1st method:
mvinterpolate between A & C to recreate B
mvinterpolate between b & d to recreate c
mvinterpolate between C & E to recreate D
mvinterpolate between d & f to recreate E
.
.
.

this works absolutely correct if there is only linear motion present.
(it completely restores the progressive frame!)

but on acceleration etc. it completely fails, because el=bl=0.5 do not fit anymore due to the non-linear motion (acceleration)

2nd method
- do some kind of full frame deinterlacing with good interpolation (edge directed is cool)
- I'll name those interpolated fields with '

then compensate as follows to recreate the missing fields
mvshow(cm=true) from A to B' and from C to B' to create B
mvshow(cm=true) from b to c' and from d to c' to create c
mvshow(cm=true) from C to D' and from E to D' to create D
mvshow(cm=true) from d to e' and from f to e' to create e
.
.
.
.

this compensation nearly ALWAYS fits the motion, what results in very less remaining combing, BUT mvshow(cm=true) tries to recreate field' and not the missed field. this means it has no advantage in resolution over the previously applyed full frame deinterlacer.

thus I need some kind of mix of both methods.

- measure the moving distance from A to b and C to b with mvtools
- set el=bl to this moving distance.

example linear motion:
A to b = 1.5 (value doesn't matter, it is just choosen to show my thoughts)
C to b = -1.5
==> el=bl=0.5

acceleration
A to b = 1
C to b = -2
==> el=bl=0.3333

slowdown
A to b = 2
C to b = -1
==> el=bl=0.6666

I hope this all wasn't too confusing...

[scharfis_brain]

If someone is interested in a completely naked uncorrected motion compensated bobber, here it is:


function mvbob(clip i)
{
# fieldseparation
j=i.separatefields()

# settings for motion compensation
pel1=4
nb1=4
mbl=0.05
wf1="uniform"
mpt1=10

# generate missing odd (even) field
x4= getparity(i) ? j.selectodd() : j.selecteven()
x5=x4.mvinterpolate(nb=nb1, bl=0.5-mbl, el=0.5+mbl, pel=pel1, wf=wf1, mpt=mpt1)
x6=interleave(x5,x4).duplicateframe(0)

# generate missing even (odd) field
y4= getparity(i) ? j.selecteven() : j.selectodd()
y5=y4.mvinterpolate(nb=nb1, bl=0.5-mbl, el=0.5+mbl, pel=pel1, wf=wf1, mpt=mpt1)
y6=interleave(y5,y4)

# weave them back together
getparity(i) ? interleave(x6,y6) : interleave(x6.trim(1,0),y6.duplicateframe(0))
assumefieldbased()
weave()
}

in most cases it fails matching the fields together, but if it matches motion, the results are impressive!

issues when motion isn't matched:
- jaggy diagonals
- weird combing
- blockyness
- scenechanges always are broken into two combed frames :(

so a lot of postprocessing has has to be done to knock out its artifacts

I think on scrolling interlaced end titles, this deinterlacing should work really good.

a sample pic, where mvbob matched most of the motion:
(look closer at the grey background!)
http://home.arcor.de/scharfis_brain/deint.jpg

[Fizick]

To Manao:
1. As I see in source, MVSHOW (in compensate mode) firstly copies current frame to destination, yes? That is why there are no black borders after compensation. I.e. the "compensation" is not honest! :)
2. At last I build makefile (by hand), and now can compile MVTOOLS with VC++ Toolkit 2003. But linker writes some warning about defaultibrary and LIBC. I correct it with this setting:

CXX=cl.exe
CXXFLAGS= /LD /Ox /O2 /G7 /D "NDEBUG" /D "WIN32" /D "_USRDLL" /D "_WINDOWS"
LINK32=link.exe
LINK32FLAGS= /dll /nologo /nodefaultlib:libc
ASM=nasmw.exe
ASMFLAGS= -f win32 -DPREFIX

If these settings is correct, why my MVTOOLS.DLL size is 148k (while your is 66k) ?

[Manao]

Hi,

First, a new version : MVTools-v0.9.3 (http://jourdan.madism.org/~manao/MVTools-v0.9.3.zip)

Changelog :

* Last cleanings in the search of the motion vectors. It should be slightly faster
* More search parameters can be set by the user, especially the search algorithm. See the documentation
* Server / client implemented. You now first have to use MVAnalyse, and then the filter you want. Look at the documentation and at the examples I'll give alter.
* MVCompensate is separated from MVShow ( it's more logic that way ). For the moment, it doesn't move the chroma ( same behavior as MVShow in the latest releases )
* Some cleaning in MVBlur / MVInterpolate / MVConvertFPS, but still some work to do. Now, MVBlur blurs around the frame, not between the frame and the previous one.
* Half of the work is done for writing vectors to a file. But the resulting file will be large ( around 500 MB - 1 GB I guess ).
* MVDenoise is slightly faster ( at least it should )
* Copies are optimized inside the filter, thanks to avisynth's copy functions.
* MVShow can display the mean SAD of the compensation ( using showsad = true )

----------

Now, some examples :

To show the motion vectors ( forward ):vectors = source.MVAnalyse(isb = false)
return source.MVshow(vectors)To show the backward one :vectors = source.MVAnalyse(isb = true)
return source.MVshow(vectors)To use MVMask :vectors = source.MVAnalyse(isb = false)
return source.MVMask(vectors)To use MVBlur :vectorsfw = source.MVAnalyse(isb = false)
vectorsbw = source.MVAnalyse(isb = true)
return source.MVBlur(vectorsbw, vectorsfw)It's the same for MVInterpolate, MVDenoise and MVConvertFPS.

One warning : do not use MVAnalyse on clips that have different resolutions inside the same script, it would cause issue ( I'm desperatly waiting for Avisynth 3.0 and it's ability to attach values to a clip... )

Another warning : pel > 1 is quite useless for the moment, since no filter have a use for nth pel interpolation.

@Fizick : in compensate mode, the result doesn't have any black borders, even if I don't do the copy. In this mode, I move the blocks pointed by the MV from the previous frame to the current one, where the blocks are not overlapping.

I don't have any warning with the libc.

My final size is shorter only because I use upx ( http://upx.sourceforge.net/ )

@Scharfi : I see your point. I'll see what I can do.

@all : I strongly recommend for the parameters of MVAnalyse fth = 40, it's really efficient for copping with noise. But now, you can also try de denoise the picture before giving it to the analyser.

[Boulder]

Manao,

scharfis_brain's excellent MVConvert60ito24p() function on the first page doesn't work with MVTools v0.9.3 (works with v0.9.2.x). What would I have to change in the function to make it work?

The error message is "invalid arguments to function "mvinterpolate" ".

[Manao]

function mvconvert60ito24p(clip x, int "mode")
{

mode = default(mode,2)
mbl=0.1

vectorsforward = x.mvanalyse(isb = false)
vectorsbackward = x.mvanalyse(isb = true)

y = x.mvinterpolate(vectorsbackward, vectorsforward, nb = 4, bl = 0.5 - mbl, el = 0.5 + mbl, wf = "hat")

interleave(y,x)
mode0=selectevery(5,2)
mode1=overlay(selectevery(5,3),selectevery(5,2),opacity=0.5)
mode2=overlay(overlay(selectevery(5,1),selectevery(5,3),opacity=0.5),selectevery(5,2),opacity=0.3)
mode3=overlay(overlay(selectevery(5,0),selectevery(5,3),opacity=0.5),overlay(selectevery(5,1),selectevery(5,2),opacity=0.5),opacity=0.5)

(mode==0) ? mode0 : (mode==1) ? mode1 : (mode==2) ? mode2 : mode3

}

[Boulder]

Thanks a lot:)

[Fizick]

It is possible to interpolate not bidirectional, not only forward or backward (use onny one vector set)?
Or maybe not interpolate, but do partial (not full) compensation?
I want try do motion compensation from frame n+2 and frame n-2 to frame n, and use these 3 frames for spot removing. In this case bloches will not corrupt the motion vector in its places.

[violao]

Fizick, I tried this, but it seems that the risk of "wrong" vectors is much higher when you skip frames in vector search. Initially I tried to estimate unreliable vectors (under blotches) by using 3rd SearchMVs between (n-1) and (n+1), but it appears from my initial test that better estimation is obtained by interpolating from healthy neighbourhood vectors.

[Manao]

New version : MVTools 0.9.4 (http://jourdan.madism.org/~manao/MVTools-v0.9.4.zip)

Changelog :

* Vectors can be saved to a file. In order to do so, add the parameter filename="C:\foo.bar" to the filter MVAnalyse. If the file doesn't exist, vectors will be saved into it. If it exists, vectors will be read from it. But, be warned :
- The file for a whole movie will be around 500 MB
- Saving / reading from a file need for the moment a linear access to the frames, so it has to be used only when encoding the movie, not when doing random access in it.
- The speed gain is not as great as one may hope, because SADs can't be saved ( it would take too much space ) and so have to be recomputed.
* The filter MVDenoise now works on 5 frames, and its parameters are now "thT" and "sadT" ( have a look in the documentation to see how they work ). It works nice ( very good for heavy denoising )
* The scene change detection thresholds have slightly changed. Now, a block has changed if its SAD it over thSCD1. The default for thSCD1 is 300, and for thSCD2 it is 130. It orks well ( better than the previous SCD engine ).

I'll have to implement random access with writing / reading from a file.

I haven't got time to look at your different propositions. However, I think I'll try to add a parameter to MVAnalyse, in order to change the gap between the two frames that are analysed ( thus allowing what Fizick is needing ).

Also, if somebody has a useful motion vectors compression scheme to propose, I'm listening, because I think a 500 MB file is still to much. Right now, I'm using an adaptive huffman coding, with prediction from the previous block. With that, I get an entropy around 1.6 bits / vector coordinate ( and the mean deepness of the huffman tree that is built is 1.65, so an arithmetic coding would not improve things by much ).

The specification for the scheme are :
* higher compression ratio than my method
* high speed, both to code and to decode

[scharfis_brain]

I have lots of problems with mvtools:

- v0.9.4. doesn't work at all.
it always claims : genericmotionfilter needs yv12 (at the line with mvinterpolate, mvblur, mvconvertfps or whatever), but the source is already yv12

- v0.9.2.x the nb parameter is useless, I do not see any difference.
the motionblur isn't getting better with higher nb
this means, on high motion, the motionblur is always ghosted instead of being one connected smoothed area..


btw. IMO it would give a MUCH better motionblur, if the image gets blurred directionally using 'simple' pixel mixing instead of block moving.
I mean, if you could just blur the pixels underlying a vector(field) into its direction, it should be THE ultimative mvblurrer...

[Manao]

Scharfi : can you provide the scripts you used ? I think you're messing up with the vector's stream.
I mean, if you could just blur the pixels underlying a vector(field) into its direction, it should be THE ultimative mvblurrer...I don't think so. First, you would need to interpolate the vector's field for all pixels, which would be slow. Then, you would have to copy & move a pixel along its vector, which would mean interpolate its position for each time we copy it. Slow again. And finally, if the vector's field was diverging, you would get strange results ( blocks tend to lessen that issue, they don't solve it all )

[mg262]

Manao - thanks for the great tools.
_______________________

I'm trying to use the motion compensation to set up the context for a temporal blur as follows:

Get a frame order like this:

10, 8, 10, 9, 10, 10, 10, 11, 10, 12,
11, 9, 11, 10, 11, 11, 11, 12, 11, 13,
...
n, n-2, n, n-1, n, n, n, n+1, n, n+2

Then forward search + MVCompensate, and select the odd frames so you get

8, 9, 10, 11, 12 (all mocomped to match 10 as closely as possible)
9, 10, 11, 12, 13 (all mocomped to match 11 as closely as possible)
etc.

____________________________________

(Then you can apply any blur with radius two and throw away 4/5 of the frames.)

Unfortunately the results aren't great... looking at each run (e.g. 8,9,10,11,12), there doesn't seem to be less motion than in the original. The script is below and if anyone has any insights into what's going wrong I'd appreciate them...

(I have tried playing with the fth parameter. Also, the frame numbers coming out of the output are correct.) Have I understood forwards/backwards correctly? Flipping to backwards doesn't help...
________________________________________

o = last

Interleave( o, blankclip(o, 2) + o, o, blankclip(o, 1) + o, o, o, o, trim(1,0), o, trim(2,0))#, o, blankclip(o))

v = MVAnalyse(isb=false, fth=0 )
MVCompensate(last, v)

selectodd()

_____________________________________

By the way, I'm wasn't sure if this should be a new thread, but all the information on these filters seems to be here, so I've stuck with it...

Mohan

[sh0dan]

Wow - this is probably the best stuff I've seen released for ages.

It has a LOT of potential for framerate conversion, deinterlacing and denoising!

Wow! Great work!

@scharfi: You need to explicitly give the first video parameter, etc:
vec = mvanalyse(fth=30, isb=true)
mvshow(last, vec)
This is because the vector clip is optional, and therefore your vector information is assumed to be the clip you'd like to apply your motion stuff on.

A bit about the implementation (feel free to ignore)

- I really like the idea of having motion information as a clip.

- Forward backward considerations. It seems a bit strange you need to do both backward and forward prediction. Why not simply alsways do forward prediction, and request the previous (cached) motion frame?

- Binary format. A separate index file, and a motion vector file would probably be the nicest implementation. When frame 'n' is requested:

1) Check if present in index. If yes, read MV's from file.
2) Calculate MV's.
3) Append MV information to binary file.
4) Write index of frame 'n' to index file.

That way you only need to keep the index (two integers per frame) in memory, and you get random access.

[MfA]

Motion compensating using the per block forward motion vectors (in terms of the direction in time) from the last frame leaves gaps in the present frame if you try to reuse it ... which complicates things.

[sh0dan]

Oh, I see - it makes sense using current frame as reference to the previous.

I noticed a very slow, but also very good motion blur by using:
vec_back=mvanalyse(fth=30, isb=true)
vec_forw=mvanalyse(fth=30, isb=false)

MVConvertFPS(last, vec_back, vec_forw, fps=100, fbw=2, thSCD2=255, thSCD1=200)
temporalsoften(2, 255, 255, 0, 2)
selectevery(4,0)
Assuming 25fps material. Works very well for my CG material.

[scharfis_brain]

and again,a feature request:

I want to repair framedrops using this script: http://forum.doom9.org/showthread.php?s=&threadid=79771

but, mvinterpolate returns garbage when trying to interpolate the missing frame.

I am going this way:

for progressive Video:

normal Sequence:

A B C D E F G

framedrop at frame D

A B C C E F G

my function interpolates the 50:50 position between C & E, but somehow the C C E F sequence messes up mvinterpolate because C is a dupe.

the same with laced video:

normal Sequence:

Aa Bb Cc Cc Ee Ff Gg

here, I interpolate between c and E to get two frames with the weights
c*0.66+E*0.33 = D
and
c*0.33+E*0.66 = d

but like said before the dupes (or with interleced: forward-backwards stutter) makes mvinterpolate going messy.

would there be any solution for that?

maybe included in the plugin itself (dropped frames are almost indentcal, so detection is very easy!)

the function I posted in the thread works for some low motion video, but completely fails on high motion / short shutter speed video...

also burst framedrops (several framedrops in one sequence: A B C C C C G H) could be handled, too.

what do you think manao?

[Manao]

Detecting dup is fairly easy with the motion vectors and the sad. However, the rest of the processing would take a long time to code ( not complicated however ), and I don't have a much time as before ( internship, not a student anymore :( ).

I'm still working on the motion estimation ( I'm adding a padding of the reference frame, to better catch objects that come into the frame, as it is done in MPEG-4 ). Halfpel works again, it is faster than before ( fast enough to make useless the saving to file feature ), but no filter is using it yet.

[morsa]

Can this be thought in a more general way?
I mean, thinking about interpolating dropped frames, I got to the idea of interpolating missing frames from old films.
You know those portions of a film where 3, 5, 10, frames have been lost.In this case whe don't have a dupe frame, So I guess we should give the filter parameters like first frame, last frame and how many frames to be interpolated.
Is this posible?

At this moment we have:
DeScratch
Despot
Equlines
RemoveGrain
RemoveDirt

So what we lack is what Scharfis is asking (sorry Scharfis if I miss something)

[Manao]

morsa : it's already possible ( just not quite straightforward ) :
function MVInterpolateBetween(clip c, int "first", int "last", int "number")
{
number = Default(number, last - first)
beginbase = (first > 0 ) ? first - 1 : 0
endbase = ( last < framecount(c) ) ? last + 1 : framecount(c)

newfps = framerate(c) * number

beginning = c.trim(0, first)
ending = c.trim(last, 0)
base = c.trim(beginbase, first) + c.trim(last, endbase)

mvf = base.MVAnalyse(isb = false, lambda = 2000)
mvb = base.MVAnalyse(isb = true, lambda = 2000)

reconstructed = base.MVConvertFPS(mvb, mvf, fps = newfps)
\.trim(number + 1, 2 * number - 1).AssumeFPS(framerate(c))

return beginning + reconstructed + ending
}

Edited : first version was not working correctly.

[Dee]

to Manao: do you plan to release sources of most recent version (and future versions)?

[Wilbert]

What do you mean? The sources are included in 0.9.4.

[Manao]

I've released a testing version because E-Male was making a test between several temporal denoisers ( http://forum.doom9.org/showthread.php?s=&threadid=79706 ). But the code was being heavily modified at that time, so I decided not to release the source for that particular un'official' version. The next 'real' release will have the source code, of course.