Script for change TFF to BFF

[yup]

Hi All!
Simple question:
this scriptAVISource("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 (http://www.avisynth.org/stickboy/).

[yup]

IanB!
:thanks:
And this script introduce delay between audio and video half time between frames in my case PAL 20ms?
stickboy
:thanks:
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.


AndAVISource("part1f.avi")
ReverseFieldDominance(true)
AssumeBFFUnless 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]

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 :rolleyes:).

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.:confused:
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]

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.

[yup]

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

[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]

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]

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].

[Gavino]

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.

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.)

[Music Fan]

Ok, thanks.;)

[IanB]

May be like Ianb explained at post #2? Two last frame from fields [n-2,n-1][n,n-1].
yup.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.

[Gavino]

Thanks for the clarification, Ian, and sorry for doubting you. :)
I based my conclusion on DoubleWeaveFields and wrongly assumed that DoubleWeaveFrames would behave similarly (since the documentation says it is equivalent to calling SeparateFields first).

[Music Fan]

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.
I don't understand this message.:o

So, what do we have to do ?

It's the first field you lose, not the last (which gets repeated).
JDL_ReverseFieldDominance avoids that problem.
Is this still good or not ?

[Gavino]

I don't understand this message.
I was mistaken to say that IanB was wrong in post #2 - DoubleWeave().SelectOdd() behaves just as he said there.
But what I said in post #13 is correct - when using SeparateFields().Trim(1,0).Weave(), the last output frame consists of two fields both identical to the last field of the input.
So, what do we have to do ?
Nothing, although it might give you a reason to choose one solution over the other, dpending on the outcome you prefer.

Is this still good or not ?
What I said about JDL_ReverseFieldDominance is true - it keeps all the original fields (but adds new ones at the beginning and end).

[Music Fan]

Thanks for this clear answer.
So, no one of these solutions to invert fields keep exactly the same number of fields ?

[Gavino]

None of the three solutions above keep exactly the same number of fields, ie
1) DoubleWeave().SelectOdd()
2) SeparateFields().Trim(1,0).Weave()
3) JDL_ReverseFieldDominance()

There is another solution, Simon Walters' ReverseFieldDominance (http://www.reocities.com/siwalters_uk/reversefielddominance.html), which keeps the same number of fields, but alters them spatially, so you end up losing a line from each field. There is no 'perfect' solution to the problem, you just have to choose the one you like most (or dislike least).

[Music Fan]

Ok, thanks.
But I wonder if a trick would be possible to keep the exact number of frames, for example ;
-add a black frame at the beginning and another at the end of the video,
-then useJDL_ReverseFieldDominance,
then separatefields,
-then remove 1 or 2 field,
-then weave.
Or something like that. But I guess that if we remove one field, weave won't weave in the good order, as one field is missing, and a TFF (or BFF) video will stay in TFF (or BFF), isn't it ?
I believe that the simplest solution is to use trim(1,0) ;
-add 2 black frames (1 at the beginning and 1 at the end) and fades (in and out) not to see the added and badly created frame when we use trim(1,0).
But if we don't wanna fade the video, I guess something else is possible.
Not simple actually.