Re: [FFmpeg-devel] AAC encoder 3x performance drop in 3.0 since Oct 2014
On Wed, Mar 9, 2016 at 3:52 PM, Reimar Döffingerwrote: > 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
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
On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagaddewrote: > 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
On Mon, Feb 29, 2016 at 10:07 PM, Michael Niedermayerwrote: > 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
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
Hi, On Mon, Feb 29, 2016 at 9:30 PM, Ganesh Ajjanagaddewrote: > 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
On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkinwrote: > 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
[FFmpeg-devel] AAC encoder 3x performance drop in 3.0 since Oct 2014
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? #!/bin/bash set -e ffmpeg -f lavfi -i aevalsrc="sin(440*2*PI*t):s=48000" -t 300 -y sin.flac git clone git://source.ffmpeg.org/ffmpeg.git || true pushd ffmpeg for REV in 16f9f7b n3.0 do if [[ -e ../ffmpeg_$REV ]] then continue fi git checkout $REV git clean -dxf ./configure make cp ffmpeg ../ffmpeg_$REV done popd for REV in 16f9f7b n3.0 do time ./ffmpeg_$REV -i sin.flac -acodec aac -strict -2 -y \ sin_${REV}.aac done ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel