[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 07:34:52PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > 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??
> 
> Is that really much of an issue?

No, but it still annoys me every time I see it.