Divisible by 16 - the magic number!

yes 16 is a good number for computers.
To really simplify, digital video is encoded using 16x16 macroblocks (mostly)
For lots of tech talk fun, google "16x16 Macroblock".
But look out, some begin like this, and then get complicated:

+The simplest and most thorough way to perform motion estimation is to evaluate every possible 16x16 region in the search area, and select the best match. Typically, a "sum of absolute differences" (SAD) or "sum of squared differences" (SSD) computation is used to determine how closely a candidate 16x16 region matches a macro block. The SAD or SSD is often computed for the luminance plane only, but can also include the chrominance planes. But this approach can be overly demanding on processors: exhaustively searching an area of 48x24 pixels requires over 8 billion arithmetic operations per second at QVGA (640x480) video resolution and a frame rate of 30 frames per second.+

Be aware. If you choose a resolution which is not divisible by 16, 8 or 4, you might end up with a 1px green border at either bottom or right side of your frame. I have seen this problem with

"If the horizontal or vertical size is not divisible by 16, then the encoder pads the image with a suitable number of black "overhang" samples at the right edge or bottom edge. These samples are discarded upon decoding. For example when coding HDTV at 1920x1080, an encoder appends 8 rows of black pixels to ht eimage array, to make the row count 1088." -Charles Poynton ( http://tinyurl.com/5vby6x)

Maybe that green line I am talking about may show up if the player/codec have problems discarding those "overhang" samples on decoding?

If you really want the most efficient and best quality encoding, you should choose a frame size which is divisible by 16, or at least 8. Have a look here for more frame size suggestions: http://labs.influxis.com/?p=6 and http://labs.influxis.com/?p=30

Have you read this article before?
http://www.apple.com/quicktime/tutorials/h264.html

There are some guidelines there for frame sizes and bitrates, that you might want to have a look at. Keep in mind that the frame rate of your video also affects bitrate requirements. Robert Reinhardt (the guy I linked to in my last paragraph in my previous post) has made a great bitrate calculator for both Flash and AVC/H.264: http://www.adobe.com/devnet/flash/apps/flvbitratecalculator/ (remember to change the video codec setting to H.264, if that is your output format)

Have you tried activating frame controls in Compressor? That should give you better quality downscaling. If you would like to save some time, you could try this tip (same principle for downscaling): http://discussions.apple.com/message.jspa?messageID=7309534#7309534

Video compression, especially for web, is all about testing to find the optimal settings for best possible quality/filesize ratio. Remember that it will save you a lot of time doing some short 10-20 second tests (just set in/out points in the Compressor Preview window), before encoding everything.

Try changing your resoultion to either 1024x576 or 768x432 (or any other resolution divisible by 16, 8 or 4), activate frame controls, adjust the video bitrate according to frame size and frame rate, and see if the result looks better.

It might be that the version of of x264 that VisualHub uses, is a bit better than the H.264 codec Apple provides in QuickTime/Compressor (at the moment). I really do not know.

Have you tried DV Kitchen from DVcreators? That application have something they call SampleLab, which makes it very easy to test different video bitrates. You can also use x264: http://www.dvcreators.net/how-do-i-install-the-x264-codec-for-dv-kitchen/

I guess I would some what agree with Josh, that the human eye might not notice the difference. I would still recommend choosing a "safe" frame size though, just to make sure you do not get any strange artifacts (like green lines at the bottom or right side of your frame), and to make sure your video plays as smoothly as possible.

Also don't forget to deinterlace anything destined for the web.

When using VisualHub you must have already exported from FCP I assume? So thereby you have already gone through a compression unless you went out uncompressed?

As stated by others is really is a massive testing and tweaking world especially if you have action versus static content. The compression can also be modified by setting markers in the FCP timeline during certain action spots and so on.

I'm a big fan of VisualHub as well (now going opensource BTW) but usually if you are dealing with original source content if you can modify settings for compression there then you will have best results...it just take time, practive and a but of techno-magic.

Good Luck!