[Ffmpeg-devel] [PATCH] DV image quality improvement

[Roman Shaposhnik]

On Sat, Feb 25, 2006 at 03:18:01PM -0500, Dan Maas wrote:
> The attached (very small) patch improves image quality from ffmpeg's
> DV encoder, increasing PSNR by about 3dB on the BBC's test footage.
  
  It is so nice to see a steady stream of nice patches coming from
  you, especially when my personal spare time is progressively
  approaching 0. I'm really looking forward to the DVCPRO HD patches!
 
> Basically, this patch disables the extra lossy quantization called for
> by the suggested class assignment method in SMPTE 314M. The SMPTE
> method is too conservative; it wasn't designed for encoders like
> ffmpeg that track AC bit consumption accurately.
 
  I have nothing against having this alternative method for assigning 
  class numbers, but I would like to 
  suggest one thing: could you, please, make it easy to switch 
  between the two versions of how classes are assigned ? 
  Something along the lines of putting the code into two separate
  always_inline functions (one for SMPTE version, and the other
  onve for your code) or simply #ifdef'ing would be just fine.
  Of course, an explanation of what's going on in the comment section will
  help a gread deal too (as would and updating regression tests ;-)). 

> The original author of the ffmpeg encoder 

  ;-) You can call me Roman

> ffmpeg's encoder is unique in that it tracks AC bit consumption very
> precisely - it always knows how much space it will take to store a DCT
> block at a given quantization level, down to the very last
> bit. Therefore it makes no sense to apply a premature bias towards
> strong lossy quantization. ffmpeg will only apply just as much lossy
> quantization as is necessary to fit the available number of bits.
  
  I completely agree with you here. In fact, when I was developing DV encoder 
  the quantization step table (on page 37) made me very puzzled. It is quite
  obvious to anyone that having just two class numbers 2 and 3 is enough
  to cover *all* possible cases of quantization -- yet they waste an
  additional bit for 0 and 1. At the time I simply decided that there
  had to be a reason (like hardware compatibility) for that and blindly
  followed the suggested classification algorithm. That's why I still
  want to have the suggested code around even though your suggested 
  optimization makes total sense.

Thanks,
Roman.

P.S. In fact, if somebody explains (or shall I say convinces me) that they
did not really have to have classes 0 and 1 we might get rid of them completely
and always assume 2 or 3 which would lead to a couple of optimization
opportunities.