On Thu, 5 May 2016 02:26:09 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> > This is quite a hack, and we should not add new APIs to support it, in > > my opinion. I think you will have a hard time finding support in an open > > source project for adding or re-adding APIs to make internal forks easier > > to maintain (and it is an internal fork as far as I am concerned; it must > > cannibalize internal headers and APIs to implement these). I understand > > your plight from a maintenance point of view for existing internal code, > > but I don't think this is the sort of thing to burden a widely used open > > source API with. I have a hard time thinking of any other use cases for > > such a program. > > i always liked to allow and support "Plugins" / externally registering > stuff, but my oppinion on that is the minority AFAIK I wouldn't be opposed to it, but if we did that today, the result would be chaos and misery for decades. Because internally there are no clean and well-defined mechanisms for anything. (The current public API is already hard enough to maintain.) If you want plugin-ization, you'd have to make a significant effort to define a clean API for it, not just expose internal APIs. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
