[FFmpeg-devel] Concerning RV40 chroma MC functions

[Michael Niedermayer]

On Tue, Nov 25, 2008 at 01:07:02PM +0200, Kostya wrote:
> As you may know, RV40 chroma MC functions look a lot like H.264, they use
> the same formula
> dst[i] = (A*src[i] + B*src[i+1] + C*src[i+stride] + D*src[i+stride+1] + bias)>>6
> 
> the problem is that while A,B,C and D are calculated in the same manner,
> bias value is constant for H.264 and varies for RV40:
> 
> (H and V are 1/4pel fractions)
> 
> H,V ->  A  B  C  D bias
> 0,0 -> 64  0  0  0  0 (any value <=32 should fit, I suppose)
> 1,0 -> 48 16  0  0 16
> 2,0 -> 32 32  0  0 32
> 3,0 -> 16 48  0  0 16
> 0,1 -> 48  0 16  0 32
> 0,2 -> 32  0 32  0  0 (any value <= 16 should fit, I think)
> 0,3 -> 16  0 48  0 32
> 1,1 -> 36 12 12  4 28
> 2,1 -> 24 24  8  8 32
> 3,1 -> 12 36  4 12 28
> 1,2 -> 24  8 24  8 32
> 2,2 -> 16 16 16 16 16
> 3,2 ->  8 24  8 24 32
> 1,3 -> 12  4 36 12 28
> 2,3 ->  8  8 24 24 32
> 3,3 ->  4 12 12 36 28

 0 16 32 16
32 28 32 28
 0 32 16 32
32 28 32 28


> 
> Now the questions:
> * how can one calculate that bias value?

table


> * what is the best way to incorporate those functions into lavc?

the variant in your future patch after a few dozen rounds ;)
no i really dont know
if this can be merged in the h264 code with _NO_ performance loss then
thats a good idea, if not id just write a naive and small C implementation
and use h264 mc when flag fast is set


> * should RV40 designers burn in hell?

yes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081125/01053e00/attachment.pgp>