[x264-devel] Need help to understand a piece of code

[Lingjiang Fang]

The code below puzzled me for a long time, can any give an explanation
for it ?

ratecontrol.c -> clip_qscale()
        /* Check B-frame complexity, and use up any bits that would
         * overflow before the next P-frame. */
        if( h->sh.i_type == SLICE_TYPE_P && !rcc->single_frame_vbv )
        {
            int nb = rcc->bframes;
            double bits = predict_size( &rcc->pred[h->sh.i_type], q,
rcc->last_satd ); double pbbits = bits;
            double bbits = predict_size( rcc->pred_b_from_p, q *
h->param.rc.f_pb_factor, rcc->last_satd ); double space;
            double bframe_cpb_duration = 0;
            double minigop_cpb_duration;
            for( int i = 0; i < nb; i++ )
                bframe_cpb_duration +=
h->fenc->f_planned_cpb_duration[i];

	    // !!! why we ignore bbits under this condition?
            if( bbits * nb > bframe_cpb_duration * rcc->vbv_max_rate )
                nb = 0;
            pbbits += nb * bbits;

            minigop_cpb_duration = bframe_cpb_duration +
            fenc_cpb_duration; 
	    space = rcc->buffer_fill +
            minigop_cpb_duration*rcc->vbv_max_rate - rcc->buffer_size;
            if( pbbits < space ) {
                q *= X264_MAX( pbbits / space, bits / (0.5 *
            rcc->buffer_size) ); }
            q = X264_MAX( q0/2, q );
        }

I think this code want to solve the vbv overflow after
the current miniGOP, space is the predicted overflow size if there is
no consumption. 
But if we discard the cost of bbits, it means we tend
to decrease q and leak more bits from vbv buffer, won't it leads to vbv
underflow?