[FFmpeg-devel] [RFC] RV30 1/3pel MC functions

[Kostya]

On Thu, Jan 03, 2008 at 09:11:30PM +0100, Michael Niedermayer wrote:
> On Thu, Jan 03, 2008 at 02:09:15PM +0200, Kostya wrote:
> > On Wed, Jan 02, 2008 at 11:12:55PM +0100, Michael Niedermayer wrote:
> > > On Mon, Dec 31, 2007 at 09:17:59AM +0200, Kostya wrote:
> > > > On Wed, Dec 26, 2007 at 03:38:35AM +0100, Michael Niedermayer wrote:
> > > > > On Mon, Dec 24, 2007 at 01:04:00PM +0200, Kostya wrote:
> > > > > [...]
> > > > > > +        mx = (s->current_picture_ptr->motion_val[dir][mv_pos][0] + (3 << 24)) / 3 - (1 << 24);
> > > > > > +        my = (s->current_picture_ptr->motion_val[dir][mv_pos][1] + (3 << 24)) / 3 - (1 << 24);
> > > > > > +        lx = (s->current_picture_ptr->motion_val[dir][mv_pos][0] + (3 << 24)) % 3;
> > > > > > +        ly = (s->current_picture_ptr->motion_val[dir][mv_pos][1] + (3 << 24)) % 3;
> > > > > > +        dxy = ly*4 + lx;
> > > > > 
> > > > > > +        uvmx = chroma_coeffs[((s->current_picture_ptr->motion_val[dir][mv_pos][0] + (3 << 24)) >> 1) % 3];
> > > > > > +        uvmy = chroma_coeffs[((s->current_picture_ptr->motion_val[dir][mv_pos][0] + (3 << 24)) >> 1) % 3];
> > > > > 
> > > > > this is wrong ([0] vs. [1])
> > > > > also i think (3*(mx&1) + lx)>>1 could be used to avoid the %
> > > > 
> > > > Umm, it can't 
> > > 
> > > ohh yes it can, heres a test program with a simpler variant without the >>
> > [code skipped]
> > 
> > My test were flawed then. Sorry.
> >  
> > > > > [...]
> > > > > 
> > > > > > @@ -422,6 +422,10 @@
> > > > > >      void (*x8_setup_spatial_compensation)(uint8_t *src, uint8_t *dst, int linesize,
> > > > > >             int * range, int * sum,  int edges);
> > > > > >  
> > > > > > +    /* rv30 functions */
> > > > > > +    qpel_mc_func put_rv30_tpel_pixels_tab[4][16];
> > > > > > +    qpel_mc_func avg_rv30_tpel_pixels_tab[4][16];
> > > > > > +
> > > > > 
> > > > > this could be put under CONFIG_RV30_DECODER as well
> > > > 
> > > > I won't touch dsputil.* until decoder is fully integrated. 
> > > 
> > > well but the hunk above does change dsputil.h
> > 
> > Here it is without dsputil stuff.
> 
> it wont compile without it

In the current configuration it will not be compiled at all.
I plan to add those dsputil chunks along with decoder enablement.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB