[MPlayer-dev-eng] [PATCH] vo and ao "exit" devices

[Reimar Döffinger]

On Fri, May 01, 2015 at 08:01:56PM -0400, Dylan Alex Simon wrote:
> > > > Someone mentioned that they wanted mplayer to exit if it failed to open their
> > > > audio device, rather than continuing with no audio.  These (trivial but
> > > > harmless) output devices allow this to happen by putting them at the end of
> > > > the output chain (e.g., "-ao alsa,pulse,exit").  Apparently someone else
> > > > suggested this approach as well, a while ago.  I will readily admit that this
> > > > is silly, but it works.  I have no particular attachment to name, description,
> > > > or approach.
> > >
> > > It seems slightly risky to me to call exit_player for an init function.
> > > It tends to rely on some state that might not be set up correctly at
> > > that point for example.
> > > Also it will not exit if the AO is fine, but e.g. we cannot actually
> > > connect to it since it doesn't support any format we can convert to
> > > for example.
> > > It might work better adding the code to reinit_audio_chain, in the
> > > init_error label?
> > > For video, the equivalent would be reinit_video_chain, and it behaves
> > > quite similar.
> > 
> > Sorry, should have said: both these functions are in mplayer.c
> 
> I was just going based on the existing "alsa9" exit_player call in
> init_best_audio_out (and similarly if init_audio_filters fails), but I don't
> really know it works.

Well, the obvious question would be: Why didn't you add it at the same
place then? It would be less code/avoid the boiler-plate for a new ao...
And probably little enough code that I wouldn't mind the point I mention
below as I admit it might not matter for the use-case you care about.

> To do it at the end of reinit_*_chain it looks like
> this would need to be a separate command line option, "-ensure-audio" or
> something, rather than an output device.  Happy to do that instead if that's
> preferable.

Well, that depends kind of what the exact use-case/desired behaviour is.
Your approach will work if you only want it to exit if the initial
initialization fails.
However I believe (but have not tested) that it will not exit if e.g. your
-af filter list is something that cannot work. E.g. -af format=s24le when
the sound-card/ao does not support 24 bit formats...
Similar for concatenated files when the format goes from a supported
to a unsupported format, your patch will not exit then, adding code
in the reinit path would (which may or may not be desirable).
Btw. I think "-ensure-audio" would be a misleading name, since non
of these approaches would exit if the file actually contains no audio...
Possibly something like -exit-on-ao-error instead? But I am not good
at option names.