[FFmpeg-devel] ffplay and the return values

Marton Balint cus at passwd.hu
Tue Apr 10 22:27:10 CEST 2012


On Tue, 10 Apr 2012, Nicolas George wrote:

> Le duodi 22 germinal, an CCXX, Stefano Sabatini a écrit :
>> 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.
>
> I agree. Furthermore, the universal convention is that 0 means success,
> other means failure, and an user-requested exit is not a failure.

I see no harm in the nonzero exit code of user exit, you can say that 
success is that if the whole video is played, not only the part of it.

>
>> 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).
>
> I am not sure what you mean exactly, but I suppose you remember that
> environment variables can not be altered upwards in the process ancestry: an
> application can transmit information to its subprocesses by environment
> variables, but the subprocesses can not return information that way.
>
> The simplest way is obviously to write something to the standard output.
> ffplay already writes its progress there: maybe it is enough to check if the
> video was read entirely.

Parsing the output of ffplay is simple, but not as simple as checking an 
exit code. Sorry, I still don't see what do we win here with the extra 
complexity.

Regards,
Marton


More information about the ffmpeg-devel mailing list