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

Michael Niedermayer michaelni
Wed Jan 2 23:12:55 CET 2008


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 >>

-----
static const int chroma_coeffs2[6] = { 8, 8, 5, 5, 3, 3};

main(){
    int v;
    for(v=-10000; v<10000; v++){
        int mx = (v + (3 << 24)) / 3 - (1 << 24);
        int lx = (v + (3 << 24)) % 3;

        int uvmx = chroma_coeffs[((v + (3 << 24)) >> 1) % 3];

        int uvmx2= chroma_coeffs2[3*(mx&1) + lx];

        if(uvmx != uvmx2)
            printf("%d %d %d %d %d\n", v, mx, lx, uvmx, uvmx2);
    }
}
-----


>  
> > [...]
> > 
> > > @@ -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

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/20080102/df0322a6/attachment.pgp>



More information about the ffmpeg-devel mailing list