[Ffmpeg-devel] [PATCH] DV image quality improvement
Mon Feb 27 14:15:46 CET 2006
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.
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
More information about the ffmpeg-devel