Plain deinterlacing or Bob+SelectEvery: what do you prefer and why?

[Chainmax]

Is there an inherent advantage for each method on particular cases?

[Mug Funky]

bob.selecteven/odd can be useful for detecting if something's already been deinterlaced (the bad way ala final cut pro or premiere). if there's not-very-much difference between the source and the bob.selecteven then it's been deinterlaced and needs to be eedi2'ed up to a higher res.

but generally you can tell that just by looking at it :)

[Chainmax]

So Bob+SelectEvery is not a good deinterlacing method then? What about straight-up deinterlacing, is TDeint+EEDI2 still the preferred method?

[Mug Funky]

i think the preferred method is the one that gives the better visual quality vs speed tradeoff. depending on the situation that's usually somewhere between leakkerneldeint and tdeint.

[edit]

of course, if you want a guarantee of no artefacts (except aliasing), then bob.selecteven is probably the way to go

[Chainmax]

I'm only interested in the best quality short of interlaced encoding. I guess that still means TDeint+EEDI2 then, thanks for the feedback :).

[Seed]

I'm only interested in the best quality short of interlaced encoding. I guess that still means TDeint+EEDI2 then, thanks for the feedback :).

I thought many people (including some gurus) here preferred mvbob or its variants, if speed is not an issue? I myself am a bit confused.

[Chainmax]

MVBob and its variants are bobbers: they deinterlace to double the original framerate. What I'm asking about is same-framerate deinterlacers.

[Didée]

Basically, quality-wise both methods are the same. The result depends on the used deinterlacing routine only. A same-framerate deinterlacer will ask you for a "field=top/or/bottom" parameter, defining which of both fields will be thrown away & interpolated: Same framerate = one field doomed.
A bobber does the same, but after each frame inserts another frame that is based on the previously thrown-away field: Framerate doubled by not dooming one field.

Or, perhaps like this:

Same-framerate-deinterlacing:
> source.Deinterlace(field=[top or bottom])

Double-framerate-deinterlacing (Bobbing):
> source.DoubleWeave().Deinterlace(field=[alternating])


So, obviously, decisive for the result is only the deinterlacing algo. And that's where MVbob is bringing an additional choice over TDeint, LeakKernel-XX, and Co. : all these are "only" motion-adaptive, i.e. in moving areas, they have to give up & can only do interpolation guesswork. MVBob currently is the only one taking the chance to search around for really-present image information that can be transported into those missing scanlines.

I'd say that, in theory, MVBob.SelectEither() should deliver superior image quality compared to the other methods, simply because the technique used for deinterlacing is more advanced.
Note that this doesnt say that the technique is already maxed-out ... MVBob does have its own problems just as well, so it's not necessarily "the best" of the available choices. The current implementation of the more advanced technique still has a few issues left over ... something should be done in that area. ;)

[Chainmax]

Thanks for the explananation, Didée :).

[Seed]

MVBob and its variants are bobbers: they deinterlace to double the original framerate. What I'm asking about is same-framerate deinterlacers.

Didee has explained nicely. What I mean is mvbob.selecteither method.

While on this interlaced material processing department, I am often affected by "highest-quality-itis syndrome", and uses
mvBob, temporal or spatial-temporal denoising filters, SeparateFields, SelectEvery(4, 0, 3), Weave method for intermediate deinterlacing of interlaced footage. That is when I leave my PC running overnight :D

[Didée]

I'm only interested in the best quality short of interlaced encoding. I guess that still means TDeint+EEDI2 then,
Check this (http://rapidshare.com/files/80071/CompareBobs.rar.html).

[Trixter]

MVBob and its variants are bobbers: they deinterlace to double the original framerate. What I'm asking about is same-framerate deinterlacers.

The problem with same-rate deinterlacers is that you will be throwing away half the motion no matter how you process it. For material shot on video, it's unacceptable -- the end result always looks "computery" (terrible phrase, I know). 60Hz interlaced material that has been same-frame deinterlaced, no matter the process, now has judder during horizontal pans and generally looks cheap, IMO.

My first full-field capture device was an IOMega Buz (remember those?) from 1998 which was essentially a very high quality Zoran MJPEG capture device coupled with some truly sh*tty software drivers. The input was awesome but the drivers didn't pay attention to field order and some captures were BFF and others were TFF. To fix the problem, I attempted deinterlacing every single clip (both field duplication and field blending) but you could clearly see, on the Buz's video output hooked up to a television, that it destroyed the smooth motion I had just captured. I couldn't live with that, so I invested in a Pinnacle device (with the same chipset, heh) that had proper drivers that worked.

So all this rambling has a point: What footage do you have where same-frame deinterlacing is the "best" option?

[Trixter]

I am often affected by "highest-quality-itis syndrome", and uses
mvBob, temporal or spatial-temporal denoising filters, SeparateFields, SelectEvery(4, 0, 3), Weave method for intermediate deinterlacing of interlaced footage. That is when I leave my PC running overnight :D

Overnight? I just finished up a PAL->NTSC transcode for 3 hours of footage -- it took two 3GHz machines 5 solid days (that's 240 CPU hours) to complete! But my transcodes look MUCH better than the Sony DSC-1024 we've got here, so nobody is complaining :D

[Seed]

Overnight? I just finished up a PAL->NTSC transcode for 3 hours of footage -- it took two 3GHz machines 5 solid days (that's 240 CPU hours) to complete! But my transcodes look MUCH better than the Sony DSC-1024 we've got here, so nobody is complaining :D

Mine is a 3Ghz (overclocked) machine too, but my clips are edited in 5-10 minutes sequences and compiled into a 10-20 chapters DVD.

BTW, I was also an ex-user of IOMega Buz :scared: . Yea, good hardware, bad driver and ugly support! Luckily 1n 1998 my required final output was VCD, and TMpegEnc did a nice job of deinterlacing and encoding. I later switched to a Philips SAA 7134 chipset capture card and never looked back. Indeed it is still my capture card via S-video input.

[Seed]

Note that this doesnt say that the technique is already maxed-out ... The current implementation of the more advanced technique still has a few issues left over ... something should be done in that area. ;)

Your SoonToComeBob() looks pretty promising. Though as you said no technique can claim to have "maxed out" in this smart-bobbing area, I eagerly await it. I hope "soon" means within a few weeks ;)

[check]

I assume this new bobber will be as slow as paint peeling? It just wouldn't feel right otherwise :D

[Seed]

The topic title keeps changing. i'm sorry to say that the current tilte "Plain deinterlacing or Bob+SelectEvery: what do you prefer and why" is not quite appropriate. TDeint (with or without EEDI2) is a very sophisticated deinterlacer and will do a much better job of deinterlacing than a dumb/not-so-smart bobber +SelectEvery

[CruNcher]

For me personaly i allways use Securebob it's a good Speed/Quality tradeof for me.
but the best Speed/Quality @ the moment wich sadly yet can't be used (at least no one wrote a custom allocator for it yet) is Nvidias Per Pixel Adaptive Motion Deinterlacer inside their Mpeg-2 Decoder (PureVideo) it has no problems to convert 1080i into double framerate progressive Video in Realtime (on the GPU) pretty exciting to see that in front of your eyes, quality isn't as good as tdeint tough :)

Tdeint with GPU support that would be the revolution :D

[Didée]

IMO, SecureDeint is too anxious with its motion masking. Avoiding motion artefacts is good and all, but if it comes at the cost of many "in fact static" areas still keeping bobobobobbing, then it's not a good tradeoff.

Motion masking of the upcoming upproach is fully adaptive to local complexity, like my unheared proposal in the TDeint thread. Works like a charm, nonetheless.:) Wrapping it out ala SecureDeint won't be a problem.

[WorBry]

Hi Didee,

In testing your ‘SoonToComeBob’, I thought you might be interested (as I would) in seeing how it fares with this clip, which I think is as good a ‘deinterlace stress test’ as any.

http://rapidshare.com/files/229055/Test_576i25_TFF_YV12_3sec.avi

It’s sample from one of the reference D1 576i25 sequences (src6_ref__625) at

ftp://ftp.crc.ca/crc/vqeg/TestSequences/Reference/

I converted the original 8 bit YUV4:2:2 (UYVY or YUY2) sequence (Top Field First) toYV12 (FFDShow-HuffYuv) via RawSource and ConvertToYV12(interlaced=true) and used a 3 second sample as the source for testing:

MVBob (latest public version 14.9.06)
SecureBob
TDeint-EEDI2
SmoothDeinterlace

I intentionally sampled the clip to include a scene change. After deinterlacing I resized to 720x544 (Lancozos3).

As expected, MVBob and SecureBob are rather more effective in avoiding residual interlacing artifacts, most noticeable with the white road line and around the captions in the areas of fast background motion. Here are grabs of frame 102:

http://rapidshare.com/files/230193/Frame_102_MVBob_14.9.06.jpg

http://rapidshare.com/files/230258/Frame_102_Secure_Bob.jpg

http://rapidshare.com/files/230342/Frame_102_TDeint_EEDI2.jpg

http://rapidshare.com/files/230416/Frame_102_Smooth_Deint.jpg

However, on stepping through the frames, it will be seen that MVBob and SecureBob are rather more susceptible to modulation (swelling) in the height of the captions with some bobbing of the strip margin. Of course, this is barely noticeable on normal playback, but is it what you are referring to by ‘bobbing of static areas’?

[Didée]

Good (awfully;)) test clip indeed. Reveals there is work left to do.

Why did you vertically resize for the comparison? That's less than ideal, in order to check for the raw deinterlace performance.

Your result with MVBob I cannot reproduce at all. With the latest version, just "MVBob()" gives me this:

http://img345.imageshack.us/img345/2469/frame102mvbobya6.th.png (http://img345.imageshack.us/my.php?image=frame102mvbobya6.png)

And that's pretty much the performace I'm getting always of it. Only rescue is to reduce "correctth" so much that the whole thing becomes almost a no-op.
You surely didn't mix up something? Could you please state the exact settings used?

[WorBry]

Didee,

Yeah, you are right, in my haste I duplicated the frame grab from the SecureDeint encode, instead of MVBob. Here’s the ‘correct’ MVBob frame 102 (at 720x544).

http://rapidshare.com/files/268836/Frame_102_MVBob_14.9.06.jpg

These are the scripts I used – nothing fancy, with both MVBob and SecureBob at default.

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
MVBob() or SecureBob()
LanczosResize(720,544)

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
interp = separatefields().eedi2(field=2)
tdeint(mode=1,order=1,edeint=interp)
LanczosResize(720,544)

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
SmoothDeinterlace(tff=true, doublerate=true)
LanczosResize(720,544)

The MVBob (and SecureBob) version used is this one (14th Sept 2006):

http://home.arcor.de/scharfis_brain/mvbob/mvbob.rar

I resized to 720x544 because that’s the resolution I normally use for MPEG-4 encodes for PC playback, but I receive your point about it being more difficult to accurately assess deinterlacing performance. Here are the grabs again without resizing:

http://rapidshare.com/files/269028/Frame_102_MVBob_14.9.06_720x576.jpg

http://rapidshare.com/files/269095/Frame_102_Secure_Bob_720x576.jpg

http://rapidshare.com/files/269170/Frame_102_TDeint_EEDI2_720x576.jpg

http://rapidshare.com/files/269138/Frame_102_SmoothDeinterlace_720x576.jpg

[Didée]

WorBry -
You also messed up the TDeint+EEDI2 deinterlacing: you've to use "eedi2(field=-2)" to let eedi2 automatically adapt to the actual fieldorder, or field=3 to manually set it up for TFF. field=2 is just plain wrong, here.
Used correctly, result looks like this (http://img108.imageshack.us/my.php?image=frame102tdeinteedi2correctts0.jpg).

Moreover, those obvious motion artefacts should be possible to catch by using the AP feature of TDeint. Didn't try that, though.

Anyhow, if you zoom in & look close, do you still hold up with the finding about which deinterlacers avoid residual combing? I see lots of it, everywhere ...

For the new toy, this clip surely forces to make some modifications. That half-transparent static overlay is a stinker. :)

But results are already getting better. And when compairing to this (http://img120.imageshack.us/my.php?image=sarahsecuretp1.jpg) or this (http://img140.imageshack.us/my.php?image=sarahmvbobzq3.jpg) or this (http://img78.imageshack.us/my.php?image=sarahtdeinteedilf5.jpg), I feel quite comfortable with getting this (http://img78.imageshack.us/my.php?image=sarahnewcg4.jpg) instead. Feels a bit like quadrature of the circle. :)

A test version is here (http://home.arcor.de/dhanselmann/_stuff/MCBob_v03a.avs) - usage at own risk only. Keeps changing.

[foxyshadis]

I spot four separate eedi2 calls (although three are pp-only), and chunks of mvbob. I would expect no less, but see if you can throw a fifth in - these new dual cores might be able to get over a half an fps right now, and you wouldn't want to ruin your reputation. ;)

[Pookie]

I spot four separate eedi2 calls (although three are pp-only), and chunks of mvbob. I would expect no less, but see if you can throw a fifth in - these new dual cores might be able to get over a half an fps right now, and you wouldn't want to ruin your reputation. ;)

LimitedSharpen and SeeSaw are peppy - fast enough for real time processing during playback. :D

[WorBry]

You also messed up the TDeint+EEDI2 deinterlacing: you've to use "eedi2(field=-2)" to let eedi2 automatically adapt to the actual fieldorder, or field=3 to manually set it up for TFF. field=2 is just plain wrong, here.

Yep, that was plain stupid of me. In my initial tests I reversed the field order to BFF (with ReverseFieldDominance) but with some weird results. On reverting back to TFF I overlooked to change the EEDI2(field) from 2 to 3.

Anyhow, if you zoom in & look close, do you still hold up with the finding about which deinterlacers avoid residual combing? I see lots of it, everywhere ...

True, but I wasnt suggesting it was absolute, just "rather more effective". Perhaps I should have chosen my words more carefully - ''reducing'' rather than ''avoiding" residual deinterlacing artifacts

A test version is here (http://home.arcor.de/dhanselmann/_stuff/MCBob_v03a.avs) - usage at own risk only. Keeps changing.

Cool, thanks:)

[Didée]

I spot four separate eedi2 calls (although three are pp-only), and chunks of mvbob. I would expect no less, but see if you can throw a fifth in - these new dual cores might be able to get over a half an fps right now, and you wouldn't want to ruin your reputation. ;)

Funny. :D

There are not any chunks of mvbob used. Except for usage of EEDIbob, MCBob was created from bare scratch. The multiframe max'ing of the motion mask is similar, sure ... there are not too much different ways to put a thread through a needle's eye. MCBob uses different yarn, however. ;)

EEDI usage isn't as insane as it might look at first glance. Normally, EEDI is used either only once (EdiPre=1,EdiPost=0, or EdiPre=0,EdiPost=1), or maximally twice (EdiPre=1,EdiPost=1). Post=2 is just experimenting, anyway.
Mind you, it's not "sports" for me to make scripts as slow as possible. I just do what I think that has to be done; and if the result runs at mfps, then it does for a reason. See, the actual MVBob crawls at ~2fps for me ... and that's with MVBob, no offense, being a script doing mostly bare basics ... and looking at the result closely, I see not enough justification for the extensive processing time. Using a fast deinterlacer, out come shimmering and artefacts. Investing much time into MVBob, out come - - shimmering and artefacts ...

So, in order to do better than what we currently have, most probably things will get slower than what we currently have. Simple logic.

Speed is low due to, of course, the overall amount of operations done. In particular:

- Same-parity search requires MVFlow pixel interpolation instead of MVCompensate block compensation. Flow is slower.
(But it has to be done necessarily. Inter-parity ME/MC as in MVBob, by principle can't do much against the main "bobbing" issue: for static parts you don't need MC, and in motion parts ME will just follow the present bobbing. Blurring before searching hardly helps on that matter. Same-parity search surely rises a bunch of other problems, but basically there's no way around using it.)

- The "nothing-new" thingy forces one more set of frame's subpixel interpolation to be stored (ressources), and one more set of motion interpolations to performed (speed). From the idea, it's surely a right thing to do. How much the actual benefit is, has to be seen. It should be mostly benefitial with EdiPre=0, and much less with EdiPre=1, so it should be switchable instead of hardcoded.


Then, there are a bunch of small functions that imo nicely qualify to be coded as (more speedy) plugins:

- Vinverse() is quite handy to kill out residual combing, with visual loss close to zero.

- MinBlur() makes a "best of both worlds" combination of a (more or less) gaussian filter with median filtering. Result reminds a little of a bilateral filter.

- At lines 125~135, there is a scripted variant of MaskTools' in/expand, which also could fit well into MaskTools. The original filters "only" in/expand absolute pixel values. Here, I'm doing the corresponding operation on "difference" maps, i.e. what gets in/expanded is the pixel "magnitude", instead of the absolute value. Or in other words, a "signed" version of in/expand, where "zero" is 128.

- the "STT" thingy already is relatively fast ... originally, I implemented the idea in the way I had "seen" it, with two subsequent 7-tap-with-holes convolutions on the bobbed frames. Then I realized that practically the same could be done with just a blurry bob. Aaah, speed. ;)

[foxyshadis]

I tease, but it looks quite interesting. Honestly, I couldn't see any difference at all in the clip you posted, but on one of my own I did. And the speed difference isn't that much!

Anyway, Vinverse is something I've needed a few times and usually had to rewrite as a custom function each time; this one looks a little nicer than my attempts. That alone is awesome.

[WorBry]

Hi Didee,

Tested MCBob v3.0 (at default settings) with the ‘stinker’ clip - I’m seeing holes and residual comb artifacts in and around the smoke in the area of the car body and wheels (above the semi-transparent strip).

http://img409.imageshack.us/img409/5229/frame111mcbob720x576ma2.jpg

http://img249.imageshack.us/img249/1403/frame111mvbob720x576vc7.jpg

http://img249.imageshack.us/img249/8190/frame111securebob720x576dq1.jpg

http://img265.imageshack.us/img265/5769/frame111tdeinteedi2720x576fq0.jpg

Certainly, as you suggested, the AP parameter in TDeint is quite effective at removing these residuals. Here's the result with

interp = separatefields().eedi2(field=3)
tdeint(mode=1,order=1,edeint=interp, AP=5, APType=0 )

http://img401.imageshack.us/img401/2051/frame111tdeinteedi2ap5720x576up5.jpg

Is there a similar tweak in MCBob?

[Didée]

@ Worbry

Indeed, I forgot something. Look below: ;)

http://img176.imageshack.us/img176/2972/correctionco3.th.png (http://img176.imageshack.us/my.php?image=correctionco3.png)


Honestly, I couldn't see any difference at all in the clip you posted, but on one of my own I did.
Jeeze, really not? Load in Vdub, and step through the frames. In the clip bobbed by TDeint+EEDI2, practically all detail is flickering or bobbing up/down. The row of lights in the foreground not only flickers, but in the righthand part also shows the uglyness of EEDI2 errors. MCBob for the most parts is as calm as a lossless bob filter can only do.

[Didée]

I've put up a slight revision of the script: MCBob v0.3b (http://home.arcor.de/dhanselmann/_stuff/MCBob_v03b.avs). Still sloppy, but it handles this motoracing clip without (too) obvious errors, while keeping the benefits intact which the whole thing is targetting at.
Also, the included Vinverse() function was updated: there was a small, but not trivial error in it.

For those with tired eyes like foxyshadis :p , I've uploaded some short samples that should make the difference more obvious:

1) static comparison (http://rapidshare.com/files/662851/BobComparison_static.rar.html) - a scene showing the effekt of the motion masking procedure

2) motion comparison (http://rapidshare.com/files/665834/BobComparison_motion.rar.html) - a scene showing the effect of same-parity search vs. inter-parity search or no search at all
(lightspots & line structures (green ones!) in the background, top edge of sara's dress on the top, ...)

3) artefacts (http://rapidshare.com/files/659527/BobComparison_artefacts.rar.html) - a very short sequence with (or without) introduction of artefacts.

The sources are of mediocre quality from the start, consequently the overall look is not exactly impressing. But when compairing them one against each other, it should get pretty obvious where the differences are. :)

For the moment, that should've been the most part. I'll promise to make up a new thread, once I've settled down on the remaining nitpicks. (Could be Don is already drumming with his fingers, because of thread hijacking ;) )

[Fizick]

may be moderator can split the thread?

[Chainmax]

...
I'd say that, in theory, MVBob.SelectEither() should deliver superior image quality compared to the other methods, simply because the technique used for deinterlacing is more advanced.
Note that this doesnt say that the technique is already maxed-out ... MVBob does have its own problems just as well, so it's not necessarily "the best" of the available choices. The current implementation of the more advanced technique still has a few issues left over ... something should be done in that area. ;)

Ok then, would you prefer MCBob.SelectEither() or MCBob.TDecimate(mode=7,rate=initialfps)?

[scharfis_brain]

what is the sense of doing decimation to the half framesrate on pure moving video without dupes?

[Chainmax]

I assume it will give better results than simply throwing away all the even or odd frames.

[Didée]

Wrong assumption. When you use a decimator to halve the framerate, the decimator will do nothing else but throw away half of the frames. Only difference to SelectX() is, if the decimator tries to be "smart", there's a slight chance to get jerkyness in some places. :)

[foxyshadis]

If you're looking for some kind of motion fluidity boost, you can use mvfps, or mvflowblur.

[halsboss]

Er, I can't reliably locate latest mvfps perhttp://forum.doom9.org/showthread.php?p=893298#post893298

[WorBry]

Or you could try this, a modification of Scharfis_Brain's mvfpsscd (mvfps with improved scene detection) using MG262(Clouded)'s 'MotionProtectedFPS' script instead of MVConvertFPS.

http://forum.doom9.org/showthread.php?p=761045#post761045

Gives nice fluidity of motion without too much blurring of slower moving detail. The original mvfps (or mvfpsscd) function is less prone to structural distortions (see the images I put up in that thread) but is much slower.

[Chainmax]

Wrong assumption. When you use a decimator to halve the framerate, the decimator will do nothing else but throw away half of the frames. Only difference to SelectX() is, if the decimator tries to be "smart", there's a slight chance to get jerkyness in some places. :)

I see, thanks for the explanation. Does it make a difference wether the video is TFF or BFF when selecting between using SelectEven() or SelectOdd()?

[zambelli]

Does it make a difference wether the video is TFF or BFF when selecting between using SelectEven() or SelectOdd()?
You should always use SelectEven(), regardless of whether you AssumeTFF() or AssumeBFF(). The point of AssumeXFF() is precisely to determine which field comes first. The first field will end up being frame #0 after bobbing, which is why you want to use SelectEven().

[Chainmax]

I didn't say I was going to use AssumexFF() anywhere on the script. I'd just Bob then select either the even frames or the odd ones. What I meant was if the video being TFF or BFF had an impact on deciding which ones to select.

[zambelli]

I didn't say I was going to use AssumexFF() anywhere on the script. I'd just Bob then select either the even frames or the odd ones. What I meant was if the video being TFF or BFF had an impact on deciding which ones to select.
But you have to select field order when bobbing. That's what determines which fields (top or bottom) end up as even or odd frames.

[WorBry]

If I am not mistaken, smart bobbers like MVBob, and now MCBob, automatically detect the field order of the interlaced source and deinterlace appropriately (i.e. Order 1 for TFF and Order 0 for BFF). However, as an added precaution, and partly out of habit, I do usually include XFF before bobbing, having first determined the field order of the source. Of course, if you get it wrong then its going to screw up the bob resulting in a jumpy output. As far as I can see, that is the only impact of XFF on the outcome. Since the output is progressive, surely it shouldnt matter whether you SelectEven or SelectOdd?

[zambelli]

If I am not mistaken, smart bobbers like MVBob, and now MCBob, automatically detect the field order of the interlaced source and deinterlace appropriately (i.e. Order 1 for TFF and Order 2 for BFF). However, as an added precaution, and partly out of habit, I do usually include XFF before bobbing, having first determined the field order of the source. Of course, if you get it wrong then its going to screw up the bob resulting in a jumpy output. As far as I can see, that is the only impact of XFF on the outcome. Since the output is progressive, surely it shouldnt matter whether you SelectEven or SelectOdd?
No, most deinterlacers/bobbers I've encountered rely on Avisynth field order (which is typically set via AssumexFF if not inherited from source) or require you to pass the field order as a parameter to the plugin/function.
SelectEven() selects the frames constructed from the dominant field. SelectOdd() will pick the frames constructed from the opposite field.

[krieger2005]

MVBob and others need the AssumexFF-command before they were called. But i think you @zambelli are not right, when you say, that with SelectEven one select the "constructed" frames.
The Thing is, that both Even and Odd frames were constructed. But for both were build different fields to get deinterlaced. For Example: On an BFF-Video is the Even frame than one, which is build from the Buttom-Field. The Upper Field will be reconstructed by the bobber. The Odd frame is build by the Upper-Field, where the Buttom-Field is reconstructed.

[WorBry]

Please note correction to typo error in my last post. BFF should be Order=0, not Order=2.
If I am not mistaken, smart bobbers like MVBob, and now MCBob, automatically detect the field order of the interlaced source and deinterlace appropriately (i.e. Order 1 for TFF and Order 0 for BFF)

No, most deinterlacers/bobbers I've encountered rely on Avisynth field order

Isn’t that precisely what this call in MVBob does?

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

SelectEven() selects the frames constructed from the dominant field. SelectOdd() will pick the frames constructed from the opposite field.

I thought there was no ‘field dominance’ in a bob with double-rate output and that the field order simply determines the ‘leading’ field in the sequence i.e.

For TFF source:

Frame 1 – Original TF unchanged, BF interpolated
Frame 2 – Original BF unchanged, TF interpolated
Frame 3 - Original TF unchanged, BF interpolated
etc

For BFF source:

Frame 1 – Original BF unchanged, TF interpolated
Frame 2 – Original TF unchanged, BF interpolated
Frame 3 - Original BF unchanged, TF interpolated
etc

Which is essentially what Krieger2005 is saying

[krieger2005]

Well isn’t that precisely what this call in MVBob does?

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

This use just the Parity of Avisynth (which is set not always correct). The Parity of Avisynth can be changed with the AssumexFF-command. And if the parity is set wrong the bobber will do the work not correct. So, in general i would say (and many other) just call the AssumexFF command before the call of any such "smart"-bobber and you will get correct outputs.

[zambelli]

I thought there was no ‘field dominance’ in a bob with double-rate output and that the field order simply determines the ‘leading’ field in the sequence i.e.
I didn't say there was a field dominance in the bobbed sequence. The field order applies only to the interlaced video. What I meant was that the even frames in a bobbed sequence will always correspond to the "dominant" fields in the interlaced source.


For TFF source:
Frame 1 – Original TF unchanged, BF interpolated
Frame 2 – Original BF unchanged, TF interpolated
Frame 3 - Original TF unchanged, BF interpolated
etc

For BFF source:

Frame 1 – Original BF unchanged, TF interpolated
Frame 2 – Original TF unchanged, BF interpolated
Frame 3 - Original BF unchanged, TF interpolated
etc
Which is essentially what Krieger2005 is saying
Which is essentially what I was saying. :) If you use SelectEven(), you'll get frames based on your dominant fields. So if your source was BFF, using SelectEven() after bobbing will give you frames based on the bottom fields of the source video. SelectOdd() would not necessarily be wrong because it'd simply return frames based on top fields instead. In the end it doesn't really matter, so one might as well stick with SelectEven() for consistency. The important part is getting field order right before bobbing. :)

[Chainmax]

I understand now, thanks :).