[FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

Michael Niedermayer michael at niedermayer.cc
Tue Mar 7 17:54:24 EET 2017


On Tue, Mar 07, 2017 at 03:04:14PM +0100, wm4 wrote:
> On Tue, 7 Mar 2017 14:37:27 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > On Tue, Mar 07, 2017 at 07:44:43AM +0100, wm4 wrote:

[...]

> > The real problem behind all this is of course more complex and a
> > combination of many of our developers being rather aggressive and
> > having strong oppinions on code outside the area they actively maintain.
> 
> So devs who don't maintain a specific part of the code don't get to
> have a "strong" opinion? I guess only a weak opinion is wanted, at most?

Whats wanted is, what works. And with an increasing number of
developers with strong and different oppinions come increasing
conflicts. A possible solution would be strict rules on who has authority
over which part of the code or people being alot more tolerant than
they are. The end result either way would be that code like the
cinepack optimzations would be accepted but thats exactly what many
people dont want. And thats where the dilemma is and i have no awnser
or solution here. What i think though is
When people leave then "what was done" didnt work.
We can try to learn out of this or we can continue as we did previously.
And it all probably boils down to seeing other peoples needs and
accepting them vs. accepting to loose some of them.
But quite possibly there are solutions i fail to see ...


>
> If you argue this way, we'd have to put maintainership of central code
> under multiple developers or so.
> 
> > That drives some contributors away
> 
> Which ones?

> The Cinepak thing was clearly rejected, and the patch
> author couldn't deal with it. If that's all it takes to run away,

well, yes, but is that surprising?
Volunteers work in the environment where they are welcome and where
their contributions are welcome. If one community is rejecting a
sgnificant part or the work one cares about, moving to a different
community, field or area is the obvous option


> he probably wasn't meant to contribute to a big project with many
> developers anyway.

> (Funny how the Cinepak maintainer never even showed
> up - tells a lot about our MAINTAINERS file?)

would it help if he did ?
I think he couldnt have done much had he jumped into the discussion



[...]
> >
> > I would very much like to see some effort to add a real plugin
> > interface instead of the opposite direction
> 
> Go ahead and propose one? But if it forces too much private API to be
> exposed, then it'd make FFmpeg development harder, because we'd have to
> guarantee stability of those internal APIs until the next major bump,
> and it'd be near-useless for outside developers because they had to fix
> their plugins every major bump.
> 
> I think the thing that's wrong with FFmpeg API is that its APIs are not
> designed for long-time API and ABI stability. That would be a good
> place to start.
> 
> A realistic approach to supporting plugins would probably be to create
> a separate API, which translates the required calls to the internal
> API, but which is designed in a way that can be supported for a long
> time. Rather low-level (and low-feature) examples would include the
> ladspa and frei0r libavfilter wrappers.

Personally i would prefer internal codecs and plugins to use the same
API, but thats a detail. I am happy with any plugin API that works
and that people are happy with.

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- 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/20170307/37f6736f/attachment.sig>


More information about the ffmpeg-devel mailing list