How to downrez TFF 1440i to BFF 480i

[NerdWithNoLife]

I had a 1080i pillarboxed clip that effectively was 1440x1080i, which I wanted to put on DVD. One problem encountered was the fact that the HD programming was top field first, while SD (in the US) is bottom field first, AFAIK. I know many people prefer to deinterlace, but since the end result was DVD and my TV's are CRT (which can properly display interlacing) I wanted 480i. Here's the script:
mpeg2source("clip.d2v")
assumetff().separatefields()
lanczosresize(720,240,240,0,-240,0) #use any resize you like, but it's good to crop while you resize.
trim(1,0,false) #trims first frame/field so you can start bottom field first.
assumebff().weave()
It came out way better than the first time I tried separating fields, resizing, and weaving. Hopefully someone else will find that useful. Oh, and if you're really picky you can delay the audio by -0.017ms to account for that whole 60th of a second.

[Guest]

That's a poor way to resize interlaced material. Use search.

There's no need to change the field order.

[NerdWithNoLife]

Whoops - forgot to set BFF in the encoder. Duh.

But doesn't a bob deinterlace? Everything I've read about bobbing involves deinterlacing. Most people want to deinterlace because they're viewing on a progressive monitor or changing frame rates, which I am not (it remains 29.97). Is it still a bob if the footage remains interlaced? I ask the great neuron2 (not sarcastically, I've learned a lot from you).

[NerdWithNoLife]

With HDTV, you are working with such a wealth of data, that even IF the method showed considerable artifacts they would not be readily apparent when resizing from HDTV to DVD res :). So you're safe both ways.
vs. the right way...
mpeg2source("clip.d2v")
crop(240,0,-240,0)
bob().lanczosresize(720,480)
separatefields().selectevery(4,1,2).weave()
Compared side by side, I concluded that I am a complete idiot! Lesson learned: do it the right way, even if you are resizing from interlaced to interlaced. I'll spend the rest of the evening reading the definition of bobbing over and over and hopefully I'll get why it is better, even when outputting interlaced material of the same framerate.
:thanks:

[scharfis_brain]

enen try yadif(mode=1) instead of bob()

it will make static areas become even crisper!

[Sagekilla]

Wait, so you have a source that's 1440x1080 with the left and right 240 most pixels being pure black?

[Blue_MiSfit]

Yeah. It may or may not be worth it to use a better bobber than just bob() for going from HD to SD. yadif should be a safe replacement, not much slower.

[IanB]

@NerdWithNoLife,

Don't use the internal Bob() filter, except for proof of concept. It is very very crude. There are many superior smart bob filters available, currently I quite like those by Tritical, also Neuron2's do a fair job as well.

Also is your source material genuinely interlaced, i.e. a sports broadcast or like. If it is film based with a 3:2 pulldown you are far far better off using IVTC filters to get back the original progressive frames, even if you (shudder) reinterlace it again. The smartest bobbers can only hope to approach the quality of correct IVTC.

And if you really truely must resize interlaced material directly, you must allow for the different vertical displacement between the 2 fields. See example (http://forum.doom9.org/showpost.php?p=1031317) for how to do an interlaced resize and see disscussion (http://forum.doom9.org/showthread.php?p=915260#post915260) for information about the process.

[NerdWithNoLife]

It's interlaced - a news clip. Each field is unique. I watch on CRT's, so interlacing is no problem. The intent is to go from 1080i to 480i, not 480p. The resulting frame rate should remain 29.97.
enen try yadif(mode=1) instead of bob()

it will make static areas become even crisper!
I tried that and the final image was deinterlaced - not desired.

And that's why I got confused in the first place. If I wanted to convert frame rates or create a progressive clip or PIP within an interlaced image, clearly it should be deinterlaced before resizing. But the goal was to convert to a smaller sized interlaced image so to a first timer separatefields().xresize(width,height).weave() *seemed* logical.

I'm still trying to understand the root cause of vertical misalignment from the above heresy. Is it because every line is meant to be between its neighbors and 540 lines do not share the same neighbors as 240 lines? I've been studying this but haven't wrapped my brain around it yet. I can see the difference but can't stand not knowing why bobbing does a better job.

[scharfis_brain]

I tried that and the final image was deinterlaced - not desired.

Then you made a mistake!

This script will output interlaced 480i at 29.97fps WITH interlacing.

mpeg2source("clip.d2v")
crop(240,0,-240,0)
yadif(mode=1)
lanczosresize(720,480)
Assumetff() #or assumebff() dependant on wished output field order
separatefields().selectevery(4,0,3).weave()


The field misalignement of this process: separatefields().resize().weave() is caused by the following:
In 1080i the fields have a displacement of 1/2 pixel towards each other.
if you scale the fields down to get 480i the fields will still have the displacement of the 1080i source.
But the pixels of the 480i video are much bigger now! so the displacement is about 1/5 now in relation to 480i.
That's why correction is needed!

This can either be done by IanB's method, or by using bob().
bob() by its nature will place the fields correctly cause it bobs the field 1/2 pixel up and down and puts put a progressive 59.94 fps stream.
Both will show comparable output.
But if you replace bob() by a motion adaptive deinterlacer then static areas will be taken from two fields, thus enhancing resolution before resizing.
After the deinterlacer the 59.94fps video will be re-interlaced to 29.97fps to get an interlaced video again.

[NerdWithNoLife]

b) is only right, if previously BFF has been signalled!
(bob() always does this!)

but what about, if you rapidly decide to switch over to another deinterlacer, that handles the fieldorder signalling correctly? you'll get a reversed fieldorder!

if TFF had been signalled:
4,0,3 -> TFF
4,1,2 -> BFF

if BFF had been signalled:
4,0,3 -> BFF
4,1,2 -> TFF

as you can see: 4,0,3 changes nothing while 4,1,2 reverses the fieldorder.

btw.: some time ago, I trapped into this, too.
Its cost had been several lost and greyed hairs....
Yeah, I can see how this gets confusing in a hurry! Which is why I had that weird way of swapping fields - kind of went through the same thing - only I'm dumber than you Scharfis_Brain! :)

[foxyshadis]

It's partially because you're losing information in the missing fields, but the main reason is a misalignment of pixels mapping from the old to the new. Some people never notice, it's one of those perfectionist things, but it will damage static frames pretty badly. Try this script on a progressive frame to visualize the difference:

assumeframebased
x1=bicubicresize(width,480).separatefields.weave
x2=separatefields.bicubicresize(width,240).weave
interleave(x1,x2)

oops, scharfi got there first.

[NerdWithNoLife]

Aha. That makes sense now. Thanks very much guys! Well, I'm off to design my own quantization matrix...

Just kidding. ;)

Edit: I totally get it now! You want to be AT the target resolution before you separate fields, otherwise the displacement will screw up. But you can't resize a full frame with two fields from two different times 1/60th second apart (I don't want to think how bad that would look), so you create a full frame of each field by bobbing it up. Then it's okay to resize. Once you're at your end resolution it's okay to separate fields - which you do - then you only need a top field and a bottom field so you select one of each (two per four), weave them together and - bam! A resized frame with proper displacement.

Victory! I hate using scripts I don't understand...

[Blue_MiSfit]

Win! Well done.

What bobber did you end up using?

~MiSfit

[NerdWithNoLife]

Used yadif(mode=1). I don't think the difference will be huge with the downrez from 1080i, but the concept is appealing. Keep the static areas static and sharp - why not use the encode to tweak it a little? Quality is important to me, so I just encode overnight. In the long run, I want a good product, not a quick encode.

[Blue_MiSfit]

There you go. I figured YADIF(mode=1) would be a good match, since it's very fast, and much better than bob() in static areas.

~MiSfit