[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