Field Order

[berrinam]

Looking at the manuals for Telecide and TFM, I see that both require the order to be specified (or given through DGIndex, etc). If these are field matchers, then why do they need to know the field order? Is this only for the segments that cannot be matched (ie, the video segments)?

Secondly, are there any deinterlacers that can determine the field order by themselves? LeakKernelDeint requires it given explicitly, and TDeint can use Avisynth's internal value. The manual for FieldDeinterlace doesn't say what it does with the order, but I presume it acts like Telecide and picks it up from Avisynth's internal value.

I read that dgdecode will set the field order correctly in AviSynth, but I didn't think this was the same with all the other loading methods (AviSource, etc). If, in fact, there are no deinterlacers which can determine the field order, how do people process video that doesn't have a constant field order and cannot be loaded by dgdecode? Maybe this is just one of those 'ugly' cases that one hopes to avoid, and just assumes the field order which is correct more than the other one?

[Revgen]

Avisynth's field order detection isn't exactly flawless, so using the parity option in TDeint isn't always going to work.

Whenever I'm working with material that switches field order, I use either TFM's or TDeint's override .txt file parameter to set the field order to BFF or TFF on certain frames or series of frames where this change occurs.

For example entering this into an ovr.txt:

233,500 o 0 # o=field order parameter 0=field order setting


And using the avisynth line below:

TFM(mode=1,order=1,ovr="mydrive:\otr.txt")


Will make sure that TFM counts frames 233 through 500 as BFF while the rest of the clip is specified as TFF.

[berrinam]

Does AviSynth actually do some analysis for field order detection?

[Revgen]

I believe that it does (or tries to ;) )

It may just try to detect the first frame. Which isn't exactly useful for this case.

[berrinam]

What about dgdecode? Does that actually provide field order hints, or am I simply deluded?

[Boulder]

You can use DGIndex to get the field order for the d2v project.

IIRC Avisynth always assumes BFF (why oh why?) unless told otherwise. As most stuff is TFF, this will often cause problems when you forget an AssumeTFF() from the script.

[stickboy]

Does AviSynth actually do some analysis for field order detection?AviSynth doesn't. Some plug-ins might.
IIRC Avisynth always assumes BFF (why oh why?) unless told otherwise. As most stuff is TFF, this will often cause problems when you forget an AssumeTFF() from the script.Because most of the stuff BenRG dealt with was probably BFF. Is most stuff really TFF? Aren't DV and most DVDs BFF?

[berrinam]

I have an algorithm which is pretty good at detecting the field order. I run it on a small sample (1%) of the video, and most of the time, it is overwhelmingly of one type. However, I don't know how to deal with content which doesn't fall into this category. What would you recommend?

[Boulder]

I've never seen a DVD with bottom field first, I don't know if they exist in NTSC releases. DV is BFF, that's true.

Berrinam: an easy way to check the field order manually is to use

xxxSource()
AssumexFF() # where x is either T or B
SeparateFields()

and open the script in VDub. Advance frame-by-frame and see if the motion is jerky. If it isn't, you know from AssumexFF() which one is the correct field order.

trbarry and sh0dan have written small functions for determining the field order, using the search will help you.

[berrinam]

trbarry and sh0dan have written small functions for determining the field order, using the search will help you.
Thanks, Boulder. I did a bit of searching and I found it. It turns out it is basically the same as my algorithm (and they both just mimic what a human does). My algorithm actually works better than a human analysis the way you described, because it samples sections throughout the entire film, and can thus detect a field order change (on a side note: if you are interested in this algorithm, and the program surrounding it, please head over here (http://forum.doom9.org/showthread.php?t=104760)).

My question from above:
However, I don't know how to deal with content which doesn't fall into this category. What would you recommend?From this, I referred to material which switches field order, like Revgen spoke about in his first post. I understand that, by hand, it would be possible to do what Revgen does, but I am looking for an automated approach. Ideally, I'm looking for a deinterlacer that can automatically detect the field order, but I am probably dreaming. Perhaps Revgen's approach is the best.

Looking at the manuals for Telecide and TFM, I see that both require the order to be specified (or given through DGIndex, etc). If these are field matchers, then why do they need to know the field order? Is this only for the segments that cannot be matched (ie, the video segments)?*Bump* Just so that this doesn't get forgotten

[neuron2]

Looking at the manuals for Telecide and TFM, I see that both require the order to be specified (or given through DGIndex, etc). If these are field matchers, then why do they need to know the field order? Is this only for the segments that cannot be matched (ie, the video segments)? Consider this TFF 3:2 sequence for frames 0-4 (top fields on top):

A A B C D
A B C C D

Suppose we are looking at the top field of frame N and trying to find its matching bottom field. We see that it can be only the bottom field from frame N or N-1.

Now consider a BFF sequence:

A B C C D
A A B C D

For this, we see that the corresponding match can be only the bottom field from frame N or N+1.
Thus, to limit the matches as needed, the field order is required.

Note that version 4 of Decomb tested both the forward and backward matches, instead of limiting it as above. That meant that Decomb 4 was capable of automatically adapting to the field order of the clip. This is a mixed blessing. While it is slightly easier for the user, it makes the filter slower and, worse, it makes possible extra spurious bad field matches. New generation Decomb therefore requires the user to specify the field order of the clip. (It provides an option to enable 3-way matching for special cases, however.)

[Revgen]

Is most stuff really TFF? Aren't DV and most DVDs BFF?

Over here (R1) TV programs and DVD's always tend to be TFF. I've yet to find BFF material anywhere in this country.

It may be different in PAL or SECAM countries.

[Boulder]

Nope, TFF here as well.

[makoto916]

Given this algorithm could this be written as an AVISynth plugin? The reason I ask is that command line launched encoders (such as QuEnc) explicitly require that BFF or TFF be specified if you’re keeping the interlacing. In my case, I have to keep the interlacing because I’m use AVISynth to process material that will be rebroadcast on TV, or for DVD authoring that will ultimately end up back on an NTSC display.

Right now I get around the problem of detecting field order by ignoring it completely and let TMPGEnc Xpress determine the field order on its own. However, if I wanted an all command line based set of tools – so that I could automate the process with a batch file – I don’t know a way to automatically determine the field order in AVISynth and switch it if necessary.

Ultimately, I mix sources from DVD (usually TFF) and DV (always BFF). If there were a plugin for AVISynth that could determine the field order and set a variable, then a routine could be written in AVISynth that could result in the output of everything as TFF and therefore the encoder wouldn’t need to worry about it.