[MPlayer-dev-eng] [PATCH] Real Audio/Video support for Mac OS X

[Donnie Smith]

On Sat, Jun 19, 2004 at 01:34:33 +0200, Reza Jelveh wrote:
> my cubes hdd died for yet unknown reasons so i couldnt test as fast
> as expected. nontheless the patch looks ok from what i see. ill test
> on my brothers ibook when possible.
OK, sorry to hear about the disk failure. It'd be nice if someone
tested it on Linux and Windows (and ...) as well, just in case I
managed to break something in jungle of #ifdef:ing.

> 1. darwin supports unix dlopen for opening shared libraries in osx.
> isnt there a more common way to implement the symbol loading?
As far as I know: no. But as I said, I wrote the patch two years ago,
and things might have changed (Darwin didn't even have dlopen then). 
The problem is that RealOne for Mac OS X uses CFM-style shared
libraries (a left-over from Mac OS Classic), and the calling
convention differes from the ordinary Mach-O, hence the glue in
setting up the function pointers.

Notice that the code to load the shared library isn't that strange, 
it's just a GetDiskFragment() (think dlopen()) to open the library and
FindSymbol() (think dlsym()) to retrive the function. The
FSPathMakeRef() and FSGetCatalogInfo() calls are just to retrive the
data (converted from a POSIX-path) we need for GetDiskFragment().

Furthermore, the sample code at 
http://developer.apple.com/samplecode/CFM_MachO_CFM/CFM_MachO_CFM.html
used to convert between the calling conventions is not listed as
deprecated, as it should if they had added a CFM-to-Mach-O function in
the libraries. (Btw, the space before "samplecode" should be removed
from the URL in the patch.)

> 2. i think it would be best to split the os specific code or
> generic code from vd_realvid.c or ad_real* and put it in a
> different file.  that would make the source more organized and
> readable(however that cleanup should be done in a different commit
> as i suppose it would count as cosmetics). 
I agree, and I tried to solicit suggestions for as to how to do this
last time. Basically, it would just be a matter of implementing
shlb_open() (currently repeated in load_syms_mac in both files)
and shlb_sym() (currently called load_one_sym_mac).

I'll need to know the exact name of the file before I do so though,
and perhaps some helpful hints as to what other files should be
changed.

> as for ah_my_goddess*.rm. i think that file is broken and doesnt
> even play in normal realplayer(i might be wrong tho). but i think i
> had the same desync behaviour in linux.
I think they fixed that bug? It plays just fine in my RealOne player,
and in mplayer with -ao sdl.

> and for high cpu usage desync thats a not really an error but rather
> you should try it with framedrop that might work against the
> desynchronisation?
My point was that: always works with -ao sdl, often (even at low CPU
usage) doesn't work with -ao macosx. Since it always works with SDL,
which should require more CPU -- right?, I'm suggesting that the
buffering in -ao macosx isn't done entirely correct. (The reason I
mentioned CPU-usage is that perhaps it will work just fine on someones
dual 2.5 GHz G5 when nothing else hogs down the machine.)


> regards
> reza jelveh
Thanks for the comments.

Donnie Smith