[MPlayer-cygwin] MPlayer packages for windows

[Sascha Sommer]

> > 2) Could you compile the package with --with-codecsdir=codecs and add a
> > codecs subdirectory to dir where MPlayer gets installed?  This way I
> > could easily drop codecs into that directory (or you might even provide
> > them with your package) and MPlayer could also play QT and Real files.
> > These file types should be added to the file type dialog on installation
> > then.
>
> Yeah, this is something I've been aware of.  Some of my packages so far
> have done exactly this.  In fact, I was even hacking at get_path to get
> the path to the codecs folder relative to the mplayer executable.  I
> think my latest packages have a much more solid solution, though.  I'll
> get back to this.

Please also try the mingw port some day. It has a modified get_path
that does exactly this. Moreover it does not depend on the cygwin dlls
what makes a static compile possible.

> S. Smith:
> > I might have a bugreport for this (cvs), I have not been able to use
> > [-fs|-vm|-zoom] without a sig11 as yet.  Switching works fine, tho.
>
> This is because of a patch I added.  This behavior does not happen in
> normal cygwin mplayer.  Here's the issue for me:
> This package is intended to be used without any command line.
> So, in theory, you'd only ever have one movie running, perhaps on loop.
> (My latest hacks have optional playlist associations, though...)
> If you're looping a file, and during loop 1 you toggle fullscreen,
> then when loop 2 begins, it goes back to windowed mode.  My solution:
> comment out "fs = options & 1" from vo_directx.  This is _awful_ and
> I'll fix it before my next release.  It would be much better to have the
> first call to config set fs, then subsequent calls should leave it
> alone.  Or, even more correct would be if the caller of config took the
> time to check vo_fs state and pass that.  In any case, it all diverges
> from standard mplayer's way of doing things.  And since I'm working on
> packages for a special case, isn't a cheap hack okay in the short run?

What about -fixed-vo? It avoids the recreation of the window. Afair staying
in fullscreen worked when I added support for it but maybe it got broken.

> Bah.  I'm trying to make more and more of my package's patches portable
> and commitable, but there's just an awful lot of changes that only apply
> to the case where I'm packaging.  Not to cygwin or even mingw mplayer.
>
> As for the codec path stuff, my newest packages have most of the
> package-specific/windows-specific code in a seperate file, to minimize
> the drastic changes to mplayer core.  A patch to mplayer.c that adds one
> line to call an initialize function will probably apply even after big
> changes to mplayer.c in CVS.  However, my old way of cramming lots of
> code where it doesn't belong left me re-writing my patches every week.
> But, one of the things I'm doing now is renaming get_path to
> normal_get_path and using my own package-specific version to find things
> like codecs, fonts, config files, etc.  Then I have a bit of code in the
> init function (called at the top of main) that sets the env. var PATH to
> include codec path.  I still need to get around to testing the binary
> codecs stuff, but I've just not had the time.  Four more weeks of
> school, then I can put in a lot more time on mplayer.

The binary codecs stuff works like this now on mingw.

> To wrap up, I am seeking comments and suggestions from you folks about
> what I can do better/different in my next round of packages.  For one
> thing, I plan on putting up an actual webpage devoted to this vein of
> development, rather than just a index of installer files.  So, yes, tell
> me what you'd like to see.
>

A page for windows mplayer would be nice. Damn I also wanted to finish
my windows gui...

Sascha