On Sun, 10 Apr 2016 at 20:46 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Sun, Apr 10, 2016 at 09:24:21PM +0200, wm4 wrote: > > On Sun, 10 Apr 2016 21:13:13 +0200 > > 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. > > > > That's like grasping for straws. I very much doubt any phone uses the > > ffmpeg API to encode AAC. > > i suspect some apps even pipe it into command line > ffmpeg and mencoder on phones. > > some apps likely use the ffmpeg API, some likely will use multiple > libs directly to provide the various supported encoding formats > using ffmpeg (api or command line) is simpler than multiple libs > so it makes sense to use it instead if one is lazy > > > libfaac is nonfree so please could you explain how apps distribute FFmpeg with libfaac? Regards, Kieran Kunhya _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
