[MPlayer-dev-eng] [PATCH] OpenDML AVI2.0 read support

[D Richard Felker III]

On Sat, Feb 07, 2004 at 11:16:42PM +0100, Arpi wrote:
> Hi,
> 
> > D Richard Felker III writes:
> >  > On Fri, Feb 06, 2004 at 05:51:14PM -0500, The Wanderer wrote:
> >  > > Should the printf() calls be changed in things like libavcodec,
> >  > > libfaad2, mp3lib and so forth?
> >  > 
> >  > Yes, most certainly! Any lib that calls printf is just plain broken.
> >  > stdout does not belong to libs!!
> > 
> > This would be against current policy as I understand it.  External
> > libs should be modified as little as possible to make syncing to newer
> > versions easier.  AFAIK mp_msg is only used in our internal libs
> > because of this and a quick grep through the sources confirms this...
> 
> Sure. Any code syncronized to external code/source ("upstream") should
> not be modified at all, or at the very minimum rate (the required
> changed to compile/work in mplayer tree, as unmodified libs arent
> in mplayer tree at all)
> 
> mp3lib is a good question, some parts of it were developed in/for
> mplayer, only layer*.c and a few .h files and tables come from mpg123.
> since mpg123 is not developed for years, it may be changed if needed.

If you insist we can add -Dprintf(...)=etc to the Makefile or
something for these broken libs, but I'm totally against leaving any
printf's in place.

> but for libmpdvdkit, libavcodec, liba52, libmpeg2, libdha/vidix, libfaad2
> shouldn't be changed.

RTFa! libavcodec already has a proper logging mechanism, av_log, which
the caller can set to an arbitrary callback. So any printf remaining
in libavcodec is a BUG!! As for the others, if it's fprintf(stderr)
I'm not entirely opposed to leaving it alone, but printf to stdout is
totally unacceptable. Once this is cleaned up, it should be possible
for mplayer/mencoder to output data to stdout (with appropriate
options to tell mp_msg to be quiet or use stderr) which would be very
useful!

Rich