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

Michael Niedermayer michael at niedermayer.cc
Fri Dec 23 22:02:09 EET 2016


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.

new developers join, older ones leave, peoples goals and oppinions
change. The libavfilter API is based on the lessons learned from
previous projects and frameworks, in that way this codebase has a quite
long timeline and many experienced developers from multiple other
free software projects upon whos shoulders this rests in some sense.

If we only make the API public once the ultimate global optimum is
reached we will never do so.
What iam asking for is not that you declare a API public that you
intend to change but that we commit to declaring the API public in the
reachable future and not as a goalline that keeps shifting farther
into the future forever.
you may eventually be happy with the API in libavfilter but by the time
others with other goals and oppinions will just start their journy.

Also making the API public should be a real goal and be considered in
the steps taken 

For example if AVFilterLink isnt intended to be substantially changed
and is intended to be public when the API becomes public
then i dont see why it should not stay public
making it private, rewritig code, adding public accessors just to
then make it public again and deprecate the accessors is a huge
amount of wasted time.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161223/9a837be3/attachment.sig>


More information about the ffmpeg-devel mailing list