[FFmpeg-devel] [PATCH 2/3] Indeo 5 decoder: common DSP functions
Sun Jan 10 20:06:38 CET 2010
On Sun, Jan 10, 2010 at 01:22:17PM +0200, Kostya wrote:
> On Sat, Jan 09, 2010 at 05:43:40PM +0200, Kostya wrote:
> > On Sat, Jan 09, 2010 at 03:47:39PM +0100, Michael Niedermayer wrote:
> > > On Sat, Jan 09, 2010 at 04:40:30PM +0200, Kostya wrote:
> > > > On Fri, Jan 08, 2010 at 11:41:23PM +0100, Michael Niedermayer wrote:
> > > > > On Sun, Jan 03, 2010 at 12:56:36PM +0200, Kostya wrote:
> > > > > [...]
> > > > > > void ff_ivi_recompose53(const IVIPlaneDesc *plane, uint8_t *dst,
> > > > [function body skipped]
> > > > >
> > > > > is this mess faster than some more readable variant?
> > > >
> > > > Here's more readable variant by me, checked to be bitexact but it's
> > > > significantly slower (> 10%), I'd rather leave old one.
> > >
> > > I also prefer speed, what about an implementation using lifting?
> > I'll try to implement it.
> Hmm, after some experiments I'd rather leave original version.
> Even grouping variables together in array gives significant performance
> drop. And pure lifting transform is not applicable here either because
> band data is grouped and it will take at least two passes (hor/vert)
> with conditions for missing bands and requires an additional temp
So you can improve snow 5/3 performance by using this code?
My point is that i dont really care which code but iam slightly alergic to
code duplication and i dont see why this should be faster here while slower
in snow than lifting ...
So please elaborate if you think snow and this have a different optimal
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel