[MPlayer-dev-eng] Re: [PATCH] win32 codec path

Alban Bedel albeu at free.fr
Tue Aug 12 09:45:28 CEST 2003

Hi Joey Parrish,

on Tue, 12 Aug 2003 01:10:35 -0500 you wrote:

> On Mon, Aug 11, 2003 at 10:58:08PM +0200, Alban Bedel wrote:
> > Well,  sh->codec->dll is only the filename of the dll as found in
> > codecs.conf. Dunno, under linux but with mingw it need the full
> > path otherwise it search in the current dir i think.
> It searches a number of places, such as current working directory,
> windows system directory, and the PATH environment variable.  I can't
> remember all the rest, but those are the important ones.
Then we must manage to have it to search in REALCODECS_PATH too.
A simple hack is to put smthg like this:

 #ifdef USE_WIN32DLL
-	    if (!load_syms_windows(sh->codec->dll))
+	    if (!(load_syms_windows(sh->codec->dll) || load_syms_windows(path)))

But if you can manage to add REALCODECS_PATH too add to the lib search
path that's perhaps better. No big deal anyway.

> > BTW there is still some little thing to correct like the
> > mplayer/config wich is automaticly created if it doesn't exist
> > (uneeded as ./mplayer.conf is alredy read with such config).
> > Anyway i think that we should sipmly remove the stuff wich create
> > this file. It's probably just some rest of the earliest config
> > file support.
> Yeah, basically my goal is to get all these little windows useability
> issues worked out in my packages, then backport those changes in a
> portable way to cvs main.  This is one of the behaviors I change a bit.
This empty config file creation can be removed from cvs without fear,
it's really just useless crap. But imho we should have a define for single
user os like win9x. So on such OS we only search config files in one
place, ignore $HOME, etc. There may even be some unix users how like
such config ;)

> > BTW, a simple thing to make it more friendly to windows users would be
> > something a bit like lame drop (for those who know that).
> > In short a little panel to build mplayer commands. A few fui elements
> > for the most common options (-fs,-cache, -ni, etc) and a text line to
> > appand other options.
> > Then users just drop a file on the panel and it'll run mplayer as
> > configured. Add an option to save this as config file and that should
> > be enouth for most (not so lame) users. With a GUI builder it should
> > be quiet easy.
> Interesting... for the most part, my strategy is to set config options
> and then associate file types.  Fullscreen toggling is done via
> double-click on video or alt+enter or 'f' key.  (See patch at
> http://joey.nicewarrior.org/cygmp/patches/02.dx-fs.patch for that
> behavior.)
I just looked at your patch and vo_directx.c again. A few things must
be changed a bit in the event handeling func.

static LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
	switch (message)
        case WM_CLOSE:
			return 0;
That's not guarented to work all the time as the user can attach
any command to 'q' key. Instead something like this must be done:
        case WM_CLOSE:

In your patch you also add some new special case in this function.
This is bad. vo should not handle keyevent and such on their own.
You must insted add some new key codes and pass them with
mplayer_put_key() like other keystrokes. To handle the alt+enter case
the best is if you can pass up/down event for all keys. Then the input
layer can handle everything. Otherwise just make an ALT_ENTER key code.
Also note that mouse click can alredy be passed (see input/mouse.h),
fell free to add new codes for double click.


BTW i also noticed that on win98 the status line display eat up a
lot of ressources (very choppy playback even on Ghz box) if the dos box
doesn't have the focus (and hence need to bo on the front with this
retarded wm ;) Using -quiet solve that.

> > Everything is controlled by a small evil group
> > to which, unfortunately, no one we know belongs.
> _Yet_

Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.

More information about the MPlayer-dev-eng mailing list