[FFmpeg-devel] [PATCH] add colours to warnings and errors

Michael Niedermayer michaelni
Thu Apr 22 20:49:31 CEST 2010


On Thu, Apr 22, 2010 at 07:13:03PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Thu, Apr 22, 2010 at 01:25:33PM +0100, M?ns Rullg?rd wrote:
> >> James Darnley <james.darnley at gmail.com> writes:
> >> 
> >> > If your terminal isn't then you need to fix it.  This is looking
> >> > more and more like a Windows only feature.
> >> 
> >> We don't do windows-only features.  They rot too quickly.
> >
> > what rots is poorly maintained features. if someone promisses to maintain
> > this there is no reason not to consider it
> 
> History shows that windows-only features tend to rot.

yes because they havnt been maintained well not because they are windows
features


> 
> >> The real problem here is that the ffmpeg output is much too verbose by
> >> default.  Any error messages are easily masked by useless chatter.
> >> The usual Unix way is to print _nothing_ on success.  Then anything
> >> printed is an error or a warning.
> >
> > the log level is configureable.
> 
> Yes, I know -v -1 will shut up most of the messages, but 1) they are
> printed by default, and 2) there's a still an awful lot being spewed
> out.
> 
> > And the defaults should be what most people prefer, "the unix way"
> > is rarely what most people prefer.
> 
> Did you ask them?  FFmpeg currently prints:
> 
> 1.  FFmpeg version and copyright.  This is impossible to silence.
> 2.  Build date and compiler version.  Impossible to silence.
> 3.  configure options used.  Impossible to silence.
> 4.  Version of all libs, twice.  Impossible to silence.

these are there because we need them in bugreports, i dont mind at all
to disable them by default if it works out in the sense that people
will enable them for bugreports.
That is iam perfectly fine with trying such change for a while and
seeing if that works or not


> 5.  Input/output stream dump.
> 6.  Frame counter.
> 
> This usually amounts to 20-30 lines of useless information (most of
> the time it's just repeating what's already on the command line).  A
> one-line error message is easily lost in that jungle.
> 
> IMO the default output should be cut down to substantially as most of
> that is only useful for debugging problems.  We'd obviously insist on
> running with -v 1 (or something) for bug reports.

i disagree, the stream dump is usefull and giving the user some feedback
about what is done is usefull too. The user might that way spot a problem
sooner (like ohh shit wheres the audio stream its not listed ...)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100422/9a6d1472/attachment.pgp>



More information about the ffmpeg-devel mailing list