FFplay hangs when a non existing filter is passed at the command line option

[ami_stuff]

for example:

ffplay -vf test <file>

tested with git-N-28799-gf354396.

[Stefano Sabatini]

Replying to ami_stuff:

for example:

ffplay -vf test <file>

tested with git-N-28799-gf354396.

I had a look at it, and came to the conclusion that it is the correct behavior. Indeed the command won't hang but only the video stream won't be shown (for example if there is an audio stream it will).

Filters are configured *after* the codec is open, and the codec is choose when it begins to play or when you switch stream interactively (with 'v' IIRC), so ffplay can't know if there is a failure until you actually switch the stream (because the filter configuration failure may depend on the decoder initialization).

So it looks like the correct behavior, since ffplay will continue to play the audio stream even if the video stream filtergraph configuration failed, which looks like a robustness feature.

Behavior may be changed with a command line option if there is a specific need for it though, please comment (or we could try to decouple filter parsing from codec initialization, but I'm not sure this is possible).

[ami_stuff]

I would like to see an audio visualisation if video filter fail and if there is no audio stream, FFplay should just quit, but you must decide if it is possible to implement this without too much work.

[ami_stuff]

Here is an ugly workaround to exit when avfilter fails :P

(seems to fix issue 2559 as well)

[Michael Niedermayer]

I suggest you post this patch to the mailing list, or to marton directly, maybe such ping would lead to this being fixed quickly

[Marton Balint]

Fixed in commit 7315e40a24e85e7f141db77951a4b14375fde55a.

FFplay will exit from now on on invalid filter configuration.