[XviD-devel] minor changes / todo list

[skal]

	Hi Marco

On Tue, 2003-06-24 at 23:20, Marco Al wrote:
> From: "skal" <skal at planet-d.net>
> 
> > 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.
> 
> I dont think it unlikely that the level adaption this method supplies is
> mostly inconsequential, and maybe even counterproductive in a R-D
> sense, and most of the gain comes from the increased deadzone ...
> 
	do you have some papers / refs about this? (of is it just
	a feeling?)

> Even if you want very low overhead there are smarter ways to adapt
> the deadzone I think (but Id have to think a lot harder to come up
> with one :).
> 
	the simplest i can think of is using retroactive feedback
	(statistics) for mapping the effect of "widening the dead-zone
	that much saved me that amount of bits and trashed the PSNR by
	that amount". It's usually the solution when one don't have a
	better solution. "Let the system adapt!". :)

> How much faster could the trellis search be done if you only allowed
> zeroing of coefficients BTW?

	Not much, i fear: the speed-up would scale with the number
	of coeffs not equal to -1,0 or 1. So it depends on the
	quantizer. Trellis quant originally scales with the squared
	number of coeffs to examine, the most interesting ones
	being the near-zero ones. Hence, in practice, it rather
	scales as the square of such near-zero coeffs. The other
	"big" coeffs usually act as "barriers" for the RUN cost
	backward evaluation, since they have no chance of being zeroed.


	later,
		Skal