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

[Michael Niedermayer]

On Thu, Feb 26, 2009 at 05:54:15PM -0800, Roman V. Shaposhnik wrote:
> Hi Michael,
> 
> thanks for replying!
> 
> On Thu, 2009-02-26 at 22:36 +0100, Michael Niedermayer wrote:
> > > As you can see -- almost all of the errors are now in 1 range. 
> > > 
> > > But! Is there a way we can do better?
> > > 
> > > My division-foo is weak today, so any kind of suggestions will be appreciated.
> > 
> > the best table is not neccessarily the one that is closest to the inverse
> > but the one that generates the best PSNR at a specific bitrate
> 
> 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

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.


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)
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 ...)


> 
> > 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?

and i definitly recommand foreman over rotozoom


[....]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090227/27e98a8e/attachment.pgp>