[XviD-devel] minor changes / todo list

[skal]

	Hi everybody,

On Tue, 2003-06-24 at 17:20, Michael Militzer wrote:
> 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  Hi,
> more important cause than
> faulty quantizer prediction).

	...reminds me of something i've been thinking about
	since long time: biases in the quantizer. 
	Ok, quant is integer. Roughly (h263) speaking you have
	a level quantized as: l' = (l+bias)/Q and reconstructed as
	l'' = l'*Q. Hence, the perfect bias should be Q/2, so that
	the reconstructed l'' is the closest available to the
	original level l, and yields the best PSNR of both worlds.

	But, one could imagine maximizing the PSNR for a particular
	block (or frame, say) is not what it's all about. Maybe
	lowering the bias will incur damage on the PSNR, but since
	it decreases the coded level by 1, the bits saved coding
	l'-1 instead of l' will later (next frame) be better used. 
	That's why one could image a decimal quantizer, where the
	integer part is the real Quant value, and the fractional one
	controls the bias... or the dead-zone (in this latter
	case, the fractional part control the amount of RUNs
	being coded). This seems to me like a poor's man
	rd-optimization almost free of computational burden.

	does it make sense?


	later,
			Skal


(ps: for additional considerations about the above, just have a look at:
http://skal.planet-d.net/coding/quantize.html
The conclusion is still not written, though :)