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

[Michael Niedermayer]

On Sun, Dec 24, 2017 at 05:50:29PM +0100, wm4 wrote:
> On Sun, 24 Dec 2017 12:43:27 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > On Sun, Dec 24, 2017 at 02:31:16AM +0100, wm4 wrote:
> > > On Sun, 24 Dec 2017 02:06:40 +0100
> > > Michael Niedermayer <michael at niedermayer.cc> wrote:
[...]
> > 
> > > - 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  
> > 
> > I would love to see such a API and i would certainly contribute but
> 
> > as explained above, we dont have it and we dont really need it for
> > registering user codec to be usefull in practice IMO
> 
> Are you seriously arguing for API users to access internal API?

no. iam not arguing that anyone who has the choice should use internal
API. 


[...]

> 
> > There are more usecases. For example codec optimizations for niche
> > codecs where rejected on ffmpeg-devel.
> > I find it unfriendly from us if we reject improvments because they
> > arent in a area most of us care and then also drop the possibility
> > for externally maintaining and registering code without doing a
> > full fork (which is much more work to maintain)
> 
> What? We accept tons of obscure features and optimizations.
> 
> The only thing I remember that got consistently rejected were the HEVC
> optimizations - not because we didn't want them, but because they used
> intrinsics in x86 (instead of external asm), which we reject on
> principle. We (apparently) had bad experiences with them in the past,
> compiler support tends to be flaky, and performance of the generated
> code can depend much on used compiler and is not very predictable. You
> know very well that we have a policy to reject intrinsics and that we
> follow it for good reasons.
> 
> I'm not sure why you feel the need to distort the facts that much just
> to make some sort of passive aggressive sounding point about general
> dev/project practices.

What is distorted ?

The case i was thinking of and refered to should be this thread:
"[FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats."
The patch was as i said rejected
It was about a niche codec (cinepak)
It was an optimization as stated.
The rest of my statment was just what i find unfriendly, that is just
my oppinon.

Maybe that sounds "passive aggressive" i dont know, but then any self critique
could likely sound "passive aggressive" to someone


> 
> > >   
> > > > > +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.  
> > 
> > That can be done and there are many ways. Not saying we want to do it
> > first possibility, one can add a int "constant" to each AVCodec.
> > configure would have to choose these or there would be holes in the array.
> 
> That sounds complicated, how would configure modify each AVCodec struct
> (which are spread into hundreds of source files)?

It would generate a header with a list, enum or #define
the named identifers of that list would be used in the individual files


> 
> > a hashtable with a mutex is an option too but that seems not worth the
> > complexity / work
> > the 3rd obvious option is to make "next" a pointer to a int which is
> > initialized in each codec to some static int. Which can then be set
> > to the array index, the main struct can then remain in read only memory
> > iam pretty sure there are many more options
> 
> Not sure how these are better than just initializing the next pointer
> for now, until deprecation removes it.

It would allow the AVCodec to be in read only memory, not a major thing
at all, but thats one of the main advantages of removing the next pointer

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171225/324c9070/attachment.sig>