zoukankan      html  css  js  c++  java
  • 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).

  • 相关阅读:
    javascript快速入门27--XSLT基础
    javascript快速入门26--XPath
    javascript快速入门25--浏览器中的XML
    javascript快速入门24--XML基础
    javascript快速入门23--XHR—XMLHttpRequest对象
    javascript快速入门22--Ajax简介
    javascript快速入门21--DOM总结
    redis里能不能针对set数据的每个member设置过期时间
    Java中的long类型和Long类型比较大小
    Long类型比较大小,long型和Long型区别
  • 原文地址:https://www.cnblogs.com/jogh/p/4967070.html
Copyright © 2011-2022 走看看