[FFmpeg-cvslog] r11202 - trunk/configure
Rich Felker
dalias
Wed Dec 12 20:24:21 CET 2007
On Wed, Dec 12, 2007 at 07:16:11PM +0100, Michael Niedermayer wrote:
> On Wed, Dec 12, 2007 at 12:15:22PM -0500, Rich Felker wrote:
> > On Wed, Dec 12, 2007 at 11:57:11AM -0000, M?ns Rullg?rd wrote:
> > > I see. Yes, that's probably possible, though I'd rather not spend time
> > > figuring out how to do it if we can get rid of these exports more easily.
> >
> > Indeed. Despite the binutils bug, we should be visciously removing any
> > public global vars anyway. They have high program startup cost
> > regardless of what linking mode is used (copy relocations or textrels
> > in the main program).
> >
> > If access to them is really needed, make a function that returns a
> > (hopefully const-qualified) pointer to the data. But I can't imagine
> > why a legitimate program would be peeking directly at these data
> > structures..
>
> some examples where this is currently used are
>
> av_log_level
> av_vlog
> currently we have wraper functions for these to set/get them
> originally i wanted to drop these functions, as can be seen by the
> #if LIBAVUTIL_VERSION_INT in log.{c,h}
> i guess we should just leave the more complex API or do you suggest that
> we change it to 2 functions to returning pointers to av_log_level and av_vlog?
I thought that stuff had been fixed to use the context and not global
vars....
> and then there are these
> first_avcodec like linked lists for formats and codecs
> these should be changed to some implementation independant access code like
>
> AVCodec avcodec_next(AVCodec *c){
> if(!c) return first_avcodec;
> else return c->next;
> }
Agree.
Rich
More information about the ffmpeg-cvslog
mailing list