[FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function

Ganesh Ajjanagadde gajjanag at gmail.com
Thu Mar 10 02:45:30 CET 2016


On Wed, Mar 9, 2016 at 5:09 PM, Moritz Barsnick <barsnick at gmx.net> wrote:
> On Tue, Mar 08, 2016 at 22:16:50 -0500, Ganesh Ajjanagadde wrote:
>> ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.22s user 0.03s system 105% cpu 4.970 total
>
> Just wondering: Is this the sin.flac from
> ffmpeg -f lavfi -i aevalsrc="sin(440*2*PI*t):s=48000" -t 300 -y sin.flac
> ??

Precisely from Andrey Utkin's remark on AAC perf drop, so yes.

>
> Is a sinusoidal signal good enough to benchmark an audio encoder? It
> only requires one very narrow frequency band, after all, no
> psychoacoustics, ...
>
> I don't see differences in general encoding speed of sine vs. noise,
> but I didn't check the influence on your code improvements. Agreed,
> noise doesn't do much for psychoacoustics probably either.

These are good points, but note that at some level all benchmarking
has the same flaws if they have variable execution length paths; i.e
what is the "holy grail" signal of interest. If you are a Bayesian,
you might place a prior on various signals; if you are a frequentist,
you could do a min-max over a class or check for Pareto dominance.

>
> (BTW, if just inspecting ffmpeg runtime without use of benchmarking
> start/stop markers, I use lavfi directly, to avoid the overhead of flac
> decoding. And not aevalsrc - sine and even anoisesrc are 10x faster.)

I am deliberately using this same command throughout all the patches I
send to give a uniform comparison of progress over time. I have noted
this for the future, thanks.

>
> Moritz
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


More information about the ffmpeg-devel mailing list