Script for change TFF to BFF

[yup]

Hi All!
Simple question:
this script

AVISource("test.avi")
AssumeTFF()
DoubleWeave()
SelectOdd()

Will be change TFF interlaced video to BFF? Task very simple, I captured video as TFF and now need reencode to DV which could be BFF.
Please advise, may be exist other way?
With kind regards yup.

[IanB]

Yes, DoubleWeave() pairs fields alternatly [01][12][23][34][45]... and with SelectOdd() then select the [12][34][56]... pairing. So you will end up with BFF frames.

Note you do loose the 1st field (0) and reuse the 2nd last field in the last frame. ...[n-4,n-3][n-2,n-1][n,n-1]

[stickboy]

Try my JDL_ReverseFieldDominance function.

[yup]

IanB!

And this script introduce delay between audio and video half time between frames in my case PAL 20ms?
stickboy

Your function JDL_ReverseFieldDominance not introduce delay and first and last frames will be get from bobbed if bobFirstLast=true.
One more thanks. I have 4 hour capture video and Your answer very important for me.
yup.

[yup]

I try 3 way:
1.

AVISOurce("part1f.avi")
AssumeTFF()
DoubleWeave()
SelectOdd()

and using cedocida DV codec in YUY2.
2.

AVISOurce("part1f.avi")
AssumeTFF()
JDL_ReverseFieldDominance(bobfirslast=true)

and using cedocida DV codec in YUY2.
3.

AVISOurce("part1f.avi")
AssumeTFF()

and using Mainconcept DV codec 2.4.16 using flang change field order.
All ways give jerky results especialy on date stamp which moving up and down.
That I made wrong?
With kind regards yup.

[stickboy]

Are you sure you need to reverse the field dominance in the first place?

[yup]

@ stickboy!
Yes, I have problem with capture AVI all my file have BFF but indeed TFF, my card Pinnacle PCI 700 and I use VirtualDub for capture. I get good result with Reverse Field Dominance.
4 way

AVISource("part1f.avi")
ReverseFieldDominance(true)
AssumeBFF

and using Cedocida DV codec
yup.

[IanB]

@Yup,

Perhaps you had better check this AVI file, it sounds like AssumeTFF() is NOT the correct choice for this file.

AVISource("part1f.avi")
AssumeTFF() # or AssumeBFF()
Bob()

Load this in to VirtualDub and examine, frame by frame, a high motion scene. Ignore any artifacts from dumb Bob(), you are just looking for correct motion order here. To be sure try again with AssumeBFF(). One should be correct the other should do the 2 step forwards 1 step back shuffle.

Please report your findings here so others may benefit from your experiences.

The above script will take the individual fields and crudely make them into 2 times as many full frames.


And

AVISource("part1f.avi")
ReverseFieldDominance(true)
AssumeBFF

Unless there is more script following, the AssumeBFF() here does nothing.

Assume?FF() just set internal flags such that field order sensitive filters can know the time order of the fields, the field order information is NOT exported.

[yup]

@IanB!

AVISource("part1f.avi")
AssumeTFF()
Bob()

give flow monion

AVISource("part1f.avi")
AssumeBFF()
Bob()

give jerky result with back motion per 2 frames.
Also when I encoding this file in CCE I do not use field shift.
Better result for me give script:

bob()# or yadifmod, or nnedi as bobber
SeparateFields()
SelectEvery(4,1,2)
Weave()

yup.

[Music Fan]

Hi,
I found another simple solution to convert BFF to TFF in the doc of Remove Blend 0.3, but I don't know if it works to convert TFF to BFF;

avisource("your_clip.avi")
separatefields()
trim(1,0)
weave()

[Gavino]

The basic idea works, but to make it convert TFF to BFF you will have to add AssumeTFF() since the Avisynth default is BFF.

avisource("your_clip.avi")
AssumeTFF()
separatefields()
trim(1,0)
weave()

[Music Fan]

Originally Posted by Music Fan

I don't know if it works to convert TFF to BFF

I just tested with both TFF and BFF videos and it works (I answer to myself ).

Originally Posted by Gavino

to make it convert TFF to BFF you will have to add AssumeTFF() since the Avisynth default is BFF

I'm not sure that one needs to add it, I often encode in TFF without this line and the resulting video is well encoded.

But there is something I don't understand in this script : the trim line removes 1 field (or actually a frame in this case, as the frames are separated in 2 progressive frames having half the resolution of the avi, each one containing one field whose lines are tightened), but the weave line renders the same number of frames than if one don't put the trim line.
Example ;

avi file#720.480, 115 frames
separatefields()#720.240, 230 frames
trim(1,0)#720.240, 229 frames, TFF became BFF (or vice versa depending on the original video's parity)
weave()#720.480, 115 frames again

How can the weave function create a complete frame with one missing field ?

[Gavino]

Originally Posted by Music Fan

I'm not sure that one needs to add it, I often encode in TFF without this line and the resulting video is well encoded.

Well, you certainly need it here, otherwise SeparateFields() will split the fields in the wrong order.
Encoding is a different case, since you can tell the encoder that the clip is TFF, but you will certainly need it for any Avisynth filters that need to know the correct field order to function properly.

How can the weave function create a complete frame with one missing field ?

A good question.
What happens is that Avisynth repeats the last field to complete the sequence, so the final frame actually consists of two identical fields.

[Music Fan]

Originally Posted by Gavino

Well, you certainly need it here, otherwise SeparateFields() will split the fields in the wrong order.
Encoding is a different case, since you can tell the encoder that the clip is TFF, but you will certainly need it for any Avisynth filters that need to know the correct field order to function properly.

I'm astonished, because my clip stays in TFF when I do this ;

avisource("your_clip.avi")#TFF
separatefields()
weave()
AssumeTFF()
bob()

I open it in Virtual Dub, and it's fluid. It's not if I choose BFF in place of TFF.
Doesn't it mean that separatefields and weave keep the good field order ?

[Gavino]

Originally Posted by Music Fan

If I understand well, the only way to invert fields without losing the last field and without de-interlacing and re-interlacing is to use ReverseFieldDominance(true) ?

It's the first field you lose, not the last (which gets repeated).
JDL_ReverseFieldDominance avoids that problem.

Originally Posted by Music Fan

Doesn't it mean that separatefields and weave keep the good field order ?

Yes, Weave will retain the field order used by SeparateFields, so you end up with the original frames again.
But in between the two, the fields will be in the wrong order so any filter that depends on the temporal order will not work properly. (Trim(1,0) falls into that category.)

[yup]

May be like Ianb explained at post #2? Two last frame from fields [n-2,n-1][n,n-1].
yup.

[Gavino]

Originally Posted by yup

May be like Ianb explained at post #2? Two last frame from fields [n-2,n-1][n,n-1].

Yes, but I think IanB has got it wrong and it is [n-2,n-1][n,n].

[Music Fan]

Right, thank you guys.
If I understand well, the only way to invert fields without losing the last field and without de-interlacing and re-interlacing is to use ReverseFieldDominance(true) ?

[Music Fan]

Ok, thanks.

[IanB]

Originally Posted by Gavino

Yes, but I think IanB has got it wrong and it is [n-2,n-1][n,n].

Yes for the DoubleWeaveFields case. This is used by Weave() and DoubleWeave() with Field Separated clips.

No for the DoubleWeaveFrames case. This is used by DoubleWeave() with Framebased clips.


DoubleWeaveFrames always joins a Top fields with a Bottom field, so at the end boundary it fetches the last frame from the source clip for both inputs and extracts a Top field, n, and a Bottom field, n-1. Which is the case for my post #2 above.


DoubleWeaveFields always joins an even frame with an odd frame , so at the end boundary it fetches the last frame from the source clip for both inputs and use it as both top and bottom field.