[FFmpeg-devel] [PATCH] Move error codes definitions from lavc to lavu

Stefano Sabatini stefano.sabatini-lala
Sun Mar 7 15:32:00 CET 2010


On date Thursday 2009-07-30 01:27:54 +0200, Stefano Sabatini encoded:
> On date Tuesday 2009-07-21 04:04:32 +0200, Michael Niedermayer encoded:
> > On Tue, Jul 21, 2009 at 01:54:39AM +0200, Stefano Sabatini wrote:
> > > On date Monday 2009-07-20 17:24:45 +0200, Michael Niedermayer encoded:
> > > > On Sun, Jul 19, 2009 at 12:09:16PM +0200, Stefano Sabatini wrote:
> > > > > Hi, as in subject,
> > > > > 
> > > > > this is required if we want for example move the error handling code
> > > > > to lavu, as it uses it. Also reduces the clutter in avcodec.h.
> > > > 
> > > > i am fine with the move in priciple but didnt we want to deprecate the
> > > > AVERROR_* macros in favor of AVERROR(E*) ?
> > > 
> > > What about AVERROR_PATCHWELCOME?
> > 
> > that has no E* so it can stay
> 
> Fine.
>  
> > > 
> > > Also how AVERROR(XXX) is better than AVERRROR_XXX?
> > 
> > it needs less code
> > 
> > 
> > > 
> > > Also are we sure mapping A/V multimedia specific errors to POSIX
> > > errors is a good idea?
> > 
> > Without an alternative suggestion its hard to say ...
> 
> My idea is to use AVERROR(EXXX) for each error which can be specified
> using POSIX error codes, *then* having a minimal but meaningful list
> of AVERROR_XXX FFmpeg error codes.
> 
> For example:
> AVERROR_PATCHWELCOME
> AVERROR_NO_OPTION_FOUND
> AVERROR_UNSUPPORTED_FORMAT
> AVERROR_VBV_FAILURE
> 
> and a corresponding av_errstring() func.
> 
> > > Also how can we say that e.g. -MKTAG('P','A','W','E') doesn't clutter
> > > with a POSIX error code?
> > 
> > we cannot but it works with all systems for which ive seen E* values
> > and a clash is exceedingly unlikely (1 in many millions) if a clash
> > happens we just change it and bump major ver, given the low likeliness
> > of conflict this seems acceptable to me but i guess some will disagree
> 
> Not very fine but acceptable (we may change idea in a distant? future).
> 
> > > Also the use of the POSIX error codes is arguable (ENOENT is used for
> > > example when we don't find an option in a context, doxy is "No such
> > > file or directory"), EILSEQ -> "unknown format", EDOM -> "Number
> > > syntax expected in filename".
> >
> > > Also how can we map an error code to an error message?
> > 
> > by writing a function that does that
> >
> > 
> > > 
> > > All these questions raise the old problem of how to deal more sanely
> > > with errors in libav*... and since I don't want to get stucked there,
> > 
> > what old problem exactly do you refer to here?
> > which issue number on roundup is it?
> 
> No roundup issue, but the issue has been discussed sometimes in the
> past (mainly proposed by Takis or me):
> 
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/54380
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/68265/focus=78180

It seems we agree to choose when possible error codes borrowed from
POSIX, otherwise use the -MKTAG trick for creating FFmpeg specific
error codes.

This also means that we should drop all the AVERROR_* macros which
have a corresponding code in POSIX.

Then we have to deal with the FFmpeg specific error codes. Actually
we have just one of them (AVERROR_PATCHWELCOME).

Possible idea:

#define AVERROR2(a, b, c, d) -MKTAG(a, b, c, d)
then we could use it like:
        return AVERROR2('P','A','W','E');

*or* we could keep:

#define AVERROR_PATCHWELCOME    -MKTAG('P','A','W','E')
and simply use:
        return AVERROR_PATCHWELCOME.

I really have no idea what would be better.

As for the error string something like the following should fit:

int av_strerror(int errcode)
{
   switch (errcode) {
       AVERROR_PATCHWELCOME:
           return "Not yet implemented in FFmpeg. Patches welcome.";
       AVERROR_BIKESHED:
           return "Invalid color or argument or flavor selected, mine is better.";
       AVERROR_NOTENOUGHMONEY:
           return "You have to pay more buck$ for enabling this feature.";
       ...
       default:
          return strerror(errcode); 
   }
}

As for the retrocompatibility issue, we could just ifdef the old
AVERROR_* definitions and drop them at the next major bump.

See attached patch.

Regards.
-- 
FFmpeg = Fabulous and Faithful Mastering Peaceless Enigmatic Geisha



More information about the ffmpeg-devel mailing list