On Mon, 15 Jul 2024, Andrew Sayers wrote:
On Mon, Jul 15, 2024 at 05:45:24PM +0200, Marton Balint wrote:
On Mon, 15 Jul 2024, Andrew Sayers wrote:
AVERROR messages should always be less than zero,
and are usually based on three or four ASCII characters.
For error codes that aren't explicitly handled by error.c (e.g. FFERROR_REDO),
print the ASCII code so the user has a little more information.
All ffmpeg internal error codes (including the ones having some special tag
representation) should be handled by error.c. The user should never receive
FFERROR_REDO, that is an internal error code, it should never reach the
user. Therefore I see no benefit in disclosing the error bytes, because that
is not the proper fix.
Regards,
Marton
So it sounds like this patch is addressing two separate issues:
1. any messages caught by the test in the patch represent a bug in FFmpeg
* how about I modify this patch to ask the user to report the bug?
* would the ASCII error code help with triage?
I don't really like adding extra code for this, and from an API point of
view any negative error code can be valid, so you can't really warn about
them.
If you want to make sure that every ffmpeg error code has a text, then add
a fate test for checking it.
2. FFERROR_REDO should be added to error.c
* let me know if I should submit a separate patch for this
FFERROR_REDO is an avformat internal error code, av_strerror() being in
avutil cannot properly support it.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
