[FFmpeg-devel] inverse weighitng tables for DV seems to be wrong
Roman V. Shaposhnik
Sat Feb 28 02:49:57 CET 2009
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
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
> 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.
More information about the ffmpeg-devel