Aspect Ratios... Tell me if this article is wrong or not...

[kschang]

Can someone tell me if all this is correct?

--------
More practical aspect ratios, or... How do I convert wide-screen aspect ratio videos to VCD/SVCD/DVD with proper letter-boxing?

Tools: Calculator, and MAYBE AVISynth if that's going to be your resize and letterboxing tool.

1) use your video player or a video tool like GSpot to figure out the resolution of your video file.

This assumes that your video is "full-screen", i.e. you don't see any letter-boxing (i.e. black bands) on top/bottom of your video when it's played in a window. If your video already has letter-boxing, it is probably already in 4:3 aspect ratio and thus needs no further adjustments

2) calculate the aspect ratio based on those resolutions, by dividing the width (first number) by the height (second number).

EX:
640 / 480 = 1.333 (or 4:3 ratio)

640 / 360 = 1.778 (or 16:9 ratio)

3) What is your destination format?

We're going to aim for aspect ratio of 4:3 since most people's TV is 4:3, so we have to add some black bands on top and bottom. That's called letterbox'ing

3a) SVCD-NTSC

This has resolution of 480x480, but it's still 4:3 ratio as it will stretch the video horizontally. Yes, this part is a bit of a pain to visualize. Just think of SVCD as 640x480 for now, and later horizontally scale by 480/640.

3b) DVD-NTSC

DVD has resolution of 720x480, and is workable as either 4:3 ratio or 16:9 ratio. It's a pain to visualize, I know. As we are aimming for 4:3 ratio, assume for now it's 640x480, then later horizontally scale by 720/640

3c) VCD-NTSC

This has resolution of 352x240, which is displayed as a 4:3 ratio (but if you do the math, you'll see that it is NOT 4:3 at all. This is the most painful fit as you must as you need to do vertical half AND some horizontal stretching. For now, think of it as 320x240 then rescale horizontally by 352/320.

4) Fitting the stuff into the imaginary 4:3 640x480 frame

4a) SVCD: To fit 640x360 video in 640x480 is no problem. The vertical difference is 120, so that would mean 60 pixel tall black band on top, and 60 pixel tall black band at bottom. 360+60+60=480, perfect.

4b) DVD: You may be tempted to run a conversion trying to fit 640x360 into 720x480, and came up with conversion factor of 1.125, and so on and so forth. It's NOT NEEDED. While this is counter-intuitive, we've stated before that we are aimming for 4:3 aspect ratio, and 720x480 will be displayed as a 4:3 picture. So we have to IGNORE the horizontal resolution for now. Then the calculation is the same as the one in the SVCD.

4c) VCD: Its resolution is low enough we're reducing the imaginary frame to 320x240 (which is half of 640 and half of 480, closest to the actual res of 352x240). To fit 640x360 video in 320x240 and keeping the ratio would mean the video must be downsized into 320x180. 240-180=60, so the top and bottom band size is 30 pixels each. 180+30+30 = 240

5a) SVCD: Horizonal scale by 480/640

5b) DVD: Horizontal scale by 720/640

5c) VCD: Horizontal scale by 352/320

6) If you are using AVISynth, the script would look something like this:

6a) SVCD version

# Assumes video imported is 640x360
BiLinearResize(480,360)  # Converts video from 640x360 to 480x360
# You could use BiCubic or some of the other algorithms available
AddBorders(0,60,0,60) #add 60 border on top and 60 border on bottom
# actual res is now 480x480   360+60+60=480

6b) DVD version

# Assumes video imported is 640x360
BiLinearResize(720,360)  # Converts video from 640x360 to 720x360
# You could use BiCubic or some of the other algorithms available
AddBorders(0,60,0,60) #add 60 border on top and 60 border on bottom
# actual res is now 720x480   360+60+60=480

6c) VCD version

# Assumes video imported is 640x360
BiLinearResize(352,180)  # Converts video from 640x360 to 352x180
# You could use BiCubic or some of the other algorithms available
AddBorders(0,30,0,30) #add 30 border on top and 30 border on bottom
# actual res is now 352x240   180+30+30=240

[guns1inger]

PErsonally I think it oversimplifies things and doesn't show a real understanding of optimising for encoding. There are a number of good tools available to do this in a more sophisticated and accurate manner. I have written one for avi to DVD conversion, FitCD covers most formats and produces an avisynth script as well. I have even seen calculators that go into HDTV resolutions.

The advantages of these calculators are a) they calculate based on correct pixel aspect ratios for each format and TV system, and b) are optimised for mpeg encoding.

[mikiem]

I admire your ambition, & dare say courage.

NOTHING is more guaranteed to start controversy then posting about aspect ratios.

That said, if you're interested, I can give you a few links which discuss the matter in some depth.

As far as any critique goes...

guns1inger is correct about your post doing a bit of oversimplifying. If it helps, SVCD 480 x 480 is a good example of anamorphic video where the player stretches the frame width. Trivia: 480 was chosen because it was felt that was the average number of vert. lines (pixels) that the home TV recieved, the rest being lost in cabling etc. - something US sat providers often exploit by sending narrowed frames to conserve bandwidth (all while praising the quality of their digital feed ).

352 x 240 is single field, cropped, NTSC D1 with a pixel aspect of roughly .9091... If you convert it to square pixel, 352 * .9091 = 320, you get the std square pixel size everyone's used to on a PC. The cropped is because the frame is cropped converting from D1 (non-square pixel) to square pixel -- NTSC non-cropped would be 1/2 of 720. Trivia, it's all that's required to fill your TV screen, though you won't get 60 fields, and was somewhat common in the early 90's I think.

Widescreen DVD (4b)... Normally based on the 16:9 part of the spec, you have anamorphic video with a frame of around 853 (please don't quote me on that as I've got more tests pending ) squeezed into 720. Not sure if it's the best method for efficiency etc., & permanent letterboxing will work, but using anamorphic gives the flexibility to play on widescreen displays too.

That all said, my suggestion might seem at first odd. I'd personally recomend simplifying it a bit more, after correcting any inaccuracies, or perhaps giving 2 options, one more accurate but one quicker.

In my experience, the more background info you give, the more some peoples eyes start to glaze, while others find reason to dissagree. And I don't recall any sites or guides where they simply and accurately just give conversion sizes, though I'm sure some exist.

[kschang]

PErsonally I think it oversimplifies things and doesn't show a real understanding of optimising for encoding. There are a number of good tools available to do this in a more sophisticated and accurate manner. I have written one for avi to DVD conversion, FitCD covers most formats and produces an avisynth script as well. I have even seen calculators that go into HDTV resolutions.

The advantages of these calculators are a) they calculate based on correct pixel aspect ratios for each format and TV system, and b) are optimised for mpeg encoding.

Actually, It was FitCD that inspired me to do this article. As its script somehow chopped off the bottom X pixels of my video, even though I had specified no cropping on the source. I *guess* that one of those tiny "rounding" sliders did me in, but there's no help file or explanation on what those options actually do. *sigh*

Also, it won't let me choose a plain 4:3 ratio as the source. I hit Open and picked the 640x360 video file. Here's the result, after I picked SVCD on the right:



Note that on the highlighted field, it is NOT possible to pick 4:3 or 16:9. Closest I can get is that DVD one, which produced the output on the right, which is, needless to say, completely... useless.

I actually DID read the existing guide by DJRumpy. While he presented the tables, he didn't actually demonstrate how to use them practically except in passing in a single sentence.

If the VERTICAL image area is less than 480, then you would add letterboxing to fill the remainder until the height is equal to 480

Which is basically what I did, except I pretty much ignore the horizontal re calculations. But I think I came up with the same results...

For example, say, movie is 640x480, which is 4:3. Since SVCD is 480x480, the only rescaling would horizontal, 640 scaled into 480.

However, if movie is 640x360, which is 16:9, according to the table, it needs to be rescaled to 480x360, then letterboxed by adding 60/60 to top/bottom to get 480 vertical. I came up with the same result, albeit in a somewhat roundabout way.

[kschang]

Hmmm... guns1inger... Played with FitCD a little bit more, it's definitely those small sliders that did me in. By playing with the destination "round to" slider to 2 (overscan to 0), I get this script instead

# -= AviSynth v2.5.6.0 script by FitCD v1.2.8 =-
AVISource("SomeVideo.avi")
BicubicResize(480,370,1/3,1/3,0,0,640,360)
AddBorders(0,48,0,62)

But as you can see, the resixing is... to 480x370, while the source was 640x360, which brings up 2 questions...

1) I thought it's faster to resize in only one dimension than 2, esp. when the difference is so small?

2) Even according to DJRumpy's guide table 1, the conversion should be to 480x360, then have 60/60 border added. So where did 370 + 48/62 came from?

A guess on where 48/62 came from... 60 is a multiple of 4, just not an EVEN multiple (4x15=60). So to make them EVEN multiples of 4, they can be slightly shifted to 64/56 (4x16/4x14) or vice versa. I guess that's the rationale to push them from the ideal even border?

[guns1inger]

Note that on the highlighted field, it is NOT possible to pick 4:3 or 16:9. Closest I can get is that DVD one, which produced the output on the right, which is, needless to say, completely... useless.

There is no 4:3 or 16:9 on a PC for source video. FitCD covers all the possibilities in it's drop down list. Example : unless an avi file has non-square pixels, it will be 1:1 monitor. If it is SVCD, there is an svcd source. etc.

Have a read of this page, especially the table at the end of the article. http://www.mir.com/DMG/aspect.html

I cannot explain the weird calculation for the 370 resizing in FitCD. I have no interest in out dated formats such as VCD and SVCD, which is why my calculator only concerns itself with DVD resizing.

[kschang]

Note that on the highlighted field, it is NOT possible to pick 4:3 or 16:9. Closest I can get is that DVD one, which produced the output on the right, which is, needless to say, completely... useless.

There is no 4:3 or 16:9 on a PC for source video. FitCD covers all the possibilities in it's drop down list. Example : unless an avi file has non-square pixels, it will be 1:1 monitor. If it is SVCD, there is an svcd source. etc.

Got it. We are ssuming PC pixels are square and thus aspect ratio is 1:1. In any case that didn't affect the calculations. It's that "round to" slider on the right that really changed things around.

I cannot explain the weird calculation for the 370 resizing in FitCD. I have no interest in out dated formats such as VCD and SVCD, which is why my calculator only concerns itself with DVD resizing.

Even with DVD 720 picked, it's STILL doing weird resolutions, and it's now definitely in the "optimization" slider under the output. Here are two screenshots for comparisons:





So basically seems like "no optimization" (slider all the way to left) is broken. You have to leave the block optimization to at least 2 (second step) or 4 (third step) for the border calculations to work.

[guns1inger]

I leave it at 16 (macroblock optimised for encoding) and no overscan (I don't do fan subbed anime, so nothing to be gained) and find that for DVD calculations it is generally accurate. The one thing that does bug me about FitCD is that it doesn't round to the nearest border when doing the final Mod16 calculation. This means that it may round down 12 pixels instead of up 4 pixels. My own calculator rounds correctly, and therefore produces (as far as I am concerned) more accurate results. That said, my results differ for FitCD's results maybe one time in ten for unusually cropped source materials.

You are right that having rounding set to No Optimisation certainly seems to produce nonsense.

[kschang]

Did a couple more tests, left it at 16. The script then look slike this:

BicubicResize(320,176,1/3,1/3,0,0,640,360)
AddBorders(16,32,16,32)

But somehow, when I run this, this chopped off the bottom X pixels of my 640x360 picture, but as you can see, there is no trim statement. It's as if including them with 0 trim somehow defaulted it to trim X pixels off the bottom. If I replace that line with

BicubicResize(320,176,1/3,1/3)

Then there's no chopping at all. It's weird.

And even stranger, the output looks horizontally compressed, both on the PC and on the burned VCD (the DVD player is set to 4:3 display). So the margins are WRONG!

For a test, I changed the 2nd line so it's 16 all around. The code then becomes:

BilinearResize(320,208)
AddBorders(16,16,16,16)

This then looks proper, both on the PC (in full screen, automatic letterbox) and on the DVD player/TV!

What am I missing? What did I do wrong with FitCD? I'm getting really confused.

[kschang]

For the heck of it, I played it in VLC, paused it, and took a snapshot. Interesting result.

VLC's playback window for this file (352x240, VCD standard MPEG) is actually 312x240. (when it should be 320?). This is confirmed by Irfanview.

I load the snapshot into PhotoImpact (my cheap PhotoShop clone) and stretched the picture back to 352x240, and checked the video frame size. Width comes out to be about 320, which is what I expected. But the height is... around 158 (+/- 2 px)? when it should be about 176, according to the script? Hmmm...

[adam]

kschang there's nothing broken about FitCD. You are using it incorrectly. The FAQ that comes with it isn't great but it does describe each of the settings. There's also tooltips if you hover over the features.

You have cropping set to none. Any change anywhere is going to change the aspect ratio and give you errors since you are just resizing active picture, not cropping as well to maintain aspect ratio. Hover over the cropping option and it tells you this. "no cropping causes aspect-ratio error." Turning optimizations totally off works fine if you make sure you aren't screwing up your aspect ratio somewhere else. To keep aspect ratio perfect everytime you'd set rounding to 1, turn off optimizations, and turn off the overscan option, and of course you'd always have to have cropping of some kind set. But this isn't using the program to its full potential either. You're supposed to play with each of these options and give and take here and there to get the optimizations you want without straying too far from the source aspect ratio.

Generally you should leave cropping at accurate, but you may have to adjust it depending on source and output settings. For round to you should try to never go higher than 2, but again adjust these as needed to maintain aspect ratio. 1 would of course be best, use 2 if you have to. You should always try to use the overscan option if you are going to be viewing it on a tv, but sometimes there's just no way to do this and maintain aspect ratio. Try to adjust the optimation roundign as high as you can without errors. Full mod16 optimazation speeds up encoding and increases quality. I love FitCD! But you've you got to adjust ALL of these settings each time to maintain aspect ratio.

guns1inger: the blocks overscan option always has its benefits even when subs are not involved. If played on a tv the outer X number of pixels (depends on tv) will not be visible. Yet you still have to encode that picture meaning bits must be allocated. Setting the overscan option to 2, crops 2 pixels from all sides and adds black borders instead which require virtually no bits to store. That's a savings of roughly 8 pixels every single frame. Doesn't sound like much but over the course of a film you are talking about a decent increase in effective bitrate and of course when viewing it you'll never miss those pixels.

[kschang]

Finally, someone who seems to know a lot about FitCD!

You have cropping set to none. Any change anywhere is going to change the aspect ratio and give you errors since you are just resizing active picture, not cropping as well to maintain aspect ratio. Hover over the cropping option and it tells you this. "no cropping causes aspect-ratio error."

Not if the source is exactly 640x360, which is 16:9, isn't it? In thise case, there is no difference between accurate vs. no cropping. Rounding was set to 4 / 4 on the left side.

Generally you should leave cropping at accurate, but you may have to adjust it depending on source and output settings. For round to you should try to never go higher than 2, but again adjust these as needed to maintain aspect ratio. 1 would of course be best, use 2 if you have to.

Another observation... For source video of 640x360, with x and y round set to 2, no cropping yields 640x360, but accurate yields 624x360 (chopping off 16 pixels!) which makes no sense. FitCD seems to have a bit of math problem in this case.

You should always try to use the overscan option if you are going to be viewing it on a tv, but sometimes there's just no way to do this and maintain aspect ratio. Try to adjust the optimation roundign as high as you can without errors. Full mod16 optimazation speeds up encoding and increases quality.

Overscan is now set to 2 blocks You mean the "macroblock optimization", right? The slider below the output side? Have that set to 16 for now, got the code as follows:

BilinearResize(320,176,0,0,640,360)
AddBorders(16,32,16,32)

But again, this looks horizontally compressed. And FitCD complains that the error here in aspect ratio is about 7.6%.

If I set the slider to MMX Optimization (4), I get this code instead:

BilinearResize(320,164,0,0,640,360)
AddBorders(16,32,16,44)

Which makes even LESS sence this is even MORE vertically compressed (by additional 12 pixels, or 5% of vertical space!! Yet according to FitCD this one is MORE accurate... (less than 1% error). Logically this doesn't make sense.

guns1inger: the blocks overscan option always has its benefits even when subs are not involved. If played on a tv the outer X number of pixels (depends on tv) will not be visible. Yet you still have to encode that picture meaning bits must be allocated. Setting the overscan option to 2, crops 2 pixels from all sides and adds black borders instead which require virtually no bits to store. That's a savings of roughly 8 pixels every single frame. Doesn't sound like much but over the course of a film you are talking about a decent increase in effective bitrate and of course when viewing it you'll never miss those pixels.

Don't mean to hijack guns1inger's conversation, but it's NOT efficient to rescale the whole picture just to save a couple pixels. The time spent to resize the full frame would more than offset the time saved encoding a few more black pixels. If you use crop then addborder without using resize, then yes, this would make sense. But resize, THEN add border to add overscan would NOT yield any time savings, logically speaking.

[guns1inger]

Many thanks, Adam - you have filled in a couple of blanks for me as well.

kschang, Adam is refering to space savings mor so that time savings. Mod 16 can decrease encoding times because of the efficiency in working with just macro-block size data chunks. Adam's argument is that adding the borders saves space over the length of a movie - space that can be allocated as extra bitrate to important parts of the film. Whether or not this comes at a cost of render times isn't part of hi argument.

[adam]

Kschang, have you read the documentation that comes with FitCD? Its brief and you'd definitely have to read between the lines but I'm comparing it to your questions and it really does answer every one of them.

"no cropping causes aspect-ratio error."

Not if the source is exactly 640x360, which is 16:9, isn't it? In thise case, there is no difference between accurate vs. no cropping. Rounding was set to 4 / 4 on the left side.

FitCD and I are generalizing. The point is that you are limited to resizing proportionally and then adding borders. Sometimes cropping is necessary to maintain aspect ratio, and it is almost always going to be necessary to implement the optimizations that FitCD offers. In your example, using accurate cropping allows you to achieve full macroblock optimization (every pixel fits in a macroblock with no left overs) without losing aspect ratio. No cropping does not.

BTW: the round to option under cropping has no effect unless you actually have FitCD set to crop. You should always leave the round to option set to 2 except with interlaced sources in which case you should set the vertical rounding to 4. Otherwise adjust as necessary to maintain aspect ratio.

Another observation... For source video of 640x360, with x and y round set to 2, no cropping yields 640x360, but accurate yields 624x360 (chopping off 16 pixels!) which makes no sense. FitCD seems to have a bit of math problem in this case.

There is no math problem. FitCD is giving you exactly what you are telling it to do. As the instructions state, accurate cropping attempts to retain as much of the film pixel resolution (active picture, not letterboxing) as possible yet still keep the aspect ratio accurate. If FitCD crops that much than that is simply how much must be cropped to maintain aspect ratio given YOUR input settings. As the instructions state, if you feel that too much is being cropped than you need to try a different cropping mode (you can choose to prioritize horizontal or vertical picture), change rounding, remove optimizations, turn off overscan cropping, manually input the amount to crop (by setting the resulting resolution after crop), or do any combination of these things. Doing so adjusts all other factors and gives you a real time answer as to whether aspect ratio is correct. You've got to play with it man.

Look, if you just turn everything off (except cropping ) then FitCD will just give you a plain jane script to get to your target resolution. This is basically where you should start. From there you should always try to turn on the overscan option. You should try to get as many optimizations as you can. And the golden rule is that you should never get any noticable aspect ratio errors (% will turn yellow then red). If at any point FitCD loses aspect ratio or crops too much to warrant implementing the optimizations, then you have to back your settings down or modify their combination. In any case FitCD only gives you the script that you tell it you want, and reports the resulting aspect ratio.

You mean the "macroblock optimization", right? The slider below the output side? Have that set to 16 for now,
But again, this looks horizontally compressed. And FitCD complains that the error here in aspect ratio is about 7.6%.

If I set the slider to MMX Optimization (4), I get...
Which makes even LESS sence this is even MORE vertically compressed (by additional 12 pixels, or 5% of vertical space!! Yet according to FitCD this one is MORE accurate... (less than 1% error). Logically this doesn't make sense.

How are you eyeballing the aspect ratio? Are you just previewing the avisynth script in media player? If you are actually encoding to mpeg did you set the aspect ratio flag correctly? Are you testing it in a media player that parses aspect ratio flags (many will not unless you do the full blown authoring to DVD)?

In order to understand what is happening you have to understand some fundamental basics of mpeg encoding. I bet you already know this but I don't think you are thinking in these terms when analyzing what FitCD is doing. FitCD is intended to be used to create scripts for use with mpeg encoding which uses aspect ratio flags. The target film pixel resolutions (actual picture) of all of the supported formats (VCD, SVCD, DVD, etc..) do not have 4:3 or 16:9 aspect ratios. Rather, the decoder resizes the output to these aspect ratios at playback. What you see on the tv is NOT what you will see if you just preview the avisynth script in media player. There is no aspect ratio flag set in this case.

At least in your example, you are dealing with an avi file that has a perfect 16:9 aspect ratio. This is done because most of the conventional codecs do not support aspect ratio flag parsing. So your avi was either created, or edited, so as to be stored in the exact aspect ratio that it is to be viewed in. This is NEVER the case with mpeg based formats. So in transferring it to mpeg you've got to distort the image and then set the aspect ratio flags accordingly to have it properly formatted at playback. That's why it will appear that the aspect ratio is way off in any of the intermediary stages. The decoder is only showing you the film pixel resolution, it is not showing you the intended playback resolution which can only be achieved by setting aspect ratio flags and then having the decoder parse them.

I can't even remember how many years I've been using FitCD (actually I use the full version Fit2disc which is only available by donating. Definitely recommend it!) I know shh has tweaked the hell out of this program and its been thoroughly bugtested by the community. I really feel very safe saying that if FitCD reports 0-1% aspect ratio error than you will indeed have proper aspect ratio when played back in the intended format. If you are seeing bizarre aspect ratios in the intermediary stages its because that is how it is supposed to look. This will be corrected at playback, and this is simply how mpeg based formats (ex: DVDs) work.

Don't mean to hijack guns1inger's conversation, but it's NOT efficient to rescale the whole picture just to save a couple pixels. The time spent to resize the full frame would more than offset the time saved encoding a few more black pixels. If you use crop then addborder without using resize, then yes, this would make sense. But resize, THEN add border to add overscan would NOT yield any time savings, logically speaking.

gunsl1inger already touched on this but the overscan option is not to save encoding time, its to maximize bitrate usage. The rule is, don't encode what you don't see. The pixels that are cropped, and now replaced with black, are pixels that would be lost in the overscanned area on the tv anyway.

But for that matter, no resizing is being done. The option crops and adds borders, that's it. Using this option actually should decrease encoding time minimally, but that's not its purpose.

[manono]

You want that 640x360 AVI resized the way you expected? Check the ITU-R BT.601-4 resizing box.

The rule is, don't encode what you don't see.

Just so you know; that's not so much a rule as an opinion. I, for one, don't use blocks overscan. You lose resolution (not necessarily when doing an AVI2DVD conversion, but definitely with DVD2DVD), and before too long you may have a display without overscan issues.

[kschang]

Well, guess I'll have to take a picture of my TV to show you... But after trying a few things I figured out that my TV has MASSIVE overscan. It loses at least 16 pixels on both the left AND right side. Even after putting in 2 blocks of margins, my pictures STILL shows with no black on left and right. THAT could have thrown my perception off a bit.

[guns1inger]

One of the reasons to preview your scripts in virtualdub is because you can force the display to mimic the AR flags. You can see things in 1:1, 4:3 or 16:9.

[adam]

How do you lose resolution using the overscan option in a DVD to DVD backup? I don't understand. Either way the same number of pixels are used to display the image on the screen. (that which you actually see,) and the image has not been scaled in any direction. Or are you saying the overscan option just adds a border on the edges? I thought it cropped and then added the border.

Yes the procedure is only useful assuming playback on something that overscans so its not for everyone but I do think its the best option for most people.

[manono]

Hi adam-

I kind of hate to argue with you because I might have missed something (and for the same reason I'm hesitant about taking on guns1inger, who has corrected me on at least one occasion), but:

Or are you saying the overscan option just adds a border on the edges?

Yes, that's what the blocks overscan does. It resizes the image down and then adds black around the smaller image.

So ordinarily when reencoding a DVD source for DVD no resizing is done, but when using 2 blocks overscan, it'll give you this:

LanczosResize(656,448)
AddBorders(32,16,32,16)

That's a significant loss of resolution in my opinion, not to mention the fact that resizing, no matter how well done, further degrades the image.

[adam]

Hey I never argue with you, we just bounce things off of each other.

I just checked and you're right, it just adds a border around the edges. There is no cropping, but there's nothing stopping you from manually doing this. My mistake and I definitely see your point now about losing resolution in all cases and about needlessly resizing with sources where res doesn't otherwise need to be altered (ex: DVD->DVD.) Like you suggested though, this is gonna be moot in most other cases since you will be resizing anyway.

Ok I agree, its just an opinion not a rule.

[guns1inger]

I would not bother adding borders to something that was already compliant resolution, but when resizing up I believe Adam has a valid point. It also has the advantage of reducing the amount of actual image resizing, which as you pointed out will do some damage (although I find asharp does a pretty good job of correcting the clarity without halo-ing)

[kschang]

I think I figured out my problem, and it's really a forehead slapper.

My AVI is XVID encoded, which VDub can't read directly, but I was able to do a DShow through AVS and fed it in any way. Keep in mind that the AVI is 640x360.

However, previewing the AVS with JUST the DirectShowSource line through VDUB shows that the resolution has suddenly became 640x480, with black borders added automaticlaly by SOMETHING!?!?!

Undocumented behavior, AFAIK. I checked the AVISynth manual in AVSEdit, didn't see a thing mentioned that it would behave like that.

So any resizing I did, I was squeezing extra black space into the top and bottom, NO WONDER it looks verticaly compressed!

Now I am DEPRESSED. :P That's what completely threw off my calculations. :P

You guys are right. There's nothing wrong with FitCD. My apologies for trying to suggest otherwise.

[jagabo]

My AVI is XVID encoded, which VDub can't read directly, but I was able to do a DShow through AVS and fed it in any way. Keep in mind that the AVI is 640x360.

Why don't you just install the Xvid codec? Then you can read the file directly in VirtualDub.

[kschang]

XVID codec IS installed (Latest keopi binaries), but my VDubMod insisted that it needs VFW style codec, where s the XVID codec I got is DSH codec, I think.

EDIT: here's the error message:




And here's my list of VFW style codecs as per GSpot

VFW CVID Cinepak Codec by Radius Radius Inc. QCAP.DLL --> ICCVID.DLL
VFW MSVC Microsoft Video 1 Microsoft Corporation QCAP.DLL --> MSVIDC32.DLL
VFW MRLE Microsoft RLE Microsoft Corporation QCAP.DLL --> MSRLE32.DLL
VFW M263 Microsoft H.263 Video Codec Microsoft Corporation QCAP.DLL --> MSH263.DRV
VFW M261 Microsoft H.261 Video Codec Microsoft Corporation QCAP.DLL --> MSH261.DRV
VFW IV50 Ligos Indeo® Video 5.11 Ligos Corporation QCAP.DLL --> IR50_32.DLL
VFW BT20 Brooktree ProSumer Video (32) Brooktree Corporation QCAP.DLL --> BTVVC32.DRV
VFW Y41P Brooktree YUV 411 Raw Brooktree Corporation QCAP.DLL --> BTVVC32.DRV
VFW YVU9 Ligos Indeo® Video Raw R1.2 QCAP.DLL --> IYVU9_32.DLL
VFW MPG4 Microsoft MPEG-4 Video Codec V1 Microsoft Corporation QCAP.DLL --> MPG4C32.DLL
VFW MP42 Microsoft MPEG-4 Video Codec V2 Microsoft Corporation QCAP.DLL --> MPG4C32.DLL
VFW MP43 Microsoft MPEG-4 Video Codec V3 Microsoft Corporation QCAP.DLL --> MPG4C32.DLL
VFW IV41 Ligos Indeo® Video 4.5 Ligos Corporation QCAP.DLL --> IR41_32.AX
VFW DIVX DivX® 5.1 Codec DivXNetworks, Inc. QCAP.DLL --> DIVX.DLL
VFW IV32 Ligos Indeo® Video 3.2 Ligos Corporation QCAP.DLL --> IR32_32.DLL
VFW FFDS ffdshow Video Codec QCAP.DLL --> FF_VFW.DLL
VFW WMV3 Microsoft Windows Media Video 9 Microsoft Corporation QCAP.DLL --> WMV9VCM.DLL
VFW MKVC FullMotionVideo Decoder QCAP.DLL --> KMVIDC32.DLL

[jagabo]

I read and write Xvid files all the time with VirtualDubMod and Koepi's build of Xvid.

[manono]

Hi-

I may have missed it, but I don't see XviD anywhere in your list. Open VDubMod and go Video->Compression. Scroll to the bottom of the list. Do you see XviD listed there? If not, install it again.

[kschang]

I may have missed it, but I don't see XviD anywhere in your list. Open VDubMod and go Video->Compression. Scroll to the bottom of the list. Do you see XviD listed there? If not, install it again.

Installed it TWICE, don't see it. Even went ahead and downloaded the latest binaries (AGAIN), nothing. Somehow VDubMod doesn't see the VFW entries.

[kschang]

I better start a new topic for this though... I've hijacked my own topic.

[manono]

Gee, that's strange. And you rebooted? I don't know then. This may be a job for celtic_druid. This kind of thing is one of his specialties.

[kschang]

Don't worry about it, as I'm on win98, and it's bound to have a few quirks.