x264 qcomp (2pass VBR)

1 qcomp (quant curve compression)

Rate-Control Equation (RCEQ)

 

RCEQ建立了一种运动复杂度（MV+ Texture）到量化步长的映射模型。其中complexity表示运动复杂度，实际实现中由编码所需的比特数表示

 

1.1 --qcomp

qcomp（0<=qcomp<=1）由用户指定，用于调节比特率在不同帧中的分布：

• 较小的qcomp偏向于CBR。因为此时qscale随complexity增长明显。高运动高qscale低码率，即抑制比特率在高运动帧中的分布。
• 较大的qcomp偏向于CQP。因为此时qscale随complexity增长不明显。qscale在所有帧中趋同，高运动高比特率。

 

1.2 rate_factor的确定（搜索）

rate_factor用于使qcomp调整过的预测码率（expected_bits）趋近用户设置的目标码率（all_available_bits）。即Loren Merritt所说的” Scale the results of (1) to fill the requested total size”。实际实现中rate_factor由迭代搜索得到：

search rate_factor that got minimum_abs(all_expected_bits - all_available_bits)
{
    gaven a certain rate_factor:

    for i in (0 -> nframes)
    {
        // get_qscale() using RCEQ
        new_qscale[i] = complexity[i]^(1-qcomp) / rate_factor;
        expected_bits[i] = qscale2bits(new_qscale[i]);
        all_expected_bits += expected_bits[i];
    }
}

1.3 --cplxblur & --qblur

为了防止QP的剧烈抖动，还可以在rate_factor确定之前分别对complexity和qscale进行高斯模糊

• --cplxblur指明了RCEQ前（rate_factor未确定）对complexity进行高斯模糊的filter_size, “fileter_size=2*cplxblur+1”
• --qblur指明了RCEQ后（rate_factor已确定）对qscale进行高斯模糊的filter_size，” filter_size = (int)(qblur*4) | 1”

 

2 example with “soccer_cif.yuv”

• $ x264 --threads 1 --bitrate 500 --no-mbtree --input-res 352x288 --pass 1 -o test.264 /c/Users/Jeff/Downloads/soccer_cif.yuv
• $ x264 --threads 1 --bitrate 500 --no-mbtree --input-res 352x288 --pass 2 --qcomp 0.2 -o test.264 /c/Users/Jeff/Downloads/soccer_cif.yuv
• $ x264 --threads 1 --bitrate 500 --no-mbtree --input-res 352x288 --pass 2 --qcomp 0.6 -o test.264 /c/Users/Jeff/Downloads/soccer_cif.yuv
• $ x264 --threads 1 --bitrate 500 --no-mbtree --input-res 352x288 --pass 2 --qcomp 0.9 -o test.264 /c/Users/Jeff/Downloads/soccer_cif.yuv

 

3 参考"X264/doc/ratecontroll.txt"

    2pass:

Given some data about each frame of a 1st pass (e.g. generated by 1pass ABR, below), we try to choose QPs to maximize quality while matching a specified total size. This is separated into 3 parts:

(1) Before starting the 2nd pass, select the relative number of bits to allocate between frames. This pays no attention to the total size of the encode. The default formula, empirically selected to balance between the 1st 2 theoretical points, is "complexity ** 0.6", where complexity is defined to be the bit size of the frame at a constant QP (estimated from the 1st pass).

(2) Scale the results of (1) to fill the requested total size. Optional: Impose VBV limitations. Due to nonlinearities in the frame size predictor and in VBV, this is an iterative process.

(3) Now start encoding. After each frame, update future QPs to compensate for mispredictions in size. If the 2nd pass is consistently off from the predicted size (usually because we use slower compression options than the 1st pass), then we multiply all future frames' qscales by the reciprocal of the error. Additionally, there is a short-term compensation to prevent us from deviating too far from the desired size near the beginning (when we don't have much data for the global compensation) and near the end (when global doesn't have time to react).