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. Even those dead Nokia phones are unlikely to have used it through ffmpeg. > > that said, to be blunt, make your encoder be capable to encode as fast > and as good quality as libfaac and after that remove libfaac support > if you want. Our own AAC developer just said that faac is "not good at all". > This is not about changing a bad encoder to a good encoder, this patch > is about removing choices. The choice between using a hammer to hit your own toes as hard as possible, and a decent encoder with good quality/speed tradeoffs? > Before this patch users can force libfaac and have twice as long > battery life at lower quality after the patch the users do not have > that choice anymore > > I do not think thats a good idea nor in the interrest of our users > > [...] I love how this completely unproven and ridiculous battery argument suddenly makes the rounds. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
