[Ffmpeg-devel] HTTP probing issue... [PATCH]

[Ronald S. Bultje]

Hey guys,

On Feb 28, 2007, Francois Revol wrote:
>>> EPIPE happens when you write to a pipe already closed at the other
>>> end
>>> (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).

Cheers,
Ronald