On Wed, Mar 9, 2016 at 3:52 PM, Reimar Döffinger <reimar.doeffin...@gmx.de> 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 <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.
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
