assumetff() assumebff()

[wotef]

- AssumeTFF() and AssumeBFF() to force parity

is there any documentation on these new functions other than their inclusion in the change log?

are they just short hand for separatefields / complementparity?
or do they do something else?

[WarpEnterprises]

The actual docu can be seen at sourceforge (of course work is still in progress!)
CVS-DOCU (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/avisynth2/avisynth/docs/index.html?rev=HEAD&content-type=text/html)
and of course at The AviSynth Homepage (http://www.avisynth.org)

Those two commands SET the fieldorder rather than change it and don't separate fields.

[eobard]

Read the docs, still can't understand. If my video is interlaced i need to used AssumeBFF, right?

[Groucho2004]

Read the docs, still can't understand. If my video is interlaced i need to used AssumeBFF, right?Read this (http://rationalqm.us/faq.html#analysis) and this (http://rationalqm.us/faq.html#order).

[johnmeyer]

I don't quite understand what problem you are having.

All the AsssumeBFF/AssumeTFF statements do is to override whatever assumption AVISynth makes about field order. Some video provides this information to the video program, and some does not. Sometimes the information provided is wrong.

So, what the Assume functions do is to force AVISynth to read the fields in the order specified, regardless of what AVISynth is told by the video header.


To test whether you have the Assume function set correctly, I recommend opening your video in this script:

AssumeTFF()
Separatefields()

Open this script in VirtualDub and walk through the video one field at a time (you are looking at fields, not frames). If the motion looks normal, you have got the right Assume function. However, if the video goes back and forth, you have it set the wrong way.

The back and forth motion gives you some idea of how screwed up your script can get if you don't have this set correctly.

I perform this test on every single interlaced video that anyone gives to me, because field orders are ALWAYS getting screwed up by people who don't know what they're doing.

[FranceBB]

I perform this test on every single interlaced video that anyone gives to me, because field orders are ALWAYS getting screwed up by people who don't know what they're doing.

Story of my live. Literally. I receive fucked up interlaced contents on a daily basis...

[johnmeyer]

Story of my live. Literally. I receive f*#%*d up interlaced contents on a daily basis...You're in the broadcast business and what amazes me, fifteen years after the HD switchover, is how often I see massive field reversal artifacts on SD material incorporated into a program. It appears that engineers at local stations don't know how to handle field dominance changes.

[PhillipWyllie]

Try AssumeTFF() first and scrub the video through parts with motion. If the video jerks back and forward have bff video and should use AsuumeBFF(). In any case to confirm that you are right try the opposite function and look for jerky video in parts with motion.

[Groucho2004]

Try AssumeTFF() first and scrub the video through parts with motion. If the video jerks back and forward have bff video and should use AsuumeBFF(). In any case to confirm that you are right try the opposite function and look for jerky video in parts with motion.Lather, rinse, repeat? The links I gave in post #4 already describe this procedure in detail. Then John posted the same thing, now you. WTF?

[videoh]

You know what they say, Groucho... Imitation is the sincerest form of flattery.

Thank you for the links you provided.