[Ffmpeg-devel] [PATCH] Snow mc_block mmx optimization

Michael Niedermayer michaelni
Sun Mar 26 21:48:41 CEST 2006


Hi

On Sun, Mar 26, 2006 at 03:10:17PM +0200, Oded Shimon wrote:
> On Fri, Mar 24, 2006 at 10:20:22PM +0200, Oded Shimon wrote:
> > On Fri, Mar 24, 2006 at 09:15:02PM +0200, Oded Shimon wrote:
> > > On Fri, Mar 24, 2006 at 07:52:01PM +0100, Michael Niedermayer wrote:
> > > > Hi
> > > > 
> > > > On Fri, Mar 24, 2006 at 04:18:04PM +0200, Oded Shimon wrote:
> > > > > On Thu, Mar 23, 2006 at 09:43:29PM +0100, Guillaume POIRIER wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 3/22/06, Oded Shimon <ods15 at ods15.dyndns.org> wrote:
> > > > > > > My turn!
> > > > > > >
> > > > > > > Just for qpel (I think? maybe also for odd resolutions)
> > > > > > >
> > > > > > > C version is faster as well, by a factor of ~2, and mmx version is about ~8
> > > > > > > times faster... md5sums pass. I think total speed increase is 10-20% for
> > > > > > > files encoded with qpel...
> > > > > > 
> > > > > > Doesn't apply here...
> > > > > 
> > > > > New patch. Also has the _mmx function names you wanted.
> > > > 
> > > > patch ok IMHO if regression tests pass, except that the mmx stuff should
> > > > go into snowdsp_mmx.c
> > > 
> > > Any suggestion to do this without exporting 16 mc_block functions?.. Or is 
> > > this fine and just do this?
> > > 
> > > extern void ff_snow_mc_block_x0_mmx();
> > > extern void ff_snow_mc_block_x2_mmx();
> > > ...
> 
> Ping.

pong

after more carefull review of this iam not so sure anymore if its a good idea

* doesnt this change 1/2 pel (no qpel) encoding?
* currently we have 2 different MC variants, 1. the h.264 case for 1/4 pel
  and our own for 1/8 pel, i really disslike this, we should attempt to
  find a more unified method

[...]

-- 
Michael





More information about the ffmpeg-devel mailing list