[MPlayer-cygwin] Basic help needed...

[Lostgallifreyan]

Reimar Döffinger <Reimar.Doeffinger at gmx.de> 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 confusing, 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 reportage 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 reporting......... 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. Weird, too, because the Win32 API DOES have a device selection capability built 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 avoided 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 them, 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 Windows versions that cannot run on a 486 anyway! Such are the perils of choosing a later compiler and assumign that all-of-Win32 compiling will work out of 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 right.

>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, and 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 achived 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 flatly refused as unrecognised! I tried MENU- too, knowing that in Windows, ALT is VK_MENU. Even tried the VK_ prefix for a lark. No answer, came the stern reply.

>> Load a file for playback, but always pause it immediately until I am ready 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 way. One I found (amongst various shennaigans with pipes and redirects that would tie DOS into tight knots, was "pause | Mplayer -slave Filename.avi" but that won't work in Windows, either in a command window, or in a shoretcut (where it is blocked as invalid syntax. I suspect ALL like methods are banned in Windows, I'd have to write a progam launcher and force the test that way. I can do this, but I don't want to, it's like building a rocket to gpo shopping. SLightly fatuous that I even have to seriously consider it just to launch a video and pause it till I'm ready (Highly desirable because it's the only way to set volume manually, and other parameters, prior to start. Given that, I'm surprised that after several years, I find I'm the latest 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 several years ago, but sometimes still happens. As the result is ABSOLUTE freeze, not even pointer movement or response to Ctrl+Alt+Del, there is no possible diagnostic, only hardware reset or power cycling to restore any passable resemblence to 'computer' as opposed to 'brick'. :) Whatever the cause, it seems to have never really been solved, and while the odds are better than 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 which 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 cause, 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 down seems to require knowing things I can't grasp, things Mplayer is using that the others aren't. Given that it's erratic, it looks like Mplayer may not be waiting for some response before closing,. By analogy, I learned in my own coding that I have to wait for audio buffers to be returned and handled properly before closing, likewise for MIDI. Maybe there are similar cases 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 anyway, my system seems ok with GL, so that might work.