* [FFmpeg-devel] [RFC] Advanced Error Codes
@ 2025-07-02 14:43 Michael Niedermayer
2025-07-02 14:52 ` Nicolas George
2025-07-02 17:21 ` Michael Niedermayer
0 siblings, 2 replies; 4+ messages in thread
From: Michael Niedermayer @ 2025-07-02 14:43 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 4418 bytes --]
Hi
People are asking for better error codes
Heres a quick pseodocode design / implementation / brainstorming:
I hope iam not re-doing some past one but i didnt quickly find a past discussion
Observations.
Errors are for developers debuging or users resolving problems
We rarely care about more then 2-3 independant errors but we care about their history like from where they came and how and what arguments caused them
We also care about the error free case being fast, really fast
We are lazy we dont want maintaince burden
We also dont want to deal with maintaining matching cleanup for each generated error
Idea 1
+ very simple
+ fully compatible can be freely mixed with existing error codes
- needs a global table
+ we never alloc, so we have no cleanup to do
+ zero overhead for passing around as its just integers
Idea 2 (Alternatrive)
This is exactly like Idea 1 but using thread local instead of a global tabl
+ No mutex
+ no global table
+ no denial of service if a thread blasts errors out while another has an occasional error
- Thread local table
- More complex and slow to move errors accross thread boundaries
For both ideas:
* New error codes are 64bit
* if they are trunctaed to 32bit they are a valid 32bit error code like AVERROR(EIO)
* That means the new error codes are 32bit (existing error code for compatibility) and
32bit (a identifier into a fixed size table.)
Pseudocode:
#define MAX_CONCURRENT_ERRORS 256 // error 256 will use slot 0, 257 slot 1 and so on
#define MASK (MAX_CONCURRENT_ERRORS - 1)
#define FREE_FORM_LEN 64 //probably we will need more, can just be bumped
typedef struct AdvancedError {
const char *error_name; ///< like "Timeout" or "Invalid Bitstream"
const char *operation_name; ///< like "Network Read" or "H.264 block parsing"
const char *source_filename; ///< like ffmpeg.c
int source_line_number; ///< like line 123 in ffmpeg.c
char free_form_description[FREE_FORM_LEN]; ///< anything extra that doesnt fit in pointers to static const strings
int64_t this_error;
int64_t previous_error; ///< A previous related error, if any
int64_t timestamp; ///< Timestamp at which the error occured
int thread_id;
} AdvancedError;
struct AdvancedError advanced_error[MAX_CONCURRENT_ERRORS]; // the whole is 32kb ATM
int64_t av_adv_err_new(int error_code,
const char *error_name,
const char *operation_name,
const char *source_filename,
int source_line_number,
int64_t previous_error,
const char free_form_description[FREE_FORM_LEN],
) {
pthread_mutex_lock()
int64_t err = error_code + (counter++ << 32);
AdvancedError *ae = &advanced_error[(err>>32) & MASK];
ae->error_name = error_name;
ae->operation_name = operation_name;
ae->source_filename = source_filename;
ae->source_line_number = source_line_number;
ae->this_error = err;
ae->previous_error = previous_error;
ae->timestamp = av_gettime();
memcpy(ae->free_form_description, free_form_description, FREE_FORM_LEN);
pthread_mutex_unlock()
return err;
}
/**
* Retrieve AdvancedError struct for a given error code or fail
* @param adv_err [OUT] where to store the AdvancedError in
*
* @return 0 on success negative on failure
*/
int av_adv_err_retrieve(int64_t err, AdvancedError *adv_err) {
int ret = -1;
pthread_mutex_lock()
int index = err >> 32;
if (advanced_error[index & MASK].this_error == err) {
memcpy(adv_err, &advanced_error[index & MASK], sizeof(adv_err));
ret = 0;
}
pthread_mutex_unlock()
return ret;
}
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [FFmpeg-devel] [RFC] Advanced Error Codes
2025-07-02 14:43 [FFmpeg-devel] [RFC] Advanced Error Codes Michael Niedermayer
@ 2025-07-02 14:52 ` Nicolas George
2025-07-02 17:16 ` Michael Niedermayer
2025-07-02 17:21 ` Michael Niedermayer
1 sibling, 1 reply; 4+ messages in thread
From: Nicolas George @ 2025-07-02 14:52 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Michael Niedermayer (HE12025-07-02):
> People are asking for better error codes
I have little time just now, but I think it is important to clarify:
- Error CODES are for when the program must react specifically to a
certain kind of error condition:
if (ret == AVERROR(EAGAIN)) …
- Error MESSAGES are to say to the user what went wrong.
There is a confusion because error codes also serve as stock error
messages.
I think what we need is better error messages and accompanying
reporting. I have a lot of thoughts about this, I will comment when I
have more time. (Spoiler: it depends on AVWriter.)
I do not think we need better error codes.
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".
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [FFmpeg-devel] [RFC] Advanced Error Codes
2025-07-02 14:52 ` Nicolas George
@ 2025-07-02 17:16 ` Michael Niedermayer
0 siblings, 0 replies; 4+ messages in thread
From: Michael Niedermayer @ 2025-07-02 17:16 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 2521 bytes --]
Hi Nicolas
On Wed, Jul 02, 2025 at 04:52:58PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-07-02):
> > People are asking for better error codes
>
> I have little time just now, but I think it is important to clarify:
>
> - Error CODES are for when the program must react specifically to a
> certain kind of error condition:
>
> if (ret == AVERROR(EAGAIN)) …
>
> - Error MESSAGES are to say to the user what went wrong.
>
> There is a confusion because error codes also serve as stock error
> messages.
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
>
> I think what we need is better error messages and accompanying
> reporting. I have a lot of thoughts about this, I will comment when I
> have more time. (Spoiler: it depends on AVWriter.)
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
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
* 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
[will send 2nd mail to keep this clearer]
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [FFmpeg-devel] [RFC] Advanced Error Codes
2025-07-02 14:43 [FFmpeg-devel] [RFC] Advanced Error Codes Michael Niedermayer
2025-07-02 14:52 ` Nicolas George
@ 2025-07-02 17:21 ` Michael Niedermayer
1 sibling, 0 replies; 4+ messages in thread
From: Michael Niedermayer @ 2025-07-02 17:21 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 2759 bytes --]
On Wed, Jul 02, 2025 at 04:43:55PM +0200, Michael Niedermayer wrote:
> Hi
>
> People are asking for better error codes
> Heres a quick pseodocode design / implementation / brainstorming:
> I hope iam not re-doing some past one but i didnt quickly find a past discussion
>
> Observations.
> Errors are for developers debuging or users resolving problems
> We rarely care about more then 2-3 independant errors but we care about their history like from where they came and how and what arguments caused them
> We also care about the error free case being fast, really fast
> We are lazy we dont want maintaince burden
> We also dont want to deal with maintaining matching cleanup for each generated error
>
> Idea 1
> + very simple
> + fully compatible can be freely mixed with existing error codes
> - needs a global table
> + we never alloc, so we have no cleanup to do
> + zero overhead for passing around as its just integers
>
> Idea 2 (Alternatrive)
> This is exactly like Idea 1 but using thread local instead of a global tabl
> + No mutex
> + no global table
> + no denial of service if a thread blasts errors out while another has an occasional error
> - Thread local table
> - More complex and slow to move errors accross thread boundaries
>
> For both ideas:
> * New error codes are 64bit
> * if they are trunctaed to 32bit they are a valid 32bit error code like AVERROR(EIO)
> * That means the new error codes are 32bit (existing error code for compatibility) and
> 32bit (a identifier into a fixed size table.)
[...]
After reading Nicolas reply i think this can be described in a different way:
I think there are
1. Messages (Human language but also nummeric information)
2. Error codes (categorizing errors, some of which are usefull to programs,
some to specific users)
3. Error instance identifiers (which identify the specific error and allow us to
associate messages and other things with it)
What my suggestion really was, is to expand error codes in a 100% compatible
way to become error instance identifiers.
Which can then be used to lookup additional information for this specific
instance of an error
Or you could see it like this:
before my suggestion:
returned errors are broad categories
after
returned errors are identifying a specific individual error (with input, URL
source code location call stack and anything one wants to add to teh struct)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-07-02 17:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-02 14:43 [FFmpeg-devel] [RFC] Advanced Error Codes Michael Niedermayer
2025-07-02 14:52 ` Nicolas George
2025-07-02 17:16 ` Michael Niedermayer
2025-07-02 17:21 ` Michael Niedermayer
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