Resize Interlaced Source from 4:3 to 16:9 - deinterlace yes or no?

[newuserxyz]

Hello!

I want to resize some mpeg2-video clips (which I grabbed from vhs) from 4:3 to 16:9. For that reason I'm playing around with avisynth to get the best result.
I read in several posts that I have to first deinterlace my (interlaced) source and afterwards resize to the new format.

I used (amongst others) the following script:

LoadPlugin("SmoothDeinterlacer.dll")
mpeg2source("mySource.d2v")
SmoothDeinterlace()
LanczosResize(736, 784)
Crop(8,104,720,576)

The resulting video is worse than the result of the same skript without deinterlacing.
What's my fault? :scared:

Thanx

newuserxyz

[Alex_ander]

I want to resize some mpeg2-video clips (which I grabbed from vhs) from 4:3 to 16:9.
If your original video shows correct proportions at playback with 4:3 setting in your player, then to turn it into 16:9 you want to crop exactly 1/4 of its height in pixel numbers, then resize the result to 720x576 and set 16:9 flag in your mpeg encoder.

[neuron2]

The resulting video is worse We can't read your mind. In what way is it worse?

[Gavino]

The resulting video is worse than the result of the same skript without deinterlacing.
What's my fault?
It might be you need to tell Avisynth and/or the deinterlacer the field order of your clip, ie TFF or BFF.

Try adding AssumeTFF() or AssumeBFF() as appropriate before calling SmoothDeinterlace (or perhaps it has a field parameter - I'm not familiar with that particular deinterlacer).

[newuserxyz]

We can't read your mind. In what way is it worse?

The video is blurry.

It might be you need to tell Avisynth and/or the deinterlacer the field order of your clip, ie TFF or BFF.

Try adding AssumeTFF() or AssumeBFF() as appropriate before calling SmoothDeinterlace (or perhaps it has a field parameter - I'm not familiar with that particular deinterlacer).

I tried both opportunities but both make no difference

[neuron2]

Your are upscaling VHS source and complaining that the result is blurry?

[reepa]

If the content is film-based, use an IVTC filter instead of SmoothDeinterlace. If not, try Yadif instead of SmoothDeinterlace (Yadif is a bobber so you'll have to reinterlace after resizing - I can't remember the required SelectEvery line).

edit: you can determine the correct field order by inserting AssumeTFF() or AssumeBFF() after mpeg2source(), then adding SeparateFields(), and finally looking at the video and selecting the non-juddery/jumpy one.

[Mug Funky]

lol @ neuron2

maybe use a bob and reinterlace later. if it's VHS it might have been transferred on a crappy filmchain or an antique telecine, in which case you'll need all the fields intact to avoid full-frame blending (blending on fields is far less noticable)

[Blue_MiSfit]

Toss us a sample?

[LocalH]

Hello!

I want to resize some mpeg2-video clips (which I grabbed from vhs) from 4:3 to 16:9. For that reason I'm playing around with avisynth to get the best result.
I read in several posts that I have to first deinterlace my (interlaced) source and afterwards resize to the new format.

I used (amongst others) the following script:

LoadPlugin("SmoothDeinterlacer.dll")
mpeg2source("mySource.d2v")
SmoothDeinterlace()
LanczosResize(736, 784)
Crop(8,104,720,576)

The resulting video is worse than the result of the same skript without deinterlacing.
What's my fault? :scared:

Thanx

newuserxyz

If the footage is true interlaced content and not film-based or 25fps then you should use some sort of bobber to get a 50fps source that retains all the temporal resolution of the original video, resize and crop, then extract the lines that came from the original fields (as opposed to the bob-generated lines) and weave them back together into new frames. Something like this (I'm going to use a cheap dumb bob as I'm writing this off the cuff but you can substitute any advanced smart bob):

mpeg2source("mySource.d2v")
AssumeBFF() # change this to AssumeTFF() if the resulting video is not fluid
Bob()
LanczosResize(736, 784)
Crop(8,104,720,576)
SeparateFields()
SelectEvery(4,0,3)


Everyone, please correct if I have included any errors in my explanation or the script.

[Alex_ander]

mpeg2source("mySource.d2v")
AssumeBFF() # change this to AssumeTFF() if the resulting video is not fluid
Bob()
LanczosResize(736, 784)
Crop(8,104,720,576)
SeparateFields()
SelectEvery(4,0,3)


Everyone, please correct if I have included any errors in my explanation or the script.

1.Weave() is missing in the end
2.Crop numbers should be like (0,72,-0,-72) for getting 16:9 from 4:3 with a 720x576 input
3.Before SeparateFields(), AssumeTFF() is useful for defining the output field order
4.AssumeBFF() in that place is only useful if the original mpeg file has wrong field order flags: d2v anyway brings that data into script.


A possible version:

mpeg2source("mySource.d2v")
LeakKernelBob(order=1)# order by source, 0 for BFF
Spline36Resize(704,576,8,72,-8,-72).AddBorders(8,0,8,0)
DoubleWeave().SelectEvery(4,1)# for TFF 16:9 encoding

The last line is equivalent to SeparateFields().SelectEvery(4,1,2).Weave(), it inverts (on output) field order which is BFF here due to resetting it by LeakKernelBob. Crop numbers for vertical borders may slightly vary depending on source, usually cropping to visible is OK.

[Gavino]

... resize and crop, then extract the lines that came from the original fields (as opposed to the bob-generated lines) and weave them back together into new frames.
Slight inaccuracy here. After resizing, the original lines are mixed with the bob-generated ones and can't be recovered. So when you re-interlace the resized fields, you will inevitably include information added by the bobber.

[shoopdabloop]

Quick question, does converting 30p to 60i do anything?
I would imagine it doesn't, but i'm not 100% sure...

(the slight vertical blurring recommended for TV sets is out of the question)

[LocalH]

Not really needed, since 30p is directly compatible with 60i. If you bob it, process it, and re-weave it without doing any vertical resizing then you should end up with the original lines at the end of the script, so essentially you'd be wasting CPU time on a useless bob+weave process.

Gavino: Ah, yes, that point slipped my mind. In that case, the better the bobber, the better the end result.

[newuserxyz]

First of all thanx for all the replies!!

If the footage is true interlaced content and not film-based or 25fps then you should use some sort of bobber to get a 50fps source that retains all the temporal resolution of the original video, resize and crop, then extract the lines that came from the original fields (as opposed to the bob-generated lines) and weave them back together into new frames. Something like this (I'm going to use a cheap dumb bob as I'm writing this off the cuff but you can substitute any advanced smart bob):

mpeg2source("mySource.d2v")
AssumeBFF() # change this to AssumeTFF() if the resulting video is not fluid
Bob()
LanczosResize(736, 784)
Crop(8,104,720,576)
SeparateFields()
SelectEvery(4,0,3)


Everyone, please correct if I have included any errors in my explanation or the script.


Thanx LocalH - that really improved the result. I used yadif as a bobber and added weave() at the end (hopefully yadif is a bobber :D)

1.Weave() is missing in the end
2.Crop numbers should be like (0,72,-0,-72) for getting 16:9 from 4:3 with a 720x576 input
3.Before SeparateFields(), AssumeTFF() is useful for defining the output field order
4.AssumeBFF() in that place is only useful if the original mpeg file has wrong field order flags: d2v anyway brings that data into script.


A possible version:

mpeg2source("mySource.d2v")
LeakKernelBob(order=1)# order by source, 0 for BFF
Spline36Resize(704,576,8,72,-8,-72).AddBorders(8,0,8,0)
DoubleWeave().SelectEvery(4,1)# for TFF 16:9 encoding

The last line is equivalent to SeparateFields().SelectEvery(4,1,2).Weave(), it inverts (on output) field order which is BFF here due to resetting it by LeakKernelBob. Crop numbers for vertical borders may slightly vary depending on source, usually cropping to visible is OK.

This script gave the best result to me. I used GSpot to find the aspect to resize to 16:9. Can you explain the math behind your values? Why do you add borders at the left and right side?

[Alex_ander]

Can you explain the math behind your values? Why do you add borders at the left and right side?
In that script the video is a)temporarily deinterlaced (for safe resizing) with double framerate, b)resized and c)interlaced with the desired field order.
The cropping/resizing numbers come from simple relationship between abstract 4:3 and 16:9 images and don't depend on actual pixel ratio of the numbers (5:4 here) stored for image sides. For example, to define how much (in relative inits) to crop for transforming 16:9 into 4:3 imagine 4:3 as 12:9, then (16:9)-(12:9)=4:9. Horizontally the part to cut off is (16:9)/(4:9)=1/4. The same proportion works in the other direction and you still have to cut 1/4 of image (in pixel numbers as measure units). So here the numbers to cut are 576/4=144 (or 72+72). As for horizontal borders, there's a small correction by ITU digitazing standard (usually followed by DVD makers). According to it (with the standard sample rate unified for PAL/NTSC) in case of PAL 702 of 720 samples per line represent the visible part of image and define 4:3 AR ( just slightly different in case of NTSC). That is why the image is most often made 704 with 8+8 borders (if 720).
After resizing, to restore interlaced structure, from each pair of frames 2 fields are used. DoubleWeave inserts a new interlaced
frame within each pair (like 0-1, 1-2, 2-3 etc.) by combining the last field of previous frame with the first field of next frame. New frames created for even pairs are selected for output: for each 4 sequential frames (0,1,2,3) the right position of the wanted frame is '1'. The field order is opposite to the defined just before DoubleWeave().