[FFmpeg-devel] [PATCH] fail before printing output format

Baptiste Coudurier baptiste.coudurier
Fri Dec 4 21:26:40 CET 2009

On 12/04/2009 04:34 AM, Michael Niedermayer wrote:
> On Fri, Dec 04, 2009 at 02:11:38AM -0800, Baptiste Coudurier wrote:
>> On 12/1/09 4:54 PM, Baptiste Coudurier wrote:
>>> On 12/01/2009 04:49 PM, M?ns Rullg?rd wrote:
>>>> Baptiste Coudurier<baptiste.coudurier at gmail.com>  writes:
>>>>> On 12/01/2009 04:38 PM, M?ns Rullg?rd wrote:
>>>>>> Baptiste Coudurier<baptiste.coudurier at gmail.com>  writes:
>>>>>>> On 12/01/2009 04:31 PM, M?ns Rullg?rd wrote:
>>>>>>>> Baptiste Coudurier<baptiste.coudurier at gmail.com>  writes:
>>>>>>>>> Guys,
>>>>>>>>> Patch makes ffmpeg print error and fail before printing output
>>>>>>>>> format
>>>>>>>>> so the error is the last line printed on terminal, this should
>>>>>>>>> greatly
>>>>>>>>> help users who cannot find the error message in between.
>>>>>>>>> With patch:
>>>>>>>>> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
>>>>>>>>> '[Taka]_Naruto_Shippuuden_134_[480p][BCB62A7B].mp4':
>>>>>>>>> Duration: 00:23:24.77, start: 0.000000, bitrate: 1213 kb/s
>>>>>>>>> Stream #0.0(und): Video: h264, yuv420p, 848x480, 1081 kb/s, 119.88
>>>>>>>>> tbr, 360k tbn, 48 tbc
>>>>>>>>> Stream #0.1(und): Audio: libfaad, 48000 Hz, 2 channels, s16, 128
>>>>>>>>> kb/s
>>>>>>>>> Metadata
>>>>>>>>> major_brand : isom
>>>>>>>>> minor_version : 1
>>>>>>>>> compatible_brands: isom
>>>>>>>>> [mxf @ 0x13e34a0]unsupported video frame rate
>>>>>>>>> Could not write header for output file #0 (incorrect codec
>>>>>>>>> parameters ?)
>>>>>>>> With that patch it's impossible to see what the invalid format was.
>>>>>>> What do you mean by invalid format ?
>>>>>> The one that was rejected by the muxer, the one you removed the
>>>>>> printing of.
>>>>> I'd say it doesn't matter because it's the muxer duty to explain why
>>>>> it failed and to provide a clear and descriptive error message.
>>>> Well, they don't do that. Would it be possible to print the output
>>>> format before the muxer error instead? That way the error message
>>>> would be the last thing printed, and all the information would still
>>>> be there.
>>> Well the order must be: open encoder, write header, dump format.
>>> dump_format after write header because write header will update the
>>> stream timebases and that information is useful.
>>> Or the output format could be printed conditionnally, with verbose>  1
>>> for example.
>> Any other opinion about this ? I'd like to hear from people dealing
>> much with users. I just saw an user not seeing the error message once
>> again.
> iam certainly not one who deals much with users but i think ffmpeg has
> quite alot of users and there always will be someone who misses an
> error message. If their number can be reduced that would be great but
> that should not be at the expense of inconvenience to the more
> inteligent users and especially not the deveopers.

Well, it seems obvious that the developers know how to retrieve the 
information they need.
IMHO if 50% of users do not see the error message because there is 5 
lines of stuff they do not understand and don't care about, that is a 
quite big problem.

> Omiting information that we need in some bugreports could be a big
> inconvenience ...

Bug reports are asked with -v 99 so ideally the information we are 
talking about would be included with a verbose > 1 check.

Besides I personally find that quickly reading the last line that says 
"error <why>" the best way to know where to look first.

That's also why I rerun "make" without -j4  if there was an error, I 
have to real time nor interest of crawling down the terminal to catch 
the error.

I also find painful that gcc spits 2 terminals of error because only one 
character was fucked up.

> Printing the error message last without ommitig anything or making it
> show up in shiny red letters should solve this

I suddently fear about trying to use colors and be portable.

Printing the error message last is definitely what I want, and what the 
patch ultimately does. Do you suggest to buffer the output of dump_format ?

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

More information about the ffmpeg-devel mailing list