On Sun, Dec 24, 2017 at 05:50:29PM +0100, wm4 wrote: > On Sun, 24 Dec 2017 12:43:27 +0100 > Michael Niedermayer <mich...@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 <mich...@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
