[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...

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> 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.

It bothers me mildly as well, but not enough to motivate me to do
anything about it.

-- 
M?ns Rullg?rd
mans at mansr.com