1pass RC in x264

[akupenguin]

I don't expect b-adapt to reduce overflows, I expect it to increase quality at a given bitrate. Because quality is what you actually want, overflows are just signs that quality could be improved a little more.

[chen]

Because quality is what you actually want, overflows are just signs that quality could be improved a little more.
Maybe there is sort of a misunderstanding. The decoder buffer mentioned above is the real buffer of the decoder instead of the VBV, and the overflow of the decoder buffer results indeed in loss of data, which cannot be simply ignored.
As for the relationship between overflows and quality improvement, i would like to share with you my opinion which is rather contrary to yours. To begin with, we go back to my previous question on CBR about how constant the bitrate can be. x264 CBR ratecontrol algo does not provide a strictly constant bitrate, but only a local average close to the target bitrate, which may under certain circumstances lead to rather different number of bits between frames. It is exactly this non-constancy in bitrate that results in an decoder buffer overflow. In other words, to avoid overflows, we need to achieve a better constant bitrate, which probably leads to a worse quality, given the tradeoff between the bitrate constancy and the video quality. If you understand what i am getting at, you will find that overflows does not simply boils down to signs of the possibility of improving quaility. If you still hold you point, i would appreciate a better explanation, especially about how to improve the video quality when an overflow occurs.

[akupenguin]

If the decoder's buffer overflows, then the server is sending data too fast. This is an error in the streaming software, not in the codec. Maybe it's sending data at CBR even when x264 doesn't use the full requested bitrate.

I maintain that the goal of CBR ratecontrol is to maximize quality given some bandwidth contraints (modelled by VBV) , and that maximization usually occurs by varying bitrate at much as possible within the constraints.

If x264's CBR is not constant enough, then use a smaller VBV buffer. If that increases over/underflows then my bitrate prediction could be improved. But the only case where you would ever want all frames exactly the same size is if you require a transmission/decode delay of only 1 frame. That might be the case for videoconferencing. I can't think of any other application.

[rbt01]

what's the rceq mean?
Ratecontrol equation or q of rce?
in ratecontrol.c, it's defined:
double last_rceq;
It's a float number, so I guest it is not equation of rc but it is q of rce.

[rbt01]

static double predict_size( predictor_t *p, double q, double var )
{
return p->coeff*var / (q*p->count);
}

why *p->count?


〉〉〉
I got it.
p->coeff is the sum of coeff of all the past frames.