P／Bフレームは予測の際に自分より前のフレームを参照フレームに使う。
H264/AVCでは直前よりも前のフレームを参照フレームに使う事ができる。
このオプションはその際、最大でどのくらい前のフレームを参照フレームとして使えるかを指定するもの。
アニメには効果的だが、実写では6程度を境に効果が急激に低下する。
デコードの速度には影響しないが、必要メモリ量が増える。
デコーダによっては最大15までしか受け付けない。
Number of reference frames
範囲：1 - 16
参照フレームの数を指定。
これにより、P/Bフレームの予測に使う参照フレームを、デコード済みフレームをさかのぼって選べるようになる（指定した枚数まで）。
高くすると一定ポイントまで圧縮効率があがる。これは原理的にアニメに非常に効果的だ。というのは、キャラクタが喋る時に口だけが同じような動きを繰り返してあとは変化しない場面、とか、風になびく髪のように同じ動きがループするような場面はよくあるから。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--ref
Usage: --ref <integer> (default=1) [1 - 16]
This is for setting the number of reference frames. It allows new P and B frames to be predicted by using a previously decoded frames (up to the number specified in --ref). Setting a higher value will increase efficiency up to a point. Naturally this is a very beneficial feature for anime since you often get many similar frames say for when a character is speaking and only the mouth is changing, or for loops where something is repeated like hair swaying in the wind.
http://www.marumo.ne.jp/db2007_7.htm#10
H.264 では、MPEG-1/2/4 までとは異なり、動き補償 (予測) の際に複数の参照フレームを利用することができる。x264 の --ref オプションでは、何枚のフレームを参照するかを指定するためのもの。
複数参照フレームが最も効果を発揮するのはフラッシュが多用されている映像。次に効果が出るのは背景の上で物体が動いてるような場合。直前フレームにはボールがあったけど、現在のフレームでは背景だけになっている部分。専門用語でこーゆーのを uncovered background (覆いがはずれた背景) とか呼ぶのだけど、これは複数参照フレームでさらに前のフレームを参照してしまえばよく似た部分が見つかる。
規格上、参照フレームはMB全体の他に8x8 サブブロック単位で別々の参照フレームを見ることもできる。--mixed-refs はその切り替えオプション。
フラッシュのシーンだけ救えれば十分だという場合は --mixed-refs を指定する必要はないだろうけど、uncovered backgroud を救いたい場合は --mixed-refs を指定した方がよいはず。MB の一部だけに差し掛かる物体の場合は 8x8 単位で別々の参照フレームを使えた方がより効率の良い符号化ができるはずなので。
まるも製作所：2007/07/15（日） x264 [15] --b-rdoより
--ref 1 # 参照フレームは 1 枚に制限 (マルチレフ無効)
framerefのデフォルトは1ですが、妥当な理由があるわけではありません。
・frameref=2にしただけでもPSNRは約0.15db向上し、5-15%の速度低下があります。これは良い取引だと思います。
・frameref=3ではPSNR向上は約0.25db（frameref=1に対して）、これは目で見て解る違いです。速度低下は約15%（これも frameref=1に対して）。残念ながら、ここから効果は急速に減少していきます。
・frameref=6のPSNRはframeref=3に対してたった0.05-0.1 dBくらいしか向上しません。一方、速度低下は約15%追加です。
・frameref=6より上となると画質向上は非常に僅かです（とはいえ素材次第で全く異なる事に注意して下さい）。一般論としては、frameref=12のPSNRはframeref=6に対してたった0.02dB、速度低下は約15-20%追加です。こうした大きなframeref指定について言えそうな事は「PSNRが下がる事はまず確実に無い、画質向上は計測できるギリギリで、目で見てわかるかどうか」くらいです。
ノート：
CABACオフの場合、不必要にframerefを高くすると符号化効率が落ちる可能性があり、実際、通常は落ちます。
CABACオンの場合（デフォルト）、いまのところframerefを「高くしすぎる」心配はしなくて良いようですが今後の開発の進捗で変わる可能性があります。
速度を考えて妥協するなら、subqとframerefを 1stパス では低く抑えて 2nd で上げるという手があります。一般的に最終的な画質低下は無視できる範囲におさまります。PSNRにして0.1dB 以下。これは目で見て解るには小さ過ぎます。しかし、1st と 2nd で frameref を変えると、フレームタイプの決定に影響が出る事があります。例外的なケースのようではありますが、確実を期すなら、素材映像にスクリーン全体を覆うフラッシング・パターンや、Iフレームが入りそうな非常に長いシーンの繰り返しが無いかを確認し、1stパスのframerefをフラッシュサイクルや繰り返しが入るくらいに大きくして下さい。例えば、3フレームに渡るフラッシュ有りとナシの繰り返しがあったら、1stパスのframerefを3以上に。実写素材では非常に稀なケースだと思いますが、ビデオゲームのキャプチャではよくあります。
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.