[FFmpeg-devel] [RFC] Libfaac not LGPL?

[Alex Converse]

On Wed, Apr 29, 2009 at 11:10 AM, Kostya <kostya.forjunk at gmail.com> wrote:
>
> On Wed, Apr 29, 2009 at 08:28:52PM +0530, Jai Menon wrote:
> > On Wed, Apr 29, 2009 at 8:23 PM, Diego Biurrun <diego at biurrun.de> wrote:
> > > On Mon, Apr 27, 2009 at 04:45:37PM -0700, Jason Garrett-Glaser wrote:
> > >> We had some discussions on #ffmpeg-devel and I asked the folks at #gnu
> > >> about this:
> > >>
> > >> http://faac.cvs.sourceforge.net/viewvc/faac/faac/libfaac/tns.c?r1=1.8&r2=1.9
> > >>
> > >> It appears that libfaac, despite declaring itself LGPL2.1, contains
> > >> quite a few licenses... many of which are completely incompatible with
> > >> the LGPL, such as the above.
> > >>
> > >> In theory, it still may be legal to distribute, as the LGPL linking
> > >> exception *may* cover the linking of .c files with non-free licenses
> > >> with .c files that have free licenses. ?However, either way, this
> > >> places FAAC squarely under non-GPL territory... such that ffmpeg
> > >> should require --enable-nonfree to link to it.
> > >>
> > >> Thoughts?
> > >
> > > It's no different than AMR, so we should require --enable-nonfree.
> > >
> > > But dropping libfaac support might be a better idea.
> >
> > Dropping aac encoding support without having any roadmap or plan
> > regarding when/how the native code will be merged doesnt seem like a
> > good idea IMHO. Even then, iirc libfaac is one of the more complete
> > implementations available now so dropping should be considered when
> > ffaacenc has reached a certain maturity.
>
> I agree. Current encoder is simply working - no good model or rate
> control yet. Also the lack of SBR and proper multichannel support
> make my encoder not even a stub replacement. Look at native Vorbis
> encoder - who uses it?
>

As far as I know libfaac does not do SBR. It does LC and possibly some
features that really nobody cares about (Main, LTP, 960). I have a
rudimentary implementation of TNS (13818-7 Annex C) in my tree but I
can't really test/tune it yet because the rest of the encoder is doing
wonky things. If faac is using TI's implementation than it is most
likely also a minimal 13818-7 Annex C implementation. Despite this I
think ffaacenc is closer to reaching faac parity than you give
yourself credit for. Also as far as multi channel support goes, AAC-LC
(the subset that actually used in the wild, no CCEs) multichannel
support is very limited. The best you can do pair single channels into
CPEs. So I'm much less concerned about that.

We have one huge advantage over the Vorbis scenario. Libvorbis is
still developed upstream. (Even if most of this development takes
place in the aoTuV fork and is backported.) Looking at the ChangeLog
the last real development to faac was done more than 4 years ago.
Everything since has been minor bug fixes. In this case just
FFmpegizing a hypothetical LGPL faac would be a real improvement.

Alternatively I could try to graft my TNS (and the bits of FFmpeg it
sucks in) onto faac to make it truly LGPL. (Though we would have to go
through the FAAC codebase and make sure there is no other code under
the MPEG refsoft license in there.)

> I am in favour of dropping faaD2 support though. Our decoder should
> become more feature-complete and looks like nobody cares for now.
>

+1

Regards,
Alex Converse