[XviD-devel] about rate control mechanism

Edouard Gomez xvid-devel@xvid.org
Thu, 16 Jan 2003 08:41:00 +0100 (CET)


En réponse à zhouxiao <janzx@163.com>:

> 
> Hi, everyone,
> Can someone tell me something about the rate control mechanism used in
> XviD ?

The included Rate Ccontroller is Constant Bitrate. If i wanted to be precise
I'd say it's a CBR/ABR (ABR==average bitrate)

> Now I am using XviD  to  encode the realtime scene collected by a 
> camera. 
> And I found that no matter how much the scene changes, the bitstream
> size for a fixed time interval is almost invariable. That is, If user
> specify the target bitrate is 900kbps, then, rate control can only
> maintain
> the real bitstream size approximately on the level of 900kbs .          

That's what we expect from a CBR rate controler :-)

The current (simplified) algorithm is not so complicated:
 1 - Compute how much bits would have been consumed if nframes were encoded
      at target bitrate exactly.
 2 - Compute how much we relly consumed.
 3 - (1) - (2) gives the number of bits for the next frame.
 4 - Supposing there's a linear relation between quantizer and frame size:
     Choose the appropriate quantizer

You're done. Of course the real algorithm is a bit more complicated because it
uses delays, and an internal parameter quality_scene in order to let frames
consume a bit more of bits sometimes and then will try to delay the loss of bits
... RC is very inytersting area :-)

> But maybe in some application, users could expect the real bitstream
> size can vary acording to the scenes' change, if the scene changes
> little, the bitrate is low, and if changes much, bitrate increases but
> cannot exceed 900kbps. That is, we need a rate adjusting mechanism which
> can ensure the real bitrate always under or on the level of target
> bitrate , not the rate control used in XviD which can only on the level
> of target bitrate.

This would be a completely different approach. We could achieve that looking at
Motion Estimation vectors. The more motion vectors of Inter blocks are close to
zero the less a frame could use bits. It's feasible but that's something
"Mr Joe" would use because it's a very quality damaging RC for common encodes.

In the hope that one day I finish the RC merge on my local working copy, then
such an RC could be included in XviD easily... but i hate saying that i'm laging
behind all developers :-(

--
Edouard Gomez - The man who hates reports