[FFmpeg-devel] ffplay and the return values

[Marton Balint]

On Tue, 10 Apr 2012, Stefano Sabatini wrote:

> On date Sunday 2012-04-08 17:52:00 +0200, Bernd Krüger-Knauber encoded:
>> Sorry,
>>
>> it's my first contribution to a bigger project.
>>
>> Here is diff -u output
>
>> --- ffplay.c.org	2012-04-07 22:02:21 +0000
>> +++ ffplay.c	2012-04-08 14:40:13 +0000
>> @@ -84,6 +84,21 @@
>>  /* NOTE: the size must be big enough to compensate the hardware audio buffersize size */
>>  #define SAMPLE_ARRAY_SIZE (2 * 65536)
>>
>
>> +enum ExitValues {
>> +	NormalExit,
>> +	UserExit,
>> +	SDLVideoModeErrorExit,
>> +	ImageToBigErrorExit,
>> +	LockMgrErorExit,
>> +	VideoStateErrorExit,
>> +	ConversionContextInitErrorExit,
>> +	OptionArgumentErrorExit,
>> +	NoInputfileErrorExit,
>> +	SDLInitErrorExit,
>> +	InputfileErrorExit,
>> +	SigTermHandlerExit
>> +};
>
> 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.

Regards,
Marton