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

[Michael Niedermayer]

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)

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/dcb0c6a7/attachment.pgp>