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

Kostya kostya.shishkov
Wed Apr 29 19:25:20 CEST 2009


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.

> 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.

> 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.)

Please don't - stalled faac helps ffaacenc development ;).

> > 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



More information about the ffmpeg-devel mailing list