CVS change done by Diego Biurrun CVS Update of /cvsroot/mplayer/main/DOCS/man/en In directory mail:/var2/tmp/cvs-serv16416 Modified Files: mplayer.1 Log Message: misc fixes Index: mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.1160 retrieving revision 1.1161 diff -u -r1.1160 -r1.1161 --- mplayer.1 22 Nov 2005 16:49:36 -0000 1.1160 +++ mplayer.1 23 Nov 2005 00:27:25 -0000 1.1161 @@ -301,7 +301,7 @@ Toggle displaying "forced subtitles". .IPs a\ \ \ \ Toggle subtitle alignment: top/\:middle/\:bottom. -.IPs "z and x" +.IPs "x and z" Adjust subtitle delay by +/\:- 0.1 seconds. .IPs "r and t" Move subtitles up/\:down. @@ -1961,9 +1961,12 @@ OSS audio output driver .PD 0 .RSs -.IPs dsp-device[:mixer-device[:mixer-channel]] -Sets the audio-output device (default: /dev/\:dsp), mixer device (default: -/dev/\:mixer) and mixer channel (default: pcm). +.IPs <dsp-device> +Sets the audio output device (default: /dev/\:dsp). +.IPs <mixer-device> +Sets the audio mixer device (default: /dev/\:mixer). +.IPs <mixer-channel> +Sets the audio mixer channel (default: pcm). .RE .PD 1 . @@ -2820,7 +2823,7 @@ has no effect, the size of the slices as provided by the decoder is used. .br If the decoder does not use slice rendering, the default is 16. -.REss +.RE .IPs (no)osd Enable or disable support for OSD rendering via OpenGL (default: enabled). This option is for testing; to disable the OSD use \-osdlevel 0 instead. @@ -2844,7 +2847,7 @@ .br 2: Use the GL_ARB_texture_non_power_of_two extension. In some cases only supported in software and thus very slow. -.REss +.RE .IPs (no)glfinish Call glFinish() before swapping buffers. Slower but in some cases more correct output (default: disabled).
Diego Biurrun CVS wrote:
@@ -1961,9 +1961,12 @@ OSS audio output driver .PD 0 .RSs -.IPs dsp-device[:mixer-device[:mixer-channel]] -Sets the audio-output device (default: /dev/\:dsp), mixer device (default: -/dev/\:mixer) and mixer channel (default: pcm). +.IPs <dsp-device> +Sets the audio output device (default: /dev/\:dsp). +.IPs <mixer-device> +Sets the audio mixer device (default: /dev/\:mixer). +.IPs <mixer-channel> +Sets the audio mixer channel (default: pcm). .RE .PD 1 .
IMHO this makes the documentation a bit unclear, based on this I'd expect "-ao oss:mixer-device=/dev/mixer:dsp-device=/dev/dsp" to work... -- Tobias PGP: http://9ac7e0bc.uguu.de
On Sun, Nov 27, 2005 at 05:37:20AM +0100, Tobias Diedrich wrote:
Diego Biurrun CVS wrote:
@@ -1961,9 +1961,12 @@ OSS audio output driver .PD 0 .RSs -.IPs dsp-device[:mixer-device[:mixer-channel]] -Sets the audio-output device (default: /dev/\:dsp), mixer device (default: -/dev/\:mixer) and mixer channel (default: pcm). +.IPs <dsp-device> +Sets the audio output device (default: /dev/\:dsp). +.IPs <mixer-device> +Sets the audio mixer device (default: /dev/\:mixer). +.IPs <mixer-channel> +Sets the audio mixer channel (default: pcm).
IMHO this makes the documentation a bit unclear, based on this I'd expect "-ao oss:mixer-device=/dev/mixer:dsp-device=/dev/dsp" to work...
Before my change, after my change or either way? Hmm, I'm not going to claim that the current description is perfect, but I don't see the problem you describe. Other output drivers are documented in the same way and where option=<value> syntax is expected, this is written explicitly. I was also hoping that the <> would make clear that it should be replaced by a concrete value... Diego
Diego Biurrun wrote:
IMHO this makes the documentation a bit unclear, based on this I'd expect "-ao oss:mixer-device=/dev/mixer:dsp-device=/dev/dsp" to work...
Before my change, after my change or either way?
Hmm, I'm not going to claim that the current description is perfect, but I don't see the problem you describe. Other output drivers are documented in the same way and where option=<value> syntax is expected, this is written explicitly. I was also hoping that the <> would make clear that it should be replaced by a concrete value...
I think it was more clear before the change. Most drivers use either the suboption parser or support only one parameter. The syntax explanation suggests that the suboption order is not important. Before it was made clear that oss is an exception in that the order _is_ important, but maybe thats just me. :-) I think it might be good to convert oss to use the suboptionparser (breaks compatibility) or reinclude the "oss[:dsp-device[:mixer-device[:mixer-channel]]]" 'usage example'. -- Tobias PGP: http://9ac7e0bc.uguu.de
On 11/27/2005 01:22 PM, Tobias Diedrich wrote:
Diego Biurrun wrote:
IMHO this makes the documentation a bit unclear, based on this I'd expect "-ao oss:mixer-device=/dev/mixer:dsp-device=/dev/dsp" to work...
Before my change, after my change or either way?
Hmm, I'm not going to claim that the current description is perfect, but I don't see the problem you describe. Other output drivers are documented in the same way and where option=<value> syntax is expected, this is written explicitly. I was also hoping that the <> would make clear that it should be replaced by a concrete value...
I think it was more clear before the change. Most drivers use either the suboption parser or support only one parameter. The syntax explanation suggests that the suboption order is not important. Before it was made clear that oss is an exception in that the order _is_ important, but maybe thats just me. :-)
It's not just you; I get the same impressions from both forms.
I think it might be good to convert oss to use the suboptionparser (breaks compatibility) or reinclude the "oss[:dsp-device[:mixer-device[:mixer-channel]]]" 'usage example'.
Agreed. The former is probably the better solution, but the latter is much the simpler. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sun, Nov 27, 2005 at 07:22:35PM +0100, Tobias Diedrich wrote:
Diego Biurrun wrote:
IMHO this makes the documentation a bit unclear, based on this I'd expect "-ao oss:mixer-device=/dev/mixer:dsp-device=/dev/dsp" to work...
Before my change, after my change or either way?
Hmm, I'm not going to claim that the current description is perfect, but I don't see the problem you describe. Other output drivers are documented in the same way and where option=<value> syntax is expected, this is written explicitly. I was also hoping that the <> would make clear that it should be replaced by a concrete value...
I think it was more clear before the change. Most drivers use either the suboption parser or support only one parameter. The syntax explanation suggests that the suboption order is not important. Before it was made clear that oss is an exception in that the order _is_ important, but maybe thats just me. :-)
I understand what your problem is now. I'd say it needs a more general fix, though.
I think it might be good to convert oss to use the suboptionparser (breaks compatibility)
Definitely. Breaking compatibility should not be a problem since this has only been in the CVS version so far. Diego
Diego Biurrun wrote:
On Sun, Nov 27, 2005 at 07:22:35PM +0100, Tobias Diedrich wrote:
I think it was more clear before the change. Most drivers use either the suboption parser or support only one parameter. The syntax explanation suggests that the suboption order is not important. Before it was made clear that oss is an exception in that the order _is_ important, but maybe thats just me. :-)
I understand what your problem is now. I'd say it needs a more general fix, though.
I think it might be good to convert oss to use the suboptionparser (breaks compatibility)
Definitely. Breaking compatibility should not be a problem since this has only been in the CVS version so far.
How about the attached patch? -- Tobias PGP: http://9ac7e0bc.uguu.de
Digging through old mails .. On Sun, Dec 18, 2005 at 12:25:38AM +0100, Tobias Diedrich wrote:
Diego Biurrun wrote:
On Sun, Nov 27, 2005 at 07:22:35PM +0100, Tobias Diedrich wrote:
I think it was more clear before the change. Most drivers use either the suboption parser or support only one parameter. The syntax explanation suggests that the suboption order is not important. Before it was made clear that oss is an exception in that the order _is_ important, but maybe thats just me. :-)
I understand what your problem is now. I'd say it needs a more general fix, though.
I think it might be good to convert oss to use the suboptionparser (breaks compatibility)
Definitely. Breaking compatibility should not be a problem since this has only been in the CVS version so far.
How about the attached patch?
Here's a version that applies .. Diego
On Sun, Dec 24, 2006 at 06:13:54AM +0100, Diego Biurrun wrote:
Digging through old mails ..
On Sun, Dec 18, 2005 at 12:25:38AM +0100, Tobias Diedrich wrote:
Diego Biurrun wrote:
On Sun, Nov 27, 2005 at 07:22:35PM +0100, Tobias Diedrich wrote:
I think it was more clear before the change. Most drivers use either the suboption parser or support only one parameter. The syntax explanation suggests that the suboption order is not important. Before it was made clear that oss is an exception in that the order _is_ important, but maybe thats just me. :-)
I understand what your problem is now. I'd say it needs a more general fix, though.
I think it might be good to convert oss to use the suboptionparser (breaks compatibility)
Definitely. Breaking compatibility should not be a problem since this has only been in the CVS version so far.
How about the attached patch?
Here's a version that applies ..
/* no comment */ Diego
participants (4)
-
Diego Biurrun -
syncmail＠mplayerhq.hu -
The Wanderer -
Tobias Diedrich