[FFmpeg-devel] [PATCH] Make decoding alpha optional for some codecs.
Reimar.Doeffinger at gmx.de
Wed Sep 18 13:12:06 CEST 2013
Paul B Mahol <onemda at gmail.com> 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
Because I believe that FFmpeg should be efficient and wasting 30% is grossly wasting.
Well, in addition it would allow removing the hacks checking for data being NULL and not having to add alpha support to MPlayer, but that is not a good reason, it just is another reason why I thought it a neat feature, a lot faster and simpler to use for (some) applications.
>Whoever needs alpha would not need your code.
>Whoever does not need alpha would not encode with alpha at first
That's a) not sure and b) the person encoding and the person playing it back are not always the same.
Some people seem to find it really important that you can see their website through a part of their flash video. Anyone whose computer is too slow for that is quite happy to see it with a black background in ffplay or MPlayer.
>The patch is intrusive and you can't make it less intrusive
>or better looking by doing silly things.
You still haven't said what part you have a problem with.
The ifs are mostly already there, so can I assume that's not what you complain about?
The get_format stuff can be avoided as Michael pointed out, though I have some concerns about it.
And actually the issue of having to initialize alpha can be avoided by setting the non-alpha pixfmt when such a flag is set.
But I have no idea what your concern really is, compared to many other optimizations this one looks rather low complexity to me (though I do not doubt it can be improved, I do not mind thinking more about it, but your level of non-constructiveness is not very motivating).
More information about the ffmpeg-devel