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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Tue Sep 17 22:00:09 CEST 2013


On Tue, Sep 17, 2013 at 07:47:30PM +0000, Paul B Mahol wrote:
> On 9/17/13, Reimar Doeffinger <Reimar.Doeffinger at gmx.de> wrote:
> > For codecs where decoding of a whole plane can simply
> > be skipped, we should offer applications to not decode
> > alpha for better performance.
> > It also means applications do not need to implement support
> > (even if it is rather simple) for YUVA formats in order to be
> > able to play these files.
> > Unfortunately a good way to test this via FFmpeg only is missing,
> > suggestions welcome.
> 
> Why is there no similar intrusive, and of questionable usefulness,
> patch that decodes only luma (Y) plane.

Because most users have a color display.
Very few players can display alpha (and if they could, a lot
of users wouldn't want it to).
Thus alpha is in a large number of use-cases completely useless to
decode, including in particular ffplay.
This is easily wasting over 30% CPU time and 40% memory bandwidth
for no reason. We have a lot more obtrusive and ugly code for smaller
savings!

> The patch is too intrusive and adds extra overhead for maintainers.

What is intrusive about it? It's only calling get_format and then
it checks the pix_fmt instead of has_alpha flag (which could or
could not be considered simpler).
I might not have done it in a ideal way, for example the get_format
that selects between an alpha or non-alpha format could be factored
out, if you think that makes it nicer. I thought it would probably
get a bit messy so I went for the "more code but less intelligence"
approach.

> Ths patch does not add any documentation.

What is there to document? Decoder offers formats it can decode
to, application picks what it wants. Not anything new really.
For some codecs like prores it actually behaves now more than before
when alpha support did not exist.


More information about the ffmpeg-devel mailing list