Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] Advanced Error Codes
Date: Thu, 3 Jul 2025 10:56:39 +0200
Message-ID: <aGZFx2W_fSnJ8Ik5@phare.normalesup.org> (raw)
In-Reply-To: <20250702171641.GF29660@pb2>

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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2025-07-03  8:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-02 14:43 Michael Niedermayer
2025-07-02 14:52 ` Nicolas George
2025-07-02 17:16   ` Michael Niedermayer
2025-07-03  8:56     ` Nicolas George [this message]
2025-07-03 15:52       ` Michael Niedermayer
2025-07-04 13:29         ` Nicolas George
2025-07-06 14:33           ` Michael Niedermayer
2025-07-02 17:21 ` Michael Niedermayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aGZFx2W_fSnJ8Ik5@phare.normalesup.org \
    --to=george@nsup.org \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git