[x264-devel] Re: May I have some resources about RC module in x264

[Loren Merritt]

On Fri, 16 Mar 2007, L.Guo wrote:

> 1262    double abr_buffer = 2 * rcc->rate_tolerance * rcc->bitrate;
>        /* 1pass ABR */
>        /* RC method is not CRF */
> 1320    wanted_bits = i_frame_done * rcc->bitrate / rcc->fps;
> 1321    if( wanted_bits > 0 )
> 1322    {
> 1323        abr_buffer *= X264_MAX( 1, sqrt(i_frame_done/25) );
> 1324        overflow = x264_clip3f( 1.0 + (total_bits - wanted_bits) / abr_buffer,
>                                    .5, 2 );
> 1325        q *= overflow;
> 1326    }
>
> In my mind, i_frame_done div 25 means a time of just coded frames. Which 
> multiplies abr_buffer's init value, a balance value of bitrate tolerance, 
> should means a reference buffer size. If so, why here uses the sqrt() ?

If you omit the abr_buffer code entirely (--ratetol inf), the resulting 
bitrate may vary a lot, but it will still average near the target bitrate.
In order for a given value of --ratetol to end up at a constant point on
the bitrate-precision-vs-quality curve regardless of the length of the
video, the buffer constraint imposed by ratetol must be proportional to
that natural variation.
The Law of Large Numbers says that if you take the sum of N independent 
random variables, the variation in the sum is proportional to sqrt(N). In 
this case each random variable is the difference between the real and 
predicted sizes of one frame. So the total variation is
sqrt(number of frames).
Ideally N would be the total number of frames, but x264 doesn't depend on 
knowing the total number in advance, so it counts only frames so far.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html