[XviD-devel] minor changes / todo list

Michael Militzer michael at xvid.org
Tue Jun 24 18:20:02 CEST 2003


Hi,

Quoting "Hans K. Rosbach" <hk at circlestorm.org>:

> > on a simular matter, i experimented with some "3rd pass" encoding
> sessions,
> > where the third pass uses "quant-length" data collected from the 1st and
> > 2nd pass to increase desired frame size accuracy.
> > in my tests it works quite well (frame overflow decrease by upto 50%),
> > however there doesnt seem to be much noticble visible improvement.
> > more testing is neccessary.
> 
> Just a thought here..
> 
> Overflow and Underflow occurs due to a faulty estimation of what the
> framesize will be at a specific quant, right?

no, not only. Sure, often the predicted frame quant turns out not being
the optimal one which leads to over- or underflow (so your observation is
correct here). However often, there is no perfect quant value: This means
that there exists no frame quant value that would exactly meet a desired
frame size (because frame quants are integer values). This as well leads
to over- and underflow (and is maybe an even more important cause than
faulty quantizer prediction).

> If so, would it not be a good option to allow re-encode a specific number
> of times? Example
> 
> //Encode frame with the estimated quant
> frame = encodeframe( estimatedquant );
> 
> //Check size, if too big then re-encode with a higher quant
> if (checksize(frame) > (estimatedsize + allowedoverflow)){
>     frame = encodeframe( estimatedquant + 1 );
> }
> 
> //Check size, if too small then re-encode with a lower quant
> if (checksize(frame) < (estimatedsize - allowedunderflow)){
>     frame = encodeframe( estimatedquant -1 );
> }

Requires several passes = slow. This solution does only adress wrong frame
quant prediction but not the problem that there often exists no perfect
quant value. Therefore over- and underflow will still occur.
  
> Of course, this is just code to illustrate my point. More "AI" is needed,
> and allowing for further attempts as to archive the wanted size.
> This would in effect be faster and more easy to use than a 3'rd pass, due to
> not needing to do a lot of other stuff all over again. Of course this does
> not allow for further advantages that might be archived by using another 
> pass, but it would allow much higher precicion.

yes, this scheme does not allow manual tweaking of the 2pass bit
distribution which we consider the most important benefit from a third-
pass. The decreased over- and underflow problems are just a nice side
effect.

Your idea might not even be faster than three passes, simply because it's
very unlikely that we exactly reach the desired framesize even with the
best possible quant value. So when following the rules of your code example,
it's seems most probable that every frame is encoded twice which is no real
improvement compared to a third-pass ;-)

> I hope someone likes it, I sure would use this option if available.

It could be helpful if we add a threshold to your idea and only reencode
a frame if we horribly missed the desired frame size. I just wonder how
frequently this happens (hopefully just very seldom). In this case the slow
down wouldn't be severe but also the benefit might be questionable...

bye,
Michael


More information about the XviD-devel mailing list