[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