On Wed, Mar 09, 2016 at 02:20:35PM -0300, Claudio Freire wrote: > On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde <gajja...@gmail.com> > wrote: > > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin > > <andrey_ut...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
