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

Reimar Döffinger Reimar.Doeffinger
Wed Mar 25 13:59:19 CET 2009


On Wed, Mar 25, 2009 at 01:43:01PM +0100, Michael Niedermayer wrote:
> On Wed, Mar 25, 2009 at 09:24:49AM +0100, Reimar D?ffinger wrote:
> > On Wed, Mar 25, 2009 at 08:25:39AM +0100, C?dric Schieli wrote:
> > >          case PIX_FMT_RGB4_BYTE:
> > > -            r= (i>>3    )*255;
> > > +            a= (i>>4    )*17;
> > > +            r= ((i>>3)&1)*255;
> > >              g= ((i>>1)&3)*85;
> > >              b= (i&1     )*255;
> > >              break;
> > >          case PIX_FMT_BGR4_BYTE:
> > > -            b= (i>>3    )*255;
> > > +            a= (i>>4    )*17;
> > > +            b= ((i>>3)&1)*255;
> > 
> > 
> > ??? the changes to r and b seem right, but what are you calculating for
> > a?
> > Just const int a = 255 should do it.

Responding to the other mail:
> I'm calculating "a" according to what suggested Stefano here :
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/066144.html

I think that isn't such a great idea, for most encoders that use it
today it would probably preferable if the highest bits were 0.

> > Also instead of those r,b changes it would make more sense to let the loop
> > only run to 16 for PIX_FMT_RGB4_BYTE and PIX_FMT_BGR4_BYTE.
> 
> that might cause uninitalized errors in valgrind that might hide real errors
> it might also lead to random behavior when the whole pal is stored

I was thinking of a memset 0 in addition, but I admit it does not make
that much sense either.



More information about the ffmpeg-devel mailing list