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

[Kieran Kunhya]

On Sun, 10 Apr 2016 at 21:39 Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Sun, Apr 10, 2016 at 11:00:23PM +0300, Jan Ekstrom wrote:
> > Hi,
> >
> > On Sun, Apr 10, 2016 at 10:13 PM, Michael Niedermayer
> > <michael at niedermayer.cc> wrote:
> > > This is not about changing a bad encoder to a good encoder, this patch
> > > is about removing choices.
> > > 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 have thought about this somewhat, and the things boil down to:
> > * Libfaac is old, unmaintained, produces relatively bad quality and
> > requires a "nonfree" configuration, which disables any sort of binary
> > distribution. Last point probably being the most problematic for
> > anyone who wants to use it outside of a server context. In which case
> > there's already fdk-aac available, which has found immense popularity
> > during the last few years before the internal encoder became better.
> > Fdk-aac still serves a purpose with HE-AAC, as well as some specific
> > LC-AAC use cases (latter according to some random people on #ffmpeg ),
> > so it yet isn't considered something worth removing.
> > * Both are very fast (about 30x realtime vs 60x realtime as far as
> > could be gathered by the numbers posted on this thread if I am reading
> > them correctly). Even if you are doing live recording, neither of
> > these is likely to be slow enough for the CPU usage to really matter.
> > * The faac encoder will still be there for those who really want to
> > still use it, albeit no longer through libavcodec. This can actually
> > ease usage for some people as they can now compile libavcodec without
> > enable-nonfree and instead handle the licensing incompatibility on
> > their side in one way or another (except it's supposedly licensed as
> > GPL while parts of its source code are suposedly GPL-incompatible,
> > thus pretty much making that case not really true, unlike fdk-aac
> > which doesn't seem to have such contradictions within its own code
> > base).
>
> > * Keeping this encoder available will serve as an endorsement for it.
> > Do we really want to endorse this encoder?
>
> its not my intend to endorse anything. I just object to the removial
> of optional libfaac support as long as its much faster than the
> native encoder. Its twice as fast ATM, thats alot
>
> libfaac shows that it is possible to encode fast, the mail from
> claudio suggests the same ...
>
> My request simply is "make our encoder as fast as libfaac before
> removing libfaac"
>
> this is not about libfaac, it is about making our encoder better
>
>
Doesn't answer my question about why we should keep a nonfree encoder which
most users can't use.
Kieran