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