Proper way to crop and resize this vid to 4:3?

[mt123]

The following pics come from an HD capture I made which using what I assume is unconverted material where the video size 1280x720 with black bars on the right and left sides. What I would like to do it crop and resize this and encode it to something smaller with xvid, probably something like 640x___ (or whatever else might be ideal) similar to a "scene" release. The problem is that if I try to make it straight 4:3 by cropping it to 960x720 and resizing it I'm still left with black bars on each side as seen in the second image. If I crop all of that out I'm left an image size of 942x690 which is not exactly a 4:3 ratio. I understand that 4:3 television is broadcast in 720x480, or least it used to be but I'm probably getting this wrong so I'm wondering how that might also factor into things.

Thanks

Original image (1280x720):


Cropped to 4:3 (960x720):


Cropped to remove remaining black bars (942x690):

[jagabo]

Exactly what you want to do will depend on the capabilities of the player. But assuming you want square pixel encoding for Divx/Xvid or h.264 encoding:

Just resize your last image from 942x690 to 640x480 (or whatever 4:3 frame size you want). Nobody will notice the ~2 percent error.

For more accurate resizing trim a total of 22 more lines from the left and right sides to create a 920x690 frame, then resize to 640x480. Where does 920 come from? 690 * 4 / 3. Or trim less from the top and/or bottom leaving a 942x706 frame (which will leave some black border) and resize to 640x480. 942 * 3 / 4 ~= 706.

[mt123]

Exactly what you want to do will depend on the capabilities of the player. But assuming you want square pixel encoding for Divx/Xvid or h.264 encoding:

Just resize your last image from 942x690 to 640x480 (or whatever 4:3 frame size you want). Nobody will notice the ~2 percent error.

For more accurate resizing trim a total of 22 more lines from the left and right sides to create a 920x690 frame, then resize to 640x480. Where does 920 come from? 690 * 4 / 3. Or trim less from the top and/or bottom leaving a 942x706 frame (which will leave some black border) and resize to 640x480. 942 * 3 / 4 ~= 706.

Thanks for your help.

A few follow-up questions if you don't mind:

Are the pixels not originally square and does that differ is it's a SD or HD broadcast? If I recorded a 720x480 SD broadcast would I need to resize to 640 to obtain a normal look? I guess that also would depend on the monitor whether it's a 4:3 computer monitor or a 16:9 LCD TV which is kind of confusing.

Also, is there any downsides to creating a vid that's, say, 624x448 (multiples of 16) that's closer to the cropped version I posted or would it just get stretched out to 4:3 when in full screen mode and thus make it kind of pointless?

[jagabo]

In general the frame size does not directly determine the final display aspect ratio. The DAR is determined by the frame size and the shape of individual pixels:

DAR = SAR * PAR

DAR = Display Aspect Ratio, the final shape of the displayed picture
SAR = Storage Aspect Ratio, the frame size
PAR = Pixel Aspect Ratio, the shape of individual pixels

So basically, any frame size can encode any display aspect ratio.

Analog broadcast has no pixels so none of this applies.

Digital broadcast supports several different frame sizes, some square pixel, some not. 1920x1080 and 1280x720 HD broadcasts in the USA are square pixel -- giving 16:9 DAR. But 1440x1080 is also valid and uses non square pixels resulting in a 16:9 DAR. A 720x480 4:3 broadcast should be resized to 640x480 (or any 4:3 SAR) if you want to use square pixels. You can also use the original frame size with appropriate PAR flags to maintain 4:3 DAR.

DVD usually uses a 720x480 frame size with non-square pixels to make a 4:3 or 16:9 DAR.

The playback device should take into account the SAR and PAR to produce the correct DAR. Of course, not all do. Some Divx/DVD players will display DAR = SAR. Some older players simply stretched everything to 4:3 DAR.

[mt123]

Thanks again. You've been a big help.

[jagabo]

Here's are some examples:

An NTSC 4:3 DAR DVD contains the 4:3 image in a 704x480 frame with 8 pixels of padding at the left and right sides of the frame.

DAR = SAR * PAR
DAR = 704:480 * 10:11
DAR = (704/480) * (10/11)
DAR = 1.467 * 0.909
DAR = 1.333 = 4:3

An NTSC 16:9 DAR DVD contains the 16:9 image in a 704x480 frame with 8 pixels of padding at the left and right sides of the frame.

DAR = SAR * PAR
DAR = 704:480 * 40:33
DAR = (704/480) * (40/33)
DAR = 1.4667 * 1.2121
DAR = 1.778 = 16:9

[mt123]

Why I got you here I ran into another situation...

I got a DVD file which is 720x480 interlaced at 29.97fps and it's a sports recording. I want to encode it with xvid into an avi file and make the resolution progressive as well. My question is how to exactly resize it and what the framerate should be. I think generally if this were a film I would make it 24fps since that's what film is recorded at but here it seems I could make it either 30fps or 60fps by turning the 60 fields per second into 60 frames per second. Then again I believe each field is 240x720 so it seems like it order to make it 480 there would have to be some added lines of resolution by doubling lines or some other method though I'm not even sure that would work...it racks my brain just thinking about it. The other option would be to make it 30 frames per second by combined the 60 fields into 30 frames but I may have this wrong as well.

Also, as far as resizing...I think the correct way to do it would be to crop 8 pixels from each side and then resize the width to 640. Is this right?

Thanks again

[manono]

I want to encode it with xvid into an avi file and make the resolution progressive as well.

Resolution has nothing to do with progressive/interlaced.

Also, as far as resizing...I think the correct way to do it would be to crop 8 pixels from each side and then resize the width to 640. Is this right?

Yeah, 640x480. Just make sure you deinterlace first, before the resize. A straight deinterlace will give you 29.97fps. A bob deinterlace will give you 59.94fps. If it were I, I'd deinterlace to 29.97fps, but there are plenty of bobbing fans around. You could always experiment and see which you prefer. A bob deinterlace, though, will need a much higher bitrate (=filesize) for the same quality.

You could always run the DVD through AutoGK and let it do the 'thinking' for you.

[mt123]

Do you happen to know if there is a quality difference between regular deinterlace to 29.97 and a bob deinterlace to 59.94? It seems there would be twice as much information for the latter and I'm wondering if there is some sort of sacrifice in doing so. For instance if there is originally 60 fields per second/30 frames per second with it being interlaced would it combine those 60 fields to create 30 progressive frames? Would the bob method take the 60 fields and somehow turn them into 60 progressive frames by manipulating them in order to achieve 480 lines of vertical resolution since I believe each field would originally be 240x720?

Also, are you familiar with autogk because I actually have the latest version but I've never been able to figure out how to do what your suggesting because there doesn't seem to be a DVD input option as shown below.

Version 2.55 (my screenshot):


Version 2.01 (from videohelp):



Maybe I just need to download an older version but I find it hard to believe that they would remove such an option

Thanks

[T-Fish]

load the .ifo file (of the movie, not the menu).
its pretty straight forward.

[manono]

Do you happen to know if there is a quality difference between regular deinterlace to 29.97 and a bob deinterlace to 59.94? It seems there would be twice as much information for the latter and I'm wondering if there is some sort of sacrifice in doing so.

A bob deinterlace, though, will need a much higher bitrate (=filesize) for the same quality.

Did you not see what I wrote, or not understand it?

Would the bob method take the 60 fields and somehow turn them into 60 progressive frames by manipulating them in order to achieve 480 lines of vertical resolution since I believe each field would originally be 240x720?

That's what bobbing does - converts each field into a frame, doubling the framerate. There are a number of way to achieve this. In general, the better the bobber the slower the encoding. AviSynth is, of course, the preferred way to bob as there are bobbers of all kinds of quality (and speed), including the very best available anywhere.

Also, are you familiar with autogk because I actually have the latest version but I've never been able to figure out how to do what your suggesting because there doesn't seem to be a DVD input option as shown below.

Yes, I'm very familiar with it. Decrypt just the video (DVDDecrypter in IFO Mode), load either the IFO or the first VOB file. If there's more than one VOB the rest get loaded automatically. It won't give you a bobbed video back, though, but a 29.97fps deinterlaced AVI.





I'm using the latest version 2.55.

[jagabo]

Xvid supports interlaced encoding. Unfortunately, many players won't handle it properly. If you want the smoothest motion bob (smart bob) to 60 fps. But again, some players will not be able to handle 60 fps. 30 fps is safest but will give noticeably less smooth motion.

Try VirtualDub's Deinterlace in Yadif, double frame rate (bob) mode. It does an ok job. Certainly better than a simple bob. If you want to get more adventurous try AviSynth's TempGaussMC_beta1().

[mt123]

Did you not see what I wrote, or not understand it?

Yes, I saw what you wrote but I guess I don't fully understand. What I'm wondering is if it's just a regular deinterlace that transforms the 60 fields per second into 30 frames per second it seems it would create 480 unique lines of resolution with each frame by combining fields compared to the bob method which takes 240 unique lines of resolution from each field and transforms them into 480 lines of resolution and therefore it seems that it would not be the same quality since there would be less fine detail. Do you understand what I'm trying to say?

Yes, I'm very familiar with it. Decrypt just the video (DVDDecrypter in IFO Mode), load either the IFO or the first VOB file. If there's more than one VOB the rest get loaded automatically. It won't give you a bobbed video back, though, but a 29.97fps deinterlaced AVI.

Ah, I knew I had to be doing something wrong. I had actually downloaded the files already which were meant to be burn-ready so I guess I didn't need to do the first part. It's a pretty nifty program - the results were pretty good and it seemed to automatically crop and resize to 640x480 (though I set it to 640).

I got another question I hope you or anyone else might be able to help me with. I capture HD content, mainly sports, and I often don't need the entire recording. Instead I like to make a cut at the beginning and end of the broadcast (when there no commercials are of course). I know I could obviously cut the file using an external h.264 cutter and import that into the program but most of them aren't very accurate or give pixelated cuts which I assume is from cutting on the b and p frames even when told not to. With virtualdub I can import to the original ts/h.264 file and create a mark-in and mark-out and that works great, very accurate, but this method is a little bit of a pain because it doesn't deal with VBR audio very well so I have to create a wav file and then turn that it's a VBR mp3 file using another program and then mux it in manually at the end. I also have to use an Xvid calculator to figure out what bitrate to use in order to create a 700mb file and so on. With autogk it's a breeze but of course it's designed to be a simple program and I get that it's probably let me do that so I guess I'm wondering if this is something the full version could do or if there is another all-in-one type of program that could achieve this as well.

[mt123]

Xvid supports interlaced encoding. Unfortunately, many players won't handle it properly. If you want the smoothest motion bob (smart bob) to 60 fps. But again, some players will not be able to handle 60 fps. 30 fps is safest but will give noticeably less smooth motion.

Try VirtualDub's Deinterlace in Yadif, double frame rate (bob) mode. It does an ok job. Certainly better than a simple bob. If you want to get more adventurous try AviSynth's TempGaussMC_beta1().

Yea, for the smaller xvid files that I share I generally like to keep them at 30fps to assure maximum playability when sharing but I might give what your suggesting a try for files that I create for personal use because my computer handle most 720p/60fps files without a problem.

[manono]

Do you understand what I'm trying to say?

Yes. The main drawback to 29.97fps deinterlacing is loss of fluidity when compared to the original interlaced 29.97fps or a bobbed 59.94fps video. Instead of 60 discrete slices of time, so-to-speak, you have only 30. This creates a slight jerkiness of movement which bothers some (not me, though). As for detail, a good bobber can pretty much negate the loss of detail because it can use information from the other field when creating a new frame whenever those portions of the 2 fields are static. And since the eye doesn't notice loss of detail as much when there's motion, that detail loss is pretty much neutralized. However, even 30fps deinterlacers have that loss of detail because they (the good ones anyway) are creating a progressive frame using one of the fields as the 'base' from which to build it. Deinterlacing either way isn't optimum, and it's better to keep it interlaced when possible, although it isn't always possible.

With autogk it's a breeze but of course it's designed to be a simple program and I get that it's probably let me do that so I guess I'm wondering if this is something the full version could do or if there is another all-in-one type of program that could achieve this as well.

AutoGK doesn't support H.264 video. Maybe the TS file contains some sort of MPEG video, in which case AutoGK can handle it. Anyway, it's not an editor and any cuts have to be performed before sending the video to AutoGK. Even its big brother, Gordian Knot, isn't designed as an editor, although the AviSynth scripts it creates can be tweaked to do what you want. Unless you're pretty experienced with AviSynth, though, you'd best do any editing you want before sending it even to GKnot.