Aspect ratio: how does it affect me?

[pyro]

I'm capturing analog PAL video from my ATI All-in-Wonder's TV tuner at 640x480. From the bits and pieces I've read on the net about processing video, I've formed the impression that I should be careful to maintain the 4:3 aspect ratio when cropping the sides in, say, VirtualDub.

However, many programs are now being broadcast in a slightly letterboxed form that does not match the standard 4:3 or 16:9 aspect ratios. This means if I'm to maintain the aspect ratio of the source video, I have to leave in the black bars on the top and bottom. Because the source is slightly noisy analog, they're not perfectly black, and this results in less efficient encoding and annoying artefacts in the black bars.

Now, if I completely ignore the aspect ratio, cropping the black bars as I wish, it still looks fine when played (windowed or fullscreen) on my PC. The players automatically stick perfectly black, artefact-free bars where they should be.

My question is, in what situations would this freely-cropped video cause problems with regards to aspect ratio?

[Darksoul71]

Hi pyro !

1st of all you should stop capturing 640x480 if you capture PAL material. PAL has a full height of 576 lines. So any capture res with a height below this value simply drops some lines.

On the AR thing: You shouldn´t worry too much about the 4:3 thing. Things are quite complicate with AR. Esp. with the original AR of your captured material and the AR of the material you want to encode to.

I dunno if AVI is your target format but I think so. Here is how I do it:
Capturing in 720x576 in MJPEG. Then cropping away "damaged" lines and/or black bars. After this I enter the remaining resolution (for example 696x560) into Gordian Knot and choose PAL 4:3 ratio. For my target res I choose a width of 640 and enable smart cropping.

GKnot now shows that my target height is 464 and that I have to crop away another 4 and 5 pixel top and down.

Final result: an AVI file at a target res of 640x464 pixels.

To answer your question shortly:
Yes a freely cropped video (witout resize) will ALWAYS have the wrong AR during playback. You just will not notice a small AR error of something like 1-2%.

-D$

[pyro]

Hi Darksoul,

The reason I don't capture in 720x576 is because it displays the wrong aspect ratio (picture stretched vertically a bit), while a 640x480 capture looks roughly correct when comparing to the same image on my TV. My impression is that 720x576 > 640x480 bicubic/bilinear resizing causes enough softening that it doesn't end up looking much better than capturing at 640x480 in the first place and not having to resize. BTW, you were correct in assuming my target is AVI -- I capture MJPEG Q19 in ShowShifter, then process it in VirtualDub with the end result being a DivX video for playback on my PC.

With regards to aspect ratios, let me use an analogy to demonstrate what I have trouble understanding. Let's say I have a bitmap image of your head, and I decide to crop the bottom to cut your neck and shoulders out. I've gotten rid of the bits I don't want, but the rest of you looks the same. I can expect the shape of the rest of your head to be displayed pretty much correctly.

Now I do the same thing with one of my 640x480 captures, chopping off the black bars. What's the difference?

[Didée]

A few comments of mine:

The reason that capturing 640x480 shows right AR, wheras full PAL 720x576 seems vertically stretched, has the following reasons:

- PAL AR isn´t 4:3, if we assume square pixels. PAL has *not* square pixels, they´re horizontally stretched. (Obviously 720x576 is not 4:3, but it shows right on your 4:3 TV screen!)

- so a full PAL capture looks squeezed on a PC monitor, but correct when send again to the TV.

- Are you using M$MediaCrumbler, ah, player? Don´t do so, *please*. Using ZoomPlayer, and after having discoverd its features of AR correction, you´ll be a much happier man ... M$MediaCrumbler can´t deal with AR at all. As soon as you play back NTSC source, you are lost with it. M$MediaCrumpler knows nothing other than sqare pixels!. In fact, it doesn´t know much at all ... ;)


About capturing 640x480 directly:

This is not really a good idea ... I tried this with my ATI AIW 8500DV. It´s a no-go for me. Capturing 640x480, no vertical resizing is done. Simply dropping some lines, thats all! This results in jagged diagonal lines, flickering, and that stuff.
In the rare cases I don´t capture 720x576 (e.g. I must use a smaller bitrate, caused by lack of disk space due to too much capturing and ripping [I only have 200 GB, buhuu]), I will capture mostly to 720x288 (!), and resize it afterwards. IMHO this gives me still better results than capturing 480 vertical. It´s right that with only 288 more information (a complete field) is lost than with 480. But the loss is *evenly distributet*, whereas the loss with 480 is *unevenly distributet*. Plus, when resizing 720x288 bicubic to e.g. 576x432, some of the horizontal overhead is computed back into the vertical lack. Again, this is only my way for low-diskspace-scenarios with long-time encodings.


All of the above could be discussed, of course. I´m not the guru, [yet].

[outlyer]

I'm not really a master but I'm pretty sure of most of the things I have to say :p

Originally posted by pyro

I'm capturing analog PAL video from my ATI All-in-Wonder's TV tuner at 640x480. From the bits and pieces I've read on the net about processing video, I've formed the impression that I should be careful to maintain the 4:3 aspect ratio when cropping the sides in, say, VirtualDub.


As has been pointed you should really, really use 576 vertical resolution. If you get blurry/soften images on resizing maybe you're not using correct values. Using virtualdub, bilinear makes a softer image, while bicubic depends on the "A" value. If you use Precise Bicubic with A=-0.60 you should get a perfect image. At least it works for me.

The 4:3 aspect is not SO important, if the source doesn't have it, forget it. I'll explain this a little more later.


However, many programs are now being broadcast in a slightly letterboxed form that does not match the standard 4:3 or 16:9 aspect ratios. This means if I'm to maintain the aspect ratio of the source video, I have to leave in the black bars on the top and bottom. Because the source is slightly noisy analog, they're not perfectly black, and this results in less efficient encoding and annoying artefacts in the black bars.


Those programs use a correct aspect ratio, maybe 2.35:1, maybe 1.85:1, there are a lot of used ARs but they have to accomodate to standard broadcasting (4:3), that's the source of the black bars.

I suggest you taht IF you want to mantains the black bars, first crop them off and then re-add them (using virtualdub just crop and then resize with the cropped dimensions and a black frame with the original dimensions). What you get is the original without any noise on the black bars.



Now, if I completely ignore the aspect ratio, cropping the black bars as I wish, it still looks fine when played (windowed or fullscreen) on my PC. The players automatically stick perfectly black, artefact-free bars where they should be.

My question is, in what situations would this freely-cropped video cause problems with regards to aspect ratio?

If you only plan on playing the content only on the computer, in avi format, forget the black bars, just crop them off. Just remember to use dimensions which are multiple of 16 (if the cropped video isn't, add tiny black bars, don't resize it).

Black bars are only needed when your target needs a fixed resolution, like VCD, SVCD or DVD, and your video is not 4:3. As you're targeting avi, just keep in mind what I pointed above.

If you finally shift to capture at 576 vertical res., as you said image will be squeezed, simply resize it to so that the new image is 4:3 and the crop the black bars.

A side note: using a player which lets you set the AR while playing is an alternative as Didée said but IMHO giving the video the correct dimensions is a better solution.

[pyro]

Thanks for the input.

Didee, I actually use Zoom Player (although these days I'm leaning more toward DivX Player since Zoom gets a bit overwhelming with all its options).

outlyer, many programs here (in Australia) are starting to get small black bars as part of the transition to digital / widescreen TV. They are not 2.35 or 1.85 -- if they were, the networks would be bombarded with complaints. They are small bars to help introduce people gradually to the idea of letterboxing.

I'd thought about filling in the black bars so that they were perfect black, but couldn't figure out how to do it. The "fill" filter in VirtualDub is one thing I looked at, but the way that one works it's difficult if not impossible to fill the sides.

In any case, you've both convinced me to play around a bit more with 720x576 captures. Here is the idea I have for processing:

1) Load the capture in VirtualDub through avisynth (so that it's separated into 50 720x288 fields), adding the "deinterlace - smooth" filter. This is the the progressive scan + weave method for deinterlacing described at www.100fps.com, and is the only method that I've been satisfied with. The filter spits out a 50fps 720x576 video.

2) Add the resize filter, precise bicubic with A=-0.60, to resize to 720x540 or 640x480.

3) Add the null transform to crop the black bars and any noise from the image.

4) Now to add a perfect black border to correct the aspect ratio and make a resolution divisible by 16 (I'm not convinced the latter is necessary though -- the DivX FAQ says 4 is okay, although less efficient). What filter do I use for this?

[Darksoul71]

Hi pyro !

I´m a bit short in time:
4) Now to add a perfect black border to correct the aspect ratio and make a resolution divisible by 16 (I'm not convinced the latter is necessary though -- the DivX FAQ says 4 is okay, although less efficient). What filter do I use for this?
The DivX FAQ is mostly crap. Even they don´t know how to resize correctly :)

You don´t need black bars to correct AR. Try the things I told you.
1) Cropping away black bars with null transform.
2) Enter resulting res to GKnot
3) Let GKnot calc the additional cropping and resize parameters
4) Add another few pixels crop and resize
5) Finished :)

PAL has a pixel aspect ratio around 1.093. So in square pixels a 720x576 PAL frame is about 780 pixels wide. This is what you have to correct by cropping and resizing.

I strongly suggest you have a look at my "GKnot with AVI files" guide over at the GKnot FAQ page: http://gknot.doom9.org/avi.html

BTW: The filter for making black bars is called letterbox. First crop away 16 lines top and down and then add 16 lines top and down to get perfect black borders. Works in AVISynth also with the letterbox command.

-D$

[outlyer]

Originally posted by pyro

outlyer, many programs here (in Australia) are starting to get small black bars as part of the transition to digital / widescreen TV. They are not 2.35 or 1.85 -- if they were, the networks would be bombarded with complaints. They are small bars to help introduce people gradually to the idea of letterboxing.


Well, I thought that it was like here, in Spain, where black lines are really thick to get the 16:9, 1.85, 2.35 and so on. Anyway, those lines aren't needed so... ;)


Thanks for the input.
4) Now to add a perfect black border to correct the aspect ratio and make a resolution divisible by 16 (I'm not convinced the latter is necessary though -- the DivX FAQ says 4 is okay, although less efficient). What filter do I use for this?

DivX is SUPPOSED to work with resolutions divisible by 4, BUT it could (or maybe it WILL) give you troubles with some video-cards, it also, as you said, is less efficient, this means that you'll probably get more quality with the same bitrate and the extra black bars to get de 16x size.
Believe me, use 16x. By the way, some time ago a saw a post saying that 32x compressed better with XviD, don't know if it's still/always true or if it's also true for DivX.

To get clean black lines you can use the same filter that for resizing in VirtualDub. Just add resize, enter the new size (if you're not really resizing, enter the original size and then you can keep nearest neighbour, if you're really resizing enter the new size without black bars and select precise bicubic). Below this, if you check "expand frame and letterbox image" you can enter the size with the bars. VirtualDub will center the image automatically so, simply put the new size and you get your black bars.

You also can, as suggested by Darksoul71, use GordianKnot to get rid of any black bars and get a correct aspect ratio, just keep in mind that you'll be cropping part of the actual image so take a look at what and how much you're losing. I'm a freak and so I prefer to add black lines than to crop part of the image.

[pyro]

Hi guys,

First, I should say that I want to get all my processing done in a single processing session in VirtualDub. For me, this takes enough time as it is and any more steps (unless they produce something spectacular) fail the cost/benefit test. So GKnot is out, though I appreciate the method works well for Darksoul. Secondly, I identify with outlyer being a "freak" about not wanting to lose part of the actual image, and would rather add clean black borders than crop it.

Now a significant usability problem which will be decisive in how I decide to process the video. When I go to crop the image with the null transform, the preview window doesn't seem to take into account any previous filters unless one of them is an actual resize both horizontally and vertically. So if I don't do a vertical and horizontal resize before the null transform, I can't crop correctly. This is a problem I've ran into previously with VirtualDub. Am I missing some setting here?

[outlyer]

If I've understood you well, for me it works the other way, I mean, null transform doesn't take into account in the preview the resize. Anyway I'll explain how I do it and I think it should be done.

You'd better add the null transform filter before, because filters are applied in the list order, next filters won't have to "fight" with the black bars' noise neither the extra black bars. (I suppose you're keeping the black bars to the minimum).

Once null transform is set, add the resize filter and then any other filters you're using and all should work perfectly.

If I misunderstood the problem, please explain it a bit more.

[Darksoul71]

Hi folks,

Where to start ? Hm, ok, the first one goes out to pyro:
Even if you consider yourself a "freak" and don´t want to loose any part of your image let me say that those cropping values are often enough below 4 pixels for each side for PAL which means cropping away below 0.6% of the actual image for each side. Is this actualy "loosing" a part of your image ? Keep in mind that you loose about 10% of the actual transmitted image by the overscan of your TV while watching TV. So anything below 2% is not a big trade off for the correct AR of your final AVI but this is up to you.

Personaly I wouldn´t do the "fill up" with black bars unless you do it the "correct" way: Letterboxing should be done macroblock optimized to garantee good compression. So your letterboxed area should be divideable by 16 in height. Everthing else will be less compressable. It should be at least divideable by 8. This has to do with way an encoder actually handles the compression of the video. Every encoder (be it MPEG4/DivX or MPEG2) seperates the full image into small tiles called macroblocks. Those are mostly 8 by 8 pixels but sometimes also 16x16 pixels. So a black bar should fill up this macroblocks fully because a macroblock with a few pixels black and a few pixels actual movie is pretty hard to encode.

On your question related to VDub and nulltransform: You CAN crop correctly before resize. It´s just that VDub can´t deal with cropped material directly in the filter preview. That´s why you should only have a look at the "output" window of VDub where the filterd movie appears correctly.

My last one goes out to Didée:
I will capture mostly to 720x288 (!), and resize it afterwards. IMHO this gives me still better results than capturing 480 vertical. It´s right that with only 288 more information (a complete field) is lost than with 480. But the loss is *evenly distributet*, whereas the loss with 480 is *unevenly distributet*

Let me tell you one thing as a "near pro": Capturing less then both fields is a NoNo. For PAL as well as for NTSC.

You get seriously into troubles by just capturing one field instead of both fields. If you´re seriousy limited in Diskspace you should either use a higher compression (lower MJPEG quality) or capture Half D1 (NTSC: 352x480 / PAL: 352x576). This enables you to get both fields.

Why ? I´ll try to explain in my crappy english:
TV (or better the way TV is stored) consists of two half frames. For PAL this a 50 FPS and for NTSC this are around 60 FPS. If you capture at something like 720x288 or 352x288 (for NTSC this would be 720x240 or 352x240) your capture card just throws away one frame. Basicly this is no problem but for horizontal camera movements this often lead to a steady stuttering movie. You can often see this with VCDs. The fact behind this is quite simple. A TV set shows one frame. The tube is glowing long enough to still show this first frame while the second halfframe is drawn. So for a TV set we always get a "deinterlaced" frame for free. On a PC we have to use smart filters to combine those two half frames to one full frames.

Just think of a man running cross a wide field. The first half frame shows the man in the middle of the screen. In the next half frame he has moved a bit forward. And so on. If you throw away every second half frame (what you do when capturing only half height) there will be frames missing and the man will "hop" from one position to another instead of running fluently.

I hope you have understood what I was talking about. You´ll find this better explained at http://www.100fps.com.

For the most time video capturing and encoding is pretty hard stuff. It´s not about just capture and encode but learning all the time.

BTW: I forgot to mention that the most TV Outs have problems in keeping the right AR. So a circle on your monitor will mostly NOT being a circle when displayed via TV Out to your TV and a few percent of AR will NOT be noticeable when played back via TV Out.

-D$

[Didée]

Darksoul71,

glad to see you giving another good and quite comprehensive explanation. Though, the problematic was clear to me, and I´ve read the 100fps site a few weeks ago ...

... BUT ...

As long as we´re capturing interlaced material, and do a pretty good, but conservative de-interlacing afterwards, we´ll anyway get the stuttering you mentioned. Just because the field-related temporal information, that makes the original TV motion scenes look smooth, is thrown away by deinterlacing, when the goal is 25/29.97 fps progressive. This is valid except for the following two cases:
- we deinterlace by simple field blending. Which, in the end, also doesn´t exactly spell h-i-g-h--q-u-a-l-i-t-y ...
- we deinterlace by converting to 50fps/60fps, but that´s quite another story.

So far. In case I told some nonsense, please feel free to correct me.

[edit: completed a half sentence ...]

[Darksoul71]

@Didée:

No, you don´t talk nonsense. I just want to add a few remarks.

Deninterlacing by field blending is defenitely NOT the way to go. It may help in some cases but most of the time you´ll get heavy ghosting in every faster moving scene.

Deinterlacing as discribed at 100fps.com by converting to a 50fps/60fps movie is really another story and very special.

But I have to disagree to you that we get the same stuttering when we deinterlace. If you use an area based deinterlacer with the right settings only the areas with interlace artefacts are interpolated or blended by the filter. I´ve tried a lot of deinterlacers and are very pleased with the combination discribed in "Hawks HiQuality Capture Guide". PAL Deinterlaced followed by the "rather smart deinterlacer". With some tweaking (and may be the use of the Smart Smoother to smooth out some remaining interlacing artefacts) I get pretty sharp movies without stuttering. At least I do not notice any stuttering during horizontal camera movements.

But I have to agree: In general we get a degration when using any sort of deinterlace filter but for now only XVid can handle interlaced video. :(

-D$

[Didée]

One thing I forgot to mention:

It´s very seldom that I get the chance to de-interlace something ...

Somehow, the capture drivers of my ATI AIW 8500DV do automatic deinterlacing of anything that´s coming in. ATI is speaking of (great, phantastic, unbeatable ... LOL!) real-time smart-deinterlacing, or something similar. Perhaps it could be even better if I would find a way to turn this off (I definetly can, indeed, when I capture to mpeg-2. But mostly I use Huffvuy) and would do it manually. But to be honest: I don´t complain about this automatic stuff. It comes out pretty good, and so I leave it on even when I happen to use mpeg-2. Plus, one thing less to hassle with ... my free time is little enough.

And since I live in PAL country (Germany), even the DVDs I backup don´t need deinterlacing.

So you see my experience is little. I only wanted to mention my point of view, out of my (theoretical) technical understanding.
And I´m always willing to learn ...

But, about stuttering or not:
Isn´t it so that deinterlacing artefacts will only appear in the movinging areas? I do think so!
Exactly those artefacts are the deltas of the fields, making smooth motion when displayed field-wise, but don´t fit when combed into a progressive scan.
Or, in other words: the motion of every 2nd field simply can´t be re-produced by progressives, since we only have 25 of them, instead of 50 (30/60 respectively). That´s why in my opinion deinterlaced material will never be as smooth as the field-coded source.

Sorry again ... If I´m getting annoying, I will sh*t up ... ;)

[Wilbert]

@Darksoul71

I´ve tried a lot of deinterlacers and are very pleased with the combination discribed in "Hawks HiQuality Capture Guide". PAL Deinterlaced followed by the "rather smart deinterlacer".

Can you give me an url of this guide? Or tell me what settings of smart deinterlace you use here.

@Didee

And since I live in PAL country (Germany), even the DVDs I backup don´t need deinterlacing.

Don't be glad that you live in a PAL country (just like I do), although the above is certainly true. The problem starts if you want to deinterlace analog material. Since this mainly is obtained by NTSC2PAL conversions by your broadcasting station, there will be two possibilities:
[list=1]
What Darksoul71 said: solved by the use of the filter PAL deinterlaced. (you could also use smartdeinterlace for this)
They f***ed up the conversion with the consequence there is no proper way to deinterlace the _whole_ video and you will see some ghosting even if you don't blend.
[/list=1]

[outlyer]

Originally posted by Darksoul71
your letterboxed area should be divideable by 16 in height. Everthing else will be less compressable. It should be at least divideable by 8. This has to do with way an encoder actually handles the compression of the video. Every encoder (be it MPEG4/DivX or MPEG2) seperates the full image into small tiles called macroblocks. Those are mostly 8 by 8 pixels but sometimes also 16x16 pixels. So a black bar should fill up this macroblocks fully because a macroblock with a few pixels black and a few pixels actual movie is pretty hard to encode.


The problem here is that this can only be achieved when the cropped image is also macroblock-friendly. If it isn't, to mantain a "legal" resolution and still use black bars, you'll have to fill the gap with black bars.

I know that cropping instead of adding black bars doesn't makes a big loss, I do it sometimes but also, sometimes, I don't like the cropping values. That's my point of view and of course it could be wrong.

Originally posted by Darksoul71
On your question related to VDub and nulltransform: You CAN crop correctly before resize. It´s just that VDub can´t deal with cropped material directly in the filter preview. That´s why you should only have a look at the "output" window of VDub where the filterd movie appears correctly.


Uoops! I forgot to mention this :rolleyes: Excuse me if it seemed that I was saying that it doesn't work.

[Darksoul71]

@Didée:
No, you aren´t getting annoying. I´ll tell you when you do ;)

I don´t know about the ATI realtime deinterlacer but if it works for you: Fine. :)

On deinterlacing:
Yes, compression artefacts are the "delta" between field one and field two (field 3 and field 4, etc).
To get rid of them without loosing too much sharpness (read: blending) you can calculate the "middle" value of this delta. That is what interpolation does. The final result will be somewhat less sharp then the original interlaced source but much sharper when compared to blended material.

Of course the motion of 50 FPS can´t be produced by 25 FPS but I´ve never seen any "stuttering" as in VCDs when playing back DVDs on my TV. Look at cinema: For me even 24 FPS can be enough for fluent playback.

@Wilbert:
1st I use the PAL Deinterlacer from Gunnar Thalin with no option enabled.
2nd I use the area based deinterlacer (also from Gunnar Thalin) with the following settings:
Both checkboxes disabled
Threshold: 15
Edge detect: 15

Quality varies from movie to movie. Sometimes I play around with edge detect or use blend instead of interpolate. But in very hard cases I put a slight smart smoother in row to smooth out remaining interlacing artefacts. In general there is no outline or guide for "good" deinterlacing. You have to play around with all available filters and in some very hard cases I even used AVISynth´s VerticalReduceBy2 to just plainly throw away one field. :)

They f***ed up the conversion with the consequence there is no proper way to deinterlace the _whole_ video and you will see some ghosting even if you don't blend.


I can only agree to this. The "best" example of this is Star Trek Voyager sent in the german TV. A typical pain in the a.. to deinterlace. :(

@outlyer: Of course the cropped image has to be macroblock friendly. I completely forgot to mention. Stupid me. But there´s no wrong point of view. If you don´t like this cropping stuff then forget about keeping AR, macroblock optimized resizing. Just crop away unwished parts of the movie and letterbox to the next by 16 / 32 pixel divideable resolution.

-D$