From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id BDFE84FBE8 for ; Thu, 3 Jul 2025 08:56:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 6249E68E891; Thu, 3 Jul 2025 11:56:47 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 15FA268D085 for ; Thu, 3 Jul 2025 11:56:40 +0300 (EEST) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 5638udDB024675 for ; Thu, 3 Jul 2025 10:56:39 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id 4BC802EFE3; Thu, 3 Jul 2025 10:56:39 +0200 (CEST) Date: Thu, 3 Jul 2025 10:56:39 +0200 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20250702144355.GE29660@pb2> <20250702171641.GF29660@pb2> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250702171641.GF29660@pb2> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Thu, 03 Jul 2025 10:56:39 +0200 (CEST) Subject: Re: [FFmpeg-devel] [RFC] Advanced Error Codes X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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".