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

[Marc Hoffman]

On 6/15/07, Marc Hoffman <mmhoffm at gmail.com> wrote:
>
>
>
> On 6/15/07, Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>
> wrote:
> >
> > Hello,
> > On Fri, Jun 15, 2007 at 12:20:23AM -0400, mmh wrote:
> > Content-Description: message body text
> > > This small patch provides the ability to load audio filters at runtime
> > > into mplayer.
> >
> > If anything, please do it as a new af_ like it was done for af_ladspa.
> > Ok, I can't guarantee this will actually work, but it seems a lot less
> > messy to me.
>
>
> ? Seems clean as an integrated mechanims its a tiny amount of code.  I did
> think of doing it as a af-filter itself but that interaction seems too
> complex.  Maybe I'm missing something.
>
>
> > The API for the audio filter is identical to the existing libaf.  This
> > > way if a module needs to be provided separately it can be done by
> > > providing a shared object which can be inserted at runtime into the
> > > audio filter chain.
> >
> > 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.
>
> 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.
>
> 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.
>
>
> > The only interface change which needs to be provided by the shared
> > > object is that it must define a pointer to the info structure which
> > > defines the filter.  This is done like this:
> > >
> > > af_info_t af_info_simple = {
> > >         "simple audio filter",
> > >         "simple",
> > >         "mmh",
> > >         "ex: simple",
> > >         AF_FLAGS_NOT_REENTRANT,
> >
> > Why the hell does everyone want to use AF_FLAGS_NOT_REENTRANT?
>
>
> I just copied this from some place else and got my filter to work.  I
> would bet thats what everyone else does as well.
>

Can I apply this patch?  Any objections?