For me, I'm turning my 3D Blurays into side-by-side mp4s at 540x960. This is the format in which I'm assuming the device records video, so it should be able to play it this way. Maybe I'll ask the Wirefly guy on youtube about the format of the video sample he showed.
EDIT: Forgot to mention that I'm doing it at that resolution because I don't want to waste space on my SD card and I don't really plan on sharing the video with an external display.
"Format" means a lot more than many people might think it does. For instance, it's possible to put hundreds of entirely different video standards of identical framerates and resolutions into an .avi file (the extension of a media file denotes only the
container into which the 'formats' are packed). Although there is some popularity bias among formats (AVI today is almost expected to contain MPEG-4-ASP with no QPel or GMC -- the likes of old 'default' Xvid/DivX encodes), this largely holds true nevertheless.
Resolution and framerate are only a small part of the puzzle (you should always aim to preserve native framerate, by the way -- 'real' native framerate, however, for telecined sources and the like, might be harder to attain than one might think).
Currently, the most modern and usable of the popular video standards (and that supporting the greatest amount of compression yet also enjoying hardware accelerated playback on mobile devices) is level-restricted 8-bit YV12-colorspace h.264/AVC in either the MP4 or MKV containers. But that's still just as ambiguous as saying "the most popular article of clothing to wear is a pair of pants," since although you've identified the general type of clothing, you still say nothing about the pants themselves -- what material, color, garment style, length, thickness, fastening design, etc.
It's good to know these things when creating your own encodes. When you make a pair of winter pants for your 8-yr old daughter, you wouldn't take two 3-meter rolls of dried leaves tied to a paper-mache basket and still deem it a suitable pair for the occasion. Maybe in some bygone primordial era this was the best you could do (if you could cram her into such a contraption), but today it's both silly and wasteful to do so in the presence of much more suitable possibilities of higher quality and better fit.
Using a stock 'iPod' preset has been a bit silly with Android devices for some time now. Most software that caters to the "iPod" use very, very poor encoding features by Android's standards. Baseline (notice the word here, "baseline") h.264 with vastly sub-par CUDA/x264/Nero/DivXHD encoder presets represents a very limited (and therefore significantly lower-quality) subset of the potential of the very same underlying h.264 'format' being used.
Ideally, then, one should seek to encode their files to the greatest level of encoding complexity their mobile device supports in order to avoid wasting significantly more space on potentially lower quality output video. When done correctly, encoding even 720p content at this complexity limit would result in truly versatile files you can keep on your computer, share with friends (be careful to observe copyright restrictions), display on a larger screen via HDMI/MHL, or simply play back in high quality on the device and its own qHD screen (recall that this native resolution is so high already that 720p videos are only 33.3% larger in each direction anyway).