Re: [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
 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  
>> wrote:
>> > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
>> >  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)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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  
> wrote:
> > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
> >  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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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  wrote:
> On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
>  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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ganesh Ajjanagadde]

On Mon, Feb 29, 2016 at 10:07 PM, Michael Niedermayer
 wrote:
> On Mon, Feb 29, 2016 at 10:02:46PM -0500, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Mon, Feb 29, 2016 at 9:30 PM, Ganesh Ajjanagadde 
>> wrote:
>>
>> > 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.
>>
>>
>> It can - it just hasn't been done yet :)
>>
>> Patches welcome, and I personally think this would be very useful and quite
>> cool.
>
> i too think this would be cool, it will be somewhat noisy though for
> some clients (like mine, which run in 8 VMs on the same host)
> depending on how many of them run and how many are idle there will
> be fluctuations

I assume that we are not operating under an "adversarial situation",
i.e that is mitigated via current FATE mechanics. Then, we can limit
the concerns to issues like the one you desribed.

For this, as an extra goal, one could envision computing some sort of
variance/confidence intervals after sufficiently many runs. This could
also go into the report, so that one could e.g go to FATE and sort by
confidence level in addition to the other fields.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are too smart to engage in politics are punished by being
> governed by those who are dumber. -- Plato
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Mon, Feb 29, 2016 at 10:02:46PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Feb 29, 2016 at 9:30 PM, Ganesh Ajjanagadde 
> wrote:
> 
> > 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.
> 
> 
> It can - it just hasn't been done yet :)
> 
> Patches welcome, and I personally think this would be very useful and quite
> cool.

i too think this would be cool, it will be somewhat noisy though for
some clients (like mine, which run in 8 VMs on the same host)
depending on how many of them run and how many are idle there will
be fluctuations

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronald S. Bultje]

Hi,

On Mon, Feb 29, 2016 at 9:30 PM, Ganesh Ajjanagadde 
wrote:

> 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.


It can - it just hasn't been done yet :)

Patches welcome, and I personally think this would be very useful and quite
cool.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ganesh Ajjanagadde]

On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
 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.
[...]
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel