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

wm4 nfxjfg at googlemail.com
Mon Feb 9 23:31:02 CET 2015


On Mon, 09 Feb 2015 17:13:45 -0500
Calvin Walton <calvin.walton at kepstin.ca> wrote:

> On Fri, 2015-02-06 at 13:51 +0000, Vittorio Giovara wrote:
> > On Fri, Feb 6, 2015 at 11:32 AM, wm4 <nfxjfg at googlemail.com> wrote:
> > > This is a proposal for an API extension.
> > > 
> > > Currently, some pixel formats support alpha, but whether the alpha 
> > > component contains something useful or just garbage is not part of 
> > > the pixel format definition. This applies at least to packed RGB 
> > > formats, where the 4th component is either alpha or garbage 
> > > depending on the context.
> > > 
> > > One possible solution is duplicating all these pixel formats, so 
> > > you'd have e.g. AV_PIX_FMT_RGBA and AV_PIX_FMT_RGBX. But I think 
> > > we all agree that we don't want more pixel formats.
> > > 
> > > The other solution, which I want to advocate here, is adding a 
> > > field to AVFrame that indicates the alpha mode. Something like:
> > 
> > The problem looks interesting. I am not sure samples with
> > premultiplied alpha exist (or what swscale does in that case). 
> > Another approach could be to expand avframe->flag, in order to 
> > signal when alpha channel contains garbage, rather than introducing a
> > new field.
> 
> The premultiplied alpha case is probably pretty rare, but I can think 
> of one particular time it might come up - If you are writing an 
> application that uses cairo to draw image frames via an Image Surface, 
> and want to encode them to a video with ffmpeg.
> 
> The pixel format used in the cairo image surfaces is one of the 
> following:
> http://cairographics.org/manual/cairo-Image-Surfaces.html#cairo-format-t
> The most common types to use are "RGB24" (which is a native-endian 
> 32bit RGB type where the extra 8 bits are unused) and "ARGB32", which 
> has, you guessed it, premultiplied alpha.
> 

Yeah, it's pretty common in graphic APIs and such. But apparently not
in file formats and codecs, so I guess FFmpeg will never need it. Good
for us.


More information about the ffmpeg-devel mailing list