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

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160410/10a56f44/attachment.sig>