[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 03:11:56PM +0200, Diego Biurrun wrote:
> On Sun, Sep 06, 2009 at 11:25:06AM +0200, Reimar D?ffinger wrote:
> > While I think it is still a good change, it may have been a bit silly,
> > since gcc still seems to be unable to place those compound literals in
> > .rodata, they still end up in data (a quick search indicates this was
> > first reported against gcc 3.0.3 and nobody cared...).
> 
> There's always hope for better compilers...

You gave me an idea, and indeed 64 bit icc 11 does put it into .rodata
now but not before this change.
So since there is a benefit I might continue these kind of changes e.g.
for pix_fmts, complain ASAP if you object or want to see a patch first.
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...