[XviD-devel] [TODOLIST ITEM] Bit rate controler module

Marc FD xvid-devel@xvid.org
Mon, 9 Dec 2002 14:13:19 +0100


hi ^^

since you're just doing the stuff, i've a request.
surrent vbr mode is, IMHO, not very flexible.
and the way bframes are handled is not very clean too.

i've got the following idea, say if it makes sense.

first, divide encoder_encode_bframes in 2 parts :
encoder_encode_bframes and encoder_scan.
the first one is a blind version of the encoder, you need to say him
everything (vop, quants, ect... all globals) and when you code
a iframe, you can give him vop based info.
the second version is based on syskin's MEanalysis. you request
info with a stats structure, and it'll fill the fields you need.
we can expand it to do various checks, even full ME if wanted.
the goal is to have estimations for the RC module to work with
(choose vops/quant/ect...)

the RC module will be updated 2 time per frame :
between scan and encode, and after encding.

RC module could be asked how many frames he wants to scan
in advance (for exemple, it would be max_bframes in current implementation)
for bframes, we'll of course need to support unsequential RC.

BTW, i don't understand why you speak of 2pass stats format. it's the task
of
the 2pass RC module, not of the api. all 2pass RCs can have a different
format.

i know the API will be harder to code this way, but RC is a crucial part of
encoding,
and there is not only 1pass ABR, 2pass VBR and 1pass const quantizer modes.
this way you can implement various RCs, like :
1pass hybrid 2pass, 3pass, 1/2pass cluster mode, ect...

i don't know if it possible, but if it's possible, we'll need to do it a
day, no ?

Regards,
MarcFD