[FFmpeg-devel] [PATCH][RFC] Indeo3 replacement

Michael Niedermayer michaelni
Sat Aug 1 03:50:07 CEST 2009


On Fri, Jul 31, 2009 at 01:28:21PM +0200, Maxim wrote:
> Michael Niedermayer schrieb:
> > On Mon, Jul 27, 2009 at 05:28:07PM +0200, Maxim wrote:
> >   
> >> Michael Niedermayer schrieb:
> >>     
> >>>>     /* setup output and reference pointers */
> >>>>     dst = &plane->pixels[buf_switch][(cell->ypos << 2) * plane->pitch + (cell->xpos << 2)];
> >>>>     /* reference block = prev_frame(cell_xpos + mv_x, cell_ypos + mv_y) */
> >>>>     mv_y = cell->mv_ptr[0];
> >>>>     mv_x = cell->mv_ptr[1];
> >>>>     offset = ((cell->ypos << 2) + mv_y) * plane->pitch + (cell->xpos << 2) + mv_x;
> >>>>     src = &plane->pixels[buf_switch ^ 1][offset];A typical cell consists of 4x4 blocks in raster order and is usually
> >>>> 4-6 blocks or 16-24 pixels wide. By INTER pictures it's usually bigger
> >>>>
> >>>>     for (y = cell->height << 2; y > 0; src += plane->pitch, dst += plane->pitch, y--)
> >>>>         memcpy(dst, src, cell->width << 2);
> >>>> }
> >>>>     
> >>>>         
> >>> also, cant the dsputil block copy code be used?
> >>>   
> >>>       
> >> Which function I have to look into? Plz help, I'm not a dsputil's guru...
> >>     
> 
> I'm very sorry but I don't really understand why you ask me to replace
> the code above with block_copy? Is "memcpy" not fast enough? I'm aware
> of the fact that we shouldn't duplicate code but I'm not sure that the
> block_copy would be a better solution for this case IMHO. Dsputil's
> block copy code operates on blocks of fixed width but I often need to
> copy blocks of 24 and more pixels wide...

copy_32() should be replaced by dsputil, so should all other copy and
halfpel MC variants that work on simple width/height

If some code can end up with "odd" sizes that can be left for now, though
i would be happy if you could explain how it ends up at such width like
24 ?

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

It is not what we do, but why we do it that matters.
-------------- 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/20090801/f586116e/attachment.pgp>



More information about the ffmpeg-devel mailing list