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

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