Correct size Resolution for AVI

[PuzZLeR]

Sliztzan, the answer you seek is subjective. Although you should stick to a set of principles for efficiency and to keep the video from being distorted, DivX/Xvid aren't bound to a set of resolution constraints to be "compliant", unlike MPEG-2 (in SD) where you almost feel compelled to make it conform to the DvD spec to make it useful.

And forget that PM. I too say it's wrong. Just use the equation I gave you. The answers you got here are consistent with it.

And I will add to this:

For Divx any resolution that is 4:3 with a 1:1 PAR (although it supports other PARs) where the X and Y sizes are even numbers (and preferably divisible by 16 for efficiency) are acceptable. Of course the lower you go, the crappier it will look when you blow it up on your TV.

Yes indeed. As well as another axiom whereby X / Y = 1.33. Then again, it's in the equation.

But yes, keeping it larger like the original retains more quality and detail, but needs more bitrate to sustain this level of quality, which is, more or less, proportional to the amount of pixels (X times Y). You can decrease the resolution to save bitrate, but hopefully your viewing screen is smaller otherwise, yes, it will look crappier.

So, in other words, just pick a rez that is divisible by 16, "fits" the equation, and fits your needs. It's that simple.

[Condorcet]

[I came across this thread more than a year after its most recent message was posted. I was searching for info about the optimal framesize to make avi files intended for viewing using an xvid.avi-capable standalone dvd player outputting to a 4:3 ntsc tv set.]

It seems to me the advice given thus far to the thread's originator (make an avi file having dar=4:3 and par=1:1) has neglected the fact that he cropped the source from 720x576 to 690x568. Cropping doesn't change par, but it typically changes sar (and therefore changes dar since dar = sar x par). In this case, the cropping reduced the sar from 720/576 to 690/568. That is, from 1.25 to 1.2148. This means the cropping reduced the dar too. The formula when cropping is NewDAR = OriginalDAR x NewSAR / OriginalSAR. That is, 4/3 x 1.2148 / 1.25 = 1.296.

In order to make an avi that doesn't appear stretched, the avi should be made so the avi dar matches the new dar. Since the avi par will be 1:1, the avi sar should be approximately 1.296 too. Not 1.333 (4:3). Here are a few of the many possible dimensions for the avi:
622x480
640x494
690x532
736x568
As others mentioned, it might be a good idea to round each dimension to a multiple of 4, 8, or 16.

The software that converts to avi might have an option to maintain aspect ratio (dar) when resizing. It will automatically calculate the target height if you specify the width, or the width if you specify the height. It also might have an option to automatically round off to a multiple of 2, 4, 8 or 16.

Two issues the discussion has lacked are the questions of avi file size constraints (if any) and the computer monitor's natural resolution. For instance, my monitor is an LCD display with natural resolution of 1920x1200. (In other words, it has 1920x1200 pixels.) It can display at other resolutions but images look best at 1920x1200. If avi file size weren't constrained (I wish!) I'd enlarge when making the avi (using lanczos resize) so that the display driver doesn't have to enlarge in real time in order to optimally fit the monitor. (I'm presuming the display driver's enlargement algorithm isn't as high quality as lanczos since it needs to enlarge in real time each time the video is viewed, whereas lanczos is given plenty of time when the avi is made.) If the avi is made with size 1552x1200, its dar (1.293) would be close to the desired dar, it would optimally fit the monitor's natural resolution (1200 lines), and both 1552 and 1200 are multiples of 16.

Let's forget the wishful assumption that avi file size is unlimited. If your monitor is 1920x1200 like mine, consider making an avi with size 776x600. It would be 1/4th the file size of a 1552x1200 avi, can be easily enlarged to 1552x1200 in realtime by the display driver to optimally fit the monitor, has a dar (1.293) close to the desired dar, and both 776 and 600 are multiples of 8.

There are other quality tradeoffs between file size, sar and bitrate. Some transcoders can automatically make such tradeoffs, but I don't know how they do that, and I don't know whether they take into account the properties of the display device (such as monitor's natural resolution). I assume they don't take that into account, since their dialogs don't ask for that information.

One final issue: The thread originator specified xvid, but didn't indicate why. Why not consider x264 instead? The x264 codec is free, and from what I hear the image quality will be better than a similar size xvid (assuming the computer is fast enough to decode x264 when playing the video). My computer seems to be fast enough to play large H.264 videos, so I'd choose x264 if I weren't constrained by my stepmother's dvd player (an iView 102DV, which can play xvid files but not H.264 files).

[manono]

Digging up a thread more than a year old and using a lot of words just to pass on bad information? The OP wanted a square pixel AVI and using ITU resizing, 640x480 (and the other 1.33:1 ratio resolutions suggested) creates such an AVI with a -0.3% aspect error. Your resizing doesn't follow the preferred ITU-R BT.601 Standard which those of that responded initially do use.

...neglected the fact that he cropped the source from 720x576 to 690x568.

Hardly.

[Condorcet]

Manono, the age of the thread isn't important--the age doesn't make it harder to find by googling, nor more correct.

My suggestions provide square pixels (par=1:1) too, and have the advantage of retaining the correct dar.

I think you've now made an additional mistake claiming the aspect error with a 4:3 avi would be only 0.3%. By my calculation it's 10 times bigger: The aspect ratio (dar) of the cropped source is 1.296, and 1.296/1.333 = .972, which is nearly 3% too small. Even assuming a 3% error is tolerable, the discussion wasn't sufficiently general. Suppose someone else seeking similar help were to find this thread and is cropping more than the originator did? The error if they blindly choose 4:3 would be greater. Discussing how in general to get the dar right (to avoid stretching the image) after cropping isn't bad information.

Despite Manono's claim on Jan 2 2009 that the originator wanted a 4:3 avi, the originator in fact never asked for that; he only wrote that the source DVD was likely 4:3. Nor did he ask to adhere to an ITU standard. What's the advantage of 4:3 for an avi to be played only on a computer, and why is that more important than maintaining the 1.296 aspect ratio? Also, if you really think 4:3 has a significant advantage, why not recommend replacing some of the cropped area with black borders before resizing so that 4:3 will give the correct aspect ratio?

[manono]

Your big mistake is basing the resize on a 720 original width when proper resizing is based on a 704 width. This subject has been beaten to death both here and at Doom9 and I don't really have much interest in it. Do it any way you like.

[Condorcet]

Manono, it's a mistake to assume the DVD source width was really 704 (not 720). Here's an excerpt from Wikipedia:

"Unfortunately, not all standard TV pictures are exactly 4:3: As mentioned earlier, in analog video, the center of a picture is well-defined but the edges of the picture are not standardized. As a result, some analog devices (mostly PAL devices but also some NTSC devices) generated motion pictures that were horizontally (slightly) wider. This also proportionately applies to anamorphic widescreen (16:9) pictures. Therefore, in order to maintain a safe margin of error, ITU-R BT.601 required 16 more non-square pixels per line (8 more at each edge) to be sampled to ensure that all video data near the margins were saved."
(http://en.wikipedia.org/wiki/Pixel_aspect_ratio)

Nothing the thread originator (Sliztzan) wrote implied his source was really 704. However, he wrote that he has GSpot. Since GSpot will display the source video's pixel aspect ratio (and other info), it's a simple way to avoid unnecessary assumptions. (More below.)

I agree with the other respondents (JohnnyMalaria, Ai Haibara) who favored encoding to non-standard sizes when that will avoid loss of quality. On Dec 30 2008, Sliztzan replied that he was fine with odd resolutions: "Not a problem." (For what it's worth, in the last couple of years I've cropped hundreds of video clips to avis having non-standard DARs, and haven't found any player software that couldn't handle them.)

Here's a simple resizing guide that takes into account arbitrary cropping:

Let WIDTHsrc and HEIGHTsrc denote the source width and height after cropping. (In Sliztzan's case, 690 and 568.)
Step 1: Use GSpot (or other tool) to display the source's pixel aspect ratio (PAR). (This can be done before or after cropping, since cropping doesn't change PAR.) Call this PARsrc.
Step 2: If making an avi with par 1:1 (square pixels), calculate WIDTHresize = PARsrc x WIDTHsrc.
Step 3: Resize to WIDTHresize x HEIGHTsrc.
Step 4. If one or both of those dimensions aren't multiples of 16, consider adding black borders (after resizing, before encoding with xvid or x264) to make both dimensions multiples of 16 (to help the encoder).

This little guide doesn't take into account the final viewing size (which I discussed yesterday). By the same principle of avoiding unnecessary resizing, one should consider the monitor's natural resolution and whether the video will be viewed "full screen," in a small window, in a zoomed window, etc., since one's cpu or gpu chip must resize it while viewing if necessary to fit the viewing size. Resizing while viewing will degrade image quality further. If you encode the avi to fit the intended viewing size (instead of to the size indicated in steps 2 & 3) then the player won't need to resize while viewing. (On the other hand, the avi file size could be several times bigger if it's made to fit a large viewing size. A plausible compromise is to use the above guide's sizes and then view with zoom factor 2 if that will be large enough for comfortable viewing but not so large that it overflows the monitor size.)

[manono]

I think you proved my point:

Therefore, in order to maintain a safe margin of error, ITU-R BT.601 required 16 more non-square pixels per line (8 more at each edge) to be sampled to ensure that all video data near the margins were saved."
(http://en.wikipedia.org/wiki/Pixel_aspect_ratio)

This is for 1.33:1 videos, such as the one the OP has. Many classic films were shot in the Academy Ratio of 1.37:1, and for those it's perfectly OK to fill the entire 720 width. And I'm assuming the DVD production houses have done everything right which, of course, isn't always the case. In the absence of something definite, though (a slightly oval shaped moon, for example) we can only go under the assumption it was done correctly.

I agree with the other respondents (JohnnyMalaria, Ai Haibara) who favored encoding to non-standard sizes when that will avoid loss of quality. On Dec 30 2008, Sliztzan replied that he was fine with odd resolutions: "Not a problem." (For what it's worth, in the last couple of years I've cropped hundreds of video clips to avis having non-standard DARs, and haven't found any player software that couldn't handle them.)

None of this (or most of your post, for that matter) is at all relevant. Sliztan clearly stated:

I will be using a 1:1 pixel for computer playback.

Which implies he wants to encode for square pixels.

[jagabo]

I agree with Manono. The 4:3 (or 16:9) image on a DVD is contained in a 704x480 or 704x576 portion of the frame. So the full 720 pixel image is slightly wider than 4:3. GSpot is wrong when it reports 8:9 PAR for NSTC DVD. It derives the PAR simply by dividing SAR by DAR, not accounting for the 8 pixels of padding at each side. Most other programs use 10:11 PAR for 4:3 NTSC DVD.

On the other hand, even within the ITU specs and industry practice there is a lot of imprecision and controversy:
http://lurkertech.com/lg/video-systems/#pixelaspect

I also think it's pretty pointless to worry about sizing for your current display device. Are you going to be using that display exclusively for the rest of your life? Also, hardware video scalers are much better than they used to be. They no longer use point or simple bilinear scaling. So worrying about exact 2x scaling is pretty silly.

[Condorcet]

Manono, first, I don't share your willingness to make assumptions, nor your habit of leaving your assumptions and calculations unstated when you offer advice. (I'm assuming your old messages in this thread are a representative sample.) You may have privately calculated that the cropped dar would be close enough to 4:3 that Sliztzan wouldn't notice the aspect error, but your writing hadn't mentioned it nor suggested in general what someone might need to do if cropping significantly changes the dar: accept an odd dar or add borders. The omission was also unfortunate since a newby finding the thread could have gotten the impression that cropping is irrelevant to the recommendation of the avi's size.

However, it's understandable why the more general case of arbitrary cropping went unmentioned, since at the time that you and the others were writing, you were focused on Sliztzan's particular problem. The way I found this thread using google gives me a different perspective: people finding the thread will be trying to solve problems that aren't identical to Sliztzan's and would benefit from a more generalized solution that explicitly accounts for arbitrary cropping. That was one of my purposes in writing. You may say it's irrelevant to Sliztzan's case, but his isn't the only case.

For what it's worth, yesterday I examined the one PAL dvd I have, Elizabeth (1998), using Avidemux. (I copied a .vob file of the main movie from the dvd to the hard disk so Avidemux wouldn't choke when opening it.) The .vob frame size is standard 720x576. I selected the crop filter and entered some small values for trimming the top, bottom and sides. The filters pane then showed the before & after sizes. It showed that the original image was wall-to-wall, all 720 columns. (Is Avidemux misleading me?) Anyway, my point is to avoid assuming the source image is a particular size, and in general avoid unnecessarily making assumptions, and when you do make assumptions it's helpful to state them. And show your work (the calculations), not just your conclusions.

Second, this is the second time you've claimed I haven't advocated 1:1 par for the avi. The guide I provided is for making an avi with 1:1 par, so it's strange that you keep doing this. Perhaps I wasn't clear when I said I agreed with two of the other respondents? I didn't mean I agree with everything they wrote. What I meant was that I agree with them that since avi's with unusual dars play fine it's unnecessary to make the dar exactly 4:3 (or 16:9 etc.). Also, I agree with them that unnecessary resizing should be avoided. I disagree with their recommendation to make the avi par the same as the dvd par. They recommended that in order to avoid resizing, but I believe they misapplied the principle of avoiding unnecessary resizing; they neglected the resizing that will need to occur later when playing the video if it isn't encoded to match the size of the viewing window and the shape of the monitor's pixels. (Hopefully the assumption that the monitor's pixels are 1:1 is valid and stays valid.)
* * * * *
Jagabo, hi. First, thanks for the tip that the par displayed by GSpot isn't reliable. Do you have any links to more information about that? (I tried googling it but it was a case of searching for a needle in a haystack.) I'd particularly like to know if some other tool is reliable.

Second, you asked whether I expect to keep the same monitor forever... I hope we all live long enough to upgrade our monitors. (Presumably their pixels will still be 1:1.) I trust the rest of the hardware will be upgraded over time too. Future computers will be faster, which means re-encoding will be much faster (if the source wasn't discarded), particularly if a script is used now to direct the cropping/resizing/encoding and can be reused later. Capacities of storage media will increase too, so an avi encoded small now (to save space) could cause regret later (if the source was discarded).

Third, do you believe that unusual dars are fine if the avi will only be played on a computer, and are useful if cropping significantly changes the dar?

[manono]

Manono, first, I don't share your willingness to make assumptions, nor your habit of leaving your assumptions and calculations unstated when you offer advice. (I'm assuming your old messages in this thread are a representative sample.) You may have privately calculated that the cropped dar would be close enough to 4:3 that Sliztzan wouldn't notice the aspect error, but your writing hadn't mentioned it nor suggested in general what someone might need to do if cropping significantly changes the dar: accept an odd dar or add borders. The omission was also unfortunate since a newby finding the thread could have gotten the impression that cropping is irrelevant to the recommendation of the avi's size.

Do you just make this stuff up out of thin air? Now you're switching your argument from one stating that all of us got the resize wrong (an argument you can't win) to one promoting anamorphic encoding (a fine idea but pointless in the context of this thread) to one saying that I should have stated how I arrived at my (correct) resize? OK, except for having the ITU box checked in the Options Tab, here's a clear demonstration of how to do it. Note that the crop is fully taken into account:

[creamyhorror]

GSpot is wrong when it reports 8:9 PAR for NSTC DVD. It derives the PAR simply by dividing SAR by DAR, not accounting for the 8 pixels of padding at each side. Most other programs use 10:11 PAR for 4:3 NTSC DVD.

Yep, encountered this issue with Gspot too while answering the questions of someone here. Ultimately you have to choose the PAR yourself, whether it's 8:9 or 10:11. It's not determinable from the stream itself, AFAIK.

Step 4. If one or both of those dimensions aren't multiples of 16, consider adding black borders (after resizing, before encoding with xvid or x264) to make both dimensions multiples of 16 (to help the encoder).

No need to do this with x264, it pads to mod16 anyway by repeating edge pixels (which is slightly more efficient than padding with black). I don't bother with mod16 anymore, except if I'm at mod16+2 or +4 - then I just crop to mod16.

[manono]

(To go just below the pic above) You can do the math (but apparently you have trouble with that), or you can use an app that's done it correctly for years now. You yourself might benefit from using the resizer in GKnot. Just make the D2V and open it in the Resolution Tab to crop and resize with the picture to guide you. As for your Elizabeth DVD, it'll work fine with that as well, but I don't know what the DAR is so no pic to help you figure a proper resize. Feel free to have the last word. I retire from this 'discussion'.

[jagabo]

The MPEG stream uses a four bit field to flag the aspect ratio. They refer you to the ITU-T Rec. H.262, ISO/IEC 13818-2 spec. for the meaning of those bits. The ITU spec. says:

1: 1:1 PAR, square pixel
2: 4:3 DAR
3: 16:9 DAR
4: 2.21:1 DAR

That is where GSpot gets the DAR it reports. It then calculates the PAR from DAR and the frame size. Unfortunately, it isn't made clear in the ITU docs whether the DAR refers to the full 720 pixel width or the 704 pixel subset. 704 comes from ITU's precisely specified 13.5 MHz sampling of an analog NTSC signal. That results a ~711x485 pixel size for the defined 4:3 analog video frame. That is cropped down to 480 lines to make a mod 16 frame. That cropping of the height requires the width be cut down proportionally to maintain the 4:3 DAR. 711*480/485 gives ~703.7, which is rounded up to 704 (mod 16 again).

So the ITU spec is inconsistent. On the one hand it precisely specifies 10:11 PAR with digital sampling of analog sources but with 720x480 MPEG frames it implies 8:9 PAR. I believe most people have decided to go with 10:11 PAR.

Me? I just encode at the original frame size (sometimes cropping away black borders) with 10:11 PAR flags and rely on the player to adjust the DAR. This way there is only one digital scaling going from the file to the display. Whether this is always correct I don't care. The ~2 percent difference between 10:11 and 8:9 doesn't matter to me.

The simplest way for people who want to crop black borders to maintain the correct AR with square pixel encoding: resize to a 4:3 frame size first (it's up to you to decide whether the 720x480 frame or a 704x480 subset is the real 4:3 image), then crop away the black borders to leave a mod4 (at least) frame size. Almost all modern Divx/Xvid players, hardware and software, can handle Xvid with mod4 frame sizes. The same works for 16:9 DVDs. Ie, resize to a 16:9 frame size and crop away the black borders.

[Alex_ander]

Unfortunately, it isn't made clear in the ITU docs whether the DAR refers to the full 720 pixel width or the 704 pixel subset.

From ITU-R BT.601 it clearly follows 704 (considering analog line active length). It is H262 document that says the opposite: if the optional sequence_display_extension (sample numbers like 711x483 defining active display area) is absent, the whole reconstructed frame is mapped to entire active area of display. It would be more natural to follow ITU 601 by default, since no additional data is required for reading samples at the standard clock frequency 13,5 MHz. That's enough for matching original geometry at playback (as sampled by ITU). Unlikely all encoders provide that 'sequence_display_extension' or have an option to set it. There's some 'lock resolution' option in TMPGEnc Xpress, not sure what it does; CCE doesn't offer such a choice. GSpot seems to always derive 'PAR' numbers from resolution and AR. Probably those sequence_display_extension numbers happen not too often (otherwise GSpot is not smart enough).

[jagabo]

It is H262 document that says the opposite: if the optional sequence_display_extension (sample numbers like 711x483 defining active display area) is absent, the whole reconstructed frame is mapped to entire active area of display.

Do you know of any tools that will show the sequence_display_extension settings? Or at least accurately report PAR and DAR?

[Alex_ander]

No, unfortunately.