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.
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:
If your input is:
1920×1080 (16:9 wide-screen/HD)
Some good flv sizes are:
1280×720 (also another source video size)
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.