MMX optimized LeakKernelDeint 1.5.4

[Boulder]

Yep, I had the time to do a little test and AssumeFrameBased() got rid of the problem

[Xesdeeni]

If anyone is familiar with my port of Gunnar Thalin's SmoothDeinterlacer to AVISynth, you might know I have a workaround in the scripts, for what I thought was in the plugin. I'm not absolutelyn positive, but I think the problem may be the same you guys are seeing. I found the same AssumeXXX() workarounds as you guys. Perhaps this isn't in the plugins?

Xesdeeni

[Kika]

SelectEvery(4,1,2) results in TFF, SelectEvery(4,0,3) results in BFF

SelectEvery(4,1,2) always reverses the Field Order, that's a normal behavior. It's the 1 which is doing this - this gives you an Offset of 1 Field, the first Field will be dropped - and that's a perfect way to change the Field Order.

Two Tipps:
Never forget the AssumeTFF (or, if needed, AssumeBFF) after opening the Video.
Always use SelectEvery(4,0,3) if no Field Order Change is needet.

[Xesdeeni]

Originally posted by Kika
SelectEvery(4,1,2) always reverses the Field Order, that's a normal behavior. It's the 1 which is doing this - this gives you an Offset of 1 Field, the first Field will be dropped - and that's a perfect way to change the Field Order.

Two Tipps:
Never forget the AssumeTFF (or, if needed, AssumeBFF) after opening the Video.
Always use SelectEvery(4,0,3) if no Field Order Change is needet.

I think I see why this is true, but I'm not sure it should work that way.

After you have run an interlaced video through a smart bobber (i.e. a deinterlacer to the field rate), you have a progressive stream. At that point, there is no field polarity information at all. It doesn't matter what the input video is, the video is a sequence of full frames.

When you do SeparateFields(), AVISynth must choose which field to use first. It appears that the original field polarity is used, although it really has no meaning at this point. That's why SelectEvery(4,0,3) gives you the original field order. But by all rights, when the stream is progressive, there is no field polarity. I'd guess the field polarity should be undefined. I guess when you do SeparateFields(), you should have to specify which field order you want. AssumeXFF() before obviously does the same thing, but it's not as obvious, and it doesn't make sense to me that a progressive video would have a field polarity.

One other problem with field polarity associated with progressive video is that this field polarity appears to sometimes be lost through other filters. I created a stream the other day that broke an input video into three sections. The first and third needed to be deinterlaced, but the middle was all film, so I was able to avoid the deinterlacer for that section. In this section I used ChangeFPS() instead. When I viewed the individual sections, all was well. But when I concatenated them, the field polarity was altered in mid stream. What's really weird, is the polarity didn't change at one of the boundaries, it changed in the middle of the first section!!! I had to add an AssumeFrameBased() to the middle(!) section to fix the first section. (You can imagine how much trial and error it took to find this seemingly unrelated fix.)

I'm certainly not sure about any of this. But this is how it seems to work.

Xesdeeni

[Boulder]

Hmm, I don't get this. I have a TFF clip, which is then smartbobbed with KernelBob(order=1). Supposedly SeparateFields().SelectEvery(4,1,2).Weave() reverses the field order, so why is the field order still TFF after SelectEvery?

Xesdeeni, I've seen the situation you described in some of my TV caps when dealt with the original KernelBob function and KD v1.4.0. If I had forgotten AssumeTFF() from the beginning of the script, there sometimes were really weird artifacts in the result as the original KernelBob takes the field order from some info that Avisynth provides.

N00b talk

[Kika]

so why is the field order still TFF after SelectEvery?

Because SelectEvery does not set any Field Order. So if the Source was TFF, it will be flagged as TFF no matter what you are doing with the Video (except AssumeBFF).

After Bobbing, the First Field is the first frame, the second field is the second frame.
After SelectEvery(4,1,2), the second frame will be used as the first Field and so on. That's why the Field Order always changes after SelectEvery(4,1,2).

[erratic]

Originally posted by Kika
That's why the Field Order always changes after SelectEvery(4,1,2).

Avisynth's internal Bob() command works differently.

# Source AVI is TFF
AviSource("cap-tff.avi").AssumeTFF()
Bob()
SeparateFields().SelectEvery(4,1,2).Weave()

Result is TFF (field order has not changed).
With SelectEvery(4,0,3) the field order changes to BFF.

# Source AVI is BFF
AviSource("cap-bff.avi").AssumeBFF()
Bob()
SeparateFields().SelectEvery(4,1,2).Weave()

Result is TFF (field order has changed).
With SelectEvery(4,0,3) the field order remains BFF.

So Bob() with SelectEvery(4,1,2) always results in TFF,
while Bob() with SelectEvery(4,0,3) always results in BFF.

It's less confusing if all bobbers work like the internal Bob() command as far as the field order is concerned.

EDIT: like I wrote earlier, KernelBob() followed by AssumeFrameBased() works like Bob(). SelectEvery(4,1,2) always results in TFF. SelectEvery(4,0,3) always results in BFF.

[Kika]

OK, that's what i used for Testing:

The Testscript:

LoadPlugin("E:\AviSynth2.5\AVS25Plugins\kerneldeint.dll")
avisource("CAPTURE.00.avi", true, "RGB24").assumeTFF()
ConvertToYUY2(interlaced=true)
KernelBob(order=1, sharp=true, twoway=true, threshold=0)
BicubicResize(672,544,0,0.6)
SeparateFields.SelectEvery(4,0,3).weave()
ConvertToRGB24(interlaced=true)


And that's for checking:

avisource("CAPTURE.00.avi", true, "RGB24").assumeTFF()

(just a Dummy for Checking)

At last, i opened the Video directly with TMPGEnc.
All encodings done by TMPGEnc with Top Field First.

Both Scripts do result in TFF-Videos also the Direct-Encoding without AVISynth.

[erratic]

Yes, your script results in TFF, but if you replace KernelBob() with Bob() it results in BFF, so Bob() and KernelBob() give different results with a TFF source.

With KernelBob() SelectEvery(4,1,2) always changes the field order.
With Bob() SelectEvery(4,1,2) always results in TFF, even if the source is TFF.

I assume that's because Bob() always resets the field order to the Avisynth default (BFF) by calling AssumeFrameBased() internally. So if you use Bob() on a TFF source the parity will change to BFF, and then SelectEvery(4,1,2) changes it back to TFF.

KernelBob() does not call AssumeFrameBased() so the parity remains TFF and SelectEvery(4,1,2) will change it to BFF.

My point is that all bobbers should have the same effect on the field order as Bob() to avoid confusion. I should be able to replace any bobber with another one without having to change anything else in my script.

Fortunately it's easy to avoid those field order differences by using AssumeFrameBased() after the bobber. AssumeFrameBased() resets the parity to BFF and then SelectEvery(4,1,2) always results in TFF, while SelectEvery(4,0,3) always results in BFF. So it's not really a big problem.

[Kika]

I assume that's because Bob() always resets the field order to the Avisynth default (BFF) by calling AssumeFrameBased() internally.

I'm not a programmer, but i guess, you are right here.
The Problem: If AssumeFrameBased() really resets the Field order internally to BFF, that's not what i want.
If i have used AssumeTFF i want AVISynth to stay at TFF!

I never used Bob(), but SmoothDeinterlace (doublerate=true) and this Bobber act's like Kernelbob if the correct Field order is given (after AssumeTFF as an example).
If i write my own (dump) Bobber by using AVISynth-Functions, it act's like KernelBob(), not like Bob().
So, from my point of view, Bob() does it wrong, all other Bobbers are doing it correct.

[erratic]

Well, if Bob() does it wrong then maybe the Avisynth programmer's can explain it to us?

Boulder posted this kernelbob function by scharfis_brain earlier.

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
}

It also includes AssumeFrameBased. Why, Scharfi?

I also tried TDeint today and it doesn't reset the field order, so it works like Leak's KernelBob() and not like Bob().
Maybe all those guys who are writing bobbers should get together and make their mind up.

[scharfis_brain]

IMO a bobber MUST read the fieldorder-flag of avisynth.

this is
1) more comfortable to use
2) no need for cracking our brains on zeroes and ones for setting TFF or BFF via a paramter
3) it is flexible. use another source with the same script without editing the order-paramter.

that's why I always check the Fieldorder within my bobbing functions, meaning the only (and correct) way to set up the fieldorder is either AssumeTFF() oder AssumeBFF() directly after loading the video.

setting an order-parameter is bothering.

also I set assumeframebased() at the end of the function is, cause else the video gets assumed as fieldbased stuff, which is NOT the correct assumption, if a video has been bobbed.

bobbed = framebased

[erratic]

I agree that a bobber should read the field order flag of avisynth, but what should a bobber do to the field order flag after bobbing?

I know that after bobbing the video is progressive, but AFAIK there's no progressive flag in avisynth: the parity is always BFF or TFF. Bob() resets the field order to BFF (avisynth default) even if the source was TFF. KernelBob() and TDeint() currently preserve the field order flag. I tend to agree with Kika that preserving the field order flag seems more correct than resetting it. I certainly think that all bobbers should at least do it the same way to avoid confusion.

[Kika]

Imho the default Field order in AVISynth should be changed from BFF to TFF - in any cases.
There's only one kind of source which needs BFF - it's DV-Video. In all other cases, TFF is the standard - even in progressive Video!
If you check some progressive DVDs, you will see that the TFF-Flag is active.
I have never seen a DVD with progressive Video and BFF - so, in most cases (except DV-Video-Users), TFF ist the right setting, not BFF.

[killingspree]

edit: stupid me... was a mistake in the gknot script

no cropping before deinterlacing

cheers

[scharfis_brain]

back to our selectevery(4,1,2) / (4,0,3) - problem.

KiKa is right. 4,1,2 reverses the FO and 4,0,3 leaves it.

so:

assumeframebased().assumebff().separatefields().selectevery(4,0,3).weave()
returns BFF

assumeframebased().assumebff().separatefields().selectevery(4,1,2).weave()
returns TFF

assumeframebased().assumetff().separatefields().selectevery(4,0,3).weave()
returns TFF

assumeframebased().assumetff().separatefields().selectevery(4,1,2).weave()
returns BFF


this means for me:

whateverbob()
whicheverfilter()

# my new standard for reinterlacing:
assumeframebased()
assumebff()
#maybe: converttoyuy2()
separatefields()
selectevery(4,1,2) #4,0,3
weave()

weird (but somehow correct) world

[Wilbert]

Some useless comments

I know that after bobbing the video is progressive, but AFAIK there's no progressive flag in avisynth:

Yup true, avs v2.5 doesn't have a progressive/interlaced flag.

So, from my point of view, Bob() does it wrong, all other Bobbers are doing it correct.

I agree that Bob() should preserve the field order flag.

There's only one kind of source which needs BFF - it's DV-Video. In all other cases, TFF is the standard - even in progressive Video!
If you check some progressive DVDs, you will see that the TFF-Flag is active.
I have never seen a DVD with progressive Video and BFF - so, in most cases (except DV-Video-Users), TFF ist the right setting, not BFF.

Progressive video has no TFF or BFF, so this comment doesn't make any sense.

Imo, it's too late to change the avs' default field order to TFF. Perhaps it's a good idea to look at this for avs v3.0.

Q) interlaced-XviD is that also TFF?

[scharfis_brain]

Progressive video has no TFF or BFF, so this comment doesn't make any sense.

maybe. maybe not.

encode a progressive movie once using TFF and the other time using BFF
(but both with progressive encoding!)

then burn both to a disc and play them back on your DVD-SAP, which is connected to a TV-Card.

you'll see, that the TFF encoded file looks progressive.
the BFF encoded one is phase shifted! (or was it vice versa ?!?)

but of course. for progressive video, a fieldorder is (mostly) nonsense

[erratic]

Originally posted by scharfis_brain
# my new standard for reinterlacing:
assumeframebased()
assumebff()
#maybe: converttoyuy2()
separatefields()
selectevery(4,1,2) #4,0,3
weave()

weird (but somehow correct) world

AssumeBFF() is unnecessary after AssumeFrameBased(). AssumeFrameBased() already resets the parity to bff.

But if the source is tff, why assumebff after bobbing? Why not assumetff. Kika, Wilbert and I would like to preserve the field order after bobbing. If you bob tff video the top field is now the first frame, so the top field still comes first. Why would you change the parity to bff? Or should every bobber behave like the internal Bob() command to avoid confusion? Maybe Bob() should be fixed. I also don't know why assumeframebased resets the parity to bff. If the source is tff, the parity should remain tff after assumeframebased. If you disagree, I'd like to know why.

[scharfis_brain]

jep! preserving the FO-flag is important, cause then we can write bobbing / reinterlacing scripts without caring much about the fieldorder.