[MPlayer-dev-eng] Proposal : library for increasing MPlayer

[Arpi]

Hi,

> As I'm new to this list and to MPlayer developement, let me introduce myself.
> I am a 30-year old developer working mainly doing C++ developements for
> a big financial institution in France. I run Windows and Linux at home, and
> Windows only at work.
> 
> My main interest here (as I explained already in the "users" mailing list)
> is that I would like to get to a proper windows port of MPlayer, which means:
> - Be able to compile it with a native windows compiler (Visual C++ 6 oer 7)
does it have any advantages besides the many disadvantages?
imho using mingw (native gcc for win32) would be easier.

> - Have all major codecs to compile as well, with optimisations
will be hard due to gcc speific optimizations

> - Have the GUI ported
you mean rewritten, right?
or you really want to port this hybrid xlib+gtk gui code?

> - Create a setup program for binary distribution
maybe it could be the first step :)

> I started to have a look at the code in order to see what would be the tasks.
> I've seen several problems with compiling under Visual C++:
> 
> - Wide use of "#include <unistd.h>" and "#include <inttypes.h>", both of 
>   which do not exist in Win32
you could drop in an inttypes.h containing the defines. see the
etc/inttypes.h for example.
for unistd, the problem isn't the include itself but the functions it
defines, are heavily used by mplayer (posix file/net/device i/o)

> - Wide use of "inline" which is not supported when compiling C with VC++
>   (__inline is supported, though)
shouldn't be problem to defice a macro...

> - Use of inline assembly with specific GCC syntax
how are you planning to solve this?
without loosing speed (at least on unix)?

> Those may cause problem when trying to port MPlayer to other platforms as
> well (I mean native ports, not cygwin stuff) (MacOS for instance).
> 
> IMPORTANT : I AM NOT ASKING FOR YOU GUYS TO DO ANY WORK IN THAT DIRECTION.
> I AM OFFERING TO DO THE WORK MYSELF AND TO SUBMIT IT TO THE MAIN MPLAYER
> TREE.
ok.

> However, I would like to propose to you how I want to do it, in order to
> know if you agree and if it goes "in the right direction" for you.
the no.1 rule: mplayer is an unix player, and it will remain that.
we cannot (and will not) accept ugly hacks, big useless changes,
or any speed loss for a win32 port.

> Basically, I would like to introduce a new library "libpl" (for Portability
> Layer). This library would provide:
> - An autoconf script for Unix platforms, with proper automatic detection
>   of some features (inttypes.h, unistd.h, other C library functions)
argh!

> - Replacement code for missing features (int types definition when inttypes.h
>   is not there, stubs for missing C library functions, ...)
> 
> - Some macro definitions for different features (inline vs __inline, ...)
> 
> - A "config-win32.h" file for win32 code configuration

why do you need a new library for this?
look at the linux/ dir, its name is misleading (should be called osdep, will
be renamed after 0.90) it already contains some linux libc func's
implementations for solaris, bsd etc.

> >From there, the main "configure" script in MPlayer (which is not autoconf, right?)
right. we all hate the autoconf shit.

> I would do this port one library after the other, but would like to know 
> whether it would be ok for me to submit patches for those changes after each 
> library is successfully compiled under Visual C++ rather than a jumbo patch
> at the end of the project. This way we would all be more assured that we don't
> loose synch too much.

you could either fork, and then do a proper port (changing gcc inline to
msvc/masm .asm etc) but it means that new features won't be there.
or you could slowly move teh unix codebase towards win32 compatibility. i
doubt that it' spossible with msvc. mingw could be the solution, it's native
(not like cygwin) but still supports gcc extensions, inline asm etc.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu