[FFmpeg-devel] ffplay and the return values

[Reimar Döffinger]

On 12 Apr 2012, at 23:37, Stefano Sabatini <stefasab at gmail.com> wrote:
> On date Tuesday 2012-04-10 22:04:36 +0200, Marton Balint encoded:
>> On Tue, 10 Apr 2012, Stefano Sabatini wrote:
> [...]
>>> I suggest to expose these codes, for example you could create an array
>>> with extended explanation and an option to tell which code corresponds
>>> to which error (-errors?), so the user doesn't need to rely on the
>>> source.
>> 
>> I'd rather put that information into the man page.
>> 
>>> On the other hand I'm not too confortable with the idea of adopting
>>> *application level* error codes and add more complexity/maintainance
>>> overhead, and I don't think the user needs *that* level of control on
>>> the exit reason.
>> 
>> Makes sense, probably a NormalExit, UserExit, InitError, OtherError
>> and SigTermHandlerError is more than enough for everyday uses.
>> 
>>> An alternative implementation may simply expose the AVERROR* code to
>>> an environment variable (FFPLAY_ERROR, FFPLAY_ERROR_REASON) - or a
>>> possibly a more robust system (writing to a .pid file?) in case more
>>> instances are run at the same time.
>>> 
>>> Would be that enough for your use case? The application may set
>>> $FFPLAY_ERROR to AVERROR_EXIT in case of user-requested early exit
>>> (see libavutil/error.h).
>>> 
>>> Another advantage of this approach is that it could be used by the
>>> other ff* tools.
>>> 
>>> This also may require to extend the error API in order to expose a tag
>>> associated to the error (more portable than using an error code
>>> numeric value, which may depend on the platform).
>> 
>> I think it is a very simple thing what the patch owner wanted, we
>> should not overdesign this.
> 
> Well I won't object on that, and you're the ffplay maintainer after
> all so you have the last word, provided that:
> - it is documented somewhere (man page or help option)
> - no excessive maintanance/complexity overhead is given
> 
> and I agree a few exit codes are better than too many specific ones.
> 
> Then we can extend the design if it turns out that it was
> *underdesigned* for some specific use cases.

Well, a bit of a problem with exit codes is that it isn't really possible to change/extend in a backwards-compatible way.
So it's not a bad idea to think extra thoroughly about how to do it.