Convert 720x480 to 640x480

[SameSelf]

Here's a question for you gurus. If I want to convert some 720x480i29.97 NTSC 10:11 PAR 4:3 video to 640x480 1:1 PAR what is the best method in your opinion? For example, Method 1:

LanczosResize(640,height)

Or, should I first crop the overscan to 704x480? Since 704x480 is the actual SAR for 4:3 video with anamorphic 10:11 PAR, while 640x480 uses a 1:1 PAR for 4:3 video. Method 2:

osp=8 # overscan pixels
Crop(osp,0,-osp,0)
LanczosResize(640,height)

I am thinking Method 2 as this avoids resizing the overscan region into the video. But other examples I have seen on the web don't crop the overscan. So I am wondering if maybe LancsozResize (or any other re-sizer) accounts for this that I am unawares? TIA.

[poisondeathray]

I typically look at the source. Some require method 1, some method 2 , some a different method. Look for known circular objects like tires or circular wall clocks. If you do it one way, and it's now "oval" then it's probably the wrong way . In general , older analog transfers typically use ITU rules, so the inner 704 pixels

[manono]

I typically look at the source. Some require method 1, some method 2 , some a different method. Look for known circular objects like tires or circular wall clocks.

I think he's more concerned about the overscan (a red herring, in my opinion) than about getting the correct aspect ratio. In any event, I don't think cropping away active video is the answer. He'll still lose to the overscan, if that's a concern, but his way he'll lose both what he cropped away as well as the overscan amount.

If it's really a roughly 1.37:1 ratio video, then what's wrong with 656x480? If it's not a 1.33:1 ratio video, then why resize to a 1.33:1 resolution? Crop only any black bars and not any active video.

[newpball]

Here's a question for you gurus. If I want to convert some 4:3 NTSC video to 640x480 square pixels what is the best method in your opinion? For example, Method 1:

LanczosResize(640,height)

Or, should I first crop the overscan to 704x480? Since 704x480 is the actual anamorphic PAR of 0.909 that is used to scale down 4:3 video to square pixels at 640x480 and still maintain the 4:3 AR. Method 2:

osp=8 # overscan pixels
Crop(osp,0,-osp,0)
LanczosResize(640,height)

I am thinking Method 2 as this avoids resizing the overscan region into the video. But other examples I have seen on the web don't crop the overscan. So I am wondering if maybe LancsozResize (or any other re-sizer) accounts for this that I am unawares? TIA.

From a clean digital source, I would go 720x540!
Why cut resolution?

From some crappy old analog source it won't matter much anyway as long as your method does not sharpen the video because that only would make things worse.

[SameSelf]

Thanks pdr for the advice. Lucky for me I was able to find a clock! Using vdub I loaded the original footage (no resizing) and it looks fairly circular with the PAR set to 10:11. If I resize without cropping it is definitely squeezed unless I set the PAR to 1:1. But then it is hard to tell for sure (it is a pretty small clock in the video). But then if I crop then reload the video, the clock widens out a little. So it looks like you are right. Need to crop to 704 first.

[SameSelf]

From a clean digital source, I would go 720x540!

Hmmm, didn't think of that. Guess I will give that a try.

[poisondeathray]

The reason NTSC "video" typically isn't vertically resized is because of interlacing. You cannot just resize interlaced video vertically with "normal" resizing because of the fields. So 4:3 would be 640x480 in "square pixels"

You can thank those Newpball's SOE friends for that

[newpball]

The reason NTSC "video" typically isn't vertically resized is because of interlacing. You cannot just resize interlaced video vertically with "normal" resizing because of the fields. So 4:3 would be 640x480 in "square pixels"

You can thank those Newpball's SOE friends for that

Good point, obviously the source should be deinterlaced to 50/60p first!

[SameSelf]

The reason NTSC "video" typically isn't vertically resized is because of interlacing. You cannot just resize interlaced video vertically with "normal" resizing because of the fields. So 4:3 would be 640x480 in "square pixels"

I was actually thinking about that and suspected that would present a problem since this is indeed interlaced. But then I guess I could de-interlace first then resize. Oh, decisions, decisions!

I guess the question now becomes, does QTGMC de-interlace better on square or non-square pixels?

[hello_hello]

I guess the question now becomes, does QTGMC de-interlace better on square or non-square pixels?

The shape of the pixels doesn't matter, QTGMC will de-interlace fine, although I can't say I've ever tried resizing the width for square pixel dimensions before de-interlacing. I've read recommendations along those lines for speeding up the de-interlacing of HD video a bit. ie resize 1080i to 1280x1080, de-interlace, then resize to 1280x720. I haven't tried it myself.
Usually it's done the other way around as if you de-interlace first you're free to resize however you like afterwards. I'll have to compare the two one day, although I suspect de-interlacing first would tend to look better if for no other reason than you're not going to need to resize twice.

Don't take recommended resizing as gospel. Resize using whatever resolution looks fine to you. I'm yet to find a 4:3 NTSC DVD that retains more detail when resized to 720x540 than when resized to 640x480. I'd like to see an example of one.

If you're de-interlacing you can generally resize down a bit after de-interlacing without any loss of picture detail. In fact I often resize 720x576 PAL DVDs to 640x480 and for older video sources the downscaled version still tends to look better than the original to me, thanks to QTGMC. Make some small comparison encodes and use your eyes, or compare different resizing in scripts before committing yourself.

I posted some samples here a while ago, originally to compare Yadif and QTGMC at 25fps and 50fps (PAL de-interlacing). The original video is attached plus the encoded samples. I'm pretty sure the encodes are all resized to 640x480 (not ITU resizing for easier comparison even though I think ITU resizing was correct for those ones).
https://forum.videohelp.com/threads/354092-Converting-video-frame-rates?p=2225116&viewf...=1#post2225116

[_Al_]

what to do with 720x480i:
-QTGMC and resize to square pixel -then upscale vertical resolution (hey do not touch vertical resolution!)
-QTGMC and resize to square pixel -then downscale horizontal resolution (you are down-scaling already SD video, it is not optimal)
-QTGMC only and give that video aspect ratio, SAR in x264 terminology (video is not square pixel, some players might just ignore that aspect ratio for some reason)
-leave it interlace (hey interlace is old school, some players will just not deinterlace in optimal way for whatever reasons)

does not matter what you do, there will be always someone on this forum who would tell you that would not be optimal because of what is in those parentheses or for whatever reason ..., but second choice seems to somehow fit the most ...

[SameSelf]

Here is the code I have come up with. Bear in mind this is 4:3 NTSC 720x480i29.97 video. And it looks pretty good

SetMTMode(5, 9) # MT setting
DirectShowSource("D:\Test.avi").AssumeFPS(30000,1001)
AssumeBFF
ConvertToYV12(interlaced=true, matrix="PC.601") # So QTGMC filters will work
SetMTMode(2) # MT setting
QTGMC( Preset="Slower", FPSDivisor=2, EdiThreads=8 ) # Keep 29.97 fps, 59.94 fps is much larger and of questionable quality
Distributor() # MT setting

LanczosResize(width,540) # Uprez de-interlaced 720x480 10:11 PAR to 720x540 1:1 PAR
nnedi3_rpow2(2) # Uprez to 1440x1080
HSN=12 # Crop head switching noise between 10 to 16 pixels
Crop(0,0,0,-HSN)
Pillar=240
AddBorders(Pillar, 0, Pillar, HSN, $000000) # Conform to 1920x1080

[SameSelf]

I think with this I am ready to say good bye to DVDs forever and put everything on BD. I think this is best given that everything from TVs to PCs to Youtube is native progressive with square pixels.

[SameSelf]

Here is the code I have come up with. Bear in mind this is 4:3 NTSC 720x480i29.97 video. And it looks pretty good

SetMTMode(5, 9) # MT setting
DirectShowSource("D:\Test.avi").AssumeFPS(30000,1001)
AssumeBFF
ConvertToYV12(interlaced=true, matrix="PC.601") # So QTGMC filters will work
SetMTMode(2) # MT setting
QTGMC( Preset="Slower", FPSDivisor=2, EdiThreads=8 ) # Keep 29.97 fps, 59.94 fps is much larger and of questionable quality
Distributor() # MT setting

LanczosResize(width,540) # Uprez de-interlaced 720x480 10:11 PAR to 720x540 1:1 PAR
nnedi3_rpow2(2) # Uprez to 1440x1080
HSN=12 # Crop head switching noise between 10 to 16 pixels
Crop(0,0,0,-HSN)
Pillar=240
AddBorders(Pillar, 0, Pillar, HSN, $000000) # Conform to 1920x1080

Does anyone have any advice on how to improve upon my code above? Thanks.

[_Al_]

-getting rid of half of frames is very invasive - do not upscale, then keeping it 60p will not be that large at all
-Upscale to HD makes no sense, except if encoding to lossless to mix the footage with some HD footage
- resizing video two times gives you better result as oppose to do it once right away (well two times anyway but differently)?
nnedi3_rpow2(4, cshift="Spline36Resize", fwidth=1440, fheight=1080) , is it 4 times too much?
purpose of using nnedi3_rpow2 is to just downscale to "weird" size from higher resolution, to avoid upscaling to "weird" size

[usually_quiet]

I think with this I am ready to say good bye to DVDs forever and put everything on BD. I think this is best given that everything from TVs to PCs to Youtube is native progressive with square pixels.

You can do whatever you like if you are putting media files on BD as data, but Blu-Ray doesn't allow progressive square pixels at SD resolutions, and it doesn't allow 59.94fps 1080p video either. As already mentioned, throwing away half the frames to get 1080p 29.97 fps is undesirable, so 720p is a better choice if you must upscale for Blu-Ray.

[newpball]

I think with this I am ready to say good bye to DVDs forever and put everything on BD.

Good move, but an even better one would be to put the videos on a UDF formatted BD.

[hello_hello]

Good move, but an even better one would be to put the videos on a UDF formatted BD.

As opposed to??

[newpball]

Good move, but an even better one would be to put the videos on a UDF formatted BD.

As opposed to??

Nothing!

Just UDF format your BD and now you can simply copy video files (or any other files) in any format onto that disc.

Nobody forces anyone, likely to their chagrin, to use a BD as prescribed by the media industry syndicate.

Of course the usual suspects will likely call blasphemy when someone suggests you can actually put videos on a BD simply by using the UDF format.

[hello_hello]

Nothing!

Just UDF format your BD and now you can simply copy video files (or any other files) in any format onto that disc.

Nobody forces anyone, likely to their chagrin, to use a BD as prescribed by the media industry syndicate.

Of course the usual suspects will likely call blasphemy when someone suggests you can actually put videos on a BD simply by using the UDF format.

I think you'll find the usual suspects are amused that once again you're referring to imaginary posters.

So were you referring to burning video files to disc as data files just as you'd burn any other type of file to disc, as opposed to creating a complaint Bluray video disc, but confusing the issue in the process because either way the disc will be UDF formatted?
https://en.wikipedia.org/wiki/Blu-ray#Data_format_standards

[SameSelf]

-getting rid of half of frames is very invasive - do not upscale, then keeping it 60p will not be that large at all

As already mentioned, throwing away half the frames to get 1080p 29.97 fps is undesirable

Oh wow, I didn't realize that QTGMC preserves the temporal detail in 59.94i. After looking carefully in Vdub at the difference between FPSDivisor=1 and 2, I can now see the difference. Thanks for clearing this up for me! I definitely want to keep that temporal resolution.

- resizing video two times gives you better result as oppose to do it once right away (well two times anyway but differently)?
nnedi3_rpow2(4, cshift="Spline36Resize", fwidth=1440, fheight=1080) , is it 4 times too much?
purpose of using nnedi3_rpow2 is to just downscale to "weird" size from higher resolution, to avoid upscaling to "weird" size

I am not sure I completely follow. Are you saying that a better code would be below? And if yes, why is that better? Thank you.

DirectShowSource("D:\Test.avi").AssumeFPS(30000,1001)
AssumeBFF
ConvertToYV12(interlaced=true, matrix="PC.601")
QTGMC( Preset="Slower", FPSDivisor=1, EdiThreads=8 )

nnedi3_rpow2(4, cshift="Spline36Resize", fwidth=1440, fheight=1080) 
HSN=12 # Crop head switching noise between 10 to 16 pixels
Crop(0,0,0,-HSN)
Pillar=240
AddBorders(Pillar, 0, Pillar, HSN, $000000) # Conform to 1920x1080

[_Al_]

Are you saying that a better code would be below? And if yes, why is that better? Thank you.

I asked you if it was better .
The whole point of using nnedi3_rpow2 is to upscale at even rate (2x, 4x) and then downscale to desired resolution. You just upscaled 720x480 to 720x540, and then used nnedi3_rpow2 to upscale 2x. So if artifacts are introduced during first resize, you only multiply it resizing later.

But that one line nnedi3_rpow2 resize, resamples 720x480 to 2880x1920 first and then it downscales it down to 1440x1080, perhaps it takes a bit longer but it is done the way it suppose to be.

[SameSelf]

Thanks, sounds like I need to do some more tests to see for myself. I will try to post back here later with what I find. It will be interesting to see if I can see any difference. Both require two steps of resizing if I understand correctly. My method involves an upsize then a doubling. Your suggestion is a quadrupling then a downsize. Both require resampling the pixels to convert from the 10:11 PAR to 1:1 PAR, correct?

Has anyone else done tests to determine which method is best? Thanks.

[SameSelf]

nnedi3_rpow2(4, cshift="Spline36Resize", fwidth=1440, fheight=1080)

So much for using that, it crashes ffmpeg and vdub.

[_Al_]

It is working here, and I tried Virtual Dub as well.
using DVavi, 720x480

avisource("ntsc_dv.avi")
assumebff()
QTGMC(Preset="slow")
nnedi3_rpow2(4, cshift="Spline36Resize", fwidth=1440, fheight=1080) 
ColorYUV(gain_y=-20)
ColorMatrix(mode="Rec.601->Rec.709")

but anyway, I think upscaling and storing it is a big waste of time and resources and even letterboxing it to 16:9 at the same time. It makes no sense. What if someone would watch it on something else than 16:9?

[SameSelf]

Well, I figured out my problem was I had the QTGMC Preset = "very slow". After backing it off to "slow" it finally worked. I looked at two screen shots and honestly couldn't tell the difference. I will let you try to guess which one is which . But I am not too happy with having to scale back the preset to "slow". So I would have to go with my original method.

Anyway, after fully processing through my workflow: AE -> PP -> Encore, I discovered that Encore chokes on 1920x1080p60. Well, maybe chokes is the wrong word. But after watching it struggle on my 15 sec test clip, I shuddered to think how it would struggle with an hour long clip. So I have scaled back to 1280x720p60 using the following which preserves the 4:3 DAR at 1:1 PAR. And Encore behaves smooth as butter now.

nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=960, fheight=720)
HSN=10
Crop(0,0,0,-HSN)
Pillar=160
AddBorders(Pillar, 0, Pillar, HSN, $000000)

[_Al_]

Anyway, after fully processing through my workflow: AE -> PP -> Encore, I discovered that Encore chokes on 1920x1080p60.

ut video ?
Or some other lossless?
MP4 with H.264? What encoding settings then.

I could not tell which belongs to what, those samples. Maybe straight lines at the shallow angle would reveal a difference if there is any difference at all.

[newpball]

Anyway, after fully processing through my workflow: AE -> PP -> Encore, I discovered that Encore chokes on 1920x1080p60.

Encore?
For 1080p60 what do you need Encore for?

[_Al_]

I missed that, yes, why Encore?

[jagabo]

I looked at two screen shots and honestly couldn't tell the difference.

Try with this video.