[FFmpeg-devel] [PATCH] libavfilter: constify filter list

Michael Niedermayer michael at niedermayer.cc
Thu Feb 1 14:46:49 EET 2018


On Thu, Feb 01, 2018 at 02:43:56AM +0100, wm4 wrote:
> On Thu, 1 Feb 2018 02:06:52 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > On Wed, Jan 31, 2018 at 12:24:43PM +0100, wm4 wrote:
> > > On Wed, 31 Jan 2018 12:11:25 +0100
> > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > >   
> > > > On Wed, Jan 31, 2018 at 10:03:58AM +0100, wm4 wrote:  
> > > > > On Wed, 31 Jan 2018 09:08:23 +0100
> > > > > Tobias Rapp <t.rapp at noa-archive.com> wrote:
> > > > >     
> > > > > > On 30.01.2018 20:37, Michael Niedermayer wrote:    
> > > > > > > On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:      
> > > > > > >> On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
> > > > > > >> <michael at niedermayer.cc> wrote:      
> > > > > > >>> Its also a step away from supporting plugins.
> > > > > > >>> Why plugins matter ? Because having plugin
> > > > > > >>> support is a big advantage, it allows a much wider
> > > > > > >>> community to work on, write and maintain filters.
> > > > > > >>>
> > > > > > >>> With plugins, people can write filters that are
> > > > > > >>> written in languages other than C. Or filters which
> > > > > > >>> some developer in FFmpeg doesnt want. Or they can be
> > > > > > >>> maintained externally by people who just do not like us.
> > > > > > >>> Or by people who perfer a FOSS license different from
> > > > > > >>> LGPL/GPL/BSD. Iam sure others can come up with more
> > > > > > >>> reasons ...
> > > > > > >>>
> > > > > > >>> Of course avfilter_register() isnt enough for plugins
> > > > > > >>> but it or something equivalent is needed for plugins.
> > > > > > >>>
> > > > > > >>> So i would prefer if avfilter_register() stays supported
> > > > > > >>> indefinitly or in case a different system is written for
> > > > > > >>> plugins then until that system is in place.      
> > > > > > >>
> > > > > > >> It just returns error and logs error message that currently external
> > > > > > >> filter is unsupported. If someone wants to implement support for
> > > > > > >> external filter, it can be easily added later using separate
> > > > > > >> list/table.      
> > > > > > > 
> > > > > > > Iam not sure "easily" is true
> > > > > > > 
> > > > > > > We started out with a fully public API that allowed external filters.
> > > > > > > and little by little its removed or made private.
> > > > > > > each individual change may be easy to undo but as a whole moving
> > > > > > > libavfilter back to having a public API is not that easy anymore
> > > > > > > 
> > > > > > > IIRC the arguments to make things private where that people wanted to
> > > > > > > improve the API. But from the idea and impression of a plan like:
> > > > > > > 1. make it private
> > > > > > > 2. design and implement better API
> > > > > > > 3. make it public again
> > > > > > > 
> > > > > > > Somehow now people lost sight and interrest in 3. and even 2. is becoming
> > > > > > > less interresting. But the problem is really without 2 + 3 actually happening
> > > > > > > doing 1 seems like not a good idea at all.
> > > > > > > 
> > > > > > > To me it seems even mentioning external filters and public API makes some
> > > > > > > people angry.
> > > > > > > But really that has to be the goal at some point. To again have a public API      
> > > > > > 
> > > > > > I agree that having (again) a public filter API would be good. This 
> > > > > > would give users the freedom to implement their own special-purpose 
> > > > > > filters (see the "dumpwave" discussion).    
> > > > > 
> > > > > Someone needs to design and write it.
> > > > > 
> > > > > Whether we have external filters is completely orthogonal to this
> > > > > change.     
> > > >   
> > > > > They were not possible before, because not enough API for
> > > > > implementing them is public.     
> > > > 
> > > > This is correct if by "before" you mean today before this is applied.
> > > > But longer ago, as in years, it was possible
> > > > 
> > > >   
> > > > > They can be possible in the future, but
> > > > > then registering them would need a different API anyway (one that
> > > > > doesn't use global mutable state, but uses some sort of context
> > > > > instead).    
> > > > 
> > > > i understand that you arent a native english speaker nor am i but
> > > > what you write here is not true.
> > > > 
> > > > Several people desire to eliminate all "global mutable state"
> > > > and thats fine, iam happy if that is achieved. But its not
> > > > that its neccessary for a fully functional API register or otherwise.
> > > > The registering code with "global mutable state" and some form
> > > > of thread synchronization would work perfectly fine.
> > > > 
> > > > What exactly is in relation to registering the problem with 
> > > > "global mutable state" ?
> > > > 
> > > > One application registering a filter with a common name and another 
> > > > application unintentionally using that ?  
> > > 
> > > Yes. It's not library-safe.
> > >   
> > > > This is not even possible because each application is in its own process and
> > > > will have its own independant copy of libavfilter in its address space only
> > > > with "read only" pages shared or with pages with "copy on write".  
> > > 
> > > This is a library. There can be multiple users of a library in the same
> > > process.
> > >   
> > > > The "one registers the other uses it by mistake" issue is as far as i
> > > > understand only possible if an application uses libavfilter and that
> > > > application uses also a lib that itself uses libavfilter too or
> > > > similar cases. 
> > > > And then both mess with registering custom filters and using custom
> > > > filters.
> > > > That looks like a very rare situation. If thats the only issue, i would
> > > > really not say theres a "need" to avoid "global mutable state"  
> > > 
> > > I don't agree. It will cause problems you're not even thinking about
> > > now. Look at any library that thought global mutable state is fine for
> > > some thing, and what problems it caused. Besides someone will have the
> > > idea to create some sort of plugin loader, and then all bets are off.  
> > 
> > to awnser just
> >  "look at any library that thought global mutable state is fine for some thing,"
> > Well we can look at libavcodec and libavformat and libavfilters register
> > code. That existed since a long time and used global mutable state.
> > searching trac for 
> > "_register(" -> 1 match thats about the lock manager not the codec/format register
> > "av_register_output_format" -> no matches
> > "av_register_input_format" -> no matches
> > 
> > So as you requested, i looked at not just any library but at multiple
> > and at exactly the very identical case of registering.
> > Zero issues have occured there.
> > 
> > People hate "global mutable state" and i do not like it either but the
> > thing that its causing problems in this case is exagerated.
> 
> The problem so far has been easier, because you could NOT register user
> defined codecs/filters. So a whole class of problems falls away. You
> added all the atomics code to hack it into somewhat working yourself,
> so I'm not sure why you deny that it had problems.

How exactly does what i said:
"The registering code with "global mutable state" and some form of thread synchronization ..."
and
"but the thing that its causing problems in this case is exagerated."

can lead to that i deny that it has/had problems !?
I even explicitly aknowledge the atomic issue in what i said.

Of course the atomic issue is theoretical its not a bug that to the best
of my knowledge anyone ever managed to hit in reality.


[...]

> In fact, you probably merged the patch that deprecated/removed the
> public filter API _yourself_.

This is quite possible, but that would have happened in the belive that
it was temporary and that there soon will be a public API again. Either
one designed by libav or ffmpeg or the old API could be re-enabled if
neither occurs.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180201/02bf5238/attachment.sig>


More information about the ffmpeg-devel mailing list