[FFmpeg-devel] ffplay and the return values

[Stefano Sabatini]

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.

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.

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).
-- 
FFmpeg = Fanciful and Fostering Mysterious Pacific Elected Governor