[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
behavior.)
> 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.
Thanks,
--Joey
> Everything is controlled by a small evil group
> to which, unfortunately, no one we know belongs.
_Yet_
More information about the MPlayer-dev-eng
mailing list