[x264-devel] Re: comments is not consistent with source code.

jogging song joggingsong at gmail.com
Sun Apr 29 16:34:49 CEST 2007


Thanks for your kind reply, Loren

" Given that B-frames' QP are locked to an offset from the adjacent
   P-frames's QP (and that's optimal for compression), the way to modify
the"
why is that optimal?

Maybe I think I know how the vbv works. What confuses me is how to make good
use of vbv? In the x264, qscale is adjusted according to
vbv buffer state, is the way to adjust qscale the best way? Just as you said
in ratecontrol.txt, this is empirical. Can you improve that?
If we want to improve it, what can we change? the way to adjust qscale?
Ratecontrol equation?

Best Regards
Jogging


On 4/29/07, Loren Merritt <lorenm at u.washington.edu> wrote:
>
> On Sun, 29 Apr 2007, jogging song wrote:
>
> >  Now I am reading the source code of rate control in x264. The function
> > clip_qscale adjusts qscale according to vbv buffer state.
> > I find some comments are not consistent with source codes.
> > Here is the codes:
> >
> >       /* 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 )
> >       {
> >           int nb = rcc->bframes;
> >           double pbbits = bits;
> >           double bbits = predict_size( rcc->pred_b_from_p, q * h->
> > param.rc.f_pb_factor, rcc->last_satd );
> >           double space;
> >
> >           if( bbits > rcc->buffer_rate )
> >               nb = 0;
> >           pbbits += nb * bbits;
> >
> >           space = rcc->buffer_fill + (1+nb)*rcc->buffer_rate -
> > rcc->buffer_size;
> >           if( pbbits < space )
> >           {
> >               q *= X264_MAX( pbbits / space,
> >                              bits / (0.5 * rcc->buffer_size) );
> >           }
> >           q = X264_MAX( q0-5, q );
> >       }
> >
> > The comments tell us that the following codes adjust qscale for B
> slices.
> > But the codes are executed in the case the slice is P.
>
> The comment is correct. It doesn't say it adjusts the QP of the B-frames,
> it says it adjusts the QP of the P-frames to compensate for B-frames.
> Given that B-frames' QP are locked to an offset from the adjacent
> P-frames's QP (and that's optimal for compression), the way to modify the
> qscale for B-frames is to modify the adjacent P-frames.
>
> > I have one question. VBV buffer allows us to change the rate according
> the
> > content of current frame. But how do we make good use of vbv buffer?
> > What is the objective pf vbv buffer in rate control? Try to make it
> > full always?
>
> Before asking what x264 does with VBV, do you know what VBV means in
> general, as descibed in the MPEG-2 and H.264 standards and related docs?
> I don't feel up to explaining that.
>
> --Loren Merritt
>
> --
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070429/51493739/attachment.htm 


More information about the x264-devel mailing list