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

Alban Bedel albeu at free.fr
Mon Aug 11 22:58:08 CEST 2003

Hi Joey Parrish,

on Mon, 11 Aug 2003 15:07:28 -0500 you wrote:

> On Mon, Aug 11, 2003 at 08:28:13PM +0200, Alban Bedel wrote:
> > > However I needed to do the follwing change (see attached patch) to
> > > get the correct path.
> What your patch is doing is hardcoding the dll path into the LoadLibrary
> call.  This is what I was originally doing, but now I'm being told that
> this is incorrect.  I don't know any more, I haven't had the time to
> test everything lately.
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.

> > > The patch is not tested at all, it's just what i remember.
> > > I used --configure --with-codecsdir=./codecs --prefix=.
> > > --bindir=. --datadir=. --mandir=. --confdir=. --libdir=.
> > > It then gave me a working "windows style" binary :)
> Ah.  Yeah, that's similar to the way I build my packages.
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.

> > > BTW i didn't tried but does freetype work on mingw ?
> I dunno, it works on cygwin without anything special.
> I'd expect it to work.  Try it out.
I can't :/ As i said, i did that on the computer of a friend of mine.
But now this computer is about 1600Km away, as i'm back home.
I just asked bcs freetype was the only thing (beside vcd) wich was really
"missing" to make it a good looking app.

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.

BTW2, vo_directx should fallback on non-overlay method even
if -vo directx:noaccel is not given. Otherwise i needed to give
noaccel for RGB format, wich was annoying if an RGB codec came
in middle of a playlist :(
Hand made patch around line 1106:

        /*create the surfaces*/
    if(Directx_CreatePrimarySurface())return 1;
-        if (!nooverlay && Directx_CreateOverlay(image_format))
+        if (Directx_CreateOverlay(image_format))
                        nooverlay=1; /*overlay creation failed*/
-                        mp_msg(MSGT_VO, MSGL_FATAL,"<vo_directx><FATAL ERROR>can't use overlay mode: please use -vo directx:noaccel\n");
-                        return 1;

That should fix this stupid behaviour. Now that i think about it,
nooverlay should probaly be reseted at the begining of config().
Again I can't test so i can't commit :( Anyway i hope it help you.

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