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

[Alex Converse]

On Wed, Apr 29, 2009 at 1:25 PM, Kostya <kostya.shishkov at gmail.com> wrote:
> On Wed, Apr 29, 2009 at 12:24:38PM -0400, Alex Converse wrote:
>> 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.
>
> Yes, but we should have it eventually.
>
>> 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.
>
> Please give more detailed list, I must get rid of that.
>

ftp://mpaudconf:adif2mp4 at ftp.iis.fhg.de/origWav/thetest5_48.wav is a
great example of material we choke on. Particularly the part at the
end.

>> 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.
>
> Well, ffaacenc disregards channel order and no special LFE treatment.
>

This is very fixable.

[...]