ageha was here

Fast first pass mode. During the first pass of a two or more pass
encode it is possible to gain speed by disabling some op-
tions with negligible or even no impact on the final pass output
quality.
Level 1 can increase first pass speed up to 2x with no change in
the global PSNR of the final pass compared to a full quality
first pass.
Level 2 can increase first pass speed up to 4x with about +/-
0.05dB change in the global PSNR of the final pass compared to a
full quality first pass.

http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html#menc-feat-x264-encoding-options-speedvquality

frameref is set to 1 by default, but this should not be taken to imply that it is reasonable to set it to 1. Merely raising frameref to 2 gains around 0.15dB PSNR with a 5-10% speed penalty; this seems like a good tradeoff. frameref=3 gains around 0.25dB PSNR over frameref=1, which should be a visible difference. frameref=3 is around 15% slower than frameref=1. Unfortunately, diminishing returns set in rapidly. frameref=6 can be expected to gain only 0.05-0.1 dB over frameref=3 at an additional 15% speed penalty. Above frameref=6, the quality gains are usually very small (although you should keep in mind throughout this whole discussion that it can vary quite a lot depending on your source). In a fairly typical case, frameref=12 will improve global PSNR by a tiny 0.02dB over frameref=6, at a speed cost of 15%-20%. At such high frameref values, the only really good thing that can be said is that increasing it even further will almost certainly never harm PSNR, but the additional quality benefits are barely even measurable, let alone perceptible.

Note:
Raising frameref to unnecessarily high values can and usually does hurt coding efficiency if you turn CABAC off. With CABAC on (the default behavior), the possibility of setting frameref “too high“ currently seems too remote to even worry about, and in the future, optimizations may remove the possibility altogether.

If you care about speed, a reasonable compromise is to use low subq and frameref values on the first pass, and then raise them on the second pass. Typically, this has a negligible negative effect on the final quality: You will probably lose well under 0.1dB PSNR, which should be much too small of a difference to see. However, different values of frameref can occasionally affect frametype decision. Most likely, these are rare outlying cases, but if you want to be pretty sure, consider whether your video has either fullscreen repetitive flashing patterns or very large temporary occlusions which might force an I-frame. Adjust the first-pass frameref so it is large enough to contain the duration of the flashing cycle (or occlusion). For example, if the scene flashes back and forth between two images over a duration of three frames, set the first pass frameref to 3 or higher. This issue is probably extremely rare in live action video material, but it does sometimes come up in video game captures.

1st	subq=1:frameref=1 
2nd	subq=6:frameref=15:partitions=all:me=umh 

Two pass encoding:
Above, it was suggested to always use two pass encoding, but there are still reasons for not using it. For instance, if you are capturing live TV and encoding in realtime, you are forced to use single-pass. Also, one pass is obviously faster than two passes; if you use the exact same set of options on both passes, two pass encoding is almost twice as slow.

Still, there are very good reasons for using two pass encoding. For one thing, single pass ratecontrol is not psychic, and it often makes unreasonable choices because it cannot see the big picture. For example, suppose you have a two minute long video consisting of two distinct halves. The first half is a very high-motion scene lasting 60 seconds which, in isolation, requires about 2500kbps in order to look decent. Immediately following it is a much less demanding 60-second scene that looks good at 300kbps. Suppose you ask for 1400kbps on the theory that this is enough to accomodate both scenes. Single pass ratecontrol will make a couple of “mistakes“ in such a case. First of all, it will target 1400kbps in both segments. The first segment may end up heavily overquantized, causing it to look unacceptably and unreasonably blocky. The second segment will be heavily underquantized; it may look perfect, but the bitrate cost of that perfection will be completely unreasonable. What is even harder to avoid is the problem at the transition between the two scenes. The first seconds of the low motion half will be hugely over-quantized, because the ratecontrol is still expecting the kind of bitrate requirements it met in the first half of the video. This “error period“ of heavily over-quantized low motion will look jarringly bad, and will actually use less than the 300kbps it would have taken to make it look decent. There are ways to mitigate the pitfalls of single-pass encoding, but they may tend to increase bitrate misprediction.

Multipass ratecontrol can offer huge advantages over a single pass. Using the statistics gathered from the first pass encode, the encoder can estimate, with reasonable accuracy, the “cost“ (in bits) of encoding any given frame, at any given quantizer. This allows for a much more rational, better planned allocation of bits between the expensive (high-motion) and cheap (low-motion) scenes. See qcomp below for some ideas on how to tweak this allocation to your liking.

Moreover, two passes need not take twice as long as one pass. You can tweak the options in the first pass for higher speed and lower quality. If you choose your options well, you can get a very fast first pass. The resulting quality in the second pass will be slightly lower because size prediction is less accurate, but the quality difference is normally much too small to be visible. Try, for example, adding subq=1:frameref=1 to the first pass x264encopts. Then, on the second pass, use slower, higher-quality options: subq=6:frameref=15:partitions=all:me=umh