MPlayer – changing ‘ao=’ codec order in mplayer.co

2019-09-19 11:34发布

问题:

Quoting mplayer.conf:
" Configuration files are read system-wide from /etc/mplayer/mplayer.conf
and per user from ~/.mplayer/config, where per-user settings override
system-wide settings, all of which are overrriden by the command line."

However, changing the order of audio codec so that 'alsa' is first in user config file does not appear to work.

My preference is to leave the /etc/mplayer/mplayer.conf file as is and make changes to the mplayer.conf file in ~/.mplayer/config

Using the following line: 'ao=alsa,pulse,sdl:aalib' only works in the /etc/mplayer conf file and therefore don't appear to be overridden by the 'per-user' settings.

Also, I would prefer not to start mplayer with the '-ao alsa' option either...

Any thoughts on if this is a 'bug' or 'feature request' or have I missed something?

Edit - adding that playing an mp3, the following warning is returned: "AO: [pulse] Init failed: Connection refused Failed to initialize audio driver 'pulse' AO: [alsa] 44100Hz 1ch floatle (4 bytes per sample) Video: no video Starting playback..."

FIXED
MPlayer looks for the environment variable 'HOME' to determine where to look for the users mplayer config file. Apps such as lighttpd used to run scripts that in turn run mplayer do not by default set the 'HOME' environment variable. One could argue and say there is a limitation with MPlayer only looking for an environment value 'HOME' rather than a more robust mechanism to determine a users 'home' directory....

Running MPlayer with 'env HOME=/var/www' will help MPlayer locate the users config file without having to edit /etc/mplayer/mplayer.conf. This also fixes the need to run MPlayer with sudo:

As an example, the following instruction works in a python script called from a remote browser connecting to lightpd web server on a raspberry pi: playing_mplayer=subprocess.Popen(['env', 'HOME=/var/www', 'mplayer', '-slave', '-nocache', '-quiet', '-volume', '60', '-key-fifo-size', '2', '-input', 'file=/run/shm/mpcontrol', '-playlist', 'http://tx.whatson.com/icecast.php?i=magic1054.mp3.m3u' ], stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.STDOUT)

回答1:

Apologies for this additional message - I didn't know how or even if I could answer my own question - but here I am now...

The fix is detailed in the question. In a nut shell: One way for MPlayer to use MPlayer's user config file, the environment variable 'HOME' must be set showing the path to an .mplayer directory where the file 'config' is located. For instances where HOME is not set (such as a script being run by a web server), append 'env HOME=/dir/where/to/find/config" when running mplayer.



回答2:

After discussions with the nice chaps over at MPlayer, I have revised my case and therefore have an additional answer but is related to lighttpd (lighty) - which is not in the title and therefore may get missed if anyone is looking for a solution to a similar issue.

Additional answer:
As mentioned, MPlayer requires the environment variable 'HOME' showing where 'home' directory is, which contains the sub dir '.mplayer' - this being the location of the users MPlayers 'config' file.
It also turns out, the environment variable 'MPLAYER_HOME' can be used instead.
If 'MPLAYER_HOME' is used, the full directory will be required, i.e. 'env MPLAYER_HOME=/var/www/.mplayer'.

So, back to my case and lighty. Obviously better to use 'MPLAYER_HOME' variable rather than 'HOME' which can be compromised via the web server.
Add the following two entries to /etc/lighttpd/lighttpd.conf:

Add the following module to the server.modules section: "mod_setenv"

And the following env var to the 'CGI' module: setenv.add-environment = ("MPLAYER_HOME" => "/var/www/.mplayer")
Restart lighty to read additions to config. 'lighty' now passes the env var 'MPLAYER_HOME' for any instruction to run scripts. Just for completeness, the python script no longer needs to prefix setting the 'env' option when running mplayer.