* [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; 8+ 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] 8+ 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; 8+ 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] 8+ messages in thread
* Re: [FFmpeg-devel] [RFC] Advanced Error Codes
2025-07-02 14:52 ` Nicolas George
@ 2025-07-02 17:16 ` Michael Niedermayer
2025-07-03 8:56 ` Nicolas George
0 siblings, 1 reply; 8+ 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] 8+ 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; 8+ 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] 8+ messages in thread
* Re: [FFmpeg-devel] [RFC] Advanced Error Codes
2025-07-02 17:16 ` Michael Niedermayer
@ 2025-07-03 8:56 ` Nicolas George
2025-07-03 15:52 ` Michael Niedermayer
0 siblings, 1 reply; 8+ messages in thread
From: Nicolas George @ 2025-07-03 8:56 UTC (permalink / raw)
To: FFmpeg development discussions and patches
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [FFmpeg-devel] [RFC] Advanced Error Codes
2025-07-03 8:56 ` Nicolas George
@ 2025-07-03 15:52 ` Michael Niedermayer
2025-07-04 13:29 ` Nicolas George
0 siblings, 1 reply; 8+ messages in thread
From: Michael Niedermayer @ 2025-07-03 15:52 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 1743 bytes --]
Hi
On Thu, Jul 03, 2025 at 10:56:39AM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-07-02):
[...]
> 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.
no, just:
return av_adv_err_new(AVERROR_INVALIDDATA, "Garbled foobar data", "Foo triangle quantum decoder"
__FILE__, __LINE__, NULL, "Whaetver you like %s", favorite_food);
teh return type is int64_t here
this also cannot fail as it allocates nothing
it also needs no context but would use a mutex or thread local storage
the message length would be bound by a maximum, set at compile time
and the number of messages that this keeps track of also would be
bound by a maximum, set at compile time
>
> 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);
I am not sure if passing a context around is going to find the volunteers
to implement and maintain. Also it has a performance impact for small and
lightweight functions.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
For a strong democracy, genuine criticism is necessary, allegations benefit
noone, they just cause unnecessary conflicts. - Narendra Modi
[-- 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] 8+ messages in thread
* Re: [FFmpeg-devel] [RFC] Advanced Error Codes
2025-07-03 15:52 ` Michael Niedermayer
@ 2025-07-04 13:29 ` Nicolas George
2025-07-06 14:33 ` Michael Niedermayer
0 siblings, 1 reply; 8+ messages in thread
From: Nicolas George @ 2025-07-04 13:29 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Michael Niedermayer (HE12025-07-03):
> return av_adv_err_new(AVERROR_INVALIDDATA, "Garbled foobar data", "Foo triangle quantum decoder"
> __FILE__, __LINE__, NULL, "Whaetver you like %s", favorite_food);
>
> teh return type is int64_t here
So we need to change all our return types?
> this also cannot fail as it allocates nothing
Where does the memory storing “favorite_food” come from?
> it also needs no context but would use a mutex or thread local storage
>
> the message length would be bound by a maximum,
Of course.
> I am not sure if passing a context around is going to find the volunteers
> to implement and maintain. Also it has a performance impact for small and
> lightweight functions.
We already pass contexts around everywhere.
I would argue that the small lightweight functions that do not already
have a context for the error are too low level to be able to provide a
meaningful error message.
So, my proposal is similar to yours, except for the following
differences:
- We allocate the memory for error messages contexts. That way, we avoid
the issue of using locks or thread-local storage but do not have a
hard limit on simultaneous errors.
- We do not change the return type of all our API, we still return “a
negative AVERROR code” to keep source compatibility, and use the best
code we can find.
- If there is no context, we stick with error codes. AVERROR(EINVAL) is
enough to say that RGB27 does not exist. A function with a context
calling a function without a context is responsible for turning the
error code into a meaningful message by including contextual
information.
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] 8+ messages in thread
* Re: [FFmpeg-devel] [RFC] Advanced Error Codes
2025-07-04 13:29 ` Nicolas George
@ 2025-07-06 14:33 ` Michael Niedermayer
0 siblings, 0 replies; 8+ messages in thread
From: Michael Niedermayer @ 2025-07-06 14:33 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 3952 bytes --]
Hi Nicolas
On Fri, Jul 04, 2025 at 03:29:19PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-07-03):
> > return av_adv_err_new(AVERROR_INVALIDDATA, "Garbled foobar data", "Foo triangle quantum decoder"
> > __FILE__, __LINE__, NULL, "Whaetver you like %s", favorite_food);
> >
> > teh return type is int64_t here
>
> So we need to change all our return types?
no
we can do it with int too, if thats preferred.
>
> > this also cannot fail as it allocates nothing
>
> Where does the memory storing “favorite_food” come from?
theres a fixed length array of AdvancedError structs.
AdvancedError has a fixed length char field.
Thats where a single custom text string can be stored.
Which would be maybe "Whaetver you like pizza" if favorite_food was "pizza"
its very very simple
typdef 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 123 for 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];
>
> > it also needs no context but would use a mutex or thread local storage
> >
> > the message length would be bound by a maximum,
>
> Of course.
>
> > I am not sure if passing a context around is going to find the volunteers
> > to implement and maintain. Also it has a performance impact for small and
> > lightweight functions.
>
> We already pass contexts around everywhere.
* Many places but not everywhere,
* The contexts do not match the lifetime of the errors
* The contexts can be accessed from multiple threads
* There can be multiple relevant errors for a single context
>
> I would argue that the small lightweight functions that do not already
> have a context for the error are too low level to be able to provide a
> meaningful error message.
"square root of negative argument" in mydecoder.c at line 123 is more
informative than EINVAL, and having no clue where or why that happened
for example decode() returning
AVERROR(EINVAL)
with 5000 lines of cryptic parser errors in messages
vs.
"square root of negative argument" in mydecoder.c at line 123, called by
vector_length_compute() line 511 called by
read_nnet() line 732 free_form_description="training_set_maybe_corrupted.dat"
Note by the time this is returned decode failed and many contexts have
been destroyed.
>
> So, my proposal is similar to yours, except for the following
> differences:
>
> - We allocate the memory for error messages contexts. That way, we avoid
> the issue of using locks or thread-local storage but do not have a
> hard limit on simultaneous errors.
malloc() can fail and it needs to be freed exactly once. And not freed
before the caller is finished doing anything it likes to do with the error
information. And it very possibly wants to pass it on to its caller
>
> - We do not change the return type of all our API, we still return “a
> negative AVERROR code” to keep source compatibility, and use the best
> code we can find.
Then you no longer know which error relates to which message
So the problem that I see, isnt solved.
Maybe it helps with other problems, i dont know.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
[-- 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] 8+ messages in thread
end of thread, other threads:[~2025-07-06 14:34 UTC | newest]
Thread overview: 8+ 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-03 8:56 ` Nicolas George
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
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