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

[Michael Niedermayer]

On Fri, Dec 23, 2016 at 11:46:07PM +0100, Nicolas George wrote:
> Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> > shouldnt there be a public annoncement about the intend to make the API public
> > shouldnt there be a public call for API design suggestions and discussion
> > shouldnt there be a public call for API related patches with deadline
> > shouldnt there be a go/no-go poll of the FFmpeg developers
> 
> I am not sure what you are angling at here. I announced my projects to
> rework the internal workings and global API when I started working on
> making request_frame non-recursive (note: request_frame, not
> filter_frame; this patch landed more than a year ago) and mentioned them
> several times since then, for example when Paul considered working on
> threading IIRC. I did not gave that much details because nobody seemed
> interested in them.
> 
> And of course, no significant change in API or design went in without
> staying for quite a time on the mailing-list.

you snipped the context and reply to the quote as if it was meant
in a different context.
Not everyone intends to attack you :)

The quoted text are the steps which IMHO make sense to design a
API and to then make it public. What you talk about are the steps that
make sense to get the changes you want in.
theres nothing wrong with that it just has a differnt goal and i
thought we talk about the other.


> 
> > I dont think a wait period makes sense. By the time everyone is ok
> > with making the API public the code will have been more then
> > extensivly tested and waiting further would likely add little
> 
> So you are saying that the wait period will take care of itself even if
> we do not decide to enforce it. I am ok with it.
> 

> And, after all, what do you want, concretely?

as you ask ...

Id like to see libavfilter be less centralized, id like to be able
to write a filter and know that if it gets rejected on ffmpeg-dev that
i can still publish it on my own git repo and everyone could easily use
it. (as with plugins which could have bin packages in distros for easy
use not requireng users to patch / merge source)
This is an especially annoying situation when theres a consulting job
and then someone decides to demand some change which practically is
preventing the actual usecase one is paid for to be solved.

If its not a consulting job droping some patch isnt a huge
problem if a reviewer is stubborn and insists on something which is
unpractical.
But if one is doing the work for someone else, droping a patch is much
more annoying. Being able to create a plugin sidesteps this.


> 
> I, personally, am not working on making external filters possible. But I
> am not preventing it either. (Well, this patch makes it a little bit
> more work, but just work, not hard.) And I think that when I am done
> with my plan, it will be actually easier because a cleaner internal API
> is easier to make public.
> 
> Another point: this particular patch, and the series that surrounds it,
> I do not really want it. For all I care, we could drop it (either all
> the series, or just 5-6 because 1-4 make the code clearer).
> 

> On the other hand, Andreas, Clément, Hendrik and James would not be
> happy, because they insisted to hide the innards of AVFilterLink more
> deeply after the filter_frame patch. This was discussed on the mailing
> list. I probably should let you discuss the issue with them. The code is
> written, it did not take much time and does not interact with my current
> work: it can be applied or dropped indifferently.

My oppinion is that If we intend to have AVFilterLink public in the
future then making it private now is a bad idea and wasted time.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/20161224/bf924692/attachment.sig>