[FFmpeg-devel] [PATCH] swscale alpha channel support

[Michael Niedermayer]

On Mon, Feb 23, 2009 at 04:16:44PM +0100, C?dric Schieli wrote:
> 2009/2/23 Michael Niedermayer <michaelni at gmx.at>
> 
> > On Mon, Feb 23, 2009 at 02:15:26PM +0100, C?dric Schieli wrote:
> > > 2009/2/21 Michael Niedermayer <michaelni at gmx.at>
> > >
> > > > On Sat, Feb 21, 2009 at 08:53:53PM +0100, C?dric Schieli wrote:
> > > > > 2009/2/21 Jason Tackaberry <tack at urandom.ca>
> > > > >
> > > > > > On Sat, 2009-02-21 at 12:49 +0100, C?dric Schieli wrote:
> > > > > > > Attached is another patch which factorizes some code in
> > > > > > yuv2rgb_template.c
> > > > > > > to ease further yuva2rgb patch.
> > > > > >
> > > > > > Rather than reading the patch I'll be lazy and just ask: with this
> > > > patch
> > > > > > applied, will yuv to rgb32 now set the alpha channel to 0xff
> > instead of
> > > > > > 0x00?
> > > > >
> > > > >
> > > > > No, the aim of the patch is to use an existing alpha channel (from
> > > > > YUVA420P).
> > > > > But I agree that setting 0xff when "creating" an alpha channel would
> > be
> > > > more
> > > > > useful than setting 0x00 as for now. I've already made a patch that
> > does
> > > > > just this (for mmx unscaled yuv420p->rgb32 and unscaled
> > rgb24->rgb32).
> > > > > I can send it for review if changing such a "default" behaviour is
> > ok.
> > > >
> > > > you can
> > > >
> > >
> > > The first patch (sws_yuv2rgb_factorize.patch) brings a little more
> > > factorization in prevision of the yuva2rgb patch. It is also a
> > prerequisite
> > > for the second patch (sws_default_alpha_value.patch) which substitute 255
> > to
> > > 0 as a default value for alpha channel throughout the code.
> >
> > patches ok assuming they either
> > * dont changes striped objects
> > * have been tested (that is all changed code paths have been checked
> >  in some way)
> >
> 
> The factorize patch doesn't change the object files.
> 
> The second one missed one hunk in yuv2rgb2.c (updated patch attached)
> Every code paths I can think of has been tested : any combination of
> mmx/nommx, unscaled/scaled, fast_bilinear/bilinear/bicubic, +-bitexact,
> +-full_chroma_int, rgb555/rgb565/rgb24/bgr555/bgr565/bgr24
> only tested on x86_32 though

[...]
> Index: ffmpeg/libswscale/yuv2rgb2.c
> ===================================================================
> --- ffmpeg.orig/libswscale/yuv2rgb2.c	2009-02-23 15:14:39.409161445 +0100
> +++ ffmpeg/libswscale/yuv2rgb2.c	2009-02-23 15:17:36.861446441 +0100
> @@ -83,11 +83,11 @@
>      g = (void *)(c->table_gU[U] + c->table_gV[V]);  \
>      b = (void *)c->table_bU[U];
>  
> -#define PUTRGB(dst,src,i,o)          \
> -    Y = src[2*i+o];                  \
> -    dst[2*i  ] = r[Y] + g[Y] + b[Y]; \
> -    Y = src[2*i+1-o];                \
> -    dst[2*i+1] = r[Y] + g[Y] + b[Y];
> +#define PUTRGB(dst,src,i,o,a)              \
> +    Y = src[2*i+o];                        \
> +    dst[2*i  ] = r[Y] + g[Y] + b[Y] + (a); \
> +    Y = src[2*i+1-o];                      \
> +    dst[2*i+1] = r[Y] + g[Y] + b[Y] + (a);
>  
>  #define PUTRGB24(dst,src,i)                                  \
>      Y = src[2*i];                                            \

alpha can be merged in the table i think which avoids that 1 add per pixel

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- 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/20090223/4ab4ae09/attachment.pgp>