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

[Reimar Döffinger]

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.