ntsc2pal script: mvbob slow, use YV12 or YUY2 ?

[kevinm]

Hi experts,

First let me acknowledge the amazing work you guys are doing but developing some of the amazing functions which I am using in my script below.

My question:

I have been stitching together many useful functions which I have gathered from this forum. I started off with Xesdeen's 'Poorman's NTSC to PAL conversion script. Then, seeking to further improve the conversion I read about a number of things I needed to fix or improve upon, so I began to add the following functions to the base script:

Reinterpolate411
Convolution3d
limitedSharpen
MVbob

I am at the point where I have managed to get the script to run but it is inceardibly slow. It seems that MVbob is the main culprit, however I have a number of color space conversions which I would like to try to minimize. I have read that there are some YV12 versions of Convolution3d for example but I am not sure of the consequences of using YV12 vs YUY2

It seems to me that it has to be a good thing to reduce the number of color space conversions but what is the best space to work in?

Before I added MVbob I was able to do everything in YUY2 but it seems I have no choice with MVbob but to use YV12.

I don't mind admitting that I am struggling a little bit with all this, I find these scripts terribly complex and it was some relief after many hours of debugging that I actually got it to run.

I wonder if one of you experts would be so kind as to look at my script (below) and suggest any changes which would give me the speed increase which I am looking for,

thanks,

Kevin



PluginPath = "c:\AVISynth25\Plugins\"

LoadPlugin(PluginPath + "warpsharp.dll")

LoadPlugin(PluginPath + "MPEGDecoder.dll")
LoadPlugin(PluginPath + "SmoothDeinterlacer.dll")
LoadPlugin(PluginPath + "mpasource.dll")
LoadPlugin(PluginPath + "MPEG2Dec3.dll")
LoadPlugin(PluginPath + "ReInterpolate411.dll")
LoadPlugin(PluginPath + "convolution3d.dll")
LoadPlugin(PluginPath + "MaskTools.dll")

LoadPlugin(PluginPath + "kerneldeint.dll")
LoadPlugin(PluginPath + "dgbob.dll")
LoadPlugin(PluginPath + "Decomb521.dll")
LoadPlugin(PluginPath + "SmoothDeinterlacer.dll")
LoadPlugin(PluginPath + "UnDot.dll")
LoadPlugin(PluginPath + "TomsMoComp.dll")
LoadPlugin(PluginPath + "MVTools.dll")


##########################################################################################
##########################################################################################
##
## The NTSC to PAL conversion script
##
##########################################################################################
##########################################################################################

# Codec used to read AVI Type2 video input ..
Input = AVISource("G:\WinDV\Tape5\tape5_ntsc_2.04-08-15_13-45.00.avi") # Have to use Type2

# Note, the color space at this point is RGB24

# Trim the clip
Trim(Input, 1, 200)

ConvertToYUY2(interlaced=true)

Input = Reinterpolate411() # Fix chroma sampling bug

InputTopFieldFirst = false

OutputFrameRate = 25

OutputWidth = 720
OutputHeight = 576

OutputTopFieldFirst = false

ConversionType = 0

Input = Input.ConvertToYV12(interlaced=true) # Need to be in YV12 colorspace for mvanalyse to work!
vpro = Input.mvbob()

vinfps = Input.framerate < OutputFrameRate ? \
vpro.BilinearResize(OutputWidth, OutputHeight) : \
vpro
vfps = ConversionType == 2 ? \
vinfps.ConvertFPS(OutputFrameRate * 2, zone = 80) : \
ConversionType == 1 ? \
vinfps.ConvertFPS(OutputFrameRate * 2) : \
vinfps.ChangeFPS(OutputFrameRate * 2)
voutfps = OutputFrameRate <= Input.framerate ? \
vfps.BilinearResize(OutputWidth, OutputHeight) : \
vfps
vfields = voutfps.SeparateFields()


# Perform some limited sharpening in the fields ..
#
vfields = LimitedSharpen(vfields, smode=3,wide=true,Lmode=2,overshoot=17,strength=100,soft=true)

vfields = vfields.ConvertToYUY2()
odd=vfields.SelectOdd.Convolution3D(1, 6, 10, 6, 8, 2.8, 0)
evn=vfields.SelectEven.Convolution3D(1, 6, 10, 6, 8, 2.8, 0)

odd=vfields.SelectOdd
evn=vfields.SelectEven
vfields=Interleave(evn,odd)

vlace = OutputTopFieldFirst ? \
vfields.SelectEvery(4, 1, 2) : \
vfields.SelectEvery(4, 0, 3)

vout = vlace.Weave()
vout = Info(vout)

return(vout)




################################################################################################
################################################################################################
##
## The following are some useful functions from the Doom9 forum ..
##
################################################################################################
################################################################################################


################################################################################################
#
# LimitedSharpen()
#
# A multi-purpose sharpener by Didée
#
################################################################################################

function LimitedSharpen( clip clp,
\ float "ss_x", float "ss_y",
\ int "dest_x", int "dest_y",
\ int "Smode" , int "strength", int "radius",
\ int "Lmode", bool "wide", int "overshoot",
\ bool "soft", int "edgemode", bool "special",
\ int "exborder" )
{
ox = clp.width
oy = clp.height
ss_x = default( ss_x, 1.5 )
ss_y = default( ss_y, 1.5 )
dest_x = default( dest_x, ox )
dest_y = default( dest_y, oy )
Smode = default( Smode, 3 )
strength = Smode==1
\ ? default( strength, 160 )
\ : default( strength, 100 )
strength = Smode==2&&strength>100 ? 100 : strength
radius = default( radius, 2 )
Lmode = default( Lmode, 1 )
wide = default( wide, false )
overshoot= default( overshoot, 1)
overshoot= overshoot<0 ? 0 : overshoot
soft = default( soft, false )
edgemode = default( edgemode, 0 )
special = default( special, false )
exborder = default( exborder, 0)
#radius = round( radius*(ss_x+ss_y)/2) # If it's you, Mug Funky - feel free to activate it again
xxs=round(ox*ss_x/8)*8
yys=round(oy*ss_y/8)*8
smx=exborder==0?dest_x:round(dest_x/Exborder/4)*4
smy=exborder==0?dest_y:round(dest_y/Exborder/4)*4

clp.isYV12() ? clp : clp.converttoyv12()

ss_x != 1.0 || ss_y != 1.0 ? last.lanczosresize(xxs,yys) : last
tmp = last

edge = logic( tmp.DEdgeMask(0,255,0,255,"5 10 5 0 0 0 -5 -10 -5", divisor=2)
\ ,tmp.DEdgeMask(0,255,0,255,"5 0 -5 10 0 -10 5 0 -5", divisor=2)
\ ,"max").levels(0,0.86,128,0,255,false)


bright_limit = (soft == true) ? tmp.blur(1.0) : tmp
dark_limit = bright_limit.inpand()
bright_limit = bright_limit.expand()
dark_limit = (wide==false) ? dark_limit : dark_limit .inflate.deflate.inpand()
bright_limit = (wide==false) ? bright_limit : bright_limit.deflate.inflate.expand()
minmaxavg = special==false
\ ? yv12lutxy(bright_limit,dark_limit,yexpr="x y + 2 /")
\ : maskedmerge(dark_limit,bright_limit,tmp,Y=3,U=-128,V=-128,useMMX=true)

Str=string(float(strength)/100.0)
normsharp = Smode==1 ? unsharpmask(strength,radius,0)
\ : Smode==2 ? sharpen(float(strength)/100.0)
\ : yv12lutxy(tmp,minmaxavg,yexpr="x x y - "+Str+" * +")

OS = string(overshoot)
Lmode == 1 ? yv12lutxy( bright_limit, normsharp, yexpr="y x "+OS+" + < y x "+OS+" + ?")
\ : yv12lutxy( bright_limit, normsharp, yexpr="y x "+OS+" + < y x y x - "+OS+" - 1 2 / ^ + "+OS+" + ?")
Lmode == 1 ? yv12lutxy( dark_limit, last, yexpr="y x "+OS+" - > y x "+OS+" - ?")
\ : yv12lutxy( dark_limit, last, yexpr="y x "+OS+" - > y x x y - "+OS+" - 1 2 / ^ - "+OS+" - ?")

edgemode==0 ? NOP
\ : edgemode==1
\ ? MaskedMerge(tmp,last,edge.inflate.inflate.blur(1.0),Y=3,U=1,V=1,useMMX=true)
\ : MaskedMerge(last,tmp,edge.inflate.inflate.blur(1.0),Y=3,U=1,V=1,useMMX=true)

(ss_x != 1.0 || ss_y != 1.0)
\ || (dest_x != ox || dest_y != oy) ? lanczosresize(dest_x,dest_y) : last

ex=blankclip(last,width=smx,height=smy,color=$FFFFFF).addborders(2,2,2,2).coloryuv(levels="TV->PC")
\.blur(1.3).inpand().blur(1.3).bicubicresize(dest_x,dest_y,1.0,.0)
tmp=clp.lanczosresize(dest_x,dest_y)

clp.isYV12() ? ( exborder==0 ? tmp.mergeluma(last)
\ : maskedmerge(tmp,last,ex,Y=3,U=1,V=1,useMMX=true) )
\ : ( exborder==0 ? tmp.mergeluma(last.converttoyuy2())
\ : tmp.mergeluma( maskedmerge(tmp.converttoyv12(),last,ex,Y=3,U=1,V=1,useMMX=true)
\ .converttoyuy2()) )

return last
}



##################################################################################################
#
# 'MVbob by 'scharfis_brain
#
# See the following link for discussion on 'MVbob' ..
#
# http://forum.doom9.org/showthread.php?s=&threadid=84725&perpage=20&highlight=mvbob&pagenumber=2
#
##################################################################################################


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
}

[kevinm]

Does anyone have any suggestions on how to speed up the conversion script I posted in my initial message?

I managed to find a version of convolution3D which accepts YV12, so that has removed one of the color space conversion steps which I had originally.

I did some experiments to determine where it was spending all the time:

Original script: 88hrs
With LimitedSharpen removed: 69hrs 40mins
With LimitenSharpen and MVBob removed: 8hrs 55mins

All these times were estimated numbers from TMPGEnc,

Is this sort of runtime explosion to be expected when running these complex functions?

I am running on an Athlon XP1800, 512M ram

I am looking into the possibility of upgrading to a faster processor to try to speed things up although if I am very luck I think I am only likely to see the runtime halved, but that that will still be 40+ hours!

any advice appreciated,

Kevin

[Manao]

I'll make a modification of the MVTools tomorrow, in order to slightly speed up MVCompensate, and I'll give you the script to use it properly ( syntax will slightly change ). But don't expect miracles ( and remind me if i forget to do it )

But the speed you're getting is quite normal.

[kevinm]

Manao,

thanks for looking into doing the enhancement. No, I am not expecting miracles, I really didn't have too much idea about the runtime expectation. I accept that to do these complex things take CPU time. I am frankly amazed at what all these functions are able to achieve.

Also, I have just ordered a new processor, an Athlon XP2600. They are getting hard to come by now that AMD are phasing them out, it has probably done me a favor, forcing me to upgrade, if I left it much longer I might have been forced to replace my motherboard too!

Kevin

[Manao]

Alright : take this version (http://manao4.free.fr/MVTools-v0.9.8.5.zip) of the MVTools.

Now, modify the script liake this :

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

# detect mismatched areas of motion compensation
bobdf=bobd.mvcompensate(mvf,mode = 0,thscd1=scd,thSCD2=sc)
bobdb=bobd.mvcompensate(mvb,mode = 0,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, idx = 2)
odd1a=maskedmerge(odd1a,fields1,difff,y=3,u=3,v=3).selecteven()
odd1b=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc, idx = 2)
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, idx = 2)
odd2a=maskedmerge(odd2a,fields1,difff,y=3,u=3,v=3).selectodd()
odd2b=fields.mvcompensate(mvb,mode=1,thscd1=scd,thSCD2=sc, idx = 2)
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()
That shouldn't change the result.

Now, for a better speed yet, change the parameter of MVAnalysis ( delete the parameters "search = 3, searchparam = 10" )

[kevinm]

Hi Manao,

many thanks for posting the new MVTools and your modified MVBob script.

I ran some experiments using a clip of just 167 frames, this was from some DV NTSC avi footage.
Some information on the TMPGEnc settings I am using in case it is relevant in any way to these results:

Rate Control Mode: Constant Quality, Quality = 100
Motion Precision Search: Highest Quality
Quantize Matrix: Output YUV data as Basic YCbCr not CCIR601



Here are the results:

1/ Using ORIGINAL MVTools (v0.9.7), original MVBob script:

Run time = 9mins 47secs
File size = 6,747

*note, I used v0.9.7 because later versions didn't recognize the "compensate" parameter in your MVBob script which I have been using (which I found on this forum).

2/ Using your new (v0.9.8.5) MVTools, your new MVBob script you gave me in your last append to this thread.

Run time = 23mins 22secs
File size = 6,749


3/ Using new (v0.9.8.5) MVTools, your new MVBob script PLUS the change you suggested to the MVAnalysis lines to delete the parameters "search = 3, searchparam = 10"

Run time = 4mins 4secs !!
File size = 6,745


4/ 1/ Using new MVTools (v0.9.8.5), ORIGINAL MVBob script:

Won't run, reports error that there is no named argument "compensate"

Looks like latest MVAnalyse doesn't support the "compensate" parameter any more,

Kevin

[Manao]

> Run time = 9mins 47secs : v0.9.7
> Run time = 23mins 22secs : v0.9.8.5That's strange. I'd say that you used pel = 1, not pel = 2. The second difference is the chroma motion estimation ( in case of exhaustive search, it's the predominent factor, and it slows a lot ). nBlkSize = 4 would finish to explain the fact that it's slower.

> Run time = 4mins 4secs : v0.9.8.5 without exhaustive searchExpected, exhaustive search was the slowest part of MVBob. What would be interesting is v0.9.7 without exhaustive search ( removing search = 3, searchparam = 10 ), and with pel = 2, and the same for v0.9.8.5.

Finally, indeed, compensate isn't supported anymore, because there's no need for it now.

[kevinm]

Manao,

when running v0.9.7 with your latest script (and removing search = 3, searchparam = 10), Avisynth fails with the following message:

Script error: mvanalyse does not have a named argument "idx"

This must be becase that older version of MVTools doesn't suport the idx parameter.

Should I modify my copy of your script to remove the 'idx' parameter and then run it using the v0.9.7 and v0.9.8.5 versions? will that give you the information you need?

thanks,

Kevin

[kevinm]

BTW, forgot to say that the previous runtime experiments were all with pel = 2

Kevin

[Boulder]

A little tip regarding speed: use High quality in TMPGEnc. It's faster and produces better quality;)

[kevinm]

Manao,

I didn't hear back from you on my last question..

"Should I modify my copy of your script to remove the 'idx' parameter and then run it using the v0.9.7 and v0.9.8.5 versions? will that give you the information you need?
"

So I had to make a guess on what you actually wanted me to do. This is what I did ..

Based in the script which you gave me ..

From mvanalyze lines:

Deleted "search=3"
Deleted "searchparam=10"
Deleted "idx"

From mvcompensate lines:

Delete "idx"

Also I check and made sure pel was set to "2"

Results:

Using old MVtools (v0.9.7)

Runtime = 3mins 57 secs
Filesize = 6,903

Using new MVtools (v0.9.8.5)

Runtime = 4mins 30secs
Filesize = 6,889


Also, Boulder, thanks for the tip on using 'High Quality' rather than 'Highest quality'. Note however that for consistency with the previous test results I continued to use the 'Highest Quality' setting for the above tests.

Kevin

[Manao]

kevin : thanks for the test, that was indeed what i wanted. Results are disappointing ( i would've thought it would be at least as fast, even with chroma me ). I check my code to see if i let something obvious slowing down the process.

[kevinm]

Manao,

I decided to let mvbob rip on the full AVI using my version of the ntsc2pal script I described early in this discussion. Up to this point I have been using the trim function and testing my script out with a very short (200 frames) clip.

When I started it off on the full clip it got to 14mins and 21secs and printed out the following message in TMPGEnc ..

(the output was PAL, i.e 25fps so this time equates to 21,525 frames)

"Avisynth caught an access violation at 0x01ed00e2 attempting to read from 0x83435b19"

I have seen a few mentions of "access violations" seen by users using mvtools, is this a known issue with mvbob?

I am using mvtools version 0.9.8.5

Note,
I have also upgraded my CPU to an Athlon XP2600, I have not seen any CPU or memory problems with any other applications and I have run extensive tests using Norton systemworks. It is still possible it could be my hardware I guess.

thanks,

Kevin

[kevinm]

Manao,

I dont know if it is relevant to the "memory access" problem but I just noticed that when I use mvbob the parity changes between top and bottom frame first.

I added an info() to the end of my script and when I played back the resulting mpeg (in MPEG-VCR) I could see the following was occurring ..

Frame1 .. "assume top frame first"
Frame2 .. "assume top frame first"
Frame3 .. "assume bottom frame first"
Frame4 .. "assume bottom frame first"
Frame5 .. "assume bottom frame first"
Frame6 .. "assume top frame first"
Frame7 .. "assume top frame first"
<pattern repeats>


I tried the following simplified script, this showed the same problem with the frame parity ..

Input = AVISource("G:\test.avi")
Trim(Input, 1, 200)
ConvertToYUY2(interlaced=true)
Input = Reinterpolate411()
ConvertToYV12(interlaced=true)
vout = mvbob()
vout = vout.Weave()
vout = Info(vout)
return(vout)

If I replace the mvbob line with the following ..

vpro = Input.SmoothDeinterlace(tff=InputTopFieldFirst, \
doublerate=true)

.. the frame polarity problem goes away.


Is this to be expected? Shouldn't the frame polarity be the same for every frame in the final mpeg stream?

thanks,

Kevin

[Manao]

The frame parity isn't managed by one of my filter, so you'd better ask scharfi & mug funky, I'm not much into (de)interlacing

For the access violations, I'll have a look. But I'd like to know if it still happens when you trim the clip to just 200 frames around the moment where it happened. And, if it is, could you make the short 200 frames clip available ?

Because i never got such problem when i used the mvtools, and debugging in rather hard in that case.

[kevinm]

Manao,
I repeated the experiment but used trim to create a clip, 100 frames each side of the fail point which occurred during the ntsc2pal conversion of the full clip. Apart from the addition of the 'Trim()' function I used exactly the same script, and the same settings in TMPGEnc.

Unfortunately the "access violation" error did not occur.

I guess this is going to be very tough to debug. Please let me know if there is anything else I can do to try top track this down.

I will start trying to isolate what filter is causing the frame polarity problem before I trouble scharfi & mug funky.

Kevin

[scharfis_brain]

uhm? why shoukd one use

mvbob().weave()

?

but if it is necessary try using this:

mvbob().assumebff().assumeframebased().weave()

this should fix the field parity error.

btw. mvbob is far away from general usage.

it has some weird downsides jet. like chroma blur and misalignment due to the need of YV12 color-space
and its compensation correction is not working a wished

manao:

will we ever see a YUY2 or RGB24 implementation of mvtools?
at least for masktools you negated that :(
(maybe as workaround: instead of one YV12 clip using three greyscale input clips each of Y U and V and of same size. but I assume this will be overdriven too much in programming and then later in scripting)

btw.: did you read my post about corrector_double()?
you didn't commented about that...

[Manao]

Scharfi : there won't be YUY2 and RGB version. These colorspace are interleaved, and it would be as fast to use converttoyv12().mvanalyse() than to process directly the video as YUY2. For the other filters, it might be faster to process in YUY2 than to convert from and to yv12, but i seriously doubt it ( since interpolation would need to be done once more in case of pel = 2, etc... )

I read about corrector_double, but i won't have time to implement it before two weeks, I'm afraid.

Kevinm : thank you. As soon as I have time, I'll launch longer scripts using the mvtools. If I'm lucky, I'll perhaps encounter that access violation.

[scharfis_brain]

@Manao: is it the speed that bothers when programming for YUY2 or is it to tricky to make code for interleaved color spaces?

If it is only the speed factor I would not be bothered ;)
It is the low resoluted chroma, that brings one into hell, when scripting for interlaced sources...
Will that change with AVS 3.0? Will there be planar Chroma spaces for all sub sampling types (4:1:1, 4:2:0, 4:2:2, 4:4:4 ) ?

I read about corrector_double, but i won't have time to implement it before two weeks, I'm afraid.

No problem.

It is great that you are doing such tools for free.
So I can wait.

[Manao]

Well, if i was to code it, I would blearly deinterleaved it to a planar format. Then, the code changes would only be cosmetic. But systematically interleaved / deinterleaved would be slow. With avs 3.0, of course, it won't be an issue anymore.

[scharfis_brain]

I finally found a good way to circumnavigate the YV12-only restriction in mvbob.

I am using full frame height compensated frames all the time.

So I decided to leave the original video in YUY2 as long es possible (pre-deinterlacing, hole-fill-deinterlacer) then convert to yv12 for frame compensation. and directly afterwards the backonversion to yuy2 is done.
this helps chroma quality a lot instead of doing the yuy2-> yv12 conversion outside of the function mvbob.

I won't post that script now, because it unstructurized like hell and not working as that intuitive (paramters etc..)

Also I found my reinterpolate420 being very useful with PAL- DV and mvbob...
the results are incredible (chrma and luma) if there weren't those little crappy mismatches *grrrr*

[kevinm]

scharfis_brain,
thanks for the tip on using assumebff().assumeframebased, this fixed the parity problem.

Why 'weave' straight after 'mvbob'? Well, that is just way I hacked my ntsc2pal conversion script to try to zoom in to where the problem appeared to be at the time.

Wise to me to use 'mvbob'? .. yes I realize it is not general purpose and I appreciate (now at least) there are some problems. I guess I got so disillusioned with the results from my ntsc2pal conversion and saw discussions about amazing results from mvbob so I decided to give it a try.

I also did the same thing in trying out 'limitedSharpen' and that seems to have paid off as it is working great.

Perhaps as a newbie I shouldn't try using these functions when they are still in their early development,

Manao, thanks for following up and continue to work on this, I am sorry to cause you all these problems,

Kevin