[FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers

[wm4]

On Sun, 24 Dec 2017 02:06:40 +0100
Michael Niedermayer <michael at 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.