On Sun, 24 Dec 2017 02:06:40 +0100 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> If you and others agree we can also easily maintain support for user apps > to register codecs. The only thing needed is to make the array bigger and > add codecs which arent ours in there as long as there is space. > doing this would be very easy, a atomic integer pointing to the begin of > the free space which is atomically increased for each register is all that > is needed Not sure how often I repeated this (specifically for you), but: - users can't provide AVCodec, because it would require accessing internal API and private ABI unstable fields - if we provide the ability to add user codecs (which I'm not fundamentally against), then it should not modify global state. Having named user codecs in a process wide list would definitely lead to name clashes or other conflicts - also, we would have to provide stable/public API for implementing codecs in the first place (all AVCodec callback fields are private), and we're nowhere near the state of adding it - dropping avcodec_register() is definitely not the worst blocker for user codecs - it's very, very far from it, because once we have fixed the things above, we can just add a new public API for registering (which would have to have a different function signature to avoid global mutable lists). So I don't know why you complain. - these points are technical, not ideological Can you point out any user application which registers its own codecs (and this violates the API)? > > +AVCodec *av_codec_next(const AVCodec *c) > > +{ > > + pthread_once(&av_codec_next_init, av_codec_init_next); > > + > > + if (c) > > + return c->next; > > AVCodec->next should be removed as it makes the structs non constant That has to happen after a deprecation phase, unless you have an idea how to make av_codec_next() not O(n^2) without this. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel