On 8/16/16, Roger Pack <rogerdpa...@gmail.com> wrote: > 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?
Yes, I. Its quality is useless. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
