Re: Basic help needed...

Reimar D=F6ffinger <[email protected]> wrote:
(11/05/2015 20:35)

>The volume option is listed under
>AUDIO OUTPUT OPTIONS

Along with enough other options related to volume as to be utterly confusin=
g, but never mind. :) I have never seen anyone make volume so complicated, =
and I'm used to working with decibels and such.

>section and the dsound ao including the options under
>AUDIO OUTPUT DRIVERS

Not in the manuals I had here, I only discovered it in the console reportag=
e that it eventually gave me once I had the syntax right, and ommited other=
 things in the argument examples given that have no meaning in Windows, and=
 just cause total unrecognition of the command, and thus no detailed report=
ing......... Beleive me, it WAS trial and error, and lots of it. Even with =
at least four manual pages from different sources to guide me.

>That also mentions -ao win32 if you want to use the old API,
>but that one doesn't have a device selection feature.

I didn't know about that, but I can't use it anyway if that is the case. We=
ird, too, because the Win32 API DOES have a device selection capability bui=
lt in. Any command that invokes the API but fails to use it is unfinished.

>If you have no idea about the options at all, a GUI like SMPlayer
>that allows you to select options by clicking and shows the command-line
>it uses can help.

Maybe. :) There are also good odds that it won't run on W98. Just picking a=
 late GCC can screw that up, it's why SubJunk's compiles work, he has avoid=
ed 64-bit compiling so far, and by either intent or good fortune has ended =
up with builds that run on all Win32, which is nice. I was lucky to find th=
em, I'd given up on that years ago.

Side ussue, but revealing:
Gianluigi Tiesi has a 'generic' build to run on anythign greater than a 486=
 CPU. Won't though, it demands DLL functions that only exist in later Windo=
ws versions that cannot run on a 486 anyway! Such are the perils of choosin=
g a later compiler and assumign that all-of-Win32 compiling will work out o=
f the box. I mention this because overlookign details like this may be why =
basic things can be so hard to do, if no-one's checking they still work rig=
ht.

>The config file syntax should be easiest to figure out by looking at the
>example.conf
>

Hmm, not got one of those. :) I looked at the exiting configs I did have, a=
nd I got by, just. Still not figured out the CTRL or ALT key capability, if=
 it even exists.

>> Use CTRL or ALT keys to extend the available keys to bind to commands.
>
>Which part is the problem?
>You know about the input.conf and got it to work?
>Key combinations are specified using -, e.g. "CTRL-.".
>We had indeed no documentation of that it seems, I added
>this into the example input.conf.
>However most people would just press whatever keys they want
>and the key name to use would be printed on the console.
>

Indeed, no documentation. I found hints on forums various. A couple of achi=
ved list mails.. The trouble is that CTRL isn't working even with the CTRL-=
 syntax (Attempts to use CTRL result in no-binding errors), and ALT- is fla=
tly refused as unrecognised! I tried MENU- too, knowing that in Windows, AL=
T is VK_MENU. Even tried the VK_ prefix for a lark. No answer, came the ste=
rn reply.

>> Load a file for playback, but always pause it immediately until I am rea=
dy to start it.
>
>Note sure you can do that from the command-line, easily at least.
>Closest I can offer is
>mplayer -idle -slave
>
>and then type "pausing loadfile some_file"
>But it does play a short bit of audio before it pauses for me.
>

I'll try that nest time I'm ready to experiment a bit. There may not be a w=
ay. One I found (amongst various shennaigans with pipes and redirects that =
would tie DOS into tight knots, was "pause | Mplayer -slave Filename.avi" b=
ut that won't work in Windows, either in a command window, or in a shoretcu=
t (where it is blocked as invalid syntax. I suspect ALL like methods are ba=
nned in Windows, I'd have to write a progam launcher and force the test tha=
t way. I can do this, but I don't want to, it's like building a rocket to g=
po shopping. SLightly fatuous that I even have to seriously consider it jus=
t to launch a video and pause it till I'm ready (Highly desirable because i=
t's the only way to set volume manually, and other parameters, prior to sta=
rt. Given that, I'm surprised that after several years, I find I'm the late=
st in a LONG queue of people hoping that it might happen.)

>> Is there a guaranteed way to prevent the occasional green-screen seizure=
 at close of Mplayer? This is much rarer than it used to be in Mplayer seve=
ral years ago, but sometimes still happens. As the result is ABSOLUTE freez=
e, not even pointer movement or response to Ctrl+Alt+Del, there is no possi=
ble diagnostic, only hardware reset or power cycling to restore any passabl=
e resemblence to 'computer' as opposed to 'brick'. :) Whatever the cause, i=
t seems to have never really been solved, and while the odds are better tha=
n they have ever been, I'd like to eliminate the risk so I can use Mplayer =
without having to avoid all critical work on the system in any session in w=
hich Mplayer is used.
>
>I have some doubts that MPlayer has much to do with it, it could
>prevent Ctrl+Alt+Del.
>So a bad driver seems likely.
>The green screen is not necessarily related, it just means the
>DShow video surface is still active.
>But just in case it is related to video drivers you could try
>a more modern output method like -vo gl or -vo direct3d.
>At least you will get a hang with a black instead of green
>screen (well, -colorkey should also change the colour with
>dshow, but the colour isn't your real problem anyway ;) ).
>

True. :) I noticed that it can balk with no change of colour, and sometimes=
 the mplayer window will close first too. While Mplayer may not hold the ca=
use, it is the only software that invokes it that I have seen. Either that =
or FFmpeg. No other media player I have tried does it. Just narrowing it do=
wn seems to require knowing things I can't grasp, things Mplayer is using t=
hat the others aren't. Given that it's erratic, it looks like Mplayer may n=
ot be waiting for some response before closing,. By analogy, I learned in m=
y own coding that I have to wait for audio buffers to be returned and handl=
ed properly before closing, likewise for MIDI. Maybe there are similar case=
s in video that are beyond my understanding, and maybe Mplayer just closes =
without handling this gracefully. If this was never a problem in *nix based=
 systems, it may well have got overlooked. I'll try those output options an=
yway, my system seems ok with GL, so that might work.