[FFmpeg-devel] [PATCH] Make decoding alpha optional for some codecs.

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed Sep 18 22:27:34 CEST 2013


On Wed, Sep 18, 2013 at 10:11:29PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 18, 2013 at 08:51:33PM +0200, wm4 wrote:
> > On Wed, 18 Sep 2013 12:24:55 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> > 
> > > to keep the code simple tha format could be left as a YUVA format
> > > only skiping the code that fills the alpha plane
> > > this should avoid the messy pixfmt setup code
> > 
> > That sounds even worse, because now the alpha plane may contain
> > garbage, depending on the user options. Why not set the correct pixel
> > format in the first place?
> > 
> > (Not sure why reimar's patch calls ff_get_format_alpha() everywhere,
> > instead of doing the reverse at a single point. It would require
> > adding a ff_get_format_no_alpha() instead. This should be in libavutil,
> > and use the pixfmt data, btw.)
> 
> yes, this is a possibility as well

I have no idea what you are thinking of.
The reason the function call is "all over the place" in ffv1 in that
patch version is because like that it actually _reduces_ the size of the
code.
Doing it afterwards would mean that first the code has the code for
matching up alpha with non-alpha pix_fmts and then that function has
the same thing once more.
I guess it is a less intrusive change, but it's not exactly simpler...
Unless you completely misunderstood what ff_get_format_alpha does and
just meant adding a function to do the alpha format -> non alpha format
mapping and use that at several places.
That might make it slightly better, but I am not sure how much.
It probably is something worth considering in order to clean up the
pix_fmt selection code in ffv1 though, whether it helps for this patch
or not.


More information about the ffmpeg-devel mailing list