[FFmpeg-devel] inverse weighitng tables for DV seems to be wrong

[Roman V. Shaposhnik]

On Fri, 2009-02-27 at 03:51 +0100, Michael Niedermayer wrote:
> > I guess I'd be really glad if you can elaborate on this point. For DV,
> > at least, if there's no quantization involved than decoding is a 100%
> > inverse of the encoding weighting. If there's quantization things can
> > get a little bit less straightforward, but still.
> 
> of course, so you store all coefficients without quantization and the
> "ideal" weighting
> but you know this cant be done because there is a limit on the bits
> thus you are limited to store some approximation that needs less
> bits

True. But as far as weighting tables are concerned the only thing
that quantization really does is it changes the probability of level
distribution, right? In a sense that probability of some levels
get to 0 with some other increasing because that's where the missing
ones map now.

To restate -- the goal of designing optimal weighting/unweighting
tables seems to be to minimize the error on the most probable 
levels after the quantization. 

> the goal thus is to get the best quality within the limit of bits,
> trying to finetune tables is something rather easy to try ...
> this may or may not be good but you cant say what is good without
> considering both rate and distortion.
> Simply picking what minimizes distortion while ignoring rate is a
> waste of time.

Are you talking about the bit-rate for every single independent
mb within an overall fixed set of 5mbs?

> and instead of tuning tables, near optimal quantization is harder but possible
> too, and this will lead to significant gains (it does for other codecs ...)
> to do it
> the most obvious way would be to first apply the common RD trellis
> quantization to a group of 5mbs (there is IIRC no bit sharing
> possible acorss these 5mb groups)

There is. In DV all 5mb's share the common bit-space of a singel DIF
block.

> after this at least one of the blocks would hit one of the bit limits
> and its lambda would be fixed while the lambdas of the remaining blocks
> could be further decreased until they as well hit some limit.
> 
> 
> (and i think i should try to explain this again when iam less tired ...)

I think this will be an awesome blog post. It'll definitely help me 
a great deal, that's for sure.

> > > our tiny_psnr tool prints the PSNR and dv is constant bitrate so it should not
> > > be hard to find a good table by +-1 of one coeff and trial and error
> > 
> > tiny_psnr assumes that there's an image. What would your recommend? 
> > workman? rotozoom? something else?
> 
> workman?! you mean foreman?

Yeah ;-) I keep confusing my foremen with my workmen ;-)

> and i definitly recommand foreman over rotozoom

Sure, and I'll also try some of the images that I have. I just thought
that there's may be a canonical set of things to try when optimizing
these kinds of tables.

Thanks,
Roman.