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

[Paul B Mahol]

On 9/18/13, Reimar Doeffinger <Reimar.Doeffinger at gmx.de> wrote:
> Michael Niedermayer <michaelni at gmx.at> wrote:
>>On Wed, Sep 18, 2013 at 06:04:59AM -0400, compn wrote:
>>> On Wed, 18 Sep 2013 08:37:51 +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 (ca. 30% less CPU usage
>>> >> and 40% reduced memory bandwidth).
>>> >> 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.
>>> >> Tested by manually hacking avcodec_default_get_format,
>>> >> suggestions for how to test in FATE welcome.
>>> >>
>>> >
>>> >Why you think this change is so important that should be
>>> >commited?
>>>
>>> it sounds similar to other cpu saving decoder features that ffmpeg
>>has.
>>> like 'skiploopfilter' or 'skipnonref' or 'fast'.
>>>
>>> do those features take similar amounts of code?
>>>
>>> do you think skipping alpha could be done in a simpler way?
>>
>>what about if this alpha skip is done similarly to gray only decoding?
>>that is a AVOption setable skip_alpha instead of get_format()
>>One advantage would be that it would not need any changes on the
>>user application side, the user (or app) could just set skip alpha
>>and the alpha decoding would be skiped
>>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
>
> It raises the question what we have that get_format stuff for if it's no
> good to be used for anything.
> Also leaving it as yuva would requiring initializing the alpha plane IMO, so
> it doesn't help for the bandwidth usage.

Nothing needs to initialize alha plane.

> But if that is more acceptable I don't mind. I don't think it is good design
> at all though.

It raises the question once more do we really need to take care of
every mplayer hack in FFmpeg.