[FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better

[wm4]

On Sun, 10 Apr 2016 21:13:13 +0200
Michael Niedermayer <michael at 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 <michael at 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.