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".
next prev parent 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