[FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

wm4 nfxjfg at googlemail.com
Mon Jan 9 11:50:34 EET 2017


On Fri, 23 Dec 2016 21:02:09 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Fri, Dec 23, 2016 at 06:51:38PM +0100, Nicolas George wrote:
> > Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :  
> > > libavfilter had a public API that allowed filters to be implemented
> > > these changes move it farther away from it
> > > I do care about having some public API that allows filters
> > > to be implemented.
> > > You pointed out that you work alone and people dont review your lavfi
> > > patches. I think if you integrate others goals more people would
> > > 
> > > For example your plans can stay the same but include the declared
> > > goal of making the API public once they are all done. And suddenly
> > > i would be interrested in this. Of course it doesnt make days
> > > have more hours or my todo shorter but pushing the public API away
> > > makes me loose interrest for sure.
> > > 
> > > Other people might have other ideas and goals too, which they want
> > > lavfi to achieve.
> > > If more things can be integrated more people might contribute ...  
> > 
> > You misunderstood: I am not excluding an API to allow external filters,
> > I am saying that it is too soon to think about it. The way filters must
> > be written is in a complete rework. Once it is stabilized, tested
> > extensively, we know it will not changing again, then we can make parts
> > of it public to allow external filters.
> > 
> > Anything else would be a compatibility nightmare. Do you not agree?  
> 
> APIs in FFmpeg will change as long as the project is alive.
> 

A public API for something as complicated and far-reaching as external
filters or codecs should be tiny and concise, not expose the current
internal API-vomit we have to the world.


More information about the ffmpeg-devel mailing list