[MPlayer-G2-dev] Darwin port

[Dan Christiansen]

On Wednesday, May 7, 2003, at 11:29 PM, Arpi wrote:

> Hi,
>
>> Attached below is a patch to make g2 pre20 compile on Darwin/Mac OS X.
>
> thanks
>
>> Everything seems to work quite well, except there's no working vo
>> module. Here's a short description of what I did:
>
> hmm. no Xv on darwin?

Nope. At least not in standard XFree86. In main MPlayer, the status of 
the VO's are:
xv, sdl, aa: working
gl: buggy
gl2, xover, xv: non-functional

The rest aren't compiled in.

>> - The WORDS_BIGENDIAN code had obviously never been compiled. Added a
>> some missing casts as well as a missing macro.

Forgot to say thanks for writing those parts in the first place. A lot 
of x86 developers are totally oblivious to the fact that most other 
CPUs are big endian :)

>> - Changed "$(AR) r" to "$(AR) sr" to avoid using ranlib. Does this 
>> work
>> on other platforms as well?
>> - The libvo2 test requires all sorts of odd flags and libraries to
>> compile on Darwin. Rather than clogging the Makefile with them, I
>> removed it from "all".
>> - Made "make clean" recursive.
>> - Updated timer-macosx.
>> - Added the required libraries to each target in the main Makefile. I
>
> these look ok
>
>> wish there was some way to simplify this..
>
> designing a new configure/make system is on the TODO. i have some 
> ideas, but
> no implementation / final design yet.
>
>> I ran into one problem which I couldn't figure out how to solve
>> properly. It seems like gCpuCaps symbol isn't included in libosdep.a,
>> so I had to explicitly link osdep/cpudetect.o into test-codecs. I 
>> tried
>> everything I could think of, and I still don't understand why it
>> doesn't work...
>
> I guess it's linking order. You have to move libosdep to the end of 
> list of
> libs, but probably before mp_msg.o because depends on that.

I tried putting it there twice, in the beginning and the end; same 
result. I suspect that either my setup is broken, some option somewhere 
is wrong, or a bug is being exposed.

>>> # FIXME: for some odd reason the gCpuCaps symbol will be undefined on
>>> Darwin
>>> #        unless osdep/cpudetect.o is explicitely linked
>>> 	$(CC) $(OBJS) test-codecs.o osdep/cpudetect.o -o test-codecs
>>> $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) $(EXTRA_LIB)
>>> $(CDPARANOIA_LIB) osdep/libosdep.a $(SMBCLIENT_LIB) $(AO_LIBS)
>>> $(VO_LIBS) $(I18NLIBS) -lm
>>
>> Other than that, with these changes, mplayer-g2 should compile fine
>> assuming the configure script from mplayer is used.
>
> great!
>
>> BTW, when you write the interface for the actual library, please
>> consider adding a simple way to extract metadata from a file. There
>> really aren't any utilities out there which can read metadata from 
>> most
>> media files.
>
> It's already possible, at least demuxers export the metadata.
> See test-stream for example.

I'll take a look later :)

>> Also, if anyone is considering porting vo_gl from mplayer, could you
>> perhaps try to isolate the X11 dependencies in the same time? I tried
>> to make a mac native vo based off it, but it was too difficult for me.
>
> Hmm. It would be good for win32 port too.
> The problem is that big part of the GL setup is GLX (or WGL on win32, 
> dunno
> the Mac case) function calls. Maybe we need 3 implementations of this 
> init
> code, one for each major OS. And maybe a 4th for FBDRI on linux...
> And a 5th for gtk-GL and a 6th for SDL-GL :)
> Maybe it's worth to completely (in file level) separate GL and 
> OS-dependnet parts.

How about doing it sort of like the X11 stuff is done in g1 with a 
gl_common? It would probably be best to isolate the individual parts. 
The way I understand it, it's basically creating the GLContext and 
registering event listeners that differs. Given a context, the OpenGL 
code should be the same. I have a feeling that SDL is slowing things 
down horribly on Mac OS X; I ought to be able to play just about any 
DivX on my 400MHz, but most drop frames in MPlayer. I'd very much like 
to help out writing a native video out module.

Considering different implementations: You could even do two versions 
on Mac OS X - one using the C API (Carbon) and another one using the 
Objective-C API (Cocoa). Personally, I'd go for the ObjC version.

With the new, library based approach, a vo should simply return a 
pointer to/instance of a GUI element to which it renders, right?

- Dan