[XviD-devel] [TODOLIST ITEM] Bit rate controler module
Marco Al
xvid-devel@xvid.org
Thu, 12 Dec 2002 21:54:06 +0100
Dirk Knop wrote:
> I'd like to see such a "scientific" approach as well, but that's
> impossible to do. It's very simple to explain why it can't work:
> - lumi masking
> - bframe quantization formula
Id like to see quantizer selection (wether it be for P-frame or B-frame is
pretty much irrelevant) and adaptive quantization be steered by quality rather
than rate goals (MSE with masking based on texture and motion should work well
enough, refdivx's measures might work too). That quantizer does not equal
quality is pretty obvious, the b-frame quantization rule is just an extra
reminder.
So you (in case of one pass coding) or rate control would give a quality for a
frame, then the encoder would make a guess at the necessary global quantizer
from a coefficient histogram (using the p-domain method) and adaptive
quantization would clean it up on a per MB scale.
> - qpel
Not an issue, will almost always be used.
> You'd need exactly the knowledge which options were used on first pass.
> Thenm you'd need the knowledge of the effect each option has on each
> frame/bitrate (here we have to go into detail: how do you want to
> determine how big a frame will be at quant4 for example? With qpel, and
> -tadaa- with lumi masking?).
I wouldnt be surprised if by using a classifier partly based on the masking
values in the first pass and p-domain statistics for each corresponding class
you could find a way to accurate predict rate and distortion even with adaptive
quantization.
> I just try to explain that the complexity of the codec is too high
Some people dont mind waiting.
> thus
> we can't use a scientific, precise approach - leaky bucket is the only
> way to go.
The leaky bucket isnt under discussion, it's unavoidable :)
Marco