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

[mmh]

Michael Niedermayer writes:
 > Hi
 > 
 > On Mon, Jun 04, 2007 at 09:49:56PM -0400, mmh wrote:
 > > Michael Niedermayer writes:
 > >  > Hi
 > >  > 
 > >  > On Mon, Jun 04, 2007 at 09:04:43PM -0400, mmh wrote:
 > >  > > 
 > >  > > Hi,
 > >  > > 
 > >  > > I'm interested in understanding some specific details about the new
 > >  > > filter structure being implemented as part of the Google Summer of
 > >  > > Code Project.  Specifically, will this new package support something
 > >  > > similar to vhooks which provide the ability to bind filters at runtime
 > >  > > as shared objects?  I hope the answer is yes.  
 > >  > 
 > >  > no
 > >  > and any dependancy on .so or runtime loading is completely unaccpetable
 > >  > as some systems simply dont support dynamic loading or shared libs
 > >  > 
 > >  > also a filter system which can dynamically load filters as shared libs
 > >  > is not that usefull unless you want to support binary only filters
 > >  > but why should we support that? or even design anything toward making that
 > >  > easy to do?
 > >  > that said iam not against optionally supporting dynamically loaded .so 
 > >  > filters but i think this is not really worth the work ...
 > >  > 
 > >  > 
 > >  > > I'm also hoping
 > >  > > something similar for audio will exist and it doesn't just cover
 > >  > > video.
 > >  > 
 > >  > i too hope we will eventually have a audio filter layer but this years SOC
 > >  > project is just about video and that is by itself more than large enough
 > >  > task
 > >  > 
 > > 
 > > 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 propriatary filters supported _they_
 > can add optional .so support ...
 > 
Fine.

 > 
 > > 2. to add so architecture platform specific capability which is not available to other platforms.
 > 
 > ?

I guess its the same as #1,  with a poor choice of words.

Thanks
Marc