[XviD-devel] GMC update

[Christoph Lampert]

On Thu, 2 Jan 2003, Marco Al wrote:

> Christoph Lampert wrote:
> 
> > Btw. creating the transformed image is integer-only again, but it's really
> > ugly "ISO standard"ish code:
> 
> Why not jack FFMPEG's code? It seems to come from one of the reference
> implementations rather than the standard, it has a more sane incremental
> implementation. It is LGPL so you can relicense it to GPL.

ffmpeg does not encode, so we could just reuse compensation. 
Actually, the routines themselves are not so much of a problem, they are
ugly in ffmpeg as well, because it's simply the algorithm that is ugly.

I wanted to first create a version which is as straight as possible so
other people might read it, understand the "idea" and convert to ASM. 
We can do speedup later... 


> > (so global motion is 16th-pel resolution and is bilinearily interpolated)
> 
> Isnt the resolution variable?

Yes, but I can't see any reason to choose lower values. 
It's won't become simpler or faster... but I couldn't check quality, of
course... 



> > Any ideas how to speed this stuff up, maybe even MMX?
> 
> If anyone wants to do it they might want to consider asking Andreas Dehnhardt
> for his thesis, he implemented on a 64 bit SIMD processor (which is bound to be
> pretty close to MMX). There is an old version on his website which only explains
> the process of GMC and analyzes the incremental version of GMC from the
> reference code, but it lacks any of the conversion to SIMD :
> 
> http://www.stud.uni-hannover.de/user/73346/StA-Dehnhardt.pdf


Yes, I have a copy of the season somewhere but thanks for mentioning it.
It looks helpful (at least for the german speaking part of the world ;-)
His method might help to SIMD the whole stuff, even though GMC is pixel-
and not block-based. 

gruel