Ok, the location of the git tree is described here:
http://wrightrocket.blogspot.com/2012/07/building-omxplayer-for-debian-on.htmlSome things to understand about media players in LinuxMCE:
LinuxMCE is all about control. Even the media support in LinuxMCE is nothing more than a consolidation point to figure out where to fire messages and for what reasons. The exception to this is of course the stuff needed to create the various data grids for media, but that's not relevant here.
In the end, you have two devices that must be made:
* a Media Stream plugin, which registers itself for media players of a given device template, and creates a MediaStream object for them (read src/Media_Plugin/MediaStream.h), describing the media playing, and its targets etc. The purpose of the plugin is to figure out where the stream needs to go (the target devices in an entertainment area), and what commands need to be done to make that happen.
* a Media Player, which is literally a target device that accepts commands to go do something (Play, Pause, ff, rew, change subtitles, etc..), and it sends events when something happens (Media is playing, a menu is on screen, etc.). It usually has no user interface of its own.
The commands that are sent from Orbiter, are sent to the Media Plugin, which send them to the Media Plugin providing the MEdia Stream for the target EA, which forwards them to the target player. This is actually done transparently, as long as you change one critical piece of code in ReceivedCommandForChild in the plugin. (instead of INVALID COMMAND, you send back INVALID DEVICE, oddly enough.)
Your task, with omxplayer, is to build a player, which has two threads:
* the DCE thread, which is already made, this is made by DCEGen, and it's literally fill in the blanks.
* the media player thread, this literally, you spawn at some point during initialization (CreateChildren, and GetConfig are good choices here. Look at Xine_Player for this.)
You thread through a pointer to the DCE thread to the player thread, as a callback mechanism, and use that to pass back anything the media player stream needs to send back to DCE.
For communication with the media player thread, you of course pass through a pointer to the media player thread, and you use it...
void CMD_Pause(...)
{
PLUTO_SAFETY_LOCK(mediaPlayerMutex);
m_pMediaPlayer->CMD_Pause();
}
you will notice the PLUTO_SAFETY_LOCK, this is a macro provided literally as a convenience, passing in a mutex, it literally locks the mutex, until the PLUTO_SAFETY_LOCK falls out of scope. This is needed because of course, the DCE stuff is a separate thread, and commands will be called asynchronously.
The other bits needed of course, the device data for the omx player device will have a device data called Name (look at Xine Player), this is literally a WM_CLASS.WM_NAME tuple, i.e. omxplayer.omxplayer .... use wmctrl -l -x to get this. Your player should explicitly set this, and it should match in the device data, this is so that Orbiter will grab the window appropriately.
Xine_Player does have additional window manager logic. You'll need to decide whether this is appropriate or not.
In the database, you just need to provide a mapping for DeviceTemplate_MediaType, so that your omxplayer player device is provided there, and that it is provided for type 4 and/or type 5 (in the mediatype table, 4 is audio, 5 is video.), and that these match what you're changing in your omxplayer plugin's Register method.
Once this is there, the stuff should at least START to work. Your job after this point is to literally provide something the media player can play, and to ferry back changes in the media player as needed. This is entirely up to you. an absolute file path is passed into MH_Play_Media, and in xine_player's case, this is passed in verbatim in most cases, unless you are of course streaming (sending to multiple EAs,) in which case the plugin starts the source player, and sends a fifo://source_player_address/ to the second player, AGAIN, THIS IS ARBITRARY! This is a URL that xine can understand, it knows how to do this, and the Plugin figures out what it needs to do, and sends the appropriate message to the players.
References:
http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Media_Plugin/MediaStream.hhttp://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Xine_Plugin/Xine_Plugin.cpphttp://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Xine_Plugin/XineMediaStream.cpphttp://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Xine_Player/Xine_Player.cpphttp://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Xine_Player/Xine_Stream.cpp-Thom
