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

Joey Parrish joey at nicewarrior.org
Tue Aug 12 08:10:35 CEST 2003

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.

> 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.

> 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

> 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;
>         }
>         if(nooverlay)
>         {
>                 if(Directx_CreateBackpuffer())
>                 {

Excellent!  This is an issue I had been planning to deal with, so I'm
very glad to see a working patch for this.  On one of my test machines
mplayer fails to create an directx overlay every time.

> 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.

Yes, very much.  I'll be sure to check it before I do anything with it.
If it works well in my packages, I'll make this patch independant and
submit it.


> 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