[FFmpeg-devel] [RFC] Exporting the alpha mode from decoders

wm4 nfxjfg at googlemail.com
Fri Feb 6 21:57:50 CET 2015

On Fri, 6 Feb 2015 20:16:50 +0000 (UTC)
Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> wm4 <nfxjfg <at> googlemail.com> writes:
> > The pixfmt docs seems to imply that the extra 
> > component  must be set to 0 if a RGB0 format is 
> > used. Camtasia puts random stuff.
> The documentation sounds wrong to me: The pix_fmt 
> was needed because of hardware providing 32bit rgb, 
> there is no guarantee what the X bits contain and 
> it makes no sense for FFmpeg to require a specific 
> content.
> It is good behaviour that libswscale writes a 
> defined value though (as it does iirc).
> (This is unrelated but I don't think "random" is 
> the right word in above sequence: The fact that 
> I did not interpret the alpha value as random 
> was apparently the reason I never changed the 
> pix_fmt. But you are clearly right that RGB32 is 
> wrong.)
> > What about AV_PIX_FMT_RGB555? It's documented 
> > as having 1 alpha bit
> I believe this is a documentation issue, see 
> rgb15to32_c() in libswscale.
> > though it doesn't have the alpha pixfmt flag set. 
> > Fix the docs? Or introduce RGB05551?
> Atm, I cannot remember a sample that supports 
> alpha in RGB555 (I do remember that it is 
> defined in some specs though).
> > There is no AV_PIX_FMT_RGB064.
> > Is it guaranteed that there is no 64 bit
> > format with padding?
> FFmpeg "promises" that RGBA64 contains a valid 
> alpha channel, just as FFmpeg "promises" bit-
> exact H.264 decoding.
> > If one ever exists, is it guaranteed that a 0
> > variant will be added?
> I cannot imagine a screen driver that provides 
> 64 bit rgb screen grabs but please prove me wrong!

If all these things are guaranteed, then I have no problems with the
current solution.

More information about the ffmpeg-devel mailing list