[Ffmpeg-devel] PIX_FMT_RGB555 and alpha channel

Michael Niedermayer michaelni
Fri Oct 20 15:23:03 CEST 2006


Hi

On Fri, Oct 20, 2006 at 10:12:35PM +1100, Steven Johnson wrote:
> Hi,
> 
> Michael Niedermayer wrote:
> >Hi
> >
> >On Thu, Oct 19, 2006 at 02:02:34AM +0200, Alex Beregszaszi wrote:
> >  
> >>Hi,
> >>
> >>Current FFmpeg uses the MSB of RGB555 as alpha channel. Look at
> >>pix_fmt_info in imgconvert.c. This causes it to set the MSB in case of
> >>conversion to RGB555.
> >>
> >>Is that for a reason? 
> >>    
> >
> >i dont know :)
> >
> >
> >  
> >>I would propose adding RGBA555 for the alpha
> >>channel containing format and remove the alpha channel from RGB555.
> >>
> >>Any objections?
> >>    
> >
> >could you elaborate on why the alpha channel bit is a problem?
> >
> >[...]
> >  
> I will elaborate.  Alex and I are implementing FLC/FLX and DTA encoding 
> into ffmpeg.  We are a little way from having stuff ready to submit, but 
> there is a problem with compression when the Alpha bit is set in an 
> RGB555 pixel, for the FLX format.  It means we have to mask every pixel 
> coming in, to take the spurious alpha bit out, or that bit prevents run 
> length compression from being effective.  The format is really wanting 
> to use RGB555, without alpha, so that black is 0x0000 and not 0x8000 but 

why does RLE compression not work with the alpha bit set?
and why exactly is the alpha bit set at all? if imgconvert.c sets it, IMO
fix imgconvert.c so it doesnt


> the only option in FFMPEG is RGB1555.  So the options are add a true 
> RGB555 and change the existing RGB555 to an RGBA555, or for us to mask 
> every pixel when it is using RGB555 pixels.  We currently mask, but it 
> makes the code ugly, and it looks like a hack, and it will be slower 
> than if there was a non-alpha version of RGB555 available to use.

a bitwise and per pixel isnt much and i will not accept adding an additional
pixel format to avoid the 1% speed loss it causes (for a dead format)
additionally, IMHO a 15/16bpp RLE-RGB encoder makes only sense if you also
have a pretty smart algorithm to choose the color, lossless will be to
big to be worth it (=gzip/bzip of raw will be smaller)
so id suggest you implement a viterbi based rate distortion optimal encoder
this should be fairly easy for such a simple format
if you do you wont notice the difference in speed that single and has :)

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list