[XviD-devel] Quality optimization

[Christoph Lampert]

On Wed, 22 Jan 2003, Marco Al wrote:
> Christoph Lampert wrote:
> 
> > b) Using SAD of Hadamard-transformed blocks instead of ordinary
> > SAD for _subpixel_ resolution refinement (not for ordinary search!)
> > can also increase PSNR significantly (though not for anime).
> 
> Do we have some timings for a 8 bit Hadamard transform yet?

I did some a while ago of skal's MMXEXT(?) version and posted them to
the list. I don't remember, but might have been twice the speed of DCT,
but half the speed of SAD. 

> Since you are shooting for quality how about simply using the DCT and
> constructing a special LUT to do fast exact #bits calculations? (Without needing
> the actual codewords or work on the bitstream it can be done a lot faster.)

Quality yes, but at a reasonable speed. Poll at xvid.org showed that
hardly anyone is willing to go below 5 fps per GHz. I guess half the speed
of current XVID would be "acceptable", but not much less. Since QPel and
GMC are also candidates for slowing everything down, compromises have to
be made. 

> Using simply SAD in the transform domain still fails to take into account the
> damage high frequency components do to bitrate, so it would still be far from
> optimal. Also why only allow it for the subpel search? Why not allow a full pel
> refinement step using it too?

Because we don't use fullsearch, so the error measure has to be very
smooth in order to support gradient decent. Tests with ffmpeg show that 
using other measurement that SAD often is not really beneficial for
fullpel, most likely because error landscapes have many local minima (it's
know that "number of bits needed" is not good for gradient decent,
because it gets trapped very early). Subpel search is kind of
"fullsearch", all neighbouring positions are visited, and the current
fullpel one should of course be included. 

Also, it's speed again. There are 4 halfpel or 8 halfpel positions per
macroblock to be visited, but in some cases a hundred or more fullpel
positions. 
 
>  A low complexity alternative to SAD_hadamard which I wouldnt be
> surprised to see outperform it is the summed SAD in horizontally and vertically
> Sobel filtered images.

Sure, as many as possible, then we can choose the best. For speed btw. I
don't know, Skal's version is very fast, but for quality, it would be
interesting. 

gruel