[FFmpeg-devel] AAC encoder 3x performance drop in 3.0 since Oct 2014

[Claudio Freire]

On Wed, Mar 9, 2016 at 3:52 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Wed, Mar 09, 2016 at 02:20:35PM -0300, Claudio Freire wrote:
>> On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde <gajjanag at gmail.com> wrote:
>> > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
>> > <andrey_utkin at fastmail.com> wrote:
>> > No idea about this. However, here is some info.
>> > The regression in speed dates to: 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec.
>> > At this commit, there was a bad speed regression (11.475 s, vs 2.525 s
>> > before vs 6.565 s current).
>> > As can be judged from this, since the main commit bringing in the
>> > revamped encoder, there have been efforts that have shaved off some
>> > time, some that increase it slightly, etc.
>> > However, the chief one that brought it down from 11.x to 6.y was
>> > b629c67ddfceb7026e407685f04d1bb09cb08d31. Since then, performance has
>> > been generally stable at ~ 6.5 s +/- 10%.
>> >
>> > Generally speaking though, it is indeed true that speed is still
>> > somewhat lacking:
>> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184631.html.
>> >
>> > Ideally, FATE should have some basic plotting/performance
>> > infrastructure, e.g a client can submit perf figures so that evolution
>> > over time can be viewed. No idea why this can't be done.
>>
>> From my experience, the slowness is mostly due to the fact that
>> twoloop gets stuck trying to meet the bandwidth limit with an initial
>> allocation (by aacpsy) that makes it hard. That is, it gives off an
>> initial solution that is far off the bandwidth limit, and makes
>> twoloop work extra hard to adjust the solution.
>>
>> I've been attempting to fix that by making psy's initial allocation a
>> closer match to the target bitrate, but that's another huge change in
>> the bit allocator that shows lots of regressions, so it isn't at all
>> near completion. But I can confirm it does speed up the encoder a
>> great deal when psy gives a better initial solution, so that's
>> probably the path to a speedier encoder.
>
> You mean besides fixing the obvious performance bugs in the code :)
> After all we manged to extract about 25% or more of extra performance
> already with no algorithm changes, so there was (is?) a surprising
> amount of low-hanging fruit.

Sure, but the speedup I see is like 4x or something like that (I
haven't properly measured it yet, but it was noticeable)