[MPlayer-cvslog] r31725 - trunk/libao2/ao_coreaudio.c

Adrian Stutz adrian at sttz.ch
Tue Jul 13 22:20:29 CEST 2010

On Tue, Jul 13, 2010 at 08:13, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> Continue anyway without audio for audio files? How would that be possible?

Yes, in case you're playing a file with only an audio stream, it would
quit. But if you're playing a file that has a video stream as well or
if you've selected more then one audio out then it will continue to
play the file.

So, for the case of audio-only files, the effect is the same as using
e.g. -vo help - but disregarding all the initialization messages that
are printed before the audio output is initialized and, for the
consistency you talk about, ugly error messages at the end:

> Failed to initialize audio driver 'coreaudio:help'
> Could not open/initialize audio device -> no sound.
> Audio: no sound
> Video: no video

Again, I agree with you this isn't ideal. But it isn't ideal for any
help that has to be triggered by suboption parsing that only kicks in
during component initialization.

I still think this commit is an improvement and also think it's more
consistent with what's happening: MPlayer is trying to find an audio
output and tries to initialize the selected ones until it finds one
that works. Signaling that the initialization failed because the user
requested a help to be displayed is wrong. It either should cleanly
display the help and not continue with initialization (and not
initialize anything before it) or then just regard the help display as
a side effect and continue - as I did with this commit, because it's
the better short-term solution.

In which case should a help command lead to error messages like the ones above?


More information about the MPlayer-cvslog mailing list