[Ffmpeg-devel] HTTP probing issue... [PATCH]
Ronald S. Bultje
Wed Feb 28 16:33:54 CET 2007
On Feb 28, 2007, Francois Revol wrote:
>>> EPIPE happens when you write to a pipe already closed at the other
>>> (and you dont catch SIGPIPE). ESPIPE seems more likely for a seek
>>> operation, no?
>> I would say yes, comments ?
> As long as you use AVERROR() properly it's ok for me :D
Now that you're on there anyway, I'm trying to implement decent error
handling in a graphical way, i.e. any use of av_log() is useless (not
internationalizable), I would like to rely purely on error return
values. I've currently implemented a hack where I add my own
AVERROR_SYSERR and set errno in a member of the context. Im' also
using AVERROR_HTTP to forward http error codes (404, 401, 403 etc.)
in the same way. This way, my app can pop up an error dialog saying
"access denied" vs "file not found" instead of some crazy "I/O
error" (AVERROR_IO) for anything, and give some contextual help also
(e.g. if AVERROR_SYS + ENOTFOUND or AVERROR_HTTP + 404, tell the user
to select an existing file, whereas if the permissions are wrong,
tell the user that access may not be authorized, contact the admin or
bla bla, I'm giving some bad examples but I hope you get the point
that in some cases, contextual help can actually make a difference
between "what the fuck" and "oh, of course, I need to do this and
then it'll work").
Now, this is obviously too crazy to be considered for integration,
but could it be considered to just drop this whole AVERROR_*? errno.h
stuff is internationalized (strerror()), available everywhere,
contains many more useful error codes and is generally used in many
places that should (according to the API) be using AVERROR_* already
anyway. A HTTP error code -> errno.h conversion mapping shouldn't be
all too hard, at least for the relevant ones (4xx and server exeptions).
More information about the ffmpeg-devel