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

[Claudio Freire]

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:
>> Hi!
>> I am aware of news that AAC encoder got stable status recently.
>>
>> But you could find this interesting. We've got an ffmpeg build from
>> October 2014, and it performs three times faster on AAC encoding than
>> recent 3.0 release. There is no complaints about audio quality on old
>> version, and I can honestly say the audio quality is really
>> satisfiable on old version. The performance is paramount in our
>> particular usecase, so it is silly to deploy a new version which
>> performs so noticeably worse. Still deploying new release is needed due
>> to other particular bugfixes.
>>
>> Obvious things like lowering bitrace, setting "-aac_coder fast" don't
>> help.
>>
>> You can check this yourself with this script (it is also inlined below):
>> https://gist.github.com/andrey-utkin/c60cd4070eb962d58075
>>
>> On my workstation, the old version finishes the transcoding in 2.5s,
>> the new one in 6.6s.
>>
>> Is there any workaround? Or is the old times speed is buried by
>> correctness and stability?
>
> 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.