[FFmpeg-devel] [RFC] Advanced Error Codes

[Nicolas George]

Michael Niedermayer (HE12025-07-02):
> its a bit fuzzy, for example
> AVERROR(EAGAIN) is for the program
> but AVERROR_PATCHWELCOME is for the developer
> while AVERROR_PROTOCOL_NOT_FOUND is for the one building the lib
> and a EOF is for the one supplying the input file

Indeed, but my point stands: the developer can read, the one building
the lib can read, the one supplying the file can read, because they are
humans. Only the program cannot read, and therefore error codes should
be only for the program.

> The av_log() messages work for a specific use case, that is
> command line tools and for advanced users and developers who are not
> intimidated by going through log files.
> AND have the time to go through the log files
> 
> They do not work that well in many cases

av_log() sucks. We need to get rid of it for everything above level
verbose.

> Consider this:
> * You want to make a list of all "failure to decode" reasons of h264 files
> - The current error codes are useless (always INVALIDDATA), the messages
>   come without synchronization from multiple threads, its not possible
>   to reliably pick the root failure reason out of these for a decode()
>   caller
> + With what i suggested, this is solved, you get a int64 code, you can look
>   it up and you know what the cause of the failure was, in what source file and
>   location it was and so on

With what I suggest, this is solved even better: you get an error
message, you do not need to look up a code in a table to get an error
message.

> * A GUI Player or Transcoder hits an error
> - The current error codes are useless (maybe INVALIDDATA again)
>   maybe the GUI can present the user with a log window, but the last 3 might not
>   be the relevant error messages
> + With what i suggested, you get a int64 code, you can look
>   it up and you know what the cause of the failure was, in what source file and
>   location it was, what URL caused it maybe and so on and the GUI can
>   take this and cleanly present it to the user in a error message box

Same here: no need for a code, just write the error message.

To be clear, you suggest, IIUC:

- The developer registers the error code.
- The developer writes the explanation for the error when registering
  the error code.
- The developer uses the error code when returning the error.
- The user gets an error code.
- The user looks up the error code to get the explanation for the error.

What I propose:

- The developer writes the explanation for the error when returning the
  error.
- The user gets the explanation for the error directly.

Or, in terms of code:

return AVERROR_MESSAGE(ctx, "Garbled foobar data at offset ${offset}",
    "offset", ctx->offset, NULL);

Regards,

-- 
  Nicolas George