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

[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.