Quote: dll.resolveexport("audio_out_format_bits", (void**)&paudiooutformatbits)
i'm assuming that the first argument is the name of the function in mplayer.dll, which is then mapped to the second argument?
i'm further assuming that these functions are the only communication between xbmc and mplayer.dll?
are these assumptions valid?
following on from that, i assume that if the above functions were implemented as an mplayer/(xine/ogle/name_other_player_here) compatability layer, then xine could be used as a drop-in replacement for mplayer? i'm not saying that that would be enough to get dvdmenus working, but getting xine working would be a fairly hefty step in the right direction.
i also think this may be a good step to take, since it would involve minimal involvement in the main xbmc source, which translates to minimal need to understand the source of xbmc considering that i also have the source of xine, and mplayer.dll's exported functions, to take care of. the layer could then also be used as a reference for the writing of other compatability layers.