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

[Michael Niedermayer]

On Sun, Apr 10, 2016 at 08:49:16PM +0000, Kieran Kunhya wrote:
> 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.

i dont want to keep it, i want our encoder to be as fast as libfaac

libfaac support should be kept until our encoder is as fast
so users can choose a twice as fast encoder at all times,
developers can test both encoders easily in the same environment
(ffmpeg).
If you remove libfaac support before adding a "fast" mode to the
native encoder, accurate benchmarking would require you to apply patches
to undo the libfaac removial first or you would test apples against
oranges if libfaac would be tested under a different application or
revission

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/c6ec186c/attachment.sig>