[FFmpeg-devel] [PATCH] Drop unneeded YUV2RGB funcs

[Kostya]

On Fri, Aug 07, 2009 at 01:38:51PM +0200, Michael Niedermayer wrote:
> On Fri, Aug 07, 2009 at 09:34:35AM +0300, Kostya wrote:
> > On Wed, Aug 05, 2009 at 01:39:49PM +0200, Michael Niedermayer wrote:
> > > On Wed, Aug 05, 2009 at 08:51:56AM +0300, Kostya wrote:
> > > > On Tue, Aug 04, 2009 at 10:46:57PM -0700, Mike Melanson wrote:
> > > > > Kostya wrote:
> > > > >> $subj, their functionality is duplicated in YSCALE_YUV_2_ANYRGB_*
> > > > >> Also that fixes bug with swapping pixels on odd lines.
> > > > >
> > > > > Forgot patch.
> > > > 
> > > > Am I a FFmpeg dev or not?
> > > 
> > > no, a real ffmpeg dev would have included benchmarks from several different
> > > architectures when he proposes droping some optimized code he wrote that
> > > contains a bug that he doesnt want to fix.
> > 
> > s/doesnt want/is too lazy/
> 
> understood but it makes no real difference, "too lazy", "too busy", whatever
> i prefer ffmpeg to improve slowly over ffmpeg worsening quickly
> and if we skip testing code entirely it will worsen quickly

Not for swscale, looks like it was shipped pre-worsened :(

> > 
> > > Yes sure we have a fallback but that may be slower, of course it doesnt
> > > have to be slower but as said that has to be checked before droping this
> > > code.
> > 
> > I've run "time swscale-example", its execution time seems to increase by
> > several percents, so here's proper patch.
> 
> id like to note that this isnt really the proper way to do benchmarks but
> as the patch fixes a bug instead of removing optimizations it doesnt matter
> here

Well, do you know a better way to test all those conversion routines for speed
than by (slightly modified) swscale-example? 

> [...]
> >  yuv2rgb.c |  132 +++++++++++++++++++++++++++++++-------------------------------
> >  1 file changed, 66 insertions(+), 66 deletions(-)
> > 24dce854c4642161db855f18df3e1848600aff10  swscale-yuv2rgb.patch
> 
> if the code is tested and works iam fine with it

Tested, seems to work fine, applied.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB