[XviD-devel] Hadamard Transform

[Christoph Lampert]

On Fri, 6 Sep 2002, Marco Al wrote:
> peter ross wrote:
> 
> >> More seriously, whenever you need the real ASM 1D/2D code
> >> (not the C-like one I sent before), just tell me...
> >> I'll take time to finish it for good...
> >
> > imho development should always work like this:
> > 1. propose idea, discuss design
> > 2. implement in c, do some testing to decide if its really needed
> > 3. implement in asm

Yes, this is the right way, of course. But on the other hand, it's a nice
application to "practice" one's ASM skills, since it's not too complex.

We should see this "discussion" as "unrelated to XVID", only as "some
coders' fun", okay? 

> Since the steps were skipped anyway, and you now have asm implementations 
> could someone benchmark it against the DCT now? (Working from cache.)
> 
> Personally I dont see it the hadamard transform making much sense in software
> with the amount of mode decisions in MPEG-4. AFAICS the number of DCT 
> transforms needed if you wanted to make the intra and 4v mode decisions
> in the DCT domain would only take a couple of percent of running time if
> those DCTs could all work from cache. In reality it will be slower of 
> course, but the reasons behind that have nothing to do with the arithmetic 
> of the transform and will hit you just as
> hard with the hadamard transform so it's of no concern.

That might be. But Hadamard made it into H.26L for mode decision, and
since the encoder is free in which method to choose, I wanted to test it. 
_If_ the approximation is good and fast, other areas come to
mind: Adaptive quantization, preprocessing, SKIP detection. All the places
where DCT would be useful, but is too slow.

gruel