One day, the world will be progressive scan and square pixels. For now, that is just the web. But it does have it’s own tricks, like compression optimization.
For example:
Using On2’s compression, it is desirable to meet a few criteria:
1) Make sure the dimensions of your final flv are all multiples of 16 pixels
2) Don’t squish or stretch the video while doing this. (well, noticeable, mostly when dealing with talking heads, its visually better to squish a little horizontally than stretch)
If your input is:
720×480 (old fashioned DV or DVD 4:3): Check what the pixel ratio is: if it’s 0.9 – its 4:3, if it’s 1.2, it’s widescreen
Some good flv sizes for old 4:3 are:
640×480
512×384
480×320
320×240
If your input is:
1920×1080 (16:9 wide-screen/HD)
Some good flv sizes are:
1280×720 (also another source video size)
854×480
768×432
640×360
512×288
320×180
256×144 (why so small?)
It is important too that your FLV player matches these dimensions or fits one of them (bigger or smaller) to look good. If you are not playing a video back at native resolution (and usually you are not due to BW constraints), test out video smoothing to see if the result is worth the extra CPU load. I usually drop from 30fps to 24fps for a film look and use the same bandwidth to get more detail into each frame (or interframe etc)
As for non square pixels? This is assuming square pixels, simple as that. Many HD cams and formats meet the letter of the law by having 1080p or or some other marketing number in the specs, but then skimp on the number of horizontal pixels (say 1440), so put simply, do a few second test render in your pipeline when dealing with new footage before commiting a bunch of video to rendering and compression and committing yourself to waiting….and waiting only to see things are not as you would have hoped.
More on video formats like h.264, On2, and Sorrenson can be found in this post
Jufa 