[Arion]

i don't want to get too deep into xbmc dll loader, so instead of trying to figure out for myself, i thought i'd just ask here, and put my time to better use, doing more useful stuff:

dll.resolveexport("audio_out_format_bits", (void**)&paudiooutformatbits)
dll.resolveexport("setvideofunctions", (void**)&psetvideofunctions);
dll.resolveexport("getaodata", (void**)&pgetaodata);
dll.resolveexport("setaudiofunctions", (void**)&psetaudiofunctions);
dll.resolveexport("mplayer_init", (void**)&pinitplayer);
dll.resolveexport("mplayer_open_file", (void**)&popenfile);
dll.resolveexport("mplayer_process", (void**)&pprocess);

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.

[jmarshall]

yes, i believe that is how it goes, and yes, only the exported functions are what we have contact with.

as for xine for dvdplayback, be aware that there are devs already working on a dvdplayback solution, so i wouldn't get too caught up in working on that.

other devs are more involved in this interface than i am, so they may be better able to comment.

cheers,
jonathan

[elupus]

well, almost.. apart from that the video renderer used is in xbmc rather than the dll, which in that turn would have to be emulated to behaive as mplayer (doub't it would be possible) + you'd probably need to expand the emu layer to support anything xine is using.
but biggest problem, as one of our own devs found out when starting a port of it, is that xine eats way to much memory to be usable.

not to kill your buzz about it, but i'd give up on the idea unless you are a very talanted coder.

elupus

[darkie]

but biggest problem, as one of our own devs found out when starting a port of it, is that xine eats way to much memory to be usable.

actually, that was vlc :-)
xine is using less memory, about 8 mb when loaded on the xbox (still much more then mplayer). and yes, i already started on porting xine too, but that is far from finshed, cause it involves lot's of work to get it working

[elupus]

whoops.. my bad..

give xine a go then arion, but i'd recommned not trying to get it to be a dropin replacement for mplayer, think that would be harder to accomplish then adding it by it's own