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

[wm4]

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.