[MPlayer-G2-dev] Darwin port

[Arpi]

Hi,

> >> - 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 :)

Most of that lowlevel code comes from mp 0_90 or main, so they are not new.

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

maybe a linker bug, sadly :(

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

yes, good idea.

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

feel free to do. i've simplified the vo API to make it even more easier to
write new native vo modules instead of hacks like SDL or GGI.

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

Yes. You can either export your buffers as-is (as pointers and
bytes-per-line (aka. stride) values), in this case all teh rendering
will be handled by vf_vo2.c
Or if your device doesn't have such buffers (special cases, when the
driver have functions to blit data, but you have no direct access)
then you can implement draw_slice() (just like in mplayer g1) to blit
parts of the image.

Hmm, just thinking about it a bit, it may be possible that some evil
devices/drivers doesn't even supports blitting by slices, just whole
images. So i have to re-add the VFCAP_ACCEPT_STRIDE for this purpose.
Ugh, maybe even VFCAP_ACCEPT_STRIDE is still needed?

I think it's time to write libvo2.txt


A'rpi / Astral & ESP-team

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