On 4/10/16, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Sun, Apr 10, 2016 at 07:29:05PM +0100, Rostislav Pehlivanov wrote: >> On 10 April 2016 at 17:42, Michael Niedermayer <mich...@niedermayer.cc> >> wrote: >> >> > On Sun, Apr 10, 2016 at 04:38:35PM +0100, Kieran Kunhya wrote: >> > > --- >> > > Changelog | 1 + >> > > configure | 6 -- >> > > doc/encoders.texi | 105 --------------------- >> > > doc/ffserver.conf | 2 +- >> > > doc/general.texi | 2 +- >> > > doc/muxers.texi | 4 +- >> > > doc/platform.texi | 2 +- >> > > libavcodec/Makefile | 1 - >> > > libavcodec/allcodecs.c | 1 - >> > > libavcodec/libfaac.c | 248 >> > ------------------------------------------------- >> > > libavcodec/version.h | 2 +- >> > > 11 files changed, 7 insertions(+), 367 deletions(-) >> > > delete mode 100644 libavcodec/libfaac.c >> > >> > this is not possible currently libfaac is twice as fast than the >> > native encoder. >> > >> > time ./ffmpeg -v 0 -i matrixbench_mpeg2.mpg -vn -c:a libfaac -y >> > test.aac >> > real 0m2.828s >> > user 0m2.776s >> > sys 0m0.048s >> > >> > time ./ffmpeg -v 0 -i matrixbench_mpeg2.mpg -vn -y test.aac >> > real 0m5.908s >> > user 0m5.856s >> > sys 0m0.048s >> > >> > >> > >> FAAC isn't maintained, hasn't had any work done on it in who knows how >> many >> years, nobody but people who don't know that the native encoder/fdk is >> better use it (just a few thankfully), isn't particularly stable >> (segfaulted a few times when I was comparing it last year) and finally, >> it's not good at all. >> An argument that it's faster than the native encoder has as much weight >> as >> an argument that libaac_plus was also faster than the native encoder, >> which >> didn't matter as it was eventually removed >> The age where we needed a few different AAC encoders because there wasn't >> really a single good multipurpose one is gone now. The times have changed >> since FAAC was developed (Nokia sponsored at lot of its development, and >> you know what they used to make) and so have the computers. What was an >> acceptable speed back then for encoding a file at a given quality isn't >> necessarily the same now. And considering that fdk-aac can run as slow as >> our encoder I'd say we're doing pretty well as far as the balance between >> speed and quality goes. > > x264 can encode at really impressive speed and also at really > impressive quality, its the users choice by using teh preset option > > for aac the user can choose speed through using the libfaac encoder > or quality through using the native encoder > speed matters for battery powered devices, not just for media servers > on phones but also for plain audio recording on phones which i think > is more common.
FWIW I once received a report that the old (now removed) vo-aacenc was lightning fast. Anybody have any speed/quality comparisons out there? :) -roger- _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
