[FFmpeg-devel] new filter infastructure stuff (Google Summer of Fun)

[mmh]

Aurelien Jacobs writes:
 > On Tue, 5 Jun 2007 07:09:04 -0400
 > mmh <mmh at pleasantst.com> wrote:
 > 
 > > Luca Barbato writes:
 > >  > Michael Niedermayer wrote:
 > >  > >> Here are some reasons why we might like to support some level of dynamic filters.
 > >  > >>
 > >  > >> 1. if you have some proprietary thing you want to apply to the video prior to re-encode.
 > >  > > 
 > >  > > if some company wants to have their proprietary filters supported _they_
 > >  > > can add optional .so support ...
 > >  > 
 > >  > And even if you want it just for internal usage...
 > >  > 
 > >  > > 
 > >  > >> 2. to add so architecture platform specific capability which is not available to other
 > >  > >> platforms.
 > >  > 
 > >  > The only reason I could find for .so is that you may like to build new
 > >  > modules w/out having to hack the main ffmpeg code, but it isn't exactly
 > >  > a problem IMHO.
 > >  > 
 > > 
 > > Hi Luca,
 > > 
 > > Another reason might be: to be able to provide a library to a customer
 > > who doesn't know how or want to run make or install the tools.  And
 > > for that matter they just have a vanilla distribution of the LINUX on
 > > machines with out compilation support.
 > 
 > You can't expect such a client to have a working ffmpeg installed.
 > Anyway, the best solution in this situation is probably to provide a full
 > ffmpeg compiled to the customer.

Thats an excellent point.

Thanks
Marc