[FFmpeg-cvslog] r26289 - trunk/libavcodec/truemotion2.c

Stefano Sabatini stefano.sabatini-lala
Tue Jan 11 08:55:42 CET 2011


On date Tuesday 2011-01-11 02:31:01 +0100, Michael Niedermayer wrote:
> On Mon, Jan 10, 2011 at 06:56:35PM +0100, Reimar D?ffinger wrote:
> > On Mon, Jan 10, 2011 at 02:58:49PM +0100, Michael Niedermayer wrote:
> > > On Mon, Jan 10, 2011 at 08:12:57AM +0200, Kostya wrote:
> > > > On Sun, Jan 09, 2011 at 09:41:52PM +0100, Stefano Sabatini wrote:
> > > > [...]
> > > > > 
> > > > > People, plese try to use meaningful error codes, they help calling
> > > > > code to detect and report which is the cause of the problem, -1
> > > > > corresponds to EPERM which is not the correct reason most of the
> > > > > times.
> > > > 
> > > > This idea has not been bikeshedded enough. But in general who cares what
> > > > error was returned by decoder? -1 is just our way to say "generic error,
> > > > we don't care about actual code"
> > > 
> > > agree
> > 
> > I understood the intial mail to mean that the main problem is that applications
> > that try to make the value into an error string end up claiming the error was
> > "permission denied", which can be really confusing.

$ ffmpeg -i foo.avi -t 0 foo.nut
...
$ ffplay foo.nut
[...]
[nut @ 0x9feadb0] EOF before video frames
slow.nut: Operation not permitted

check cmdutils.c:print_error
 
> I wonder if theres any code that does anything with these error codes
> programatically reacting on them beyond EAGAIN seems hard
> and printing a "whatever error" might look akward in addition and below
> of a much more verbose av_log error message
> is any application doing that?
>
> Note, iam not at all saying the codes should not be improved ...



More information about the ffmpeg-cvslog mailing list