[Ffmpeg-devel] [PATCH] DV image quality improvement (original) (raw)

Roman Shaposhnik Roman.Shaposhnick
Mon Feb 27 14:15:46 CET 2006

On Sat, Feb 25, 2006 at 03🔞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.

More information about the ffmpeg-devel mailing list