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

Dan Maas dmaas
Sat Feb 25 21:18:01 CET 2006


The attached (very small) patch improves image quality from ffmpeg's
DV encoder, increasing PSNR by about 3dB on the BBC's test footage.

If you do an A/B comparison, you'll see less DCT quantization
artifacting on frames produced using this patch.

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.

Here is a full explanation:

Table 22 on page 41 of SMPTE 314M ("An example of the classification
for reference [sic]") proposes a method for selecting class numbers. A
class number biases a particular DCT block towards more or less lossy
quantization. It's a way of saying, "I think this block will need
more/less lossy quantization in order to fit its bitstream into the
available space." The class number is not the final word on
quantization; it is an additive bias that is taken into account when
determining the actual macroblock quantization level.

The table in SMPTE 314M is merely a suggestion. A DV encoder is free
to assign class numbers by any method it chooses.

The original author of the ffmpeg encoder implemented class number
selection according to the table. During my earlier work on the
encoder, I discovered that this method is too conservative. It assures
that the majority of DCT blocks will be subject to significant lossy
quantization, even when there is enough space in the bitstream to use
little or no quantization.

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 believe that the SMPTE 314M table is so conservative because it is
intended for resource-constrained codecs that don't track AC bit
consumption as accurately as ffmpeg. For a resource-constrained codec,
it is more important to err on the side of safety, to avoid
accidentally under-quantizing a block and overflowing the available
number of bits. ffmpeg's accurate bit tracking ensures that this never
happens. So, there is no need to be so conservative.

Tweaking class number selection makes a very significant difference in
image quality. If you compare images compressed with both techniques,
you'll see a substantial reduction in DCT quantization artifacts with
my new method.

Regards,
Dan
-------------- next part --------------
Index: libavcodec/dv.c
===================================================================
RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/dv.c,v
retrieving revision 1.75
diff -u -p -r1.75 dv.c
--- libavcodec/dv.c	24 Feb 2006 09:16:26 -0000	1.75
+++ libavcodec/dv.c	25 Feb 2006 20:10:37 -0000
@@ -651,7 +651,6 @@ static always_inline void dv_set_class_n
                                               const uint8_t* zigzag_scan, int bias)
 {
     int i, area;
-    static const int classes[] = {12, 24, 36, 0xffff};
     int max=12;
     int prev=0;
 
@@ -674,9 +673,11 @@ static always_inline void dv_set_class_n
        }
     }
     bi->next[prev]= i;
-    for(bi->cno = 0; max > classes[bi->cno]; bi->cno++);
 
-    bi->cno += bias;
+    if (max > 255)
+        bi->cno = 3;
+    else
+        bi->cno = 2+bias;
 
     if (bi->cno >= 3) {
         bi->cno = 3;



More information about the ffmpeg-devel mailing list