deinterlace idea (for DV source mostly?)

[Terka]

look at:
http://forum.doom9.org/showthread.php?t=124486&highlight=terka
there is a clip:
http://rapidshare.com/files/25061661/Psi.rar
or
http://www.mytempdir.com/2047066


when tried different deinterlace methods (mcbobnnedi inclusive) on the clip, but some parts are really unstable (see the white car).
There is a idea similar to:
http://forum.doom9.org/showthread.php?t=96344&highlight=terka
(but not good results using this method)
--------------------------------------------------------------------------------------------
output will be 50p
some parts are not moving (eg. car), but handheld camcorder is.
together with interlace source this causes flickering, in this case
moving up/down.
Is it possible to select and calm these areas by making an some kind of "average" of these areas in time? This could be done similar like:
I know there is a vdub filter (anime) (cant remember the name), which takes 2 pictures and when they are "similar" <treshold, it makes them the same.
------------------------------------------------------------------------------------------
2nd: if the picture is jumping up/down-for those areas
could be used every even picture which replaces the odd.
OR when even pictures are much different, the odd ones can be interpolated (there are already "double fps" functions)
maybee this above is stupid? Thanks for reply. Terka

[smok3]

Get your own Premium-account now! Instant download-access! (Or wait 133 minutes)

i never downloaded anything from this sh*** host till now...

[Terka]

so where to post?

[ariga]

so where to post?

Sticky in General Discussion -> http://forum.doom9.org/showthread.php?t=96362

[Terka]

updated the first post
http://www.mytempdir.com/2047066

[yup]

Terka!
Try before bobing MVDepan with combing Depanstabilize. Problem only one borders.
yup.

[Terka]

yup, you think as the example on http://manao4.free.fr/mvtools.htm ?
------------------------------------------------------------------------------------------
To use MVDepan with Depan plugin (DepanStabilize function example):

vectors = source.MVAnalyse(isb = false)
globalmotion = source.MVDepan(vectors, pixaspect=1.094, thSCD1=400)
DepanStabilize(source, data=globalmotion, cutoff=2.0, mirror=15, pixaspect=1.094)
------------------------------------------------------------------------------------------

[Terka]

i tried settings above +yadifmod, and deinterlace artefacts appears

[foxyshadis]

What we got here is... failure to deinterlace. Some movies you just can't reach. So you get what we posted here today, which is the way he wants it... well, he gets it. I don't like it any better than you folks.

Home movies are some of the hardest to deinterlace because of all the handheld jitter. You can get rid of most of the combing by following it up with Vinverse() though, works very well with yadif and tdeint/tmm/nnedi.

[Didée]

The problem is not so much residual combing in the result. The handheld jitter is the main problem. And the bottom line is indeed, alas, "some movies you just can't reach".

The technical problem here is the "black hole" of deinterlacing, which appears when there is vertical motion with a speed of (close to) 1|3|5... pixels/field.
The effect is that MC tries to pull the missing information from the neighbor fields, but the neighbor fields miss the very same information when the vertical speed falls into the mentioned pattern.

The sad thing here is that there is pretty much of this worst-case kind of motion, due to the handheld jitter.

A (theoretical) possible approach is extending the temporal search range, i.e. to search not only the +/- 1 neighbor fields, but also the +/- 2,3,.. neighbors, and figure from which of them the most useful information can be obtained.
However, an actual implementation via Avisynth scripting would be complex beyond all reasonable bounds. Thinking about it is the only thing I dare to do ... implementing surely not. (0.001 fps scripts are quite un-handy during development, especially when lots & lots of try-and-error is involved.)

[2Bdecided]

If you nnedi, motion compensate, and merge 7 frames, it's still not right. As Didée said, the information just isn't there. Or if it is, the tools aren't smart enough to pull it out yet. If nnedi used ten frames instead of one field... ;)

Cheers,
David.

[Terka]

:thanks: you for reply!
yes, the problem is flickering caused by handheld.
what if not trying to restore the original=progessive (which could be impossible due to missing information),
BUT
trying to calm down the flickering using the method(s) i mentioned above (or some other). This will improve the quality and compressibility.

in this clip, there is not so big difference between mvbob,mcbob and yadif, so if we can spend cpu time on "calming".
could plese someone help with the "calm-deinterlace-flickering denoiser"
im asking about this, because i think many people using handheld DV as source.
PS:the filter i mentioned before is dup http://neuron2.net/dup/dupnew.html
:thanks: and :script: :script: :script:

[Terka]

the flickering parts will have flickering freqency 50hz, could this be useful for selecting them?

[Didée]

Strictly speaking, a frequency of 25Hz, not 50Hz. (Full oscillation period). And after bob-deinterlacing, that frequency might be just anything in the affected parts, not just a fix one.

Calming is an idea, but hardly less difficult. The crux is that the local difference is very *big* in the flickering spots, whilst denoisers rely on differences being *small* to assume that processing is safe. Allowing big differences to be temporally processed, detail loss and artefacts are almost guaranteed, because it's very difficult to tell the "good" differences (flicker) from the "bad" differences like false compensation.

Sidenote: MCBob could be easily modified in that direction - it often returns some residual flicker due to the need to be an "exact" bobber, i.e. to return the original fields unchanged. Allowing it to slightly change the original fields, too, the result usually is more stable, and processing speed is faster.

Sidenote #2: No need to cry "gimme, gimme!" - tried that already yesterday, and it doesn't help in this case here.

Getting the thing calm-by-any-means isn't a problem, though: something like FFT3D(sigma=100,bt=5) should give a pretty calm result ...

[Terka]

Didée,
sorry for crying. could you give an advice how to select the "flickering parts" using mask/mvtools?

[IanB]

I guess a solution is to upgrade to a camera with image stabilization technology.

However a drawback of this technology I have found is it stuffs doing pans. As you start your pan the camera compensates against you until it hits it edge limit, at which point the control circuitry becomes unstable and you get a jerk. Really good cameras work out you are panning and you only get the one jerk, others keep trying and continue to jerk.

[Didée]

sorry for crying
*hands over a handkerchief*

Alas, no. Off the sleeve, nothing occurs to me to detect exactly those areas and nothing else.

It's the old story - for human's eye it's an "easy" task, but behind the lines that involves extremely complex spatio-temporal interpretation, almost impossible to simulate with "simple" filters. Smells like a job for neural networks.

[Didée]

in this clip, there is not so big difference between mvbob,mcbob and yadif, so if we can spend cpu time on "calming".
Well, it depends on how you define "not so big difference". :)
Sure, in those problematic parts, even MCBob does show noticeable flicker. But overall,
trying to calm down the flickering using the method(s) i mentioned above (or some other). This will improve the quality and compressibility.
, MCBob shows once more that its temporal stability (and therefore compressibility) is remarkable:

Yadif(mode=1) - 49022 kB - 55449 kbit/s - 162.7 %
Tdeint(EEDI) - 45468 kB - 51428 kbit/s - 150.9 % # TDeint(mode=1, edeint=EEDIbob())
bob(0.0,0.5) - 38518 kB - 43564 kbit/s - 127.8 %
MVBob() - 35406 kB - 40042 kbit/s - 117.5 %
TDeint(mode=1) - 33864 kB - 38299 kbit/s - 112.3 %
MCBob() - 30220 kB - 34082 kbit/s - 100.0 %


Explanation: I encoded the various deinterlacers with Xvid at quant=3, using a high-bitrate matrix (flat-8), without Bframes.
It's not an exact science, but gives a reasonable hint about temporal stability (or "flickering"): the bigger the result, the more flicker was in the source. The smaller the result, the better the temporal stability.

It's a (pretty poor!) attempt to substitute for something that we don't have at all: a metric that considers the temporal aspects of a source. Metrics for analyzing we have plenty, but they all work purely spatial. But temporal relations are important too - especially for video codecs that use delta differences ...

[Terka]

when encoded using q3, h236, qpel
mcbob-nnedi.avi 13131178
mvbob-nnedi.avi 12635796
mvbob.avi 14130986
yadif-nnedi.avi 14913918
so the difference is few %
same for huffyuv.
------------------------------------------------------------------------------------------

Sidenote: MCBob could be easily modified in that direction - it often returns some residual flicker due to the need to be an "exact" bobber, i.e. to return the original fields unchanged. Allowing it to slightly change the original fields, too, the result usually is more stable, and processing speed is faster.
Will you show the code?
------------------------------------------------------------------------------------------
btw: on my c2d 6750
fps time/s time increase/s size(huff) size increase/% cpuusage
yadif-nnedi 50 92 165167 95%
MVbob() 50 220 139% 168834 2% 50%
MVbob-nnedi() 50 190 107% 169193 2% 50%
MCbob-nnedi() 50 330 259% 169854 3% 90%
mvbob shows only 50%cpu load and mvbob-nndi is slightly faster than mvbob

[Terka]

its interesting, that when used huff, than yadif is the smallest, when xvid mcbob.
and the cpu load for mvbob only 50%

[Didée]

its interesting, that when used huff, than yadif is the smallest, when xvid mcbob.

Not very surprising. Huffyuv compresses only spatial, where compression of mpeg-codecs has a strong temporal part.
When Huffyuv is smaller, the single frames have more spatial redundancy (or 'predictability'), i.e. "less detail".
When Mpeg is smaller, it's because the temporal correlation between frames is better (the codec can make better matches through motion compensation), which in this case is an indicator for temporal stability, or "flicker".

[Terka]

Didée, could you please type the code for:
Sidenote: MCBob could be easily modified in that direction - it often returns some residual flicker due to the need to be an "exact" bobber, i.e. to return the original fields unchanged. Allowing it to slightly change the original fields, too, the result usually is more stable, and processing speed is faster.

last week i tried different things using AVSP to calm the flicker, but not much sucessful.
its not easy for me to select the small areas, replacing them with
duplicities or averaging them is easier.

[Didée]

Ah, sure.

http://img209.imageshack.us/img209/1711/changeslo3.png (http://imageshack.us)

But that's only for improving on some general very slight shimmering, usually caused by detail of very high frequency.
For what you are dreaming of, this probably won't help very much.

You might also try Mencoder's "mcdeint" with multi-reference motion search. Can't tell if that improves in this case (I doubt it), however multi-referencing is the basic trick that should be done.

[Terka]

Didée, thank you.
could you help me with selection of the areas, which have the motion vectors "small", you know what i mean.

[foxyshadis]

Look at the docs for mvmask.

[Terka]

tried calm down the "flicker" on MVbob's source like this:
backward_vec = source.MVAnalyse(isb = true, truemotion=true, pel=2, idx=1)
forward_vec = source.MVAnalyse(isb = false, truemotion=true, pel=2, idx=1)
source.MVFlowFps(backward_vec, forward_vec, num=100, den=1, ml=100, idx=1) # get 50 fps
SelectOdd()

after encoding to xvid Q2 got results:
mvbob only: 19,8MB
mvbob+script: 14,3MB
of course the frames are not the same:
orig:
X X X X
new=interpolated="shifted in time":
_N N N N
so now i want to make a mask for "flickering areas" and join the
sources together

[2Bdecided]

I would feel really uncomfortable running that over my video unless I had good reason to. The kind of artefacts MVFlowFps can introduce are far worse than a 1-line flicker. With fast movements the results can be fairly disastrous.

I guess if you can make a perfect mask you could largely avoid this, but if not...

Cheers,
David.

[Didée]

As you say. Seems not like a very promising approach. I'd rather try something like MVanalyze on a vertically median-clipped MxBob, compensate the original bob with distances of +/- 1, 2, and (maybe) 3 frames, check the compensations with disregard to one-pixel vertical deviations (code for that is already in MCBob), then use the remaining diff as pfclip for ttempsmooth when averaging all compensations together.
No guarantee that this would work out in practice, but to me it seems like an obvious approach to tackle the problem.

"Oh, could you..."

Sorry no, currently not. Right now I'm fighting with a larger paid job having a tight deadline. Next two weeks are full to the brim.
Besides, the problem is there for many many years ... no need to rush a solution NOW, come hell or high water. It won't run away.

[Terka]

im working on this to learn avisynth a bit.
>i want to make a mask for "flickering areas"=STATIC and join the
sources together. So the MVFlowFps artifacts probably will not be so bad. in mcbob are already "static" areas used.

Didée, thanks, ill try to understand the mcbob.

[Terka]

it too difficult for me to create good mask using mvmask.
could someone help to select only "static parts"?

[Didée]

Had a little time during lunch break today. It's not an approach that juggles around with MV-masks and stuff ... it's more a brute-force denoising after MCBob.

Two encodes of your 'Psi' clip:

http://rapidshare.com/files/71465351/Psi_encodes.rar.html

One is "standard" MCBob, the other is modded MCBob (returning just "repaired" internally) plus more compensated temporal averaging. Script is in the RAR.
Note the filesizes - with 6of9 @ q3, the 2nd one is 50% smaller...

Dunno if this suits your needs, however it was easy to script. ;)

[Terka]

Thanks Didée!
I must have a closer look at it script/result! Ill download it as soon as i get home from work.
imho: this "de-shimmer" is different to all denoisig filters logic:
Not blur, but change parts of the source alot. Thats why i tried to interpolate="morph".

[Terka]

Didee,
thank you, the results are really good-specially the size decrease.
The picture is much less flickering, but some details are lost.
Fast moving object are disappering. Maybee for perfect issue solving some special filter not yet done is needed. :thanks: a lot Terka

[Terka]

Hi,
tried played a bit with avisynth:
idea was:


x x x_x_
x x _x_x
x x (1) x_x_
x x ---> & _x_x
x x x_x_
x x _x_x
input: interlaced video
(1) got 2 videos: separatefields().selecteven(), separatefields().selectodd()
(2) for every from theese "progressive" videos, compute "missing" frames "m"
using mvtools
xmxm
mxmx
xmxm
& mxmx
xmxm
mxmx

(3) got final_even and final_odd frames

xx mm
mm xx
xx mm
mm xx
xx mm
mm xx

(4) join them together
xmxm
mxmx
xmxm
mxmx
xmxm
mxmx
xmxm





true_interlaced=avisource("c:\hj\Psi.avi").Crop(100,100,-40,-400)
input=true_interlaced.SeparateFields().ocisluj()

dopoc_odd=input.Selecteven().DoubleFramerate().Selectodd()
odd=input.selectodd()
finalni_even=interleave(dopoc_odd,odd).weave().AssumeFrameBased()

dopoc_even=input.SelectOdd().DoubleFramerate().Selectodd().duplicateframe(0)
even=input.selectEven()
finalni_odd=interleave(dopoc_even,even).weave().AssumeFrameBased()
###############################################################
finalni_video=Interleave(finalni_odd,finalni_even)
finalni_video
finalni_even
finalni_odd
stackvertical(finalni_VIDEO,finalni_ODD.Selectevery(1,0,0),finalni_even.Selectevery(1,0,0))


#######################
function DoubleFramerate (clip c)
{
#To double fps with MVFlowFps for 'best' results (but slower processing):
backward_vec = c.MVAnalyse( isb = true, pel=2, search=3, idx=1) #pel 2 +-ok pel 1 rozmazne
forward_vec = c.MVAnalyse( isb = false, pel=2, search=3, idx=1)
c.MVFlowFps(backward_vec, forward_vec, num=2*FramerateNumerator(c), den=FramerateDenominator(c), idx=1)
}

function ocisluj (clip c)
{
ShowFrameNumber(c,x=10, y=25, font="arial", size=24, text_color=$c00000)
}

function DuplicateLastFrame (clip c)
{
DuplicateFrame(c,Framecount(c))
}


i got 2 smooth videos, but when i interleave them together,
it looks not ok.
can someone give me some suggestion?

[scharfis_brain]

I tried exactly the same several years ago.
I has to FAIL, cause the reference to the intermedia field is missing.
I only works for LINEAR motion such as continiuos pans.
everything else just fails and shows weird combing.

[Terka]

Sharfi, thanks for reply.
1.)
i understand your reply like this:
o=object on screen moving from AtoB and slowing down:

Ao o o oB
x-mvcompensated object (is in middle between o and o):
Ao x o x oxoB

but should be
Ao x o x oxoB
because is slowing down


2.)
my question was about:
finalni_video is not ok, but
finalni_even and finalni_odd separately looks good.
thats why i tried the
stackvertical(finalni_VIDEO,finalni_ODD.Selectevery(1,0,0),finalni_even.Selectevery(1,0,0))
stuff

3)
as far i understand, this method produces x-axis error, while
interframe method (hope its correct) like bob(), nnedi y-axis error (or time error if you want)
maybee put this together could help somehow?
on static areas this above should be ok. no shimmer.
could you explain me a bit how the "corrector" works?

4)ive tested many deinterlacers, tried to understand the way mvbob and mcbob works. not much sucessfully. for me looked
mvbobmod from pate15 page a bit better than the mv/mcbobers.

[Didée]

First, the statement "it has to FAIL" is too definite. MCBob uses exactly this kind of interpolation, and IIRC the results are not too bad. ;)


Small scenario:
At Bt Ct
-- -- --
Ab Bb Cb At/Bb/Ct are the original fields, Ab/Bt/Cb are what a bob filter has to create.

Assuming we want to create the missing field Bt with MVTools, there are two possible approaches:

(1) Search vectors for At --> Bb and Bb <-- Ct, make compensation with those vectors

(2) Search vectors At<-->Ct, make compensation with 50% of vectors' length

Method (1) is what MVBob uses, method (2) is used by MCBob.
Without going into the countless details and small tidbits that have to be considered, the basic characteristics of these two methods are these:

(1) has a higher probability of the compensation being successful. But even if the compensation is successful, it has a lower probability of putting new information into the field to be constructed.

(2) has a lower probability of the compensation being successful. But if the compensation is successful, it has a higher probability of putting new information into the field to be constructed.

The drawbacks IMO are quite obvious:

Method (1) can rather easily deliver compensations that are "correct", since the compensation is made against a fixed reference. But: The reference is what we already have. That's why this method tends to just re-create the information that we already have, instead of bringing new information into a frame.

Method (2) might fail because it often creates the wished result, but at the wrong moment-in-time.

Or, even shorter: Method (1) suffers mostly from spatial uncertainty. Method (2) suffers mostly from temporal uncertainty.


Thus trying to answer you Q's:

re 1.)
Simplyfied, but correct. The same-parity + Flow method creates a result in the (linear) middle between two fields. But since motion often isn't linear, the infact wished result might not be in the middle (50%), but perhaps at 42%, at 56%, at 15% or at 87% ...

re 2.)
Continuation of the answer to 1.) ... Sure, if you look just at the raw interpolations, they look okay. An interpolation that was created at a wrong point-in-time looks good on its own. But it can't look good when the wrong-timed interpolation is weaved together with the original field.

re 3.) .. ( > "as far i understand, this method produces x-axis error," )
Not only. The possible error is always in the direction of present motion. If you observe video with lots of left-right-panning, then yes, you will encounter mostly "x-axis errors". But motion can be in any direction. If you film a ball that is falling down to earth, then you'll get "y-axis errors" from this method.


Related to "Corrector()":

Corrector() basically deals for finding if frame A is similar enough to frame B to be considered correct. However the comparison is not made between A and B, but between modified versions A' and B' ("analyse" frames).
For creation of missing fields, this is only of limited use. When compairing compensations to the reference, Corrector favors the most similar compensation. The point is, in the interesting spots (those that contain "detail"), there is a "big" difference between top-field and bottom-field. Moreover, it's exactly this difference that we want to get: this difference is the "additional information" that we want to get from the neighbor fields.
Corrector() isn't the most suited way to deal with this fact, that's why MCBob doesn't use it, and all error correction is done manually instead.


A theoretical approach:

1) do the same-parity motion search of method (2) above
2) follow the "path" of a motion vector, and figure at which point on the way there is the best correlation to the (other parity) reference field, with zeroing-out of 1-pixel-heigh vertical differences.

... which would be very computationally expensive.

-----

And all of this was merely some light scratching on the outmost hull. When you go deeper and discover/realize all the small problems that can potentially arise, you'll find that you're doing a blindfolded walk through a forest of thornes.
Building the ultimate "perfect bob filter" is similar likely than building a perpetual motion machine.


... And at the end of the day, it always boils down to this:

- you want to re-create missing information.

- in the process of doing so, you need to make decisions.

- decisions might be correct or wrong. Chances of guesswork usually are fifty-fitfy.

- to ensure that the correct decision is made, you would need to already know the information that you are searching.

- since you don't (a priori-) know the information that you are searching, you're back to guesswork...

Catch 22, the cat bites its tail, vicious circle ... however you want to name it.

[Terka]

Didee,
thank you for comprehensive reply.
re 2.)
of course the errors appears when weaving.
BUT
the problem i was speaking about is not about WEAVE, but in INTERLEAVE
finalni_video=Interleave(finalni_odd,finalni_even)
thats why i tried
stackvertical(finalni_VIDEO,finalni_ODD.Selectevery(1,0,0),finalni_even.Selectevery(1,0,0))
to compare "the same" frames.
But it looks to me that they are not, that interleaveve behaves
somehow strange. Try yourselve.
------------------------------------------------------------------
to the two possible approaches:
the method 1)
you mean

from
At Bt Ct
-- -- --
Ab Bb Cb
got
At Bt Ct
-- AB -- BC --
Ab Bb Cb
and make another compensation for AB - BC
to get BF (final):
At Bt Ct
-- BF --
Ab Bb Cb
(because AB, AC are on wrong position like you said:
"Method (2) might fail because it often creates the wished result, but at the wrong moment-in-time."
btw. have you seen the mvbobmod at
www.pate15.de/entrelacement/entrelacement_5.htm

[Didée]

Ah, now I see ... you have an idx-error in your script. The function 'DoubleFramerate()' uses a *fixed* number: idx=1. But you're applying the function to two different clips: one time to "input.selecteven()", and one time to "input.selectodd()". Because of the fixed idx, when you call DoubleFramerate() the 2nd time, it uses the subpel interpolation from the 1st call. This of course is plain wrong.

Your scripts from above, changes for correct idx handling in red:
(Note I did not check the script as a whole for correctness, only the idx handling.)
true_interlaced=avisource("c:\hj\Psi.avi").Crop(100,100,-40,-400)
input=true_interlaced.SeparateFields().ocisluj()

dopoc_odd=input.Selecteven().DoubleFramerate(_idx=1).Selectodd()
odd=input.selectodd()
finalni_even=interleave(dopoc_odd,odd).weave().AssumeFrameBased()

dopoc_even=input.SelectOdd().DoubleFramerate(_idx=2).Selectodd().duplicateframe(0)
even=input.selectEven()
finalni_odd=interleave(dopoc_even,even).weave().AssumeFrameBased()
###############################################################
finalni_video=Interleave(finalni_odd,finalni_even)
finalni_video
finalni_even
finalni_odd
stackvertical(finalni_VIDEO,finalni_ODD.Selectevery(1,0,0),finalni_even.Selectevery(1,0,0))


#######################
function DoubleFramerate (clip c, int "_idx")
{
#To double fps with MVFlowFps for 'best' results (but slower processing):
backward_vec = c.MVAnalyse( isb = true, pel=2, search=3, idx=_idx) #pel 2 +-ok pel 1 rozmazne
forward_vec = c.MVAnalyse( isb = false, pel=2, search=3, idx=_idx)
c.MVFlowFps(backward_vec, forward_vec, num=2*FramerateNumerator(c), den=FramerateDenominator(c), idx=_idx)
}

function ocisluj (clip c)
{
ShowFrameNumber(c,x=10, y=25, font="arial", size=24, text_color=$c00000)
}

function DuplicateLastFrame (clip c)
{
DuplicateFrame(c,Framecount(c))
}

[Terka]

Didee, thank you, you know im real beginner to programming.
But still cant pass the number to the function.
I think i can add 2nd same function DoubleFramerateOdd DoubleFramerateEven with fixed param., but this is unhandy.

[Didée]

Sorry, I forgot to put the function parameter in quotes (to make it work as "named" argument).

Script above has been corrected.

[Terka]

its working now.
but still the behaviour of
finalni_video=Interleave(finalni_odd,finalni_even)
is not correct. The interleave is somehow wrong.
below you can see same frame from:
2 sources:
finalni_video, finalni_odd.
They have to be the same because of interleve, but they are not.
http://img507.imageshack.us/my.php?image=interleavedideeal0.png

[Didée]

It's quite possible that something's going wrong along the lines of interleaving / selecting / weaving, and you'd need a few AssumeXFF() here and there ... those are the things I don't pull out of the sleeve in the middle of the night (I'm not scharfis_brain:p).

Perhaps I can look in a few hours at it - unless you figured it by yourself until then.

[mikeytown2]

Here's my 5AM idea for deinterlacing :confused:

Split clip into 2 clips: even & odd
Stabilize clips so vast majority of pixels line up
Process even and odd with something like MSU Frame Rate Conversion Filter to get 2x Frame rate
Now we have 2 clips with double the frame rate, but they should be mirroring eachother
Compare differences between original even frames and "Filler" odd frames, as well as odd frames and "Filler" even frames
Select smoothest path and recombine

By doing this it may not be exactly what happened, but it might look good. Probably not the best idea I've come up with recently.

[Terka]

odd is ok
even is ok
Interleave(odd,even) is not ok. :devil:
both are after AssumeFrameBased()

[scharfis_brain]

assumeframebased() always resets the fieldorder to BFF.
You need to set it via assumetff() if the source is tff

[Terka]

but both odd, even are full=frames (after computed the missing lines), so AssumeFrameBased is not needed.

[Terka]

in my script i got 2 videos: even, odd.
the only thing i need to is interleave them.
in the script it is not working. BUT
when i save the 2 videos separately as:
even
odd
and in new *.avs join them together: using Interleave - its ok.
???strange??

[Didée]

Well, I forgot one more "idx=_idx" in the last script I posted - now it's finally correct (hopefully), so try again.

What bugs me more is that MVFlowFPS sometimes produces bad results for no obvious reason.

Quickly put together the following script, to have easy traceable content:
(yeah, the script is ugly, no need to tell)

base = blankclip(width=704,height=576,pixel_type="YV12",fps=50.000,color=$408080)
base = base.subtitle("This is some scrolling text ...",size=40,x=128,y=528)


interleave( base, base.crop(0,16* 1,-0,-0).addborders(0,0,0,16* 1,color=$408080),
\ base.crop(0,16* 2,-0,-0).addborders(0,0,0,16* 2,color=$408080),
\ base.crop(0,16* 3,-0,-0).addborders(0,0,0,16* 3,color=$408080),
\ base.crop(0,16* 4,-0,-0).addborders(0,0,0,16* 4,color=$408080),
\ base.crop(0,16* 5,-0,-0).addborders(0,0,0,16* 5,color=$408080),
\ base.crop(0,16* 6,-0,-0).addborders(0,0,0,16* 6,color=$408080),
\ base.crop(0,16* 7,-0,-0).addborders(0,0,0,16* 7,color=$408080),
\ base.crop(0,16* 8,-0,-0).addborders(0,0,0,16* 8,color=$408080),
\ base.crop(0,16* 9,-0,-0).addborders(0,0,0,16* 9,color=$408080),
\ base.crop(0,16*10,-0,-0).addborders(0,0,0,16*10,color=$408080),
\ base.crop(0,16*11,-0,-0).addborders(0,0,0,16*11,color=$408080),
\ base.crop(0,16*12,-0,-0).addborders(0,0,0,16*12,color=$408080),
\ base.crop(0,16*13,-0,-0).addborders(0,0,0,16*13,color=$408080),
\ base.crop(0,16*14,-0,-0).addborders(0,0,0,16*14,color=$408080),
\ base.crop(0,16*15,-0,-0).addborders(0,0,0,16*15,color=$408080),
\ base.crop(0,16*16,-0,-0).addborders(0,0,0,16*16,color=$408080),
\ base.crop(0,16*17,-0,-0).addborders(0,0,0,16*17,color=$408080),
\ base.crop(0,16*18,-0,-0).addborders(0,0,0,16*18,color=$408080),
\ base.crop(0,16*19,-0,-0).addborders(0,0,0,16*19,color=$408080),
\ base.crop(0,16*20,-0,-0).addborders(0,0,0,16*20,color=$408080),
\ base.crop(0,16*21,-0,-0).addborders(0,0,0,16*21,color=$408080),
\ base.crop(0,16*22,-0,-0).addborders(0,0,0,16*22,color=$408080),
\ base.crop(0,16*23,-0,-0).addborders(0,0,0,16*23,color=$408080),
\ base.crop(0,16*24,-0,-0).addborders(0,0,0,16*24,color=$408080),
\ base.crop(0,16*25,-0,-0).addborders(0,0,0,16*25,color=$408080),
\ base.crop(0,16*26,-0,-0).addborders(0,0,0,16*26,color=$408080),
\ base.crop(0,16*27,-0,-0).addborders(0,0,0,16*27,color=$408080),
\ base.crop(0,16*28,-0,-0).addborders(0,0,0,16*28,color=$408080),
\ base.crop(0,16*29,-0,-0).addborders(0,0,0,16*29,color=$408080),
\ base.crop(0,16*30,-0,-0).addborders(0,0,0,16*30,color=$408080),
\ base.crop(0,16*31,-0,-0).addborders(0,0,0,16*31,color=$408080),
\ base.crop(0,16*32,-0,-0).addborders(0,0,0,16*32,color=$408080) )
AssumeTFF()

vid_50p = last.assumefps(50.0).AssumeFrameBased()

vid_50i = SeparateFields().SelectEvery(4,0,3).Weave()

#-----------------------

source = vid_50i
source

true_interlaced = last # avisource("c:\hj\Psi.avi").Crop(100,100,-40,-400)
input=true_interlaced.SeparateFields()#.ocisluj()

dopoc_odd=input.Selecteven().DoubleFramerate(_idx=1).Selectodd()
odd=input.selectodd()
finalni_even=interleave(dopoc_odd,odd).weave().AssumeFrameBased()

dopoc_even=input.SelectOdd().DoubleFramerate(_idx=2).Selectodd().duplicateframe(0)
even=input.selectEven()
finalni_odd=interleave(dopoc_even,even).weave().AssumeFrameBased()
finalni_video=Interleave(finalni_odd,finalni_even)
###############################################################
#finalni_video
#finalni_even
#finalni_odd
#stackvertical(finalni_VIDEO,finalni_ODD.Selectevery(1,0,0),finalni_even.Selectevery(1,0,0))

#stackhorizontal(finalni_video.info(),vid_50p.info())
stackhorizontal(finalni_video.subtitle("50i to 50p using MVFlowFPS"),vid_50p.subtitle("50p source"))

return( last )
##############


#######################
function DoubleFramerate (clip c, int "_idx")
{
#To double fps with MVFlowFps for 'best' results (but slower processing):
backward_vec = c.MVAnalyse( isb = true, truemotion=true, pel=2, overlap=4, search=2, searchparam=8, idx=_idx) #pel 2 +-ok pel 1 rozmazne
forward_vec = c.MVAnalyse( isb = false, truemotion=true, pel=2, overlap=4, search=2, searchparam=8, idx=_idx)
c.MVFlowFps(backward_vec, forward_vec, num=2*FramerateNumerator(c), den=FramerateDenominator(c), idx=_idx)
}

function ocisluj (clip c)
{
ShowFrameNumber(c,x=10, y=25, font="arial", size=24, text_color=$c00000)
}

function DuplicateLastFrame (clip c)
{
DuplicateFrame(c,Framecount(c))
}

Which produces nothing but some scrolling text. When stepping through the frames, results are quite mixed:

almost good ... http://img172.imageshack.us/img172/4899/almostgoodrf3.th.png (http://img172.imageshack.us/my.php?image=almostgoodrf3.png)

pretty bad ..... http://img181.imageshack.us/img181/47/verybadzs6.th.png (http://img181.imageshack.us/my.php?image=verybadzs6.png)

I played with the various parameters of MVAnalyse and MVFlowFPS, but to no avail. The appearance of errors changes, but basically I get always that mixture of "almost good" and "very bad" interpolations from MVFlowFPS. Bummer.

Seems like an MVTools bug ...

[Terka]

yes, the _idx was the issue.
Ive seen similar "bad" interpolation. Lets report it to Fizick..