On Fri, 2015-02-06 at 13:51 +0000, Vittorio Giovara wrote: > On Fri, Feb 6, 2015 at 11:32 AM, wm4 <nfx...@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. -- Calvin Walton <calvin.wal...@kepstin.ca> _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
