MoComped deinterlace... don't know why i didn't think of this approach before.

[Mug Funky]

just had a flash of inspiration. it's obvious, really.

the main problem with making a motion compensated deinterlacer with MVtools is you need a good bob to start with, and if you work just with separated fields, the compensation screws up the half-pixel offset that odd and even fields have.

so...

i wondered what would happen if i motion-compensated field-separated video, but got my vectors from a bob?

the result is pretty good! to make things smoother, i've use forward and backward compensation and mixed them together.

it runs surprisingly fast.

however...

there's no protection from bad matches at this very early stage (this can be added pretty easily, but i can't be arsed doing it now - i want this script's concept tested first).

also, chroma doesn't get compensated at the moment (i've just used MVcompensate as is). this could be added as well, or you could do it manually by using my script on 3 clips, Y, U, and V.

here's the script:
function MVbob(clip c)
{
order=(c.getparity==true)? 1:0

bobd=c.kernelbob(order=order).verticalreduceby2()
fields=c.separatefields()
mvf=bobd.mvanalyse(sx=4,sy=4,pel=1,isb=false)
mvb=bobd.mvanalyse(sx=4,sy=4,pel=1,isb=true)

even1=c.separatefields().selecteven()
odd1a=fields.mvcompensate(mvf).selecteven()
odd1b=fields.mvcompensate(mvb).selecteven()
odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)

even2=c.separatefields().selectodd()
odd2a=fields.mvcompensate(mvf).selectodd()
odd2b=fields.mvcompensate(mvb).selectodd()
odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd1b,0.5)

even=interleave(even1,odd1).weave()
odd=interleave(even2,odd2).weave()

interleave(even,odd)
}

hopefully this can give some other people ideas on how to prevent errors leaking through, because as it is now, this script should not be used if you want a good result :)

[edit]

hehe... this thing eats camera pans for breakfast! all it needs is a few kinks ironed out and it'll be rocking.

[scharfis_brain]

wow!
this thing is really cool!
and it is fast!

but it suffers from mvtools lacking sub-pixel accuracy.
manao? will this feature be included in one of the future versions?

could it be combined with this experimental global-motion-compensated deinterlacer?


avisource("doom9.avi").assumetff()
bob()
showframenumber(scroll=true)
i=converttoyv12()
m=depanestimate(i,zoommax=1,improve=false,pixaspect=0.94)
i.DePanInterleave(data=m,pixaspect=0.94,prev=1,next=0)
separatefields()

selectevery(8,0,3,5,6)
weave()
stackhorizontal(last.subtitle("depan-bob"),i.subtitle("bob()"))

[scharfis_brain]

I played with mug funky's mvbob() a little bit, and found how to add some little subpixel accuracy:

function MVbob1(clip c)
{
order=(c.getparity==true)? 1:0

bobd=c.kernelbob(order=order,threshold=8).verticalreduceby2().lanczos4resize(c.width,c.height)

fields=c.separatefields().tomsmocomp(-1,-1,0)
mvf=bobd.mvanalyse(sx=4,sy=4,pel=1,isb=false,lambda=2000)
mvb=bobd.mvanalyse(sx=4,sy=4,pel=1,isb=true,lambda=2000)

even1=c.separatefields().selecteven()
odd1a=fields.mvcompensate(mvf).selecteven()
odd1b=fields.mvcompensate(mvb).selecteven()
odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)

even2=c.separatefields().selectodd()
odd2a=fields.mvcompensate(mvf).selectodd()
odd2b=fields.mvcompensate(mvb).selectodd()
odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd1b,0.5)

even=interleave(even1,odd1.separatefields().selecteven()).weave()
odd=interleave(even2,odd2.separatefields().selectodd()).weave()

interleave(even,odd)
}

it works with edge-directed upsampled fields now
first I tried a pure kernelbob, but its jaggy output made the MC going worse. so I decided using verticalreduceby2.lanczos4

this mvbob1 has the downside, that small movements tend to produce slight bobbing, but the overall quality is better, cause now its has the double pixel accuracy.

[Manao]

Yes, I plan to make a release tomorrow, and half pixel search will be working correctly. I'll disable the motion interpolators ( I'm currently rewriting it, because they were more than a mess ). It just misses the documentation right now.

However, you'll need to change the syntax a little.

[Mug Funky]

thanks, scharfi... the idea was frighteningly obvious, no? :) i initially tried using dumb bob, but this would hit unmoving areas. leak's optimised kernelbob is almost as fast and doesn't suffer from that.

now what's needed is some sanity-checking in it. this will involve masking, and will probably slow it down a fair amount. right now it isn't so good with scenechanges, and as you say suffers from lack of subpel accuracy (though if you're downscaling the output it isn't really a big deal).

manao: thanks again for MVtools, masktools, etc. it's scary how useful these tools are :)

[edit]

scharfi: if you're upscaling, you should probably make the blocksize 8 to avoid too much jumping around of the vectors.

[Chainmax]

Have you tried using TDeint's bobber instead?

[Mug Funky]

didn't see much difference...
considering i want to wrap this thing in masks to stop false-matches coming through, i chose kernelbob for a tradeoff between speed and accuracy on static areas (the dumb-bob shimmer gets confused with motion, so we can't be having that).

[Chainmax]

Didn't Leak say some time ago that his KernelBob had a bug?

[Mug Funky]

well, i haven't noticed... maybe it's a chroma thing? the output is sufficient for this script, and it's definitely fast enough :)

any bugs on the bob stage will be outshone by artefacting in the deinterlace. (though now manao's released a new MVtools i can go down to half-pel).

[Didée]

:D No intention to be penetrant, but the method reminds me a little of a comment in this (http://forum.doom9.org/showthread.php?s=&threadid=81430) thread:

Originally posted by Didée, 2 months ago

What about te following:

Generally:

- Make a *soft* bob, e.g. TMCbob with "line averaging" active
- calculate fw & bw vectors
- selecteven/selectodd those vector clips
- apply MVCompensate to the original top/bottom field sequences, using those "decimated" vector clips, producing fw and/or bw compensated fields
- try and see if those can be used as-is, or if averaging fw(n-1) with bw(n+1) is better, or ...

Basically, here it is a problem that the vectors are created on a bobbed source with lack of vertical information, thus making the vertical coordinates of the vectors unprecise.
However, using a soft bobber should already dim the problem down. Additionally, one could try either of the following:

- Take the soft-bobbed clip, reduce its height by 2, then calculate the vectors
- Take the soft-bobbed clip, sharpen it vertically, calculate the vectors, apply ^^above procedure on the fields with point-resized doubled height, and reduce them again afterwards

... or something similar.

Vertical precision *might* be a problem, but it should be possible to make it minor enough. The vector lenghts, however, would be correct.

I suppose it could work. Or someone tell me why it obviously can't work.

As long as the idea survives ;)

BTW, what about working on double-height fields and reducing 'em afterwards, instead of VerticalReduce'ing the bobbed clip? I'm under the impression MVanalyse's results get better with increasing framesize.

[scharfis_brain]

TW, what about working on double-height fields and reducing 'em afterwards, instead of VerticalReduce'ing the bobbed clip? I'm under the impression MVanalyse's results get better with increasing framesize.

ermmm....

Did you read my 2nd post of this thread?
(verticalreduceby2() afterwards will only blur and return vertically mis-aligned fields)

[Didée]

ermmm ... ;)

Did you read my post carefully enough. I spoke of reducing the double-heighted fields. This wording leaves room - and so it was intended - for an arbitrary operation. I did not speak of applying VerticalReduceBy2() on them ...

But now I realize I just did it again. I dared to speak about deinterlacing. Heaven help, when will I finally learn to seal my mouth on this topic :D

[Leak]

Originally posted by Chainmax
Didn't Leak say some time ago that his KernelBob had a bug?

Well, I'm not doing an AssumeFrameBased at the end, which makes it different from Scharfis_Brain's original KernelBob, but after some discussion it turned out to rather be a feature than a bug, and if you like the old behaviour you can just add the AssumeFrameBased after KernelBob and it'll act the same.

So, no, it's not neccessarily a bug. :)

np: Faction - And Not Very Transparent (Intelligent Toys 2)

[Mug Funky]

aaaah, i remember reading that post, didee... must have sunk into the bottom of my mind and jumped out again :)

still, the script's out there, so it's all good. feel free to hack at it (it really needs some kind of protection against blocking).

the half-pel search of the latest MVtools helps it quite a lot - near-horizontal lines are less wibbly.

Leak: good to hear there's no bug. i certainly never saw a difference, but i may have missed something because the frames were going by so much quicker with your version :)

[Leak]

Originally posted by Mug Funky
Leak: good to hear there's no bug. i certainly never saw a difference, but i may have missed something because the frames were going by so much quicker with your version :)

*g*

Well, you could consider it a bug as without the AssumeFrameBased you can't really use SeparateFields on the output, but as I said, some people thought it should work that way, so I kept it.

np: Triola - Neuland (Im Fünftonraum)

[scharfis_brain]

exept of some minor glitches with heavy, non estimateable motion, this mvbob() rocks.

here are some sample images:

http://home.arcor.de/scharfis_brain/mvbob/038-doublweave.jpg
http://home.arcor.de/scharfis_brain/mvbob/038-kernelbob.jpg
http://home.arcor.de/scharfis_brain/mvbob/038-mvbob.jpg


http://home.arcor.de/scharfis_brain/mvbob/674-doubleweave.jpg
http://home.arcor.de/scharfis_brain/mvbob/674-kernelbob.jpg
http://home.arcor.de/scharfis_brain/mvbob/674-mvbob.jpg

I additionally included a weaved image to show the amount of interlacing.

[morsa]

could this be adapted to output 25 fps for Pal and 30 for NTSC ?
May be I'm really lost.....Scharfis.....!!

[scharfis_brain]

just place selecteven() after calling mvbob1()

this little function Mug Funky gave us, is able to make interlaced video looking more like it has been filmed as progressive :)

[joshbm]

@scharfis_brain:

I've tried mvbob1() and it appears to give very rigid looking output. While mvbob() works quite nicely. Any ideas?

Regards,
Josh

[Mug Funky]

scharfi: i was hoping you'd try it out on that clip :) it's a pretty good benchmark for deinterlacers.

could it possibly be uploaded somewhere? i suppose anything with pans and stuff would work.

[edit]

MVcompensate's syntax has changed, and kinda broken my script (it stores compensation off the original clip now in it's default mode). here's an updated one.

using blksize=4 and pel=2 makes things very slow, but quite delicious :)

function MVbob(clip c,int "blksize", int "pel", int "lambda")
{
order=(c.getparity==true)? 1:0

blksize=default(blksize,8)
scd=(blksize==8)? 300 : round(300/4)
pel=default(pel,1)
lambda=(blksize==8)? default(lambda,2000) : default(lambda,1000)

bobd=c.kernelbob(order=order).verticalreduceby2()
fields=c.separatefields()
mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,compensate=false)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true,compensate=false)

even1=c.separatefields().selecteven()
odd1a=fields.mvcompensate(mvf,mode=1,thscd1=scd).selecteven()
odd1b=fields.mvcompensate(mvb,mode=1,thscd1=scd).selecteven()
odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)

even2=c.separatefields().selectodd()
odd2a=fields.mvcompensate(mvf,mode=1,thscd1=scd).selectodd()
odd2b=fields.mvcompensate(mvb,mode=1,thscd1=scd).selectodd()
odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd1b,0.5)

even=interleave(even1,odd1).weave()
odd=interleave(even2,odd2).weave()

interleave(even,odd)
}


"pel" is the same as MVanalyse's pel. either 1 or 2, for fullpel and halfpel respectively.

"blksize" is the same as the new blksize parm in Mvtools. default 8, but 4 will give nice results at slower speed.

"lambda" is a kind of "vector cleaner". it increases the vector field coherence, thus reducing stray vectors. default works okay. it must be doubled for 4x4 blocks i find (or should it be quadrupled? it doesn't have enough of and effect to really worry).

[scharfis_brain]

@joshbm: my interpretation of MugFunky's mvbob() currently is limited to TFF-video.
If you work with BFF-Video, you need to place doubleweave().selectodd() before calling mvbob1()

@MugFunky: I'll try the new version with the changed mvtools-syntax.
(I was too lazy to implement this myself, I was sure, you would do it :) )

I also have an Idea in mind to detect and knock out artifacts caused by motion compensation.

currently, you estimate motion using the half-sized bobbed clip and compensate motion on the bare fields.

to detect artifacts, one will need to compensate the bobbed clip, too (fwd AND bwd)
than compare the compensated frames to the original frame.
if the deviation is bigger than an certain threshold, one has to use the bobbed pixels instead of the mocomped ones for such detected areas.

I'll try to script such a detection. but do not count on my sucsess.
The things I tested so far showed, that mocomping introduces a lot of noise the the subtraction, so detection may hard to realize.

I do not have enough space available for that clip anymore.
PM me, if you want to get it transferred using another way.
It is about 20MB 640x480@29.97 fps YUY2-MJPEG-avi.
I found it somewhere here on the forums, but don't know anymore where it was.
This clip is my all-purpose-testclip. Because it:
- is interlaced
- has static parts with max. vertical detail
- has rainbowing (to confuse deinterlacers)
- has some little grain (try to denoise it without smearing the low contrasted background!)
- has loooong smooth camera-pans
- has a rapid zoom
- has clear defined diagonals (visualize edge directed interpolation)
- is NTSC (searching for a good way to make crisp & smooth PAL out of it)

Maybe I'll try to setup another account for hosting it.

[scharfis_brain]

for those, who don't trust in static images.
here is a sample video:
http://home.arcor.de/scharfis_brain/mvbob/doom9-mv-vs-krnl.avi
( left side == mvbob() ; right side == kernelbob() )

and here is the unprocessed video:
http://home.arcor.de/scharfis_brain/mvbob/doom9.avi

(deactivated, because else my 1GB/Month-Traffic limit is reached tomorrow, and we are just at the beginning of November!)

[acrespo]

I have tried on anime source and there are some interlaced artifacts with latest version of MVBob. Is MVBob recomend to anime or only to real image?

[Mug Funky]

eek... i didn't get round to saying "you shouldn't use this on anime", but i guess i probably should have.

anime doesn't have "real" motion in the same way video does, so motion-compensation will artefact heavily on it.

if you like you can use it as a pre-processor for another deinterlacer, so long as it hits the right fields (the non-comped ones, not the mocomped ones). it's not much of a solution.

for anime i recommend Tdeint, personally (or simple IVTC, but Tdeint handles both).

[scharfis_brain]

@Mug Funky: had you been able masking out mismatched areas?
all my tests so far show, that it will be a hard job to do so.

chroma-compensation currently seems to be broken...
It is really important to get the chroma compensated, too (of course with the same vectors as lume is compensated!)

This will be needed to create a good detection, cause luma-only masking will not catch all mismatches.

[scharfis_brain]

there is an copy & paste error in mvbob!

you all need to correct this line:

odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd2b,0.5)

then chroma looks better in the odd frames!

[Mug Funky]

thanks, scharfi :)

i knew if anyone found bugs, it'd be you (and i was kinda counting on it).

yeah, thinking about error detection, it's going to be a little tricky with the whole half-pixel offset stuff. perhaps keep the full-size bob handy and check it against that?

[scharfis_brain]

fullsize checking is a very bad idea, cause it would detect the jaggyness of kerneldeint!

I prefer the half-size checking:


complete untested idea to check for errors, I had on my way home:

bob=c.kernelbob(order=order).verticalreduceby2()
...motion-analysis...

bobf=bob.mvcompensate(mvf)
bobb=bob.mvcompensate(mvb)

fwdmask=interleave(bob,bobf).motionmask(...).selecteven/odd ?

bwdmask=interleave(bob,bobb).motionmask(...).selecteven/odd ?

[Fizick]

Sorry for offtopic, but anybody can translate word "bob" to English? Is it some abbreviation B... O... B... ?

[scharfis_brain]

please fill in the form with the word "bobbing" here:
http://www.thefreedictionary.com/

[Mug Funky]

hehe... that's an intricacy of english. "bob" is usually a person's name (typically your uncle's, though in my case it was my grandfather :)).

full rate dumb deinterlace is nicknamed "bob" because the picture bobs up and down (sort of in the sense "bobbing along").

[joshbm]

I've tested it and wow it's great! Hopefully you guys can resolve the chroma issue. Once it is fixed it will be my main bobber!

Thanks guys,
Josh

[scharfis_brain]

function MVbob(clip c,int "blksize", int "pel", int "lambda", int "thy", int "thc", int "bobth", bool "predenoise")
{

#disable all scene detection, because it is self-correcting
sc=255

# luma and chroma thresholds for correcting false detected motion
thy=default(thy,20)
thc=default(thc,10)

# threshold of kerneldeint
bobth=default(bobth,8)

#denoise the video for kerneldeint (better static areas for noisy video)
predenoise=default(predenoise,false)

blksize=default(blksize,8)
scd=(blksize==8)? 300 : round(300/4)
pel=default(pel,2)

#I decided lambda=0 being better, cause it stupidly trys to catch everything. errors are corrected afterwards.
lambda=default(lambda,0)

order=(c.getparity==true)? 1:0

bobx=predenoise ? c.temporalsoften(2,5,7) : c
bobx=bobx.kernelbob(order=order,threshold=bobth)
bobd=bobx.verticalreduceby2().lanczos4resize(c.width,c.height)


fields=c.separatefields().tomsmocomp(-1,-1,0)
fields1=fields

mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,compensate=false)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true,compensate=false)

bobdf=bobd.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
bobdb=bobd.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
difff=interleave(bobdf,bobd).motionmask(thy1=thy,thy2=thy,thc1=thc,thc2=thc,thSD=sc).selectodd()
diffb=interleave(bobdb,bobd).motionmask(thy1=thy,thy2=thy,thc1=thc,thc2=thc,thSD=sc).selectodd()
diff=logic(difff,diffb,"OR")

even1=c.separatefields().selecteven()
odd1a=fields.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
odd1a=maskedmerge(odd1a,fields1,difff,y=3,u=3,v=3).selecteven()
odd1b=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
odd1b=maskedmerge(odd1b,fields1,diffb,y=3,u=3,v=3).selecteven()
odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)
odd1=(order==1) ? odd1.separatefields().selecteven() : odd1.separatefields().selectodd()

even2=c.separatefields().selectodd()
odd2a=fields.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
odd2a=maskedmerge(odd2a,fields1,difff,y=3,u=3,v=3).selectodd()
odd2b=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
odd2b=maskedmerge(odd2b,fields1,diffb,y=3,u=3,v=3).selectodd()
odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd2b,0.5)
odd2=(order==1) ? odd2.separatefields().selectodd() : odd2.separatefields().selecteven()

even=interleave(even1,odd1)
even=even.weave()
odd=interleave(even2,odd2)
odd=odd.weave()


analysis=maskedmerge(bobx,diff,diff,y=3,u=3,v=3)
interleave(even,odd)

#stackhorizontal(last,analysis).converttoyuy2().bilinearresize(1280,height)
}


this is my first release of a full motion compensated fullframerate deinterlacer with correction of false matched motion.

there are a lot of things to improve:

- a much nicer error-replacement is needed
it curerently is stupid replacing with folled blending of bwd&fwd clip.
there must be a decision:
if only on clip (bwd or fwd) has errors on a certain pixel, return only the clip with the good pixel, instead of leaving the good clip as it is, repleace the other clip with some interpolated stuff and afterwards blend both together.

- I'll try if I can use another motionmasking, than kdeints internal one. it is far to sensible to noise.

- re-structurize the script
it has some naming issues, introduced by muf funky (odd isn't always odd and even not always even...)




I found, that a lambda of 0 gives the best motion estimation (especially for low contrastened areas!)

[joshbm]

I get "Script error: motion mask does not have a named argument "thy1" (line 69).

I have the latest MVTools as well as MaskTools.

[fixed] lol.. Kind of weird but I capitalized it to thY1. It worked like a charm.

PS- This thing works awesome!

Regards,
Josh

[Manao]

Kind of weird but I capitalized it to thY1. It worked like a charmWhat ? it shouldn't happen, avisynth is case insensitive.

[joshbm]

I know, but it worked lol...

Maybe some character was incorrect, but it worked like a charm.

Regards,
Josh

[scharfis_brain]

another version:
- improved motion detection
- improved mismatch-replacement

function MVbob(clip c,int "blksize", int "pel", int "lambda", int "thy", int "thc", int "bobth", bool "predenoise", bool "showmask")
{

#Helper functions:

function tmcstupid(clip c)
{ input=c.converttoyuy2(interlaced=true).separatefields.tomsmocomp(1,-1,0)
a = getparity(input) ? input.selectodd : input.selecteven
b = getparity(input) ? input.selecteven : input.selectodd
a=stackvertical(a.crop(0,0,0,1-a.height),a.crop(0,0,0,-1))
output = getparity(input) ? interleave(b,a) : interleave(a,b)
output.assumeframebased().converttoyv12()
}

#disable all scene detection, because it is self-correcting
sc=255

showmask=default(showmask,false)

# luma and chroma thresholds for correcting false detected motion
thy=default(thy,20)
thc=default(thc,10)

# threshold of kerneldeint
bobth=default(bobth,8)

#denoise the video for kerneldeint (better static areas for noisy video)
predenoise=default(predenoise,false)

blksize=default(blksize,4)
scd=(blksize==8)? 300 : round(300/4)
pel=default(pel,2)

#I decided lambda=0 being better, cause it stupidly trys to catch everything. errors are corrected afterwards.
lambda=default(lambda,0)

#determine clip Fieldorder
order=(c.getparity==true)? 1:0

# create clip for motion analysis and hole-filling
bobx=predenoise ? c.temporalsoften(2,5,7) : c
bobx=bobx.kernelbob(order=order,threshold=bobth).undot()
bobd=bobx.verticalreduceby2()
#bobd=bobd.lanczos4resize(bobx.width,bobx.height)
bobd=bobd.tomsmocomp(-1,-1,0).undot()

# create clip for motion compensation
fields=c.tmcstupid().undot()

# define clip for hole filling
fields1=bobx

# create motion vectors
mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,compensate=false,search=3,searchparam=10)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true, compensate=false,search=3,searchparam=10)

# detect mismatched areas of motion compensation
bobdf=bobd.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
bobdb=bobd.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
difff=interleave(bobdf,bobd).motionmask(thy1=thy,thy2=thy,thc1=thc,thc2=thc,thSD=sc).selectodd()
diffb=interleave(bobdb,bobd).motionmask(thy1=thy,thy2=thy,thc1=thc,thc2=thc,thSD=sc).selectodd()
diff=logic(difff,diffb,"OR")

# do the deinterlacing
even1=c.separatefields().selecteven()
odd1a=fields.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
odd1a=maskedmerge(odd1a,fields1,difff,y=3,u=3,v=3).selecteven()
odd1b=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
odd1b=maskedmerge(odd1b,fields1,diffb,y=3,u=3,v=3).selecteven()
odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)
odd1=(order==1) ? odd1.separatefields().selecteven() : odd1.separatefields().selectodd()

even2=c.separatefields().selectodd()
odd2a=fields.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
odd2a=maskedmerge(odd2a,fields1,difff,y=3,u=3,v=3).selectodd()
odd2b=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
odd2b=maskedmerge(odd2b,fields1,diffb,y=3,u=3,v=3).selectodd()
odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd2b,0.5)
odd2=(order==1) ? odd2.separatefields().selectodd() : odd2.separatefields().selecteven()

even=interleave(even1,odd1)
even=even.weave()
odd=interleave(even2,odd2)
odd=odd.weave()

# output
interleave(even,odd)
analysis=maskedmerge(last.levels(0,1,255,0,200),diff,diff,y=3,u=3,v=3)
showmask ? analysis : last
}

usage: generally just mvbob()

but if static areas are flickering (logos, subtitles etc.)
one need to raise bobth and/or set predenoise to true.

if motion errors appear (small dot-like holes) one need to lower the bobth.

thy (luma) and thc (chroma) are used for artifact prevention from mvtools.
the lower those values, the more artifacts are catched, but the more detail as well.

blksize, pel and lambda should be clear.

within mvbob() I am currently using ,search=3,searchparam=10
it makes a better compensation, but is painly slow.
you may want to delete ,search=3,searchparam=10 from both line for better speed...

[malkion]

scharfis, I keep getting kernelbob does not have a named arguement "order"... with the last mvbob() script.

could you help?

[Leak]

Originally posted by malkion
scharfis, I keep getting kernelbob does not have a named arguement "order"... with the last mvbob() script.

What version of KernelDeint are you using? If you're using one of scharfis_brain's scripted versions, you might want to take a look here:

http://forum.doom9.org/showthread.php?s=&threadid=81322

This version definitely has an order parameter... :)

[malkion]

Thanks Leak...

I did find the problem when I had the time. It's my KernelBob function. I don't have the right version.

line 42 in MvBob

bobx=bobx.kernelbob(order=order,threshold=bobth).undot()

my KernelBob (most likely too outdated) has no such call in it...

function kernelbob(clip a, int "th",bool "mask")
{ mask=default(mask,false)
th=default(th,5)
ord = getparity(a) ? 1 : 0
f=a.kerneldeint(order=ord, sharp=true, twoway=false, threshold=th,map=mask)
e=a.separatefields.trim(1,0).weave.kerneldeint(order=1-ord, sharp=true, twoway=false, threshold=th,map=mask)
interleave(f,e).assumeframebased
}

you see? only mask and th values... Can someone post the latest KernelBob while I searches for it? Thanks.

(error msg in vdub)

kernelbob does not have a named argument "order"

[edit]

ok, fixed. Kernelbob found in kerneldeint.dll :D

[zeus163]

OK, first I have to say, that I'm a cut and paste script writer. Now that I have that off my chest, I'm trying to get MVbob working. I first found out that I needed to upgrade my kerneldeint, which I did. Then I got an undot error and went and found that. Next, I got a tomsmocomp error. I went and got that and put it in. But now I get I get this error: "Script error: motion mask does not have a named argument "thy1" (line 60). I see that joshbm had this error and tried his fix, but that didn't work for me by capitalizing the "Y" in thy. Searching for "thy" obviously produced too many results. I'm sure there is something I'm overlooking, but I don't know what it is.

TIA

[malkion]

motion mask uses masktools.dll

MaskTool 1.5.4 (http://jourdan.madism.org/~manao/MaskTools-v1.5.4.zip)

[Mug Funky]

hmmm... to be honest i just got home and haven't had a chance to try out Scharfi's latest effort, but i'm thinking maybe you don't have an up-to-date masktools?

there's a thread in avisynth development that will have the latest version in it (if you've got a HyperThreading enabled P4, then read the thread carefully...).

http://forum.doom9.org/showthread.php?s=&threadid=82435&perpage=20&pagenumber=2

download the one with the binarize fix... it's the latest. get the second one below it if you have a HT P4.

[zeus163]

Thanks guys! Got back from $0.50 taco night and there was my answer. I got it going now. Woo-hoo!

Now to try it on some small clips.

[Socio]

balazer,

I believe file atachments have to be approved by the admin before they show up on this forum.

[Guest]

Originally posted by Socio
balazer,

I believe file atachments have to be approved by the admin before they show up on this forum. Done.

[Socio]

I have tried this script with three versions of MvTools and always get the same error:

Script error" mvanalyse does not have a named argument "compensate"


Edit:
I think I found the problem had to change a couple "compensate" 's to "mvcompensate" in the script.

Nope that did not fix it, now I get

Script error" mvanalyse does not have a named argument "mvcompensate"

if I try MVCompensate I get:

Script error" mvanalyse does not have a named argument "MVCompensate"




Figured it out!

I had to edit out "compensate=false" from these two lines in the script and it worked!

# create motion vectors
mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,compensate=false,search=3,searchparam=10)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true, compensate=false,search=3,searchparam=10)


Ultra freaking slow though, 2936 frames est time 3hrs 55 minutes!

[balazer]

You were right about the problem. Corrected here:

I've tried scharfis_brain's MVBob and found it to be, simply, the best de-interlacer I've ever seen or used. It's amazing. I almost forget that I'm watching an interlaced source. Here is the original post, with usage instructions:
http://forum.doom9.org/showthread.php?s=&threadid=84725&perpage=20&pagenumber=2#post566854

I've assembled all the required parts here, hoping that it will be easier for people to use. If you put all the required AVISynth plugin DLLs in your plugins folder and enable auto-loading, you won't have to load any plugins explicitly.
http://www.avisynth.org/AviSynthPlugins

Attached is scharfis_brain's MVBob, modified to reflect a change in the function name of LeakKernelDeint. Rename it to MVBob.avsi and put it in your plugins folder.

These are the other parts you'll need:

UnDot v0.0.1.1 and TomsMoComp v0.0.1.7 :
http://www.trbarry.com/
or
http://www.avisynth.org/warpenterprises/

MVTools 0.9.8.5 and MaskTools 1.5.6:
http://manao4.free.fr/
or
http://forum.doom9.org/showthread.php?s=&threadid=67232&highlight=mvtools

LeakKernelDeint 1.5.3:
http://gast3.ssw.uni-linz.ac.at/~kp/AviSynth/LeakKernelDeint/
or
http://forum.doom9.org/showthread.php?s=&threadid=81322&highlight=leak+kerneldeint

To use MVBob you'll want to make sure that you have the clip's field parity set correctly before you pass the clip to MVBob. (follow the instructions in the KernelDeint readme)


I've encoded several clips and placed them online. They are just the finished product - not before & after or side-by-side comparisons.
http://www.eecs.umich.edu/~balazer/mmb_media/

[Valky]

Originally posted by balazer
You were right about the problem. Corrected here:

I've tried scharfis_brain's MVBob and found it to be, simply, the best de-interlacer I've ever seen or used. It's amazing. I almost forget that I'm watching an interlaced source. Here is the original post, with usage instructions:
http://forum.doom9.org/showthread.php?s=&threadid=84725&perpage=20&pagenumber=2#post566854

I've assembled all the required parts here, hoping that it will be easier for people to use. If you put all the required AVISynth plugin DLLs in your plugins folder and enable auto-loading, you won't have to load any plugins explicitly.
http://www.avisynth.org/AviSynthPlugins

Attached is scharfis_brain's MVBob, modified to reflect a change in the function name of LeakKernelDeint. Rename it to MVBob.avsi and put it in your plugins folder.

These are the other parts you'll need:

UnDot v0.0.1.1 and TomsMoComp v0.0.1.7 :
http://www.trbarry.com/
or
http://www.avisynth.org/warpenterprises/

MVTools 0.9.8.5 and MaskTools 1.5.6:
http://manao4.free.fr/
or
http://forum.doom9.org/showthread.php?s=&threadid=67232&highlight=mvtools

LeakKernelDeint 1.5.3:
http://gast3.ssw.uni-linz.ac.at/~kp/AviSynth/LeakKernelDeint/
or
http://forum.doom9.org/showthread.php?s=&threadid=81322&highlight=leak+kerneldeint

To use MVBob you'll want to make sure that you have the clip's field parity set correctly before you pass the clip to MVBob. (follow the instructions in the KernelDeint readme)


I've encoded several clips and placed them online. They are just the finished product - not before & after or side-by-side comparisons.
http://www.eecs.umich.edu/~balazer/mmb_media/


"There is no function called "kernelbob" on line 42"
Is this error somehow related to changes in kerneldeint, since I have downloaded all the tools you mentioned?

bobx=bobx.kernelbob(order=order,threshold=bobth).undot()

Btw, your video clips looked REALLY nice on your website (I watched that 93mb clip with flag and some stadium audience)

[balazer]

The kernelbob problem is fixed in the version of MVBob that I attached. We'll have to wait for the mods to approve the new attachment.

[scharfis_brain]

One can clearly see the MV-mismatches in the video michiganmarchingband.
especially on patterned textures.

I hope to get this knocked out with an updated mvtools.dll of manao.


I am waiting for the corrector_double() , as I suggested some time ago

If this corrector exists, I can easily integrate the global motion compensation of depan.dll and a better mismatch handling than the one of the current version of mvbob().

[Leak]

Originally posted by Valky
"There is no function called "kernelbob" on line 42"
Is this error somehow related to changes in kerneldeint, since I have downloaded all the tools you mentioned?

bobx=bobx.kernelbob(order=order,threshold=bobth).undot()

It's called LeakKernelDeint now; just add the missing "Leak" and it should work...

np: Zorn - Michelle's Unblockable (The City's Collapsing (But Not Tonight))

[Manao]

I heard the call, here is a release with Corrector modified to your liking :

MVTools v0.9.9 (http://manao4.free.fr/MVTools-v0.9.9.zip)

There are other changes, but still no temporal interpolators ( they are tricky, though results are better ( & slower ) than before )

[Valky]

Originally posted by joshbm
I get "Script error: motion mask does not have a named argument "thy1" (line 69).

I have the latest MVTools as well as MaskTools.

[fixed] lol.. Kind of weird but I capitalized it to thY1. It worked like a charm.

PS- This thing works awesome!

Regards,
Josh

Didn't work here. I have already get to this point after numerous other errors in script. What else did you do? error in row 60.

[scharfis_brain]

@manao: wow. THAT was fast!
many many thanks.

@all:
if I have some time, I'll take a deeper look into mvbob().
(hopefully this or following weekend)

mvbob() will need a complete rebuild. it currently is too much unstructurized.

also, I would like to bundle a mvbob-package, like I did with restore24 to avoid major confusion with updated plugins and/or Copy/Paste mistakes.

[Manao]

scharfi : in fact, I had it in my sleeves for two weeks now, but i was trying to finish these damned interpolators. But since waiting for having a fine results with them would have taken too long, here is the new release.

BTW, I take the opportunity here to say that if you're encoutering a strange behavior with the latest version ( not necessarily with Corrector ), don't try too hard to find a bug on your side of the script, the chance is high the issue is on my side ( as always, a lot of changes everywhere... ).

[balazer]

Seems attachments are a bit of a pain, as mods don't always approve them quickly (or at all). No disrespect to the mods - just seems silly that a text file attachment would need to be approved.

This MVBob works per my previous post. Use MVTools 0.9.8.5, not the newer 0.9.9. Save the following code into a file MVBob.avsi and put it in your plugins folder.

#LoadPlugin("c:\program files\avisynth 2.5 filters\LeakKernelDeint.dll")
#LoadPlugin("C:\Program Files\AVISynth 2.5 Filters\undot.dll")
#LoadPlugin("C:\Program Files\AVISynth 2.5 Filters\tomsmocomp.dll")
#LoadPlugin("C:\Program Files\AVISynth 2.5 Filters\mvtools.dll")
#LoadPlugin("C:\Program Files\AVISynth 2.5 Filters\masktools.dll")

#Modified from scharfis_brain's post:
#http://forum.doom9.org/showthread.php?s=&threadid=84725&perpage=20&pagenumber=2#post566854

#requires UnDot v0.0.1.1, TomsMoComp v0.0.1.7, MVTools 0.9.8.5, MaskTools 1.5.6, and LeakKernelDeint 1.5.3


function MVbob(clip c,int "blksize", int "pel", int "lambda", int "thy", int "thc", int "bobth", bool "predenoise", bool "showmask")
{

#Helper functions:

function tmcstupid(clip c)
{ input=c.converttoyuy2(interlaced=true).separatefields.tomsmocomp(1,-1,0)
a = getparity(input) ? input.selectodd : input.selecteven
b = getparity(input) ? input.selecteven : input.selectodd
a=stackvertical(a.crop(0,0,0,1-a.height),a.crop(0,0,0,-1))
output = getparity(input) ? interleave(b,a) : interleave(a,b)
output.assumeframebased().converttoyv12()
}

#disable all scene detection, because it is self-correcting
sc=255

showmask=default(showmask,false)

# luma and chroma thresholds for correcting false detected motion
thy=default(thy,20)
thc=default(thc,10)

# threshold of kerneldeint
bobth=default(bobth,8)

#denoise the video for kerneldeint (better static areas for noisy video)
predenoise=default(predenoise,false)

blksize=default(blksize,4)
scd=(blksize==8)? 300 : round(300/4)
pel=default(pel,2)

#I decided lambda=0 being better, cause it stupidly trys to catch everything. errors are corrected afterwards.
lambda=default(lambda,0)

#determine clip Fieldorder
order=(c.getparity==true)? 1:0

# create clip for motion analysis and hole-filling
bobx=predenoise ? c.temporalsoften(2,5,7) : c
bobx=bobx.leakkernelbob(order=order,threshold=bobth).undot()
bobd=bobx.verticalreduceby2()
#bobd=bobd.lanczos4resize(bobx.width,bobx.height)
bobd=bobd.tomsmocomp(-1,-1,0).undot()

# create clip for motion compensation
fields=c.tmcstupid().undot()

# define clip for hole filling
fields1=bobx

# create motion vectors
mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,search=3,searchparam=10)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true, search=3,searchparam=10)

# detect mismatched areas of motion compensation
bobdf=bobd.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
bobdb=bobd.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
difff=interleave(bobdf,bobd).motionmask(thy1=thy,thy2=thy,thc1=thc,thc2=thc,thSD=sc).selectodd()
diffb=interleave(bobdb,bobd).motionmask(thy1=thy,thy2=thy,thc1=thc,thc2=thc,thSD=sc).selectodd()
diff=logic(difff,diffb,"OR")

# do the deinterlacing
even1=c.separatefields().selecteven()
odd1a=fields.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
odd1a=maskedmerge(odd1a,fields1,difff,y=3,u=3,v=3).selecteven()
odd1b=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
odd1b=maskedmerge(odd1b,fields1,diffb,y=3,u=3,v=3).selecteven()
odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)
odd1=(order==1) ? odd1.separatefields().selecteven() : odd1.separatefields().selectodd()

even2=c.separatefields().selectodd()
odd2a=fields.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
odd2a=maskedmerge(odd2a,fields1,difff,y=3,u=3,v=3).selectodd()
odd2b=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
odd2b=maskedmerge(odd2b,fields1,diffb,y=3,u=3,v=3).selectodd()
odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd2b,0.5)
odd2=(order==1) ? odd2.separatefields().selectodd() : odd2.separatefields().selecteven()

even=interleave(even1,odd1)
even=even.weave()
odd=interleave(even2,odd2)
odd=odd.weave()

# output
interleave(even,odd)
analysis=maskedmerge(last.levels(0,1,255,0,200),diff,diff,y=3,u=3,v=3)
showmask ? analysis : last
}

[Valky]

I get this error on line 72 'motionmask does not have argument name thy1'
with this script too. I changed back to MVTools 0.9.8.5 as suggested.

Any idea where this error comes from? There were some solutions mentioned before to change to capital letters this 'thy1' but it didn't work with me. I guess this isn't virtualdub error?

[kempfand]

I believe motionmask has a conflict with MPEG2DEC.dll.

I had the same error, deleted MPEG2DEC.dll, and it now works like a charm.

Andreas

[Manao]

MotionMask is a filter from the masktools, not related at all with MVTools.

However, MotionMask is also a filter present in one of the mpeg2dec ( don't remember which one ). To prevent avisynth to confuse them, replace motionmask by masktoolsdllname_motionmask ( as stated in avisynth's documentation ).

[Wilbert]

Seems attachments are a bit of a pain, as mods don't always approve them quickly (or at all).
I didn't see it. Sorry :)

[Valky]

So what does this has to if I use avisource in my script? Should I still delete mpeg2dec.dll from plugins-folder or is it built-in avisynth nowadays?

[Manao]

Re-read my answer : change in the script all the occurence of motionmask by masktools_motionmask

@all : you should be able to use this version of MVTools : http://manao4.free.fr/MVTools-v0.9.9.1.zip

[dvwannab]

oh my this baby is sloooowwwwww. Anyone else experiencing the same. I used a simple script:

Import("c:\program files\avisynth 2.5 filters\mvbob.avs")

LoadPlugin("c:\program files\avisynth 2.5 filters\dgdecode.dll")
LoadPlugin("c:\program files\avisynth 2.5 filters\LeakKernelDeint.dll")
LoadPlugin("C:\Program Files\AVISynth 2.5 Filters\undot.dll")
LoadPlugin("C:\Program Files\AVISynth 2.5 Filters\tomsmocomp.dll")
LoadPlugin("C:\Program Files\AVISynth 2.5 Filters\mvtools.dll")
LoadPlugin("C:\Program Files\AVISynth 2.5 Filters\masktools.dll")

mpeg2source("c:\france.d2v")

mvbob()

Dropped the script in VDmod and encoded 10 minute clip with 1-pass DivX 5.1.2. After 5.5 hours it was at 20% complete :(
I used the code in balazer's last post (looks the same as scarfis_brain) and MVTools 0.9.8.5.

[Wilbert]

@Valky,

To clarify Manao's remarks, have a look at the bottom of:

http://www.avisynth.org/AviSynthPlugins

[joshbm]

I agree it's kind of slow, but it works great :).

Keep us updated on the new mvbob() :).

Regards,
-joshbm

[scharfis_brain]

I am currently modifying mvbob() to work with the newest mvtools and its inculded corrector.

I've got it working at 3 to 4 fps on a 640x480@29.97fps NTSC video.
My machine is an athlonXP@1.5 GHz

maybe I can optimize that script further.
maybe it will loose speed again due to new features ;)

if your mvbob() is painfully slow, just comment out the extended motion search parameters:

mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,chroma=true)#,search=3,searchparam=10)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true, chroma=true)#,search=3,searchparam=10)

[dvwannab]

Originally posted by scharfis_brain
I am currently modifying mvbob() to work with the newest mvtools and its inculded corrector.

I've got it working at 3 to 4 fps on a 640x480@29.97fps NTSC video.
My machine is an athlonXP@1.5 GHz

maybe I can optimize that script further.
maybe it will loose speed again due to new features ;)

if your mvbob() is painfully slow, just comment out the extended motion search parameters:

mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,chroma=true)#,search=3,searchparam=10)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true, chroma=true)#,search=3,searchparam=10)

OH NO WAY, dude!!! I just watched my marathon encode and WOOOWWWWW!!! Definitely blows away 100fps.com method and all others I have come across. Keep up the good work...... with maybe just a tad bit more speed :D Just kidding ;)

[joshbm]

How is your new MVBob() coming along? lol... I am eager to see an update :D.

Regards,
joshbm

[scharfis_brain]

@all: I've completed the first step.
the rewrite of mvbob() is finished.
the speed is gained. at least by factor two.

@manao: I wasn't able to get your corrector() working properly.

but please take a look yourself:


setmemorymax(256)


#Helper functions:

#stupid tmc-bobbing for better edge definition
function tmcstupid(clip c)
{ input=c.converttoyuy2(interlaced=true).separatefields.tomsmocomp(1,-1,0)
a = getparity(input) ? input.selectodd : input.selecteven
b = getparity(input) ? input.selecteven : input.selectodd
a=stackvertical(a.crop(0,0,0,1-a.height),a.crop(0,0,0,-1))
output = getparity(input) ? interleave(b,a) : interleave(a,b)
output.assumeframebased().converttoyv12()
getparity(input) ? assumetff() : assumebff()
}



#colorize a clip for identification in the output
function col(clip i, int j)
{v=128
(j==0) ? i.coloryuv(gain_u=v) : \
(j==1) ? i.coloryuv(gain_u=0-v) : \
(j==2) ? i.coloryuv(gain_v=v) : \
(j==3) ? i.coloryuv(gain_v=0-v) : \
i
#blue 0
#yellow 1
#red 2
#green 3
#passthrough else
}



function MVbob(clip c,int "blksize", int "pel", int "lambda", int "thy", int "thc", int "bobth", bool "predenoise", bool "showmask")
{

#disable all scene detection of mvcompensate(), because mvbob() is self-correcting due to the corrector()
sc=255

showmask=default(showmask,false)

# luma and chroma thresholds for correcting false detected motion
thy=default(thy,20)
thc=default(thc,10)

# threshold of kerneldeint
bobth=default(bobth,8)

#denoise the video for kerneldeint (better static areas for noisy video)
predenoise=default(predenoise,false)

blksize=default(blksize,4)
scd=(blksize==8)? 300 : round(300/4)
pel=default(pel,2)

#I decided lambda=0 being better, cause it stupidly trys to catch everything. errors are corrected afterwards.
lambda=default(lambda,0)

#determine clip Fieldorder
order=(c.getparity==true)? 1:0

# bobx -> deinterlaced video, used for motion search and hole filling

# mvf -> motion vectors forward
# mvb -> motion vectors backward

# bobd -> blurred bobx for error checking (correcting false compensated blocks!)
# bobdf -> forward compensated bobd
# bobdb -> backwards compensated bobd
# bobdm -> average of bobdb and bobdf

# fields-> ELA-upsized fields for motion compensated output
# mcf -> forward compensated fields
# mcb -> backward compensated fields
# cv -> average of mcb and mcf

# dpf -> forward compensated fields (global motion)
# dpb -> backward compensated fields (global motion)
# dp -> average of dpb and dpf

# mc -> corrected motion compensated result

# create clip for motion analysis and hole-filling
bobx=predenoise ? c.temporalsoften(2,5,7) : c
#bobx=bobx.leakkernelbob(order=order,threshold=bobth)
bobx=bobx.tdeint(mode=1,mthreshl=bobth,mthreshc=bobth,type=3,Link=0).assumetff()
bobd=bobx.undot().verticalreduceby2()
bobd=bobd.lanczos4resize(bobx.width,bobx.height)
#bobd=bobd.tomsmocomp(-1,-1,0).undot()

# create clip for motion compensation
fields=c.tmcstupid().undot()

# create motion vectors
mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,chroma=true)#,search=3,searchparam=10)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true, chroma=true)#,search=3,searchparam=10)

# detect mismatched areas of motion compensation
bobdf=bobd.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc)
bobdb=bobd.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc)
bobdm=bobdf.mergeluma(bobdb,0.5).mergechroma(bobdb,0.5)

bobdpf=fields.MVDepan(mvf, zoom=true, rot=true, pixaspect=1.0 ) #, float error, bool info)
bobdpb=fields.MVDepan(mvb, zoom=true, rot=true, pixaspect=1.0 ) #, float error, bool info)
bobdpm=bobdpf.mergeluma(bobdpb,0.5).mergechroma(bobdpb,0.5)

# do the deinterlacing
original_even=c.separatefields().selecteven()
original_odd =c.separatefields().selectodd()

mcf=fields.mvcompensate(mvf,mode=1,thscd1=scd,thSCD2=sc).deblock()
mcb=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc).deblock()
dpf=fields.MVDepan(vectors=mvf, zoom=false, rot=false, pixaspect=1.0,thscd1=scd,thSCD2=sc,info=true,error=255 ) #, float error, bool info)
dpb=fields.MVDepan(vectors=mvb, zoom=true, rot=true, pixaspect=1.0,thscd1=scd,thSCD2=sc, info=true,error=255 ) #, float error, bool info)

dp=dpf.mergechroma(dpb,0.5).mergeluma(dpb,0.5)
cv=mcf.mergechroma(mcb,0.5).mergeluma(mcb,0.5)

# --------------------------------------
# here, I want to insert the correction
# but corrector seems to deliver bobd, bobdf and/or bodb to the output,
# while only bobx, mcf and mcb should be delivered!
# col(x) is just a chroma adjuster to visualize the outputted clips
# so manao, can you confirm this misbehaviour of corrector? or am I using it in the wrong way?

mc=corrector(bobd,bobx.col(1),bobdf,mcf.col(2),bobdb,mcb.col(3),mode=0,th=11)


#
# -----------------------------------
#
compensated_even=(order==0) ? mc.selecteven().separatefields().selecteven() : mc.selecteven().separatefields().selectodd()
compensated_odd =(order==0) ? mc.selectodd().separatefields().selectodd() : mc.selectodd().separatefields().selecteven()

even=interleave(original_even, compensated_even).weave()
odd =interleave(original_odd , compensated_odd ).weave()

# output
interleave(even,odd)
stackhorizontal(last,bobx)
#stackhorizontal(bobdf,bobd,bobdb).bicubicresize(1264,480)
stackhorizontal(mc,bobx)

}


# use older mvtools to do framerate conversions.
function mvfps(clip i, float fps)
{ fwd=mvtools0962_mvanalyse(i,isb=false,lambda=1000)
bwd=mvtools0962_mvanalyse(i,isb=true, lambda=1000)
i.mvtools0962_mvconvertfps(bwd,fwd,fps=fps*10)
temporalsoften(1,255,255)
selectevery(10,0)
}

loadplugin("d:\x\tdeint.dll")
loadplugin("d:\x\masktools.dll")
loadplugin("d:\x\MVTools0962.dll")
loadplugin("d:\x\MVtools0991.dll")
LoadPlugin("d:\x\dgdecode.dll")
LoadPlugin("d:\x\undot.dll")
loadplugin("d:\x\tomsmocomp.dll")
loadplugin("d:\x\leakkerneldeint.dll")

loadplugin("d:\x\loadpluginex.dll")
loadplugin("d:\x\warpsharp.dll")


avisource("doom9.avi")

assumetff()

converttoyv12(interlaced=true)

mvbob(predenoise=false,bobth=9,thy=255,thc=255,showmask=false,lambda=400,blksize=8)



if I do just

mc=cv

instead of

mc=corrector(blah blah)

the output is very fine. expept of the mv-mismatches.

but when I am using corrector somehow the analysis clips are passed to the output.

I really appreciate if you could have a look into it.

[Manao]

That's what i thought, you interleaved analysis and output clips. Clips have to be given in that order :

analysis_0, output_0, analysis_1, analysis_2, ... analysis_n, output_1, output_2, ... output_n.

I chose that order because analysis_0 and output_0 work differently from the other. But i recon, reading again the documentation, that how clips should be given was slightly ambiguous.

[scharfis_brain]

wow!

now it works!

you should really update the documentation regaring this issue. it was very confusing....


hm.. but I think mvbob it still needs a lot of work.

I'll implement a function that really really makes static logos/texts/objects static.
(they are un-corrected by the corrector, but that is by nature)

[scharfis_brain]

I've managed to implement nearly everything I wanted to into mvbob.

download a package here:
http://home.arcor.de/scharfis_brain/mvbob/mvbob.rar

it contains all needed plugins, which are automatically loaded when importing the mvbob.avs into your personal script.
do NOT remove the plugin-dlls from the folder that contains mvbob.avs

mvbob.avs contains three functions:

mvbob(clip c, int "blksize", int "pel", int "lambda", int "th", int "ths", int "bobth", bool "predenoise")

blksize(4,8,16) -> defines the final size of the motion-blocks.
the smaller, the slower and the more accurrate the motioncompensation, but more instable, too.
so use 16 if your video is not stable enough
default = 8

pel (1,2) -> subpixel accuracy of mvtools.
default(2)

lamda(0...?)
see mvtools-documentation
default(1000)

bobth(0...255)
deinterlacing threshold for the internal motion adaptive deinterlacers (leakkernelbob/tdeint)
do not go much over 10
default(8)

th(0...255)
the threshold for correcting false compensated motion
0 -> there will be no motioncompensation in your output (everything gets 'corrected')
255-> no correction
default(8)

ths(0...255)
threshold of static area correction (bobbing prevention)
0-> no correction
255-> full 'correction' motion compensation misses will show up again
(works against th! so be careful)
default(4)

predenoise(true/false) (experimental)
is a stupid temporalsoften with fixed parameters to help the deinterlacer
show no be used, cause it fools motion estimation.
default(false)

mvfps(clip i, float fps, int "blur")

motion compensated framerate changer

fps -> target framerate

int blur-> factor of internal oversampling
blur=10 will internally sample 10 times the framerate and will blend
3 of those 10 frames together to hide motion artifacts
default(1) (no blurring)


reYV12(clip i)

reverts PAL-DV to its nature: YV12
without quality loss
speeds up things significantly in the processing chain!

report any problems and quality issues immediately, please.


EDIT:

this tool is able to do a fully motion compensated standards conversion for you!

example:

NTSC-DV to PAL:

avisource("ntsc-file.avi")
reinterpolate411() #if you wish to....
mvbob()
lanczos4resize(width,576)
converttoyv12()
mvfps(50)
converttoyuy2()
assumebff().separatefields().selectevery(4,0,3).weave()

PAL-DV to NTSC:

avisource("pal-file.avi")
reYV12() #if you wish to....
mvbob()
mvfps(59.94)
converttoyuy2()
lanczos4resize(width,480)
assumebff().separatefields().selectevery(4,0,3).weave()

hey! that's it!
easy, isn't it?

in future, if manao has hopefully reimplemented the motion interpoaltors to the newer versions of mvtools, the framerate conversion will be much faster, cause I can reuse the motion vectors of mvbob().

[kempfand]

@ scharfis: Many thanks for sharing your latest creation.

Q: Is it possible to write a variant of reYV12() which takes RGB24-input ?

I use the Canopus-DV codec through my entire chain, and usually open the DV-avi with AVISource("DV.avi", pixel_type="RGB24", fourCC="CDVC") which means I have to use ConvertToYUY2() followed by reYV12().

AVISource-opening the DV with pixel_type="YUY2" kindof squeezes the colours.

Kind regards,
Andreas

[scharfis_brain]

which means I have to use ConvertToYUY2() followed by reYV12().

which is the correct way to use it.

[Valky]

Well, I finally got this work and saw some results with it. Thanks scarfis for getting al the needed tools in a some packet.

It's awfully slow on my 1800+ machine. 1-2 frames per second.
How do you use it as just a simple deinterlacer for normal dv-pal video and is the final output always 50fps video?

[scharfis_brain]

How do you use it as just a simple deinterlacer for normal dv-pal video and is the final output always 50fps video?

the output of mvbob() is always fullrate. (50fps / 59.94fps)


use

mvbob()
selecteven()

for halved framerate output.

it won't be much faster if I would have done a special half framerate mode into mvbob(), cause all the parameters have to be calculated. No matter whether you want full or half framerate.

[2Bdecided]

I can't even manage to get the speeds you're reporting!

I'm using AVS2AVI -c null to go from one uncompressed AVI file to another, and I'm getting about 0.02FPS(!!!!) converting PAL to NTSC. That's 21 hours to convert 40 seconds! This is on a P4 2.8GHz.

I'm using...


import("C:\Program Files\AviSynth 2.5\plugins\mvbob.avs")
avisource("all no grey.avi")
#reYV12() #if you wish to....
assumetff()
convertToYV12
mvbob()
mvfps(59.94)
converttoyuy2()
lanczos4resize(width,480)
assumebff().separatefields().selectevery(4,0,3).weave()


There are a couple of reasons why this code might not work or might not be optimal - I'm not sure if assumetff() is the right way to pass TFF material to mvbob()*, I know convertToYV12 without interlace-true is wrong, and the source material has already gone from YUV2 to RGB24 before it even gets into the script.**

However, all this asside(!!!), why is it _so_ slow?

Cheers,
David.

* - but I'll find out when I actually get to watch the result in 21 hours!!!

** - anyone know a way to pass raw YUV files like these (http://www.ldv.ei.tum.de/liquid.php?page=70) (good test sequences there btw) straight into AVISynth?

[scharfis_brain]

UHM? 0.02fps?

this means that you are getting ONE new frame every 50 seconds ????

This cannot be the case.

I get about 0.5 to 1.5fps using this script with my AthlonXP1600+ @ 1.5 GHz (768MB DDR-266 RAM)

a plain converttoyv12 is definately WRONG!
either use converttoyv12(interlaced-true) (use this with TV-Cards captures)
or reYV12() (for PAL=DV stuff, this is the best choice!)

assumetff() and assumebff()
are used to set up the correct fieldorder.

PAL-DV is always BFF, while TV-Cards captures are more common to be TFF.

ensure that both assume?ff() calls are setting the SAME fieldorder.

is the fieldorder was set incorrectly, the output will show heavy motion jitter.

To open YUV-files directly in AVISynth, you will need the plugin rawsource.dll
get it (and other plugins, too!) here:
http://www.avisynth.org/warpenterprises/

[2Bdecided]

Thanks for the reply scharfis_brain.

Originally posted by scharfis_brain
UHM? 0.02fps?

this means that you are getting ONE new frame every 50 seconds ????

This cannot be the case.

Yes, it really is! It's been running since I last posted, and we're up to 55 frames now, ETA of about 13 hours. I've only been browsing the net. It's obvious there's something wrong, but I don't know what. It's probably a general AVIsynth problem on my system (it's just as slow in VDub), so maybe I should address it in another thread.


a plain converttoyv12 is definately WRONG!
either use converttoyv12(interlaced-true) (use this with TV-Cards captures)
or reYV12() (for PAL=DV stuff, this is the best choice!)

This isn't PAL DV, so I was going to use convertoyv12(interlaced=true). I litterally just threw this script together to see if assumetff() would work, and then was amazed at how slow it was!


ensure that both assume?ff() calls are setting the SAME fieldorder.

I'll check. I'd swear on previous conversions I had opposite for PAL and NTSC (not DV) to avoid judder.

EDIT: I Ctrl-C'd it. The field order seems fine - TFF on the way in, BFF on the way out with no judder (checked field-by-field in TMPGEnc deinterlace filter, even-odd). So far, the quality looks great!


To open YUV-files directly in AVISynth, you will need the plugin rawsource.dll
get it (and other plugins, too!) here:
http://www.avisynth.org/warpenterprises/ [/B]

I'd been there, but not realised what that one would do - I'll try it tomorrow.

Thanks for your help.

Cheers,
David.

[scharfis_brain]

where is your source from? (device)
which properties has it? (resolution, codec etc.)

how fast is this simple script:
avisource("all no grey.avi")
?


o-o...


import("C:\Program Files\AviSynth 2.5\plugins\mvbob.avs")

remove all files from the plugin-folder.

place the mvbob package somewhere else.

all dll placed in the plugin folder are getting loaded automatically by AVISynth. THis is not a good idea with those more advanced scripts.

[Mug Funky]

scharfi: one question aboot reYV12 - is it useful if my decoder is delivering yv12 already? i use ffdshow to decode DV when i can (ie. when i'm not using premiere) and so far haven't had any problems with colour, but i'm not quite sure what i'd be looking for if i did have colour issues...

[scharfis_brain]

reYV12 is only useful, if the DV-Decoder did upsample the YY12-PAL to YUY2 while decoding.

If your decoder already puts out the untouched YV12 (like ffdshow does, indeed) you do NOT need to use reYV12.

[zilog jones]

Wow, this is amazing stuff!

I've had mostly great results, but I tried it with some game footage (with lots of fast movement and panning) and occasionally got some weird artefacts (in localised parts of the screen) like this:

http://www.skynet.ie/~zilog/pics/mvbob-weird2.png

(full frame example: http://www.skynet.ie/~zilog/pics/mvbob-weird.png)

It happens quite frequently with pans in this clip, and sometimes it's just a few dots here and there.

I tried changing blksize to the other two numbers but it didn't seem to make much difference. Anything else I should try changing? I take it the crappy quality (it was a composite source) isn't really helping either?

Besides this, it's a damn good de-interlacer, and it's been exactly what I've been looking for for ages. I still have to try out standards conversion with it too, which will probably also be amazing. Keep up the good work!

[scharfis_brain]

yeah, those artifacts are caused by kerneldeint's motion map.

every! to repeat myself EEVVEERRYY

motion adaptive deinterlacer (tdeint, kerneldeint, etc.)

are not capable to decide between motion and static (bob and weave) IF
you are trying to feed it with a shorter shutter speed than 1/50 sec or 1/60 sec.

And computer games are currently always at zero shutter (no motionblur)

this yields to this effect:
patterned linear moving structures are alternating their luma from field to field at the same place.
this lets the motionmap of our motion adaptive deinterlacers mark this moving area static.

you may try to set bobth lower.
At the risl bobbing real static areas, of course.

Try a plain tdeint or kernelbob on that source. you'll see that it looks the same like mvbob.

btw.: could you send a unprocessed game sample video to me?
I am search for such clips for long, but noone I know has a game-console :(

[zilog jones]

That makes sense - don't think I ever tried proper deinterlacing with game footage before, so I never came across that problem.

The framerate conversion works great! Though it's quite slow on my PIII 933MHz - half an hour for 60 frames (and that's without resizing and weaving)! It's worth it though :D

Oh, and I'll PM you about sending some game footage.

[scharfis_brain]

The framerate conversion works great!
Do not thank me.
It is completely manao's stuff. I didn't alter anything. Thank him ;)

And as you know - from the beginning of this thread - Mug Funky invented this mv-ed bobbing.

I just throwed in some things here and there, cooked it up to 100 degrees of celsius et viola ;)

[2Bdecided]

scharfis_brain,

Thanks for all your help in this thread. I managed 10fps with that simple script through AVS2AVI, or 18fps if the source and destination files were on separate HDDs. So, I realised something was very wrong!

When I used rawsource to access the original YUV files (rather than using the AVI files created by the yuv2avi.exe supplied with the YUV files) the speed of the full PAL>NTSC conversion picked up from the previous 0.02fps to about 1fps.

The results are very good, so I'm very happy!

Thanks again.

Cheers,
David.

[Terka]

@scharfis_brain

to achive best results for fast moving scenes (sport) and deinterlace to 50fps: i have to use fast shutter speed. but to avoid deinterlacing artefacts you wrote it should be slower?

[scharfis_brain]

to achive best results for fast moving scenes (sport) and deinterlace to 50fps: i have to use fast shutter speed.

why this?

1/50 sec shutter creates a motionblur that suggests natural motion to our eyes, while shorter shutters are creating a strob-effect (one can see moving contoures/ghosts even on TV).

[Terka]

its because i film sport to see the mistakes

[scharfis_brain]

generally high speed shutter video is much better for the motion compensation/estimation.
So the quality should be really godd with mvbob()

but the problems with motion adaptive deinterlacers will remain.

to quote myself:
patterned linear moving structures are alternating their luma from field to field at the same place.
this lets the motionmap of our motion adaptive deinterlacers mark this moving area static.

I think, that this is rarely the case with sports.

But it could often occur with game footage, like zilog jones experienced.

[DeathTheSheep]

Questions from the bob-newbie:
1. Deinterlace=good, but can this thing double the framerate of non-interlaced material?
2. When I tried to stick the code in, it said "kernelbob not found". Where on earth do you get kernelbob?


Thanks for bearing with me, y'all!

[scharfis_brain]

1) no!
try mvfps() for that purpose

2) When I tried to stick the code in

what does that mean?!?

did you Dled the mvbob-package?

[DeathTheSheep]

2) When I tried to stick the code in
Yeah, I ended up sticking it in by hand and typing in the basic kernelbob thing too. Yeah, I didn't hear the part about mvbob or whatever...


Oh, and this mvfps...I've heard about this thing before, I just have no clue where to find it. Excuse me for my ignorance pertaining to AVISynth... ;-()

[scharfis_brain]

Yeah, I ended up sticking it in by hand and typing in the basic kernelbob thing too. Yeah, I didn't hear the part about mvbob or whatever...


Oh, and this mvfps...I've heard about this thing before, I just have no clue where to find it. Excuse me for my ignorance pertaining to AVISynth... ;-()

You like masochism, don't you?

go back one page and take a look for 'package'
it should make everything clear.


or go here for lazy persons ;)
http://forum.doom9.org/showthread.php?s=&postid=606487#post606487

[DeathTheSheep]

You like masochism, don't you?

Yes, I'm just a pathetic excuse for an idiot who'd do anything for pain. There i go again... ;-)

[opoman]

Scharfis_brain:

I have been trying (unsuccessfully until a few nights ago) to find an acceptable PAL to NTSC conversion for UK PAL TV broadcast games of rugby, perhaps the stiffest test of a converter as far as motion-fidelity is concerned, with fast panning, zooming and subject movement (my 3.25 minute test clip (125MB) was left with groyal and is presumably still available to those who contact him.http://www.videohelp.com/forum/viewtopic.php?t=255936&postdays=0&postorder=asc&start=90 )

I have tried your mvbob conversion with this rugby clip and the result was a terrific improvement on all that had gone before - the motion is entirely smooth and convincing and the very few imaging artefacts do not, in any way, spoil the viewing.

Congratulations to you and the sources that you used.

The golden priority in viewing rugby games is the motion - mostly horizontal. Any stuttering or flickering drives the viewer nuts after a few minutes - motion smoothness and truth are the key.

As it stood, your script is too good for me - my three minute clip of rugby took six hours to process with my system (tmpgenc or CCE, with a 1Gig PIII and .5 gig RAM). However, one of the contributors to the dvdhelp thread, groyal, has made some modifications to your approach which, while maintaining a watchable standard, have reduced processing time by about a factor of six.

Inevitably, like Oliver Twist, I want more. Is there anything further that you might suggest as a possible way to further adjust the image-quality vs processing time balance in favour of shorter processing time whilst maintaining 'motion-fidelity'.

Though not strictly a cross-post I am aware that by linking the fora I may cause objections. I hope *not* as some cross-fertilisation has already brought considerable benefit.

[scharfis_brain]

However, one of the contributors to the dvdhelp thread, groyal, has made some modifications to your approach which, while maintaining a watchable standard, have reduced processing time by about a factor of six.

I would like to see those modifications

[Richard Berg]

Here's the fast version:


crop(12,6,696,568)
i=bob(height=240)

fwd=mvtools0962_mvanalyse(i,isb=false,lambda=400)
bwd=mvtools0962_mvanalyse(i,isb=true, lambda=400)
i.mvtools0962_mvconvertfps(bwd,fwd,fps=59.94)

AddBorders(12,0,12,0)
AssumeFieldBased()
Weave()

I'm surprised this works well -- vertical resampling usually screws up deinterlacers. Also, the technique of only analyzing an interior block of an image won't work for all sources obviously. The poster does make a great point that mocomp is geometric in the # of pixels; anything you can do to reduce the mocomp'd area will help a lot more than you think.

[opoman]

I'm sorry, Scharfis_brain, my incorrect reference to 'dvdhelp' was a slip of the brain - I should have referred to the link I gave at the top of my piece - there you will find a little more detail than Richard Berg has given.

The latter was surprised that the faster script worked 'well.' That may be a quote from some other assessment but my own finding is that only with specific regard to the sports (rugby)clip's 'watchability', or what you might call motion-fidelity, the faster script does well. Others may want more perfect images.

[scharfis_brain]

better replace
bob() by leakkernelbob(...)

this will reduce flicker and increases detail!

plus, if you are worried about scene changes, take a look at this: http://forum.doom9.org/showthread.php?s=&threadid=90271

though its scene change detection is NOT optimal, it may cause some weird effects. so please test it before using it widely.

the script you are using is halving the resolution and creating a weird bobbing-effect on TV, because the fields become misaligned:
both of your fields share the same vertical position
but the one field needs to be shifted by exactly 1/2 pixel in relation to the other one.

so try this script:

crop(12,6,696,568)
i=leakkernelbob(order=?,threshold=7)

#either
i.mvfpsscd(59.94)
#or uncomment if you dislike mvfpsscd:
#fwd=mvtools0962_mvanalyse(i,isb=false,lambda=400)
#bwd=mvtools0962_mvanalyse(i,isb=true, lambda=400)
#i.mvtools0962_mvconvertfps(bwd,fwd,fps=59.94)

bicubicresize(width,472).AddBorders(4,4,4,4) #only this returns a proper Aspect Ratio -> encode at 704x480
Assumetff().Separatefields().selectevery(4,0,3).weave() #reinterlace



But *MAYBE* you want to go for another approach, that gives semi-smooth motion at much higher processing speed.
but it will only work with slow-speed-shutter (1/50 sec)video.
(motion is blurry)



crop(12,6,696,568)
leakkernelbob(order=?,threshold=7)
last.trim(1,0).mergeluma(last,0.5).mergechroma(last,0.5)
converttoyuy2()
convertfps(59.94)
bicubicresize(width,472).AddBorders(4,4,4,4)
Assumetff().Separatefields().selectevery(4,0,3).weave()

[opoman]

Thankyou for the suggested variations, Scharfis_brain.

I'll try options 2 and 3 when I can discover why leakkernelbob(order=1,threshold=7) is inducing a vertical green stripe at the RHS of my picture. Option 3, as judged in vitualdubmod, looks fast and promising (green stripe apart).

I'm unable to try option 1 as I can't track down a plugin which will induce avisynth to allow mvfpsscd()

[Leak]

Originally posted by opoman
I'll try options 2 and 3 when I can discover why leakkernelbob(order=1,threshold=7) is inducing a vertical green stripe at the RHS of my picture. Option 3, as judged in vitualdubmod, looks fast and promising (green stripe apart).

Try adding "align=true" to the parameters for the Crop above it, that should fix it. Yes, it's a bug, but adding "align=true" should fix it, and might probably even speed things up a little bit.

[opoman]

crop(12,6,696,568,align=true)

unfortunately, doesn't remove the green stripe.

However, crop(8,6,704,568)

is OK.

Trouble is, I haven't yet figured out exactly what is going on so I don't immediately know if Scharfis_brain's crop setting is crucial. Seems, from a quick encode in CCE, and assessment in virtualdubmod, that the script is both phenomenally fast and, maybe, acceptable to watch. I'll know when I put a bunch of these new tests through the player/TV.

[Leak]

Originally posted by opoman
crop(12,6,696,568,align=true)

unfortunately, doesn't remove the green stripe.

Hmmm... I could've sworn that copies the video data so it's aligned again - I guess I'll have to have a look at my code sometime soon...

Anyway, you can also just do the cropping after LeakKernelDeint - since you're only cropping a bit of the edges, deinterlacing a few pixels more is hardly going to hurt.

np: Gold Chains - Citizens Nowhere (Young Miss America)

[psme]

I use the all-in-one rar package and did a test on a short 4mins clip using DVD-Rebuilder. It took around 30 hours on my P4 3G (Northwood) 512M DDR333.

The clip is from the first 2 chapters of a DVD which is in pure 480i NTSC format of real video content. For some reason the encoded clip becomes in 25fps format and everything is in slowwwwww motion!

Do I need to use mvfps to convert it back to normal NTSC rate? I thought the default mvbob() will keep the format as is, or not?

Thanks in advance.

regards,

Li On

[scharfis_brain]

30hrs. is definately far too much.

on the page befor, 2bdecided experienced a similar problem!

on my athlonXP 1600+ it run at about 1 to 2 fps

also mvbobs output is always doublerate.

please post your script!
(and maybe a source sample - an unprocessed one!)

[opoman]

Odd result for the speed. My standard 3min 25sec PAL rugby clip took 6 hours for CCEbasic to convert to NTSC, using a 1Gig PIII and now, I've just tested it with a brand new 3Gig P4 and it went four times faster - maybe the difference is in the encoder settings and the known fact that CCE is faster than some others.

Maybe you meant 3 hours rather than 30.

[scharfis_brain]

@opoman: your times are realistc.
you can achieve a speedup, if you do

mvbob()
resize()
mvfps()

(this is, because the image is smaller for NTSC)

btw. last week, I finished a whole 2hrs video standards conversion from NTSC to PAL.
all together it needed about 4days of continous processing

but its results are astonishing.
you won't even notice, that the source was NTSC!

btw.: it was an adult movie, cause I did not have any other long contnuous NTSC video.
also this kind of video has
*ermmm* lots of overlapping, covering and periodic/rapid moving objects :p :p :p
so its easy to search for the artifacts, if you know, what I mean.
(finally, I can watch it on my TV set, which is unable to display 60 Hz! :D )

[psme]

Avisynth script reported by RB-Opt:

1 - #------------------
2 - # AVS File Created by DVD Rebuilder
3 - # VOBID:01, CELLID:01
4 - #------------------
5 - LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
6 - mpeg2source("E:\dvd-rb-in\D2VAVS\V01.D2V")
7 - trim(0,5862)
8 - setmemorymax(384)
9 - import("C:\Program Files\AviSynth 2.5\plugins\mvbob.avs")
10 - assumetff()
11 - mvbob()
12 - ConvertToYV12()

I use the default QuEnc 2 pass encoding. I think during the first chapter encoding QuEnc reported framerate is around 1.3fps then the second chapter encoding speed drop to around 0.2fps.

The super long processing is not the issue. My problem is why the source 29.97 480i NTSC became in 25fps PAL format!

There is nothing special about my test clip. It is just a ramdom selection of a normal NTSC VIDEO content DVD. I can provide the VOB if needed but I really don't think the source is the problem. Maybe it's the DVD-Rebuilder? Though I just use their latest Installer release with almost all the default config, except the use of Avisynth process of course.

regards,

Li On

[scharfis_brain]

try this script


import("C:\Program Files\AviSynth 2.5\plugins\mvbob.avs")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
mpeg2source("E:\dvd-rb-in\D2VAVS\V01.D2V")
trim(0,5862)
assumetff()
mvbob()


also never encode directly, because a second automated pass will cause weird thigs!
process to an intermediate file (HuffYUV!) before encoding!

The super long processing is not the issue. My problem is why the source 29.97 480i NTSC became in 25fps PAL format!

are you sure, that your encoder is able to understand 59.94 fps progressive?
do you own devices being able to play back 480p59.94 ?!?

[Xesdeeni]

Originally posted by scharfis_brain
also never encode directly, because a second automated pass will cause weird thigs!
process to an intermediate file (HuffYUV!) before encoding!Given that AVI files are limited to 4 GB (2 GB by some programs). I'd guess that's 8-12 minutes a file, so it will require multiple files.

Xesdeeni

[scharfis_brain]

@Xesdeeni:
that's wrong!
AVI files can be easily made much larger than 4 GB.
The only thing required is a File System different than FAT(12/16/32).

so use win2k or xp and you won't get into file size trouble!

[psme]

Originally posted by scharfis_brain
The super long processing is not the issue. My problem is why the source 29.97 480i NTSC became in 25fps PAL format!

are you sure, that your encoder is able to understand 59.94 fps progressive?
do you own devices being able to play back 480p59.94 ?!?

Sorry, I'm new to encoding so I don't really understand your question. I use the DVD-Rebuilder bundled QuEnc encoder (version 0.59 I think). The source VOB is of course in 29.97p/59.94i normal NTSC video content. My playback is via DScaler 5 decoder (forced Weave deinterlace) with FFDShow processing. FFDShow Info read the correct 29.97fps on the original VOB. The mvbob() re-encoded VOB read 25fps in FFDShow and everything is in slowwww motion!

regards,

Li On

[scharfis_brain]

a SDTV MPEG2 encoder does not accept 59.94PPPPPPPPPP!!!
so it may have gotten confused with it and falled back to (wrong) 25p.

mvbob always does 59.94i -> 59.94p for NTSC
and 50i -> 50p for PAL.

so it effectively doubles the framerate!

what is your final intention by the use of mvbob?

[psme]

I see! Thanks for the explanation!

My intention is to see the effect (and power!) of your mvbob VIDEO deinterlace quality, for normal DVD playback on a HTPC to a projector on a big screen!

On standalone hardware processing, so far the best quality on pure video source deinterlace is the Faroudja DCDi processing IMO.

On a PC, IMO, the DScaler's MoComp2 video deinterlace gives the best image quality, followed by TomsMoComp.

And I always want to see a motion compensation video deinterlace processing. I thought the mvbob claim something like that so I want to see it's quality.

The perfect way should be just apply mvbob in Avisynth inside FFDShow during real time DVD playback. But on my p4 3G the framerate is less than 2fps I think! The image itself seems correct but with a <2fps I can't really judge the picture quality!

So my only choice is to do a re-encoding with the best encoding quality possible together with the mvbob processing.

I guess my question will be, which (cheap) MPEG2 encoder does 59.94p processing to be used with mvbob processing?

Thanks in advance.

regards,

Li On

[scharfis_brain]

why mpeg2?
just use xvid with fixed quant of 2 or 3 for testing purposes!

[psme]

Indeed, why MPEG2? Stupid me! I bet at the same bitrate Xvid can't look worse than any MPEG!

Though I need to do some research on Xvid encoding though...

regards,

Li On

[Xesdeeni]

Originally posted by scharfis_brain
that's wrong!
AVI files can be easily made much larger than 4 GB.
The only thing required is a File System different than FAT(12/16/32).

so use win2k or xp and you won't get into file size trouble! Well, in the case of the above process, it looks like you are right, there isn't a 4 GB limit. Sorry.

But, in order for an AVI file to be compatible with all applications, it must be less than 2GB, regardless of the file system. Many applications can handle 4GB, so that is often safe as well.

In order to support larger than 4GB, the application must support the OpenDML extension. Several of the applications I use regularly don't, so I stuck that 4 GB limitation in my head as a general rule. But, it looks like both VirtualDub and AVISynth support this extension, so for the above process, it should work.

Does anyone know if the specific codec can interefere with this?

Xesdeeni

[scharfis_brain]

I NEVER cared about AVI file sizes, cause I ALWAYS process to segmented AVI, to be able to resume crashed processings more easy (in common, only the last segment is defective, after a crash).
This is also important, because I cannot run my PC over night. The HDDs are far too loud (sounds like a circular saw).

also, I never feed my applications directly with avi.
everything passes AVS.

[Xesdeeni]

Well, that's confusing. How can you not feed directly, but not use AVI's either!?

Xesdeeni

[scharfis_brain]

1) source preparation
DVD or DV sources -> some painfully slow and instable AVS processing -> segmented AVIs (Huffy)

2) encoding or cutting
segmented AVIs -> AVS (trim all attempts to one complete vidoe)-> encoder or editing program

is this THAT complicated???

[Xesdeeni]

Originally posted by scharfis_brain
is this THAT complicated??? Hey, you're the one that saidalso never encode directly, because a second automated pass will cause weird thigs!
process to an intermediate file (HuffYUV!) before encoding!and thenalso, I never feed my applications directly with avi.
everything passes AVS.Wait! Now I get it. You use an intermediate AVI, but you don't let the application load the AVI directly, you use AVISynth...sometimes the thickness of my skull surprises even me.

Xesdeeni

[kle500]

Originally posted by scharfis_brain
last week, I finished a whole 2hrs video standards conversion from NTSC to PAL.
all together it needed about 4days of continous processing

but its results are astonishing.
you won't even notice, that the source was NTSC!

btw.: it was an adult movie, cause I did not have any other long contnuous NTSC video.
I was looking to do the same for the same type of video (adult NTSC interlaced).
with the mvbob.rar package, there are heavy artifacts (paterns) during scene change.

Can you please tell me what exact script you used, to achieve these results?
Cause i am quite sure that you noticed many patern artifacts to your convertion too.

Right now i am trying this script, with different deinterlacer. (smoothdeinterlacer).
I am stuck with smoothedeinterlacer, cause it doesn't produce the artifacts that i see with, either kernelbob, or Leakkernelbob.
But i use a modified script of smoothdeinterlacer, that get rid of black horizontal lines during movemet.
Below is the script i am testing right now:
Import ("C:\Program Files\AviSynth 2.5\plugins\mvfpsscd.avs")

Mpeg2Source("xxx.d2v")

ConvertToYUY2(interlaced=true)
i=SmoothDeinterlace(doublerate=true,tff=true,lacethresh=1,staticthresh=10,showlace=false).converttoYV12()

i.mvfpsscd(50)
Lanczos4Resize(width,576)
Assumetff().Separatefields().selectevery(4,0,3).weave() #reinterlace
Allthough, there are still some artifacts (paterns) during fades, using the mvbob script, is worst, and a lot slower.
So can you tell us what script you used please? :) :)

[scharfis_brain]

please post a picture of those artifacts.

yes. mvbob() creates some weak artifacts on scene changes.
(they didn't bother me, because: hey its just a scene change :) )
they can be lowered by playing with th

and please: drop smoothdeinterlacer!
use TDeint(mode=1) instead!

[kle500]

@scharfis_brain

...hmmm. you know i can't post a picture here...
it's realy hard for me to find a nice frame to post.

I will try the Tdeint, thank's

if you want, i can send you some samples...

[kle500]

@scharfis_brain

With smoothdeinterlace, i have 2x the speed i have with Tdeint,
using a simple script NTSCi -> PALi
Why is that?
Is it correct?

[Tommy P]

Hi everybody!

First of all, thank you, scharfis_brain, for a great toolbox! And thanks to everybody who participated in this thread; for me the educational value I found here was unmeasurable.

I have a couple of questions though.

I shot some wedding video on a regular NTSC miniDV camera, then captured it using Premiere Pro 1.5. So it should be YUV 4:1:1, right? Well, when I use DirectShowSource("Clip.avi") to open the file in VDubMod, and then go to File -> Info, it shows as YUY2 4:2:2. Why? (When I use AVISource("Clip.avi"), the Panasonic DV codec installed on my computer spits out RGB, so it doesn't tell me anything about the original format.)

Next, I put together a video in Premiere Pro, add titles, transitions, etc. Then I export the finished video to uncompressed (well, to Huffyuv actually), and the output turns out to be RGB32. Why is that? I expected the output to be YUV, as I thought Premiere Pro could handle YUV internally?

OK, so far so good. Now I'm trying to do NTSC --> PAL conversion. Say, the exported clip is called Finished.avi (remember, it's RGB32)

Is there anything obviously wrong with this script, considering that I'm going to import the converted video into Premiere Pro again (but this time into a PAL project), and then use built-in MediaConcept encoder. My final destination is a PAL DVD.

########################################################
avisource("Finished.avi")
converttoyv12(interlaced=true)
mvbob()
lanczos4resize(width,576)
mvfps(50)
converttoRGB(interlaced=false)
assumebff().separatefields().selectevery(4,0,3).weave()
########################################################

Also, I'm a bit unclear about all this color conversion stuff, in particular, RGB32 vs RGB24. Does Premiere Pro really use the alpha channel? If not, can I force the output to be RGB24 to save space?

Thanks a lot!
Tommy

[vinetu]

Originally posted by Tommy P
Well, when I use DirectShowSource("Clip.avi") to open the file in VDubMod, and then go to File -> Info, it shows as YUY2 4:2:2. Why?
The DirectShow DV decoder filter installed on your computer spits out YUY2.
Originally posted by Tommy P
Next, I put together a video in Premiere Pro, add titles, transitions, etc. Then I export the finished video to uncompressed (well, to Huffyuv actually), and the output turns out to be RGB32. Why is that?

Output in Premiere Pro should be YUV only if you export to DV and the timeline contain only DV - All other cases output is RGB32.
Originally posted by Tommy P
Is there anything obviously wrong with this script...
Yes. Don't use "mvps(50)" and "assumebff().separatefields().selectevery(4,0,3)" in the same time.
Originally posted by Tommy P
Does Premiere Pro really use the alpha channel? If not, can I force the output to be RGB24 to save space?
Ha! This sound like "Does the autos realy use 4 wheels -I see only 3..." :)
In older versions it was possible to choose 24 or 32 bit - I doubt it's possible in PPro

[Tommy P]

Thank you, vinetu, for your quick response.

You wrote:
Don't use "mvfps(50)" and "assumebff().separatefields().selectevery(4,0,3)" in the same time

Do you mind explaining why? How would you correct this part of the script?

With respect to my other question ("Does Premiere Pro really use the alpha channel?"), perhaps I didn't make myself clear enough. What I was trying to ask was this:

How do I find out whether the Premiere uses the alpha channel in my particular project? Because if it doesn't, I'd like to strip it off when saving.

Thanks a lot!
Tommy

[morsa]

I started using MVBob today (I downloaded the mvbob.rar package).
I have an NTSC clip of a bridge passing through the screen which is giving me lots and lots of artifacts that make it unusable.
I'm using plain mvbob() function.May be I'm some way a little bit stupid and I need to tweak things a lot, but problem is after reading the whole thread I don't know where to start or what to change :( .
I also PM Scharfis offering the clip to use it as a torture one.

PS: BTW everytime I try to load mv60ito24 or mvfps any version of Vdub and/or VdubMod exit unexpectedly.I suspect It should be something related to Mvtools, but I don't really know.
I have P4 Prescott Hyperthreading 3.4 GHZ.

[scharfis_brain]

all other deinterlacers do fail on these clips, too!

so mvbob() must fail, because its mv-artifact-prevention relies on the standard-deinterlacers.

only the newest version of Tdeint introduces the ap-parameter, that is intended to deal with these artifacts.

[morsa]

yes, I know.It is just that MVbob, specially on the bridge clips, gives so many misaligned blocks that the clip gets really a mess.
I will see what happens if I use despot after it, may be I can treat those blocks as if they were "spots" :)

[Xesdeeni]

Can you post a couple of fields/frames just for reference?

Xesdeeni

[Krizzz989]

Originally posted by scharfis_brain
if your mvbob() is painfully slow, just comment out the extended motion search parameters:

mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,chroma=true)#,search=3,searchparam=10)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true, chroma=true)#,search=3,searchparam=10)
I'm new to avs script editing, how do I comment out these two lines? Thanks in advance for any help.

[scharfis_brain]

the item I mentioned is already excluded from execution.
it is the code after the # - chars

[dragonfly]

What am I doing wrong?
I tested mvbob and the output was very good. But it wasn't playing smooth. Very very jerky output. I tried the following.
I used the zipped file from scharfis_brain. Thanks by the way for making life a bit easier :)

The source video was a vacation in Barcelona. It is a Pal - 25 fps - interlaced DV-movie. The colorspace is on my computer is YUY2.
The test material was 4 seconds in a shopping mall. The cars that drove through the shot were giving some artifacts on the video because they were driving fast.

I used this avs for the video.

LoadPlugin("\convolution3d.dll")
LoadPlugin("\UnDot.dll")
LoadPlugin("\MaskTools-v1.5.6\MaskTools.dll")
LoadPlugin("\warpsharp.dll")
LoadPlugin("\LoadPluginEx.dll")
LoadPlugin("\DustV5.dll")
LoadPlugin("\aWarpSharp.dll")
LoadPlugin("\DGDecode.dll")
LoadPlugin("\asharp.dll")

SetMemoryMax(256)

Import("D:\Captures\Avisynth Scripts\iip v0.5a.avs")
Import("D:\Captures\Avisynth Scripts\LimitedSharpen1.avs")
Import("D:\Captures\Avisynth Scripts\mvbob testing\mvbob.avs")

AviSource("\Testmaterial DV.avi")

Converttoyv12(interlaced=true)
assumebff()

mvbob(blksize= 8,
\ pel= 2 ,
\ lambda= 1000,
\ th= 8,
\ ths= 4,
\ bobth= 8,
\ predenoise= false
\ )


I loaded this avs-file in virtualdubmod and choose full processing mode without compression (virtualdubmod says "no compresion rgb", however my file is yuy2. Does this mean virtualdub converts the colorspace again?)
The encoding of this was very slow. 1 frame per second. And my harddisk was going insane through the whole encoding process. The source video is 13.7MB and the output video was 237MB!! How can this be?

I checked the logfile of virtualdubmod 1.5.10.1 and it was giving me this error al lot of times:

[i] Starting up: VirtualDubMod build 2439/release

[!] Dub: I/O thread has not cycled for ten seconds -- possible livelock.
(Thread location: 7C90EB94)


To come back where I began...What am I doing wrong? And what would you advise me?

[dragonfly]

Why can't CCE read this script?
Everytime I try to use mvbob in CCE it gives me an error. (http://img205.echo.cx/my.php?image=error8xa.jpg)

I eventually want to encode my file (look at the post above) with cce and burn it to dvd later.
[list=1]
Use script from my previous post to deinterlace the raw avi with mvbob in virtualdub.
Load the deinterlaced file from step 1 into another avs-script and use the filters iip and limtitedsharpen.
Load the script from step 2 into CCE and encode it.
Author the resulting file and burn it to dvd.
[/list=1]
Is this an efficient way of working?

[Mug Funky]

200/4 = 50. maybe HDTV can do this, but not CCE.

use "selectodd" after mvbob.

[dragonfly]

Thanks Mug Funky, it worked. But I want to know why I must put this in avisynth. I read that Selectodd() selects the even frames, but what has this to do with CCE? Does CCE always divide by 4? Because then I understand --> The clip is 100 frames, if I put SelectOdd() in the script then CCE selects 100 frames and divides it by four. If not it doubles the frames.

Sorry to go offtopic, but I want to understand this.

[scharfis_brain]

CCE only supports SDTV-framerates!

meaning:
23.976 fps NTSC Film (propressive)
25.0 fps PAL (progr. and interl.)
29.97 fps NTSC video (progr. and interl.)


50 or 59.94 fps, which are produced by bobbing in general and by MVbob also aren't supported by CCE, because those framerates are not SDTV!

[2Bdecided]

This post is about the motion compensated framerate change, rather than the motion compensated deinterlace, but since both are used in the PAL>NTSC conversion that we're discussing, I'll post here...

I've just used this package to convert a PAL video of a school play to NTSC. I used LeakKernelDeint(order=1) instead of mvbob because it increased the conversion speed significantly.

Overall the converted output was of excellent quality - better than you usually see on, say, BBC America.

However, there's a persistent problem which may be worth looking at - it happens in the test clips I used before, and happened a lot in this school video: Where you have a border between two very different colours (e.g. golden angel's wings and black background, or white paper and brown wall, or whatever), then (even when the scene is relatively, but not completely static) small slithers of one colour will briefly break out into the other colour. It seems to happen around vertical transitions, rather than horizontal (as far as I've noticed). I assume it's an issue with the motion vectors, but haven't checked. It's still there with mvbob - in fact it has nothing to do with the choice of deinterlacer.

It's a pity, because otherwise the conversion quality would be excellent. Though one other thing I noticed: when the teacher wagged her finger quickly, her finger disappeared!

I'm not posting to criticise or complain, just to point out areas for improvement, if the developers are interested.

Cheers,
David.

[Xesdeeni]

Did you notice whether this effect was in the original? DV recordings (at least NTSC ones) use 4:1:1. This means a single color is shared by four pixels. Most of the time, the colors are similar, so no harm. But if the difference between them is sufficient, there are very visible color errors.

I'm not sure about PAL DV. I've read that it can actually use either 4:1:1 or 4:2:0. But I think the choice is up to the camera.

A while back I tried to create a VirtualDub filter that helped with this. My idea was to use the luma (the 4) information to guess what the chroma (the two 1's) should be. I called it "Luma Follow." I also put in basic linear interpolation. Luma Follow didn't work as well as I expected, and I had to do some clamping that I didn't expect. The interpolation looked better. But either looked better than the DV codec output I use (MainConcept). You can find the filter and some samples at http://www.geocities.com/xesdeeni2001/.

For details, see this thread (http://forum.doom9.org/showthread.php?s=&threadid=58294), specificially this post (http://forum.doom9.org/showthread.php?s=&threadid=57013&perpage=20&pagenumber=2). For updates, see this thread (http://forum.doom9.org/showthread.php?s=&threadid=57013).

Xesdeeni

[Wilbert]

I'm not sure about PAL DV. I've read that it can actually use either 4:1:1 or 4:2:0.
I don't think you have read that somewhere :) It's 4:2:0 (with different sampling as MPEG-1/MPEG-2).

[2Bdecided]

Thanks for the reply Xesdeeni, that looks very useful - but it's not what I'm seeing here! What's happening is nowhere near as subtle, and is certainly not on the source - though it could easily be due to the motion compensation getting confused by slight colour bleed or noise in the source.

Imagine a big block of black next to a big block of white, like this...

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
this part is black this part is white

When there's some slight movement (e.g. a very slow camera pan), very occasionally the black part breaks out into the white, like this...

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX /
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

or something like that! I'll have to play with some parameters, because that might tame it, but I'm not going to redo the whole video because it took 8 hours and it's done and sent now!

Cheers,
David.

[Xesdeeni]

Originally posted by Wilbert
I don't think you have read that somewhere :) It's 4:2:0 (with different sampling as MPEG-1/MPEG-2).My bad. PAL DVCPRO 25 is apparently 4:1:1.

Xesdeeni

[vcmohan]

2Bdecided
It is not clear to me whats happening. Can you put different symbols for black and white pixels?

[2Bdecided]

Here's an actual example...

http://www.david.robinson.org/pics/mvfps_issue.jpg

PAL on the left, converted to NTSC on the right - just a small section, with the PAL original resized to make the comparison easy. The original was deinterlaced using mvbob, the conversion shot was grabbed before being re-interlaced.

The camera is tracking a character walking off to the right, so the stationary golden pillar is moving to the left of the shot. As you can see, the gold breaks out into the black during the conversion.

I wonder if it's noise or colour bleed on the original confusing mvfps, because the transition from gold to black looks very obvious to the human eye - so when it goes wrong, it's very obvious. It only happens for one field, so it draws your attention as a "flash" on the screen - and it happens reasonably often - you'll see something like this maybe 5-15 times in ten seconds of video if there's any panning.

I can't release the clip because it's not mine, but I see a similar thing with mvfps PAL>NTSC conversion on the SVT new mobile and calendar shot that's here:

http://www.ldv.ei.tum.de/liquid.php?page=70

A similar thing happens - the white of the calendar breaks out into the brown of the wallpaper.

It's only a little thing, but I thought it might help to know about it. If not - ignore it!

Btw, if there is a setting I should change to reduce this particular type of artefact, please let me know.

Cheers,
David.

[WorBry]

Mug Funky or Scharfis_Brain,

Until recently I've been using TDeint for deinterlacing my Pal DV Type II home movies prior to conversion to DivX at 50fps, as follows:

AVS Script:
avisource("Clip.avi")
ConvertToYUY2(interlaced=true)
ColorYUV(off_y=-16,gain_y=16) # to correct luma shift with Sony DV codec
TDeint(mode=1,order=0)
LanczosResize(720,544)
Convolution3D(1,4,5,3,4,2.8,0)
RemoveGrain(mode=2)
#
DivX 6 settings:
4000 kbps
2-pass
Unconstrained
EXtreme
key frame 250
B Frame single
no PV or GMC

The results have been very good, but having now tried MVBob in place of TDeint, I can only say WOW - slow, thats for sure, but well worth the wait. However, having looked at the MVBob script, which I cant pretend to fully understand, I see that it incorporates pre-denoise filters - Undot and Temporal Smooth. I know that image quality is somewhat subjective, but from a theoretical viewpoint, do you think that l should drop RemoveGrain from the script, and possibly also Conv3D? Alternatively, would it do any harm to replace Undot with RemoveGrain in the MVBob script. My only reasoning is that I found RemoveGrain to marginally improve the compressability of my DV clips compared to Undot, as also did Conv3D.

Although not specifically related to AVISynth, would you also recommend switching on "Global Motion Compensation" in the DivX settings, or is that dealt with by MVBob?

Any other pointers you could suggest for optimizing the results with Pal DV sources would be really appreciated, as after all of this experimentation, I'm keen to settle on a standard format.

Great work you guys. Frankly the results I've been getting with MVBob have quelled any notion I was having about changing to a progressive scan camcorder, much to my wife's relief....well, at least until they become more financially accessible (the camcorders that is) :)

[scharfis_brain]

pre-denoise is only used for a initial bob-deinterlace to make the motion mask more stable. It will NOT reach the output. It is only used for motion-vector search.
Undot ist used to remove some orphan pixels that occur during the EDI (Edge directed interpolation).

[WorBry]

Thanks alot for your speedy and helpful reply

[ariga]

To get half the frame rate out of mvbob in one of the posts it is suggested to use selecteven and another post later suggests selectodd. Does it make a difference ? Also for PAL DV, is anything else needed before/after mvbob() ?
Thanks.

[akoten]

I'm using the following script on a 20min PAL-DV movie:

Import("C:\Programme\AviSynth 2.5\plugins\mvbob.avs")
AVISource("dv.avi")
(Trim(373,25697)++Trim(26237,33349)).FadeIO(50)
MVbob(quick=false)
Lanczos4Resize(768,576,0,2,720,574)
overlay(SelectEven(),SelectOdd(),opacity=0.5,output="yuy2")

The vfw-decoder for DV comes from ffdshow. I load the script in VdubMod1.5.10.2 and select "fast recompress" and "encode to VP70" (or MJPEG via ffdshow, that doesn't matter). After some while Vdub crashes without any message.

Somewhere I read that mvtools had a memory leak problem. So I updated it to version 1.0.3. But no difference.

Somewhere I read that I should have at least 1GB of RAM. Well I only have 128MB (on WinXP-SP2). Please, could somebody confirm that this is definitively too less?

Another topic at the end: I know that with the last line (overlay) the resulting overall process is quite similar to a simple blended deinterlace but IMO the movie looks much better (although the conversion speed is very close to "untolerable" :sly: ). What deinterlacing method is best if my hardware can't play 50fps in realtime?

regards
AKo

[foxyshadis]

Something that might help, try installing Tritical's 2.5.7-pre Avisynth (http://bengal.missouri.edu/~kes25c/Avisynth_311205.exe), which should at least pop up an error when it crashes.

Also ensure that you have the latest mvbob (http://forum.doom9.org/showthread.php?p=757259&highlight=mvbob#post757259), which uses the latest mvtools.

128 megs on XP, doing video processing? Ouch... Hope you have nothing else open, and setmemorymax(48) or so. With a heavy script I can use up to 400-500 megs during processing, just for avisynth, and mvbob counts as heavy. It may well be the source of the problem, though it seems more likely the system would just swap like mad. Maybe you need more swap file.

At the end, if you're asking about deinterlace during playback, leakkerneldeint is very fast and should work even on older systems. If you mean deinterlace during script, well, mvbob is where it's at.

[akoten]

@foxishadis:

Latest mvbob does NOT include latest mvtools. Although there is no version description somewhere in the mvtools.dll I suppose it is something around 0.9.8.x. Latest stable version is 1.0.3, or even newer is version 1.1 alpha.

Did I really write 128Megs? I meant 256MB. With swap file 768MB altogether. Anyway, I can see that there is really quite a bit of action on my swap file. But should this really lead to a crash without even an "out of virtual memory" message? What is "setmemorymax(48)"? Where to configure?

However, I'll try the Avisynth-version you suggested and let you know. Currently I just have 2.5.6 running.

Something interesting maybe is that with latest official Vdub (1.6.11) I get MUCH more frames processed than with VdubMod. And another thing is that with 1.6.11 the processing speed is around 0.5fps and with VdubMod it is around 1.5fps.

Why I was asking for the best deinterlacing method (during script only, of course!) is that my "overlay()" method produces "transparent" objects (opacity=0.5!) where they are moving. What I would like is that moving objects have the same brightness as if they were static. I have no idea how to achieve that, but maybe somebody made up his mind about this kind of question.

[foxyshadis]

What you're doing is just a cheap hack, what you really want is motion blur (http://forum.doom9.org/showthread.php?p=615027#post615027). Here's a version that uses the newer mvflowfps. Slooooow though.


function mvfpssimple(clip i, float fps, float "shutter")
{
shutter=default(shutter,50.0)
fwd=MVAnalyse(isb = false, blksize=blk, truemotion=tm, pel=2, idx=4)
bwd=MVAnalyse(isb = true, blksize=blk, truemotion=tm, pel=2, idx=4)
MVFlowBlur(bwd,fwd,blur=shutter)
}

MVFlowBlur encapsulates the idea of mvfps in one function. Increase shutter to decrease the amount of blurring. Prepare for amazingly slow render times.

In other news, setmemorymax(x) is a directive you place at the top of scripts to limit mem use. I'm not sure what the default is (should be low), but you might need to either lower or raise it.

You're right, by the date on the mvbob mvtools.dll, it's v1.0. I just wanted to make sure you had the latest script, though.

[Xesdeeni]

I load the script in VdubMod1.5.10.2 and select "fast recompress" and "encode to VP70" (or MJPEG via ffdshow, that doesn't matter). After some while Vdub crashes without any message.Maybe it's just me, but I've found VirtualDubMod to be very unstable. Heck, just choosing File|File Information... causes it to crash. The only reason I use VDM is if I want to add an AC3 stream and edit it. I have to save often to avoid having to start over. They say VDM will handle YV12, but I can't get it to do so. And it's MPEG-2 decoder doesn't pay attention to the flags, so it's useless for that. I usually stick with the original VirtualDub.

Xesdeeni

[scharfis_brain]

256 MB is FAR to less for mvbob!
even with my 768 MB I am getting into trouble very often!

also avoid the blending used.

mvfpssimple() can simulate slower shutters for you but at another cost of speed and RAM.

Get at least 1 GB of RAM to get mvbob() and mvfpssimple() running stable!

[akoten]

function mvfpssimple(clip i, float fps, float "shutter")
{
shutter=default(shutter,50.0)
fwd=MVAnalyse(isb = false, blksize=blk, truemotion=tm, pel=2, idx=4)
bwd=MVAnalyse(isb = true, blksize=blk, truemotion=tm, pel=2, idx=4)
MVFlowBlur(bwd,fwd,blur=shutter)
}



This function does not work, until some adjustments are made. Obviously you just wanted to give me a hint how to do the final programming myself, right? Anyway, I was not able to manage a down-conversion from 50fps (mvbob) to 25fps with MVFlowBlur.

To repeat my wish: I want the result to be 25fps, the moving objects should be as clearly visible as possible, and they should be as close to the original objects regarding transparency as possible. What exactly do you think is bad about my idea with "overlap()" except that here transparency is always 50%?

In my opinion blurring is not a good idea, because it would remove second level motion in moving objects (like e.g. the rotation in a flying ball).



256 MB is FAR to less for mvbob!
even with my 768 MB I am getting into trouble very often!


I just bought 1GB of RAM and :thanks: it crashed quite a bit later. After also rising virtual RAM to have 2.5GB overall, it worked for my 21min clip. The result should have been a DV (via ffdshow encoder) but it looked kind of destroyed. So I reran with encoder=MJPEG and again it crashed. Unloading the script, loading it again and then converting finally WORKED! So I'm quite sure that there still is some kind of memory leakage somewhere in mvbob or it's subfunctions.



Maybe it's just me, but I've found VirtualDubMod to be very unstable.


You're quite right! I only use VDM for simple MPEG2's (coming out of PVAstrumento) and for AVISynth scripts. At least AVIsynth-script support is a thing VD really should support, don't you think? However I found that the crashes I mentioned in my post do not have anything to do with VDM.


AKo

[Xesdeeni]

At least AVIsynth-script support is a thing VD really should support, don't you think?You can't get VirtualDub to work with AVISynth scripts? It works fine for me. I've had no problem on 5 computers across 8 different o/s installations (Windows ME, Windows 2000, Windows XP SP1 & SP2). I've been using VirtualDub to test my scripts before feeding them to anything else since before version 1.4. The only time I used VirtualDubMod was when I wanted to edit an AC3 audio stream without decoding and re-encoding it.

Xesdeeni

[akoten]

You can't get VirtualDub to work with AVISynth scripts? It works fine for me. I've had no problem on 5 computers across 8 different o/s installations (Windows ME, Windows 2000, Windows XP SP1 & SP2). I've been using VirtualDub to test my scripts before feeding them to anything else since before version 1.4. The only time I used VirtualDubMod was when I wanted to edit an AC3 audio stream without decoding and re-encoding it.

Xesdeeni

I mean support for EDITING AVIsynth scripts

AKo

[foxyshadis]

VDubMod had it, Avery never felt like keeping it and fleshing it out. Ask him or fcchandler (vdub-mpeg2) what their plans in the area are.

[zlab]

Hi,
I hvave difficulty to run mvbob() inside the mvbob.rar package,
it always return error: "Scipt error: there is no function named: corrector"
anyone kind enough to give me a hand?
I also found a script mvbob1 seen work as good as mvbob as follows:

function MVbob1(clip c,int "blksize", int "pel", int "lambda")
{
order=(c.getparity==true)? 1:0

blksize=default(blksize,8)
scd=(blksize==8)? 300 : round(300/4)
pel=default(pel,1)
lambda=(blksize==8)? default(lambda,2000) : default(lambda,1000)

bobd=c.Leakkernelbob(order=order).verticalreduceby2()
fields=c.separatefields()
mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true)

even1=c.separatefields().selecteven()
odd1a=fields.mvcompensate(mvf,mode=1,thscd1=scd).selecteven()
odd1b=fields.mvcompensate(mvb,mode=1,thscd1=scd).selecteven()
odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)

even2=c.separatefields().selectodd()
odd2a=fields.mvcompensate(mvf,mode=1,thscd1=scd).selectodd()
odd2b=fields.mvcompensate(mvb,mode=1,thscd1=scd).selectodd()
odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd1b,0.5)

even=interleave(even1,odd1).weave()
odd=interleave(even2,odd2).weave()

interleave(even,odd)
}

what's the different?
also, someone send me a script, use whenever the edge not proper deinterlace, usage: mvbob().AAAFaster()

function AAAFaster(clip clp, bool "Scale2X")
{
Scale2X = default( Scale2X, false )
clp.Lanczos4Resize(clp.Width * 2, clp.Height * 2)
TurnLeft().SangNom().TurnRight().SangNom()
return Scale2X ? last : ReduceBy2()
}

[AVIL]

Hi,

The filter "corrector" is not included in the last version of mvtools. Its now a standalone plugin, available at Fizick site.

See:
http://forum.doom9.org/showthread.php?p=786515#post786515

[zlab]

Thanks for your kindly info.

[Xesdeeni]

The most impressive thing about the Olympics was the outstanding standards conversion. The video was all 50i HD converted to 60i HD for American broadcast. I saw a few artifacts, but in general, the conversion was fabulous. I suspect on SD broadcasts, the artificacts would have been invisible.

Maybe someday this mocomp technique will approach that quality on PC-powered machines.

Xesdeeni

[kle500]

Hello everyone.
I am trying to do a standards conversion on NTSC(i) -> PAL(i), and i wanted to give a try to MVBOB.
I downloaded the Mvbob.rar file, and used this script.

#Import ("C:\Program Files\AviSynth 2.5\plugins\mvfpsscd.avs")
import("C:\Program Files\AviSynth 2.5\plugins\mvbob\mvbob.avs")
LoadPlugin("C:\DVD UTILS\dgmpgdec146\DGDecode.dll")
Mpeg2Source("G:\test\VIDEO_TS\test.d2v",idct=0)
mvbob()
lanczos4resize(width,576)
converttoyv12()
MVfps(50)
converttoyuy2()
assumebff().separatefields().selectevery(4,0,3).weave()

but i get "THERE IS NO FUNCTION NAMED MVFPS".
I tryied Avisynth 2.54 - 2.55 - 2.56, none of them worked.
I am sorry for the noobie question, but i am completly lost here.
Can someone suggest a script on testing the Standards Conversion with Motion Compensation?

Right now i am using other deinterlacers with good results, but not good results in panning camera.
That's why i want to test this aproach.
Any help will be welcome.

Kind Regards

[Mug Funky]

try uncomment the first line that loads the mvfps function :)

[edit]

btw, if you want to try out a mocomp script, here's a simple one that gives good results on talking heads and such. deinterlacing isn't so important if your output is interlaced too - the artefacts aren't bad if your threshold is too low.

try leakkernelbob + clouded's "motionprotectedfps", then resize to pal and re-interlace. it's very fast, especially if you're used to mvbob + mvfps...

[Backwoods]

The most impressive thing about the Olympics was the outstanding standards conversion. The video was all 50i HD converted to 60i HD for American broadcast. I saw a few artifacts, but in general, the conversion was fabulous. I suspect on SD broadcasts, the artificacts would have been invisible.

Maybe someday this mocomp technique will approach that quality on PC-powered machines.

Xesdeeni

Thought so? I thought the complete opposite. It looked like a blocky mess to me.

[kle500]

try uncomment the first line that loads the mvfps function :)

[edit]

btw, if you want to try out a mocomp script, here's a simple one that gives good results on talking heads and such. deinterlacing isn't so important if your output is interlaced too - the artefacts aren't bad if your threshold is too low.

try leakkernelbob + clouded's "motionprotectedfps", then resize to pal and re-interlace. it's very fast, especially if you're used to mvbob + mvfps...
Realy appreciate you help.
I did uncomment the first line of the above script, but it didn't make any difference.
I am trying now this script:

Import ("C:\Program Files\AviSynth 2.5\plugins\mvfpsscd.avs")
import("C:\Program Files\AviSynth2.5\plugins\mvbob\mvbob.avs")
LoadPlugin("C:\DVD UTILS\dgmpgdec146\DGDecode.dll")
Mpeg2Source("G:\test\VIDEO_TS\test.d2v",idct=0)

leakkernelbob(order=1,threshold=2)
motionprotectedfps(50)
lanczosresize(720,576)
assumetff()
separatefields().selectevery(4,0,3).weave()

I am encoding right now.
It is a clip from XXX movie NTSC Interlaced that has a lot of outdoors movement.
I hope i will see better results than with simple kernelbob + convertfps.
Do you think that MvBob gives better results?
I wish i could make it work, so i could try it to the same clip.

[scharfis_brain]

at least use securedeint() instead of leakkernelbob() since securedeint() avoids severe interlacing artifacts especially with handycam footage. Also it gives you better definition due to EEDI2 interpolation.

mvbob() would be even better, but it needs a lot of time to process.

[Boulder]

scharfi,

could you update MVBob to use MaskTools v2 alpha?

Would it also be possible to add the option to input YUY2 data in MVBob and then output YV12? I understand that it must convert the colorspace to YV12 at some point so it would be nice if the colorspace was left to YV12 in the end to avoid having to do another YUY2->YV12 conversion.

[scharfis_brain]

I have plans to update it.

But not in the near future due to lacking time.

[kle500]

I've try the clip i mentioned before, and the panning is almost excelent using motionprotectFps, but i have some observations.

Using Leakkernelbob (order=X, threshold=1), gives me very good speed.
Using, Tdeint, i get much lower speed, but i get many many artifacts and lines (allthough i try to alter the threshold).
Using Securedeint(), i get wrong field, but sloooow speed (how can i change the order?).

These are the observations for the deinterlacers, but my main problem is that i have some tearing effects in the background.
For example, i have a small clip with some metalic curtains in the backround (i am sorry but i don't know how to call these).
You know, the metalic horizontal curtains everybody has in offices.
So, there are 3 White Ropes going vertical the curtains.
When the camera moves, these ropes get very very distorted.
What function can i call in MotionprottectFPS, to alter this?

Kind regards
George

[scharfis_brain]

you may try the raising the iterate parameter of motionprotectedfps().

also place an assumetff() or assumebff() before securedeint to ensure correct handling.

[foxyshadis]

I can update it, since MT2 conversion is simple and adding an option for boulder is quick, but I'm in no way implying this is the way it'll work in scharfi's future releases. :p I added a yv12out boolean parameter.


getparity(i) ? i.separatefields().eedi2(field = 3) : i.separatefields().eedi2(field = 2)

I believe this should be simplified to

i.separatefields().eedi2(field=-2)

In addition most of the isyv12 protections are useless, as ianb says a spurious ConvertToYV12 takes 0 time and no memory copies. (Just a pointer copy.)

Anyway, I, uh, have no interlaced material to test, so I just chopped up some cg video with one of your bob-to-interlace lines. It seemed to work the same, and was marginally faster... don't expect miracles though. (Looks very very good with cgi, btw.)

I submit the modified mvbob (http://foxyshadis.slightlydark.com/random/mvbob.avs) to your vetting. As usual, masktools2 is at its thread (http://forum.doom9.org/showthread.php?t=98985).

@kle500
Ugh, venetian blinds are going to be hard, if they're near the limit of pixel-differentiation. Many high-frequency patterns like that cause trouble for bobbers.

[Boulder]

Thanks :)

[kle500]

@scharfis_brain
Even if i raise the Iterate, there is no difference.
I tested the Mvfpsscd(50), and i see lower distortion in the above clip i mention.
But, way slower than with MotionProtectFPS(50).

Forgive me for my ignorance but, do you suggest to use Mvfpsscd in my clips?
As i mentioned before, i have NTSC interlaced videos that are all shot with camera (a lot of panning).
Any good suggestions?

[zambelli]

@scharfis_brain:

Hi Scharfis! I'm having some trouble getting MVbob() and SecureDeint() to work with the latest MVtools (1.3.0). Could you please take a look at http://forum.doom9.org/showthread.php?p=838637#post838637 and let me know if I'm doing something obviously wrong? Thanks!

[Revgen]

You need to download the corrector function separately since it's not included in recent versions of mvtools.

You can get it separately here http://avisynth.org.ru/mvtools/corrector.html

[zambelli]

You need to download the corrector function separately since it's not included in recent versions of mvtools.
You can get it separately here http://avisynth.org.ru/mvtools/corrector.html
Yeah, I've got it. My problem is not that MVbob() doesn't work at all - but that it produces combing artifacts even in non-moving images. See my linked post above.

[boombastic]

With this script i'm getting the error:

ther's no mvfps function.Why?Thanks!!

SetMtMode(5)
mpeg2source("F:\1x02\VIDEO_TS\VTS_01_1.d2v")
import("d:\Programmi\AviSynth 2.5\plugins\SeeSaw.avs")
import("d:\Programmi\AviSynth 2.5\plugins\mvbob.avs")
#import("d:\Programmi\AviSynth 2.5\plugins\spresso.avs")
ColorMatrix(d2v="F:\1x02\VIDEO_TS\VTS_01_1.d2v")
Crop(8,80,-32,-80)
SeparateFields()
a=SelectEven().DeGrainMedian(limitY=0,limitUV=4,mode=1).SeeSaw(NRlimit=2, NRlimit2=2, Sstr=1.0, Slimit=7, Spower=2, Sdamplo=8, Szp=10, bias=1)
b=SelectOdd().DeGrainMedian(limitY=0,limitUV=4,mode=1).SeeSaw(NRlimit=2, NRlimit2=2, Sstr=1.0, Slimit=7, Spower=2, Sdamplo=8, Szp=10, bias=1)
weave()
#TomsMoComp(1,3,1)
mvbob()
mvfps(25)
LumaYV12(0,0.9)

[zambelli]

Yeah, I've got it. My problem is not that MVbob() doesn't work at all - but that it produces combing artifacts even in non-moving images. See my linked post above.
If anyone runs into the same problem... Turns out this was causes by Avisynth's memory cap being set too low (16MB). It appears that some plugin in the MVBob suite doesn't report out of memory errors but produces bad results instead. So... Remember to give MVBob plenty of room to breathe!

[canuckerfan]

not sure if this is the right place to ask, but here goes. is there anyway to update mvbob to take advantage of SSE2 capabilities?

[Revgen]

not sure if this is the right place to ask, but here goes. is there anyway to update mvbob to take advantage of SSE2 capabilities?

I don't think it would matter.

MVBob needs RAM more than SSE2 or a faster CPU.

It's also a function, so SSE2 would have to be present in all plugins in order to work.

[halsboss]

Is the latest MT2 version of MVbob here from foxyshadis ? http://forum.doom9.org/showthread.php?p=812334#post812334

[TSchniede]

I think the newest version is on
http://forum.doom9.org/showthread.php?p=1052018#post1052018

I myself use a modified version of mvbob as mvbob.mrestore usually gives better results than restore24 or other ivtc but it is really dead slow


#needs mvtools >= 1.8.2 for pelclip, was: clip2x, dct is available since 1.6.1
#based on mvbob, a motion compensated bobber, build by scharfis_brain.
##nnedi and nnedibob was made possible by tritical and the fellow Doom9 community who contributed CPU cycles.

#Helper functions:
Function DumbBob(clip Input, int "Height")
{
Input.Bob(0, 0.5, height = Height)
GetParity(Input) ? AssumeTFF() : AssumeBFF()
}
#slow, but accurate EEDI-bob, always dumb ;)
function eedibob(clip i, bool "s")
{
s=default(s,false)
i.separatefields().eedi2(field = (getparity(i) ? 3 : 2), nt = (s ? 35 : 50), pp = (s ? 3 : 1))
assumeframebased()
getparity(i) ? assumetff() : assumebff()
}
Function nnEDIbob(clip Input)
{
Input.nnedi(field=-2)
}
# BSec is based on SecureBob, default is only different for YUY2 color.
# l > 2 : different motiondedection, compares each field wih its temporal predessors, it reacts faster to "static" areas => anime
# similar to motion/interlacing dedection of Kerneldeint
#
# postprocessing: (touces even non-interpolated fields in default code, one possible solution is included below)
# edgeth,calmHEddge calms all nearly horizontal edges with strong temporal filtering (ReduceFlicker),
# makes the bob-weakness less obvious, luma only => anime, edgeth is the threshold for the edge dedection.
function BSec(clip Input, int "th", int "l",int "type", int "edgeth", bool "calmHEddge"){
function staticmask(clip e, int th, int l, int chromafilt){
e0 = e.MotionMask(thY1 = th, thY2 = th, thC1 = Round(th * 0.5), thC2 = Round(th * 0.5), thSD = 255, U = 3, V = 3)
e1 = e0.trim(1, 0)
e2 = e0.trim(2, 0)
e3 = e0.trim(3, 0)
e4 = e0.trim(4, 0)
e5 = e0.trim(5, 0)
e6 = e0.trim(6, 0)
e7 = e0.trim(7, 0)

ea0 = mt_logic(e0, e1, "or", u = chromafilt, v = chromafilt)
ea1 = mt_logic(e2, e3, "or", u = chromafilt, v = chromafilt)
ea2 = mt_logic(e4, e5, "or", u = chromafilt, v = chromafilt)
ea3 = mt_logic(e6, e7, "or", u = chromafilt, v = chromafilt)

eb0 = mt_logic(ea0, ea1, "or", u = chromafilt, v = chromafilt)
eb1 = mt_logic(ea2, ea3, "or", u = chromafilt, v = chromafilt)

ec = mt_logic(eb0, eb1, "or", u = chromafilt, v = chromafilt)

(l==0) ? ec .duplicateframe(0).duplicateframe(0).duplicateframe(0) :\
(l==1) ? eb0.duplicateframe(0) :\
(l==2) ? ea0 : e0

return last
}

th = default(th, 3)
l = default(l, 2)
type=default(type,3)
edgeth = default(edgeth, (default(calmHEddge,false) ? 110 : -1))

YV12input = isyv12(Input)
i2=YV12input ? Input : Input.converttoyv12(interlaced = true)
i3=i2.separatefields()
YVtype = YV12input ? 3 : 1

Bobbed = (Type == 0) ? Input.DumbBob() :\
(Type == 1) ? Input.eedibob() :\
(Type == 2) ? Input.eedibob(s=true) :\
Input.nnEDIBob()

Weaved = i2.DoubleWeave()

EvenFields = i3.SelectEven().StaticMask(th, l, YVtype)
OddFields = i3.SelectOdd() .StaticMask(th, l, YVtype)

BobbedYV12= (YV12input ? Bobbed : Bobbed.converttoyv12())

CombMaskT = Interleave(EvenFields, OddFields).dumbbob()
CombMask = (l > 2) ? Weaved.StaticMask(th, l-2, YVtype).fadein0(3,color=$FFFFFF) : Merge(CombMaskT.Trim(1, 0), CombMaskT, 0.5).mt_binarize(threshold=20,upper=true,u = YVtype,v = YVtype).fadein0(2).invert()


HLMask = edgeth > 0 ? mt_lutxy(BobbedYV12.mt_edge(mode = "3 3 3 -1 -1 -1 -2 -2 -2 4", thY1=0, thY2=255, thC1=255, thC2=255,u=1,v=1),
\BobbedYV12.mt_edge(mode = "-2 -2 -2 -1 -1 -1 3 3 3 4", thY1=0, thY2=255, thC1=255, thC2=255,u=1,v=1)
\,yexpr="x y + "+string(edgeth * 2)+" > 255 0 ?",u=1,v=1).mt_expand(u=1,v=1).removegrain(12) : i3 #HLMask chroma is garbage !!!

BobbedYV12 = edgeth > 0 ? mt_merge(BobbedYV12,BobbedYV12.ReduceFlicker(),HLMask, u = 2, v = 2) : BobbedYV12

####### restrict temporal filtering to interpolated fields, instead to only moving "horizontal" lines (IMHO those are always "moving" due to interpolation)
# BobbedYV12 = interleave(i2.separatefields(),BobbedYV12.separatefields().selectevery(4,1,2)).weave()

# merge bobbed moving areas with weaved static areas
mt_merge(Weaved, BobbedYV12, CombMask, u = YVtype, v = YVtype)

####### Debug: show difference between normal motiondedection and alternative eg. l==x and l==x+2, only useful for x <= 2
# stackhorizontal(mt_merge(Weaved, Bobbed, CombMask, u = 3, v = 3),mt_merge(Weaved, Bobbed, Weaved.StaticMask(th, l), u = 3, v = 3))

YV12input ? last : last.converttoyuy2().mergechroma(Bobbed,1.0)
getparity(Input) ? assumetff() : assumebff()
assumeframebased()
return getparity(Input) ? assumetff() : assumebff()
}


# MCF (MotionCompensateFields) is based on different versions of MVBob, BSec.MCF(simplemv=true) should yield results similar to recent MVBob()
# MCF makes motioncompensation on the interpolated fields on a bobbed clip, unlike MVBob which includes SecureBob.
# differences:
# uses pelclip instead of idx => more MT friendly
# uses dct option (mdct) helps for (flickering video / fadeout) but is slow
# thSAD (tSAD) makes motion compensation only in areas with reasonable results =>
# the blurred check in the corrector makes nearly never obvious artifacts, even for threasholds >5
# otherwise areas with very high contrast can still contain arifacts which cancel each other out in the smoother
# debugtSAD: show the input and the motion compensated predesor and succesor, try on scenechanges and blends
# coherence: coherence of the motion vectors, default is 1000 for mvtools, 6000 for mvbob, I took 2000 because bad blocks get thrown away - thSAD
# mblur: is clip for mismatch analysis burred by simple kernelblur or medianblur?
function MCF(clip bobc, int "blksize", int "th", int "tSAD", bool "debugtSAD", int "mdct", int "coherence", bool "mblur")
{
function blurclip(clip oclip, bool blurtype){
return blurtype ? oclip.removegrain(12).removegrain(12) : oclip.BicubicResize(oclip.Width * 2, oclip.Height).MedianBlur().BicubicResize(oclip.Width, oclip.Height)
}
# threshold for correcting failed compensated motion
th=default(th, 10)

# defaults for the mocomp
blksize=default(blksize,8)
ol = blksize/2
tm = true
mdct= default(mdct,0)

# recent versions of mvtools can implicitly mask away blocks with SAD > x, only for mvcompensate
tSAD = default(tSAD,320)
debugtSAD = default(debugtSAD,false)
coherence = default(coherence,2000)

# blur type for mismatch analysis
mblur = default(mblur,false)

#determine clip Fieldorder
yv12 = isyv12(bobc)

# create the upscaled clips for mvtools
bob2x = bobc.Lanczos4Resize(bobc.width()*2,bobc.height()*2,src_left=0.25, src_top=0.25)

# create motion vectors
mvf=bobc.mvanalyse(blksize=blksize,pel=2,isb=false,chroma=true, pelclip=bob2x, truemotion=tm,overlap=ol, dct=mdct, lambda=coherence)
mvb=bobc.mvanalyse(blksize=blksize,pel=2,isb=true, chroma=true, pelclip=bob2x, truemotion=tm,overlap=ol, dct=mdct, lambda=coherence)

# create the motion compensated clip that are passed through to the output
mcf=bobc.MVCompensate(mvf,pelclip=bob2x, thSAD=tSAD)
mcb=bobc.MVCompensate(mvb,pelclip=bob2x, thSAD=tSAD)

# create clips for mismatch detection
bobcf= (yv12 == false) ? mcf.converttoyv12().blurclip(mblur).converttoyuy2() : mcf.blurclip(mblur)
bobcb= (yv12 == false) ? mcb.converttoyv12().blurclip(mblur).converttoyuy2() : mcb.blurclip(mblur)
bobcs= (yv12 == false) ? bobc.converttoyv12().blurclip(mblur).converttoyuy2() : bobc.blurclip(mblur)

# detect mismatches of mvtools and replace them with motion adaptive bobbed areas
mc=corrector(bobcs,bobc, bobcf,bobcb, mcf,mcb, mode=0,th=th)

# select the correct lines
compensated_even= mc.selecteven().separatefields().selectodd()
compensated_odd = mc.selectodd() .separatefields().selecteven()

# merge them with the original fields
original_even=bobc.selecteven().separatefields().selecteven()
original_odd =bobc.selectodd().separatefields().selectodd()

even = interleave(original_even, compensated_even).weave()
odd = interleave(original_odd , compensated_odd ).weave()

interleave(even,odd)

# output video
(bobc.getparity()) ? last.assumetff() : last.assumebff()
debugtSAD ? (isyv12 ? stackvertical(fields,mcf,mcb) : stackvertical(fields,mcf,mcb).converttoyuy2()) : last
}

# needed plugins
LoadPlugin("RemoveGrain.dll") #use SSE version if your CPU allows
LoadPlugin("masktools.dll")
LoadPlugin("mt_masktools.dll") #replacement for masktools, mt_motion broken - (th unused, at least when I checked, v29 I think)
LoadPlugin("mvtools.dll")#newest version recommended
LoadPlugin("corrector.dll")#for new mvtools
LoadPlugin("medianblur.dll") # can be used for mismatch detection instead of removegrain
LoadPlugin("nnedi.dll")
LoadPlugin("eedi2.dll")
LoadPlugin("ReduceFlicker.dll") #use SSE version if your CPU allows