[FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
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
> 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
> > 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
More information about the ffmpeg-devel