Log in

View Full Version : Reducing 1080i to 480 and keeping it interlaced


phædrus
7th April 2007, 20:59
I asked kind of a dumb question down in the HDTV forum about hybrid sources, which I won't repeat. I guess I just wasn't thinking clearly, because I haven't really dealt with this hybrid problem. Perhaps this is a dumb question, but this ought to be the place for it.

If I want to encode a program that is hybrid, broadcast in 1080i, and keep the interlacing to avoid obvious hassles of deinterlacing mixed media (straight video and telecined portions), what kind of avs script would I do?

Seems to me if I could separate fields, resize them, then recombine them and encode as interlaced, this would work for resizing 1080i down to 480i.

So...

SeparateFields()
LanczosResize(720,240)
Weave()

Then encode this with CCE or whatever as interlaced. If I am missing something, please correct me.

burfadel
8th April 2007, 07:31
Use Lanczos4Resize, it will give a slightly better picture (and sharper) and the expense of a tiny bit of speed. The commands are exactly the same, just add the 4!

scharfis_brain
8th April 2007, 11:58
using separatefields().resize().weave() is a very bad idea. You'll loose a big amount of image detail due to a vertical field mismatch.

it is better to deinterlace, resize and then reinterlace:


mpeg2source("1080.d2v")

# or the new ported yadif(mode=1)
bob()

# use 704,576 if you got a 25fps 1080i input
lanczosresize(704, 480)

# uncomment this line, if you plan to feed this into a commercial encoder like procoder, cce or tmpgenc
#converttoyuy2()

#set the desired output fdieldorder
assumetff()

# reinterlace
separatefields().selectevery(4,0,3).weave()

burfadel
8th April 2007, 13:49
Instead of the lanczosresize(704, 480) command, use lanczos4resize(704, 480) for a slightly better, sharper picture :)

using separatefields().resize().weave() is a very bad idea. You'll loose a big amount of image detail due to a vertical field mismatch.

it is better to deinterlace, resize and then reinterlace:


mpeg2source("1080.d2v")

# or the new ported yadif(mode=1)
bob()

# use 704,576 if you got a 25fps 1080i input
lanczosresize(704, 480)

# uncomment this line, if you plan to feed this into a commercial encoder like procoder, cce or tmpgenc
#converttoyuy2()

#set the desired output fdieldorder
assumetff()

# reinterlace
separatefields().selectevery(4,0,3).weave()

foxyshadis
8th April 2007, 14:27
Or use lanczosresize(704, 480, taps=32) for the bestest, sharpest picture in all the world!

I think Scharfi, of all people, would know the tradeoffs between 3 & 4 taps quite well. And frankly it isn't really all that much. Especially since broadcast sources usually range between decent and ugly, more taps just highlights major artifacts in bad scenes.

jeffy
9th April 2007, 22:09
Could someone please tell me if there is any condition against usage of this:
http://forum.doom9.org/showthread.php?p=915216#post915216
(correction in the last post)

scharfis_brain
9th April 2007, 22:30
it is too complicated. just use

bob-deinterlacer()
resize()
reinterlace()

it is far easier to understand an the loss of speed is negligible

jeffy
9th April 2007, 22:37
it is too complicated. just use

bob-deinterlacer()
resize()
reinterlace()

it is far easier to understand an the loss of speed is negligible

Thank you.

phædrus
18th April 2007, 02:22
using separatefields().resize().weave() is a very bad idea. You'll loose a big amount of image detail due to a vertical field mismatch.

it is better to deinterlace, resize and then reinterlace:


mpeg2source("1080.d2v")

# or the new ported yadif(mode=1)
bob()

# use 704,576 if you got a 25fps 1080i input
lanczosresize(704, 480)

# uncomment this line, if you plan to feed this into a commercial encoder like procoder, cce or tmpgenc
#converttoyuy2()

#set the desired output fdieldorder
assumetff()

# reinterlace
separatefields().selectevery(4,0,3).weave()

scharfis_brain, thanks for replying. I have seen so many of your posts here, and I consider you the deinterlace guru. I think I can use this. I've been lazy lately and just converting the ts files with HDTV2DVD. But when I have a program that is worth the effort to encode with CCE, I will use this. One question -- is there some reason that the conversion to YUY2 is where it is? Would it be bad to put it at the end of the script? Just curious, since any other time I've used CCE with an avs script (not that many times, really) I have converted to YUY2 at the end.

scharfis_brain
18th April 2007, 05:55
converting before yuy2() is much better, cause the conversion can be done on progressive video.

if converting to yuy2 after reinterlacing, you'll end up with much more blurred chroma.

If you like even better chroma, you need to place converttoyuy2() before the resizer

phædrus
21st June 2007, 22:25
converting before yuy2() is much better, cause the conversion can be done on progressive video.

if converting to yuy2 after reinterlacing, you'll end up with much more blurred chroma.

If you like even better chroma, you need to place converttoyuy2() before the resizer

scharfis_brain, I just wanted to follow up and thank you again for help with the script. I have used it a couple of times to make mpg files with CCE of David Letterman clips and PBS documentaries. Works very nicely, though I wish my computer was faster. Doing a 2-pass for a one-hour program takes about 15 hours. Such is life, if you want quality, and don't have a new computer.

I confess, though, even after reading the avisynth.org wiki on the selectevery command, I don't understand the parameters. As Data's brother Lor said when he installed dr. Sung's emotion chip, "I don't know what it's doing, but it's doing something."

phædrus
27th July 2007, 03:27
scharfis_brain, just one additional question. In this script you made:


mpeg2source("1080.d2v")
bob()
lanczosresize(704, 480)
converttoyuy2()
assumetff()
separatefields().selectevery(4,0,3).weave()

If the original clip is bottom field first, should I set the output to be assumebff() in this script instead of tff? This is confusing to me because in CCE, or the version I'm using at least, there is a checkbox you have to check if the input is bff, because CCE always puts out tff (if I read the manual correctly).

So I'm confused here. If the input is bff, should I put assumetff in the script just as you have it, and then leave CCE alone? Or should I change line 5 of the script to assumebff, and then check the box in CCE so that it will do whatever it does to switch the field order and come out with tff.

I've had an interlaced encode or two that played back jerky in WMP and PowerDVD, so I thought possibly I had messed up the field order on those somehow, and I had better ask.

manono
28th July 2007, 13:08
Hi-

As you can tell, I'm not scharfis_brain. Unless and until he comes back to contradict me or to clarify what I'm about to say, then this is how I do it. I think I got all of it from him anyway, except for the doublecheck at the bottom, which is from neuron2.

1.) If it's BFF and you want to keep it BFF and then encode as BFF (making the necessary change in CCE):

AssumeBFF()
SeparateFields().SelectEvery(4,0,3).Weave()

2.) If it's BFF and you want to change it to TFF and encode as TFF (with no change in CCE):

AssumeBFF()
SeparateFields().SelectEvery(4,1,2).Weave()

You can doublecheck to make sure you got it right by temporarily adding Assume(whatever field order you think it's supposed to be).SeparateFields() at the very bottom of the script, opening it in VDub(Mod), and playing it during a motion sequence. If it plays smoothly, you got the field order correct, and you then just have to make sure to set it correctly in the encoder. If it plays jerkily after being encoded, you can be sure it was a wrong encoder setting, rather than your script, that was at fault. But all is not lost, because you can set it right again in ReStream.

foxyshadis
28th July 2007, 20:29
At that point it shouldn't matter, and you should be able to use either tff+4,0,3 or bff+4,1,2 to create the exact same stream. Two ways of saying the same thing. Where source matters is at or immediately before the bob step; avisource defaults to bff, and mpeg2source sets the field order correctly based on the source.

Jan Marijniszoon
23rd September 2007, 11:05
I have been reading this thread with interest.

But something spins my mind here...

When you do bob(), then the fields are being upscaled with bicubicresize. Isn't this causing a quality loss?

I know this thread is about HD material.
But how about SD material?

Say I want to convert a 720x576 clip to 640x480 then shouldn't SeparateFields.Lanczos4Resize(640,240).Weave be less quality loss then the bob-method? And does there even exist a way that does the job 100% lossless?

scharfis_brain
23rd September 2007, 11:32
resizing can not be lossless!

the way of separatefields().rezise().weave() will cause a vertical field misalignment, which jields into staistepping and resolution loss.

any_good_bob()
resize()
separatefields().selectevery(4,0,3).weave()

is the better method! if you are choosing a motion adaptive or motion compensated deinterlacer, the scaling result will be awesome, cause static areas will sacles progressively and moving areas will scaled with the result of the deinterlacer's interpolation.

foxyshadis
23rd September 2007, 15:46
If you're doing realtime, for instance, and can't afford a bob-resize, the correct way for TFF is (if my memory/logic is correct):

SeparateFields()
interleave( \
selecteven.LanczosResize(w,h,src_top=-.5), \
selectodd.LanczosResize(w,h,src_height=height+.5) \
)
Weave()

Swap the top/height for BFF. But even a decent, fast bobber like yadif will probably yield better results with scharfi's method.