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

[Baptiste Coudurier]

On 04/22/2010 07:59 PM, Rodney Baker wrote:
> May I provide some feedback on this from the point of view of a user who uses
> ffmpeg in a number of scripts for automating conversion processes?
>
> On Fri, 23 Apr 2010 04:19:31 Michael Niedermayer wrote:
>> [...]
>>>
>>> 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
>>
>
> I agree. Most of the time (when things work write) this information falls into
> the "don't care" category. A clearly documented option to enable these for bug
> reports is necessary, but otherwise they should be silenced.

Well given how many complete bug reports we get on the bug tracker, I'm 
not sure it is best solution. Since users don't seem to read what is 
written anyway, I would deduce that they don't care that much.

IMHO removing information valuable to us in order to fix bugs, will only 
make situation worse than it is.

The BIG RED COLOR is however clearly the best solution to hope to get 
some users read what is written.

>>> 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 ...)
>>
>> [...]
>
> Again, I agree. The I/O stream dump and frame counter should be shown by
> default, but perhaps an option to silence them (and/or dump them to a user-
> specified log file) would be useful.
>

frame counter can be silenced already.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org