[XviD-devel] Re: XviD-devel digest, Vol 1 #269 - 5 msgs

[zhouxiao]

Hi, Edouard Gomez, thanks for your reply.

Another question is:
  If I want use a VBR algorithm to replace the CBR of XviD encoder, Can you introduce me some effective alogorithms?  My goal is to do a realtime MPEG4 encoder wich can compress video at very low compression ratio on the precondition of certain quality.
  As I know, DivX seems to use the SRC scheme mentioned in MPEG-4 VM. 
  But I cannot find which algorithm is used in FFMPEG.

zxjan           

 
>> 
>> 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
>