[FFmpeg-cvslog] r19787 - in trunk/libavcodec: aac.c aacenc.c ac3enc.c adpcm.c adxenc.c flacenc.c g726.c libfaac.c libgsm.c libmp3lame.c libopencore-amr.c libvorbis.c mpegaudioenc.c pcm-mpeg.c pcm.c roqaudioenc.c v...

[Reimar Döffinger]

On Sun, Sep 06, 2009 at 05:27:11PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > On Sun, Sep 06, 2009 at 04:58:13PM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > Apart from that, I am very unhappy about the way decoders, encoders,
> >> > muxers etc. get registered currently, only due to the "next" pointer all
> >> > of that has to stay in the .data section and making up about 100 kB and
> >> > constantly growing...
> >> 
> >> Do you have a suggestion for a portable alternative?
> >
> > Well, not without breaking the API.
> > But you can just use
> > struct codec_list {
> >     struct codec_list *next;
> >     const AVCodec *codec;
> > } first_codec;
> >
> > in principle. Admittedly this doubles the memory usage of the list
> > itself and the operation AVCodec -> list position becomes expensive
> > (that is one reason why I think it should/must involve breaking the
> > API), but at least all the other stuff AVCodec stuff can stay in .rodata
> > then.
> > Or do you see an issue that I missed?
> 
> That's not really an improvement IMHO.

Not having to load all the codec definitions from disk at startup just to register
them and then having to keep them around as dirty pages is not an improvement??
Of course if you assume that registering will always be done with locking you
could also use an array, possibly even with some extra optimizations in case
just avcodec_register_all is called... Not sure there is much of a point for that though.