[MPlayer-dev-eng] PATCH dynamic link loader for libaf, audio filter package

[Marc Hoffman]

Hi,

On 6/15/07, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
>
> On Fri, 2007-06-15 at 07:49 -0400, Marc Hoffman wrote:
> > On 6/15/07, Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>
> > wrote:
> > > Why would someone want this though?
> >
> >
> > 1. I need to link at runtime a  module which  can't be integrated with
> the
> > code itself directly due to proprietary IP issues.  As long as Mike and
> the
> > rest of the crew don't get a hold of the so's.
>
> This sounds basically like an attempt to circumvent the GPL. Whether or
> not it would actually be legal it might not be something we want to
> encourage.


Not completely, this is for some internal tools which someone plans to use
as part of their service infrastructure.   So the software doesn't not get
distributed as far a I know at least the software is not sold but the
service is.  I think this is ok.

> 2. The functionality which I have been asked to add to mplayer is a bit
> > esoteric and specific to SMPTE time codes.  And I have been asked to
> make my
> > work private.
>
> This also sounds potentially questionable. You can agree to develop
> GPLed code and not distribute the result without permission, but any
> distribution that does happen must be under the terms of the GPL. Does
> whatever party you're working for intend to keep the result for private
> use? Anyone else but you who receives it gets it under the terms of the
> GPL (and even you if you get it back from someone else), and cannot be
> asked to keep it private.



Private use, I believe.   Actually, I have been going around and around on
the issue of to integrate or not integrate.  And to mainline the code to
reduce long term maintenance costs but the group doesn't want to disclose
the technology at the current time.

> Well I don't want to patch the player thats too complex to do for
> ever.  So
> > I was thinking that this would be a good mechanism to tie the things
> > together for a very long time and minimizing costs etc.
>
> I think we do not want to make any kind of API or ABI stability
> guarantees for the audio filters. Thus if there is a module interface it
> should have some kind of version information to detect incompatible
> modules; but so far I'm not convinced there should be a module interface
> at all.



I agree there are no Guarantees here at all the internal data structure
layouts change and these modules will cease to work.  I know the issue all
to well.


Putting the political issues aside will the group accept my patch?  I also
think its fairly useful in that it does in someways simplify filter
development.  Where you can just work on your filter and link it into the
big system.

Marc