[Ffmpeg-devel] Patch for dynamic liba52.so loading

Rich Felker dalias
Sat Jun 11 15:45:33 CEST 2005


On Sat, Jun 11, 2005 at 11:28:37AM +0200, M?ns Rullg?rd wrote:
> Rich Felker <dalias at aerifal.cx> writes:
> 
> > On Fri, Jun 10, 2005 at 06:44:47PM +0200, August Mayer wrote:
> >> Hello,
> >> 
> >> It seems that the code for dynamically loading liba52.so (CONFIG_AC3 && 
> >> CONFIG_A52BIN) has been rotting for some time. There are two problems in 
> >> libavcodec/a52dec.c:
> >> 1. It uses fprintf instead of av_log, and
> >> 2. libavcodec/parser.c directly links to a52_syncinfo, which is not 
> >> available as a global symbol in this case.
> >> 
> >> I've corrected these two problems; attached are the patches for it.
> >> 
> >> Moreover, I have changed the code so that the references and
> >> function pointers are stored in static variables instead of the
> >> AVCodecContext. This looks more sensible to me, because liba52 only
> >> needs to be loaded once during program lifetime. Is it possible
> >> that there are multiple codec contexts? If so, then liba52.so would
> >> have been loaded multiple times.
> >
> > Of course there are multiple codec contexts. Is there a good reason
> > for dynamic loading support? IMO it's unnecessary complexity that
> > should just be removed..
> 
> There is no technical reason for dynamic loading.  It allows
> libavcodec to be distributed under the LGPL, and still use liba52,
> even if you believe the lies being perpetrated by the FSF.

As long as the party setting it up for this use is not also
distributing liba52 or outerwise doing something for it that requires
accepting the GPL on liba52 I agree. On the other hand, if someone
makes a proprietary program that needs to decode ac3, and distributes
it with libavcodec compiled for dynamic liba52 loading, then offers a
separate download of liba52 under GPL terms, they ARE infringing on
liba52. Making them separate downloads or separating them in other
ways does not get around the fact that they have prepared a non-GPL
derivative work of liba52, thus invalidating their rights to
distribute liba52 under the GPL.

Rich





More information about the ffmpeg-devel mailing list