Alternative to doubleweave? (mcbob related question)

[Terranigma]

I was wondering if there was perhaps an alternative to doubleweave, because doubleweave causes a lot of problems for certain scripts such as mcbob. It alternates fields on a per-frame basis, so I follow it with AssumeTop or Bottom-Field first depending on the nature of a clip, but using it in conjunction with mcbob slows encoding to tortoises speeds (Like The slowsky's on that cable commercial =P). mcbob speed seems to get affected if used, on like, 30 frames or so. Not sure on how many frames needs to be specifically processed with mcbob for the slow script to become much slower, but roughly 30 processed frames seems about right. Perhaps there's another way I could use doubleweave alongside other filters so that mcbob won't conflict with doubleweave?

[scharfis_brain]

huh. I don't anderstand what effect you want to achieve using doubleweave.

post your script.

[Terranigma]

huh. I don't anderstand what effect you want to achieve using doubleweave.

post your script.

Here's a script i'm kinda forced to use that uses doubleweave and mcbob (this's for ntsc film, I only use mcbob on frame changes or frames that follows the standard c pattern). I really can't use a script i'd like to use since, for some reason, mcbob slows the encode to a crawl. I'd, instead have to compensate for one of your deinterlacers scharfis_brain such as securedeint. Your deinterlacers don't affect encoding speed

tpr = "C:\star wars.tpr"
ovrE = "C:\Star Wars (EVEN).txt"
ovrO = "C:\Star Wars (ODD).txt"
doubleweave().tprivtc(tpr)
assumetff()
ovr=last
effect1 = mcbob().selecteven()
ConditionalFilter(ovr, effect1, "Value", "==", "false",false)
ConditionalReader(ovrE,"Value",false)
ovr2=last
effect2 = mcbob().selectodd()
ConditionalFilter(ovr2, effect2, "Value2", "==", "false",false)
ConditionalReader(ovrO,"Value2",false)
vinverse()
base = last.separatefields()
backward_vec2 = base.MVAnalyse(isb=true, delta=2,blksize=4,overlap=4/2,dct=2)
backward_vec1 = base.MVAnalyse(isb=true, delta=1,blksize=4,overlap=4/2,dct=2)
forward_vec1 = base.MVAnalyse(isb=false, delta=1,blksize=4,overlap=4/2,dct=2)
forward_vec2 = base.MVAnalyse(isb=false, delta=2,blksize=4,overlap=4/2,dct=2)
base.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=800)
weave()
fft3dfilter(sigma=1.3, plane=4)
dull= last
sharp = dull.SeeSaw(ssx=1.6,NRlimit=5, NRlimit2=6,Sstr=2.2, Slimit=12, Spower=1, Szp=2,bias=90,soothet=0)
Soothe(sharp, dull, 5)
addgrainc(2,1)
RemoveGrain(mode=1)

Could it have something to do with the fact for mvdegrain, I choose not to use any idx values?

[Didée]

What did your PC do to you to deserve SUCH punishment?

[stickboy]

I don't have an answer to your question--if you need DoubleWeave, there is no alternative; it does what it's defined to do--but regarding your comment about AssumeTFF/AssumeBFF:

If your clip starts off with the correct field-order, then call ComplementParity() before calling DoubleWeave(), and then the field-order will be preserved. (See Why does DoubleWeave change the field-order? (http://avisynth.org/stickboy/DoubleWeave.html).)

[scharfis_brain]

doubleweave().bob() cannot yield in a good result as doubleweave() always alternates the field order.

mcbob() is massively disturbed by it.

[Terranigma]

doubleweave().bob() cannot yield in a good result as doubleweave() always alternates the field order.

mcbob() is massively disturbed by it.
You are totally correct. As an alternative, i've used tritical's tdeint's doublerate deinterlacer with tryweave=true. mcbob's not bothered by tdeint, but most of the frames, when used with tpr, are different from the project file. =P

[Terranigma]

If your clip starts off with the correct field-order, then call ComplementParity() before calling DoubleWeave(), and then the field-order will be preserved. (See Why does DoubleWeave change the field-order? (http://avisynth.org/stickboy/DoubleWeave.html).)
Yes, I've tried that already. I do read the docs before posting. Using complimentparity before doubleweave changes the frames with tprivtc, Iend up getting a lot of interlaced frames. I'll just have to figure something else out. :)

[ChiDragon]

Does your capture card drop frames or fields or something? I didn't think Star Wars had any pulldown pattern changes.

EDIT: TMPGEnc also has a field order option, maybe switching that as well would fix it. Though you may have to redo the IVTC when you change that anyway...

[Terranigma]

Does your capture card drop frames or fields or something? I didn't think Star Wars had any pulldown pattern changes.

EDIT: TMPGEnc also has a field order option, maybe switching that as well would fix it. Though you may have to redo the IVTC when you change that anyway...

No, it has nothing to do with the set field order since doubleweave ignores it anyway. scharfis_brain's right on the money.
mcbob dislikes doubleweave.

[ChiDragon]

I was referring to your comment about ComplementParity and TPRIVTC. That has to have something to do with the field order setting or using ComplementParity wouldn't change TPRIVTC's output.

[Terranigma]

I was referring to your comment about ComplementParity and TPRIVTC. That has to have something to do with the field order setting or using ComplementParity wouldn't change TPRIVTC's output.

It does. Why don't you give it a try yourself and see? I already talked this same issue over with tritical. I've tried numerous things, that's why I asked him to check out tprivtc's code so we can figure out a way to avoid using doubleweave and come up with a totally new filter.

[Didée]

Seriously, Terranigma: are you actually aware of what you are doing in that script? I'm in doubt.

1) Speed:
It's not a problem with DoubleWeave and/or MCBob. The problem is that MCBob is just very complex, and the blue-eyed application in that script is beyond anything. You can't do it that way with MCBob.
First, you conditionally fiddling MCBob into the IVTC#ed source. On the result of that, you call MCBob again, and once more conditionally fiddle this result in the former one. This is already insane, but you're not finished yet. On this veherry complex thing, you perform yet another instance of MV-stuff (MVAnalyze+MVDegrain2), then append a jolly FFT3DFilter. And if it wasn't enough, you take the whole gordian-knot and push it through SeeSaw.
Most probably a machine with 2GB RAM is too small for this, and at least 4GB RAM would be required. Not to speak of CPU power - supposely you could bring a Cray to crawl with this thing. (Assuming you could run Avisynth on it;))

So, the "speed issue" is just that with MCBob in that script, you're *hoplessly* running out of ressources. That's the reason for the extreme slowdown you're noticing. Other deinterlaces use much less ressources, that's why your script won't show that slowdown when using a silmpler deinterlacer.


2) Feasability:
Put short, you cannot use MCBob in this context, anyway. There is nothing to gain. MCBob is suited for true interlaced content exclusively. It necessarily chokes on anything else: progressive/progressive phase-shifted, telecined footage, fieldblended footage - all of this is a no-no. MCBob will only do something sensible if every single field is temporally unique. And this is not the case here.

[Terranigma]

OK, I understand now. Thanks for clearing that up. I see what you mean by my pc being punished :D