On Wed, Mar 09, 2016 at 09:56:00PM +0100, Reimar Döffinger wrote:
> On Wed, Mar 09, 2016 at 09:04:29PM +0100, Michael Niedermayer wrote:
> > On Wed, Mar 09, 2016 at 07:32:29PM +0100, Reimar Döffinger wrote:
> > > On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> > > > On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > > > > Yields 2x improvement in function performance, and boosts aac encoding
> > > > > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under
> > > > > -march=native):
> > > > > after:
> > > > > ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.22s user 0.03s
> > > > > system 105% cpu 4.970 total
> > > > >
> > > > > before:
> > > > > ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.40s user 0.05s
> > > > > system 105% cpu 5.162 total
> > > > >
> > > > > Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a
> > > > > further 2x through
> > > > > additional symmetry. Of course, one could approximate with the 0 mod
> > > > > 4 variant,
> > > > > error would essentially be ~ 1/len in the worst case.
> > > > >
> > > > > Signed-off-by: Ganesh Ajjanagadde <gajja...@gmail.com>
> > > > > ---
> > > > > libavcodec/lpc.c | 3 ++-
> > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
> > > > > index 3839119..052aeaa 100644
> > > > > --- a/libavcodec/lpc.c
> > > > > +++ b/libavcodec/lpc.c
> > > > > @@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s,
> > > > > const float *samples, int len,
> > > > > const double a = 0.5f, b = 1.0f - a;
> > > > >
> > > > > /* Apply windowing */
> > > > > - for (i = 0; i < len; i++) {
> > > > > + for (i = 0; i <= len / 2; i++) {
> > > >
> > > > > double weight = a - b*cos((2*M_PI*i)/(len - 1));
> > > >
> > > > the windows should not be recalcuated for each frame. But either
> > > > calculated once during init or calculated at first use if that makes
> > > > sense
> > > >
> > > > actually i suspect there should be close to 0 calls to libc math
> > > > functions after init in the encoder, or is there some use of these
> > > > functions in aac that cannot be replaced by a simple table?
> > >
> > > I don't understand the code, but I assumed that len changes
> > > regularly here, which is the main problem.
> > > I never actually checked if there is maybe only a small
> > > number of common values at least though.
> >
> > encoding matrixbench with defaults i get this list of lens with their
> > freuqncies
> > 1 ff_lpc_calc_ref_coefs_f 108
> > 131 ff_lpc_calc_ref_coefs_f 116
> > 148 ff_lpc_calc_ref_coefs_f 584
> > 75 ff_lpc_calc_ref_coefs_f 84
> > 1 ff_lpc_calc_ref_coefs_f 88
>
> That looks to me like it will depend on content.
> Then probably only a cache will work.
> It could safe a few more operations by directly
> containing the weight.
> Still, not sure it's worth the effort, I think we'd
> only save another 1% over what you get with
> this patch + using cosf.the patch is surely a good idea either way [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
