The media plugin in and of itself is a base class.
But to understand the differences between plugins and devices, we must examine first where they load:
* Devices load as processes, they open a socket to the dce router on the core, and can run anywhere. They are self contained in and of themselves, and must get information from other devices with DCERouter as proxy.
* Plugins, are also devices, but they load in the memory space of DCERouter. This is very important because of the way that C++ handles objects...
Because the plugins load in the same memory space, they have access to the public and protected structures (classes, methods, objects, etc.)
read that again.
What does this enable?
keep in mind there are other plugins besides your own:
* Climate Plugin--Handles the high level climate code
* Lighting Plugin--Handles the high level lighting code
...
* Datagrid Plugin--Handles maintaining, populating, and selectively returning what parts of a data grid to display.
* Orbiter Plugin--Handles the high level maintenance of orbiters
* Media Plugin--Handles the high level aspects of media control, pipes, the file list UI, finding which streams to create, etc..
all of the things i describe above are intentionally compartmentalized and abstracted.
These things provide the house wide logic that the rest of the system hangs off of.
Now, with this explained, I can get to the point:
The media plugin implements the MH commands, the media handler commands.
the media handler needs
* a location of some media, this can be anything, a URL, a path, some sort of uber-proprietary resource locator, something...
* a media type, is this..audio...video...dvd....game...tv...
* an entertainment area, or areas.
optionally,
* a device or device template to prefer.
and some other little bits, but not important for this discussion.
The media handler, goes into the media plugin... and there is a join table specifying player device templates for media types (MythTV Player mapped to media type 1, Xine Player mapped to Media type 5, etc.) DeviceTemplate_MediaType
...but how does this tie into the plugin? don't worry, I'm coming to task very quickly...
keep in mind that i said that plugins can reference data structures....
Devices use the Connect() method to enter into their code.... Plugins use a different entry point than Connect()... Register().....
(slight edit, I was typing too fast) ;-)
If you look in Xine_Plugin, look at the Register() method in Xine_Plugin.cpp... what do you see? .... you see a reference into the media plugin, for registering a media connection to the media player..the Xine player... passing in a reference to the xine plugin itself.
This completes the circle...and creates the backbone of an extendable plugin system.
Now, the registered media plugins, also have a device priority devicedata, so you can specify certain media plugins to have precedence over others....
but..what does the Plugin itself do?
The plugin itself is responsible for creating a concrete form of the MediaStream class in a unique type (XineMediaStream, for example, for xine player streams)..which contains special properties for that stream... whether it contains audio, or video, etc... look at the mediastream class itself for details.
The plugin is also responsible for finding devices within an entertainment area capable of fulfilling the media handler command (Xine Plugin looks for all the xine player devices in the entertainment areas specified.)
Once we know this, we can figure out, for example:
* If we started the media stream on one machine, and it's the same machine, maybe we just need to pass a local file?
* If the source and destination machines are different, or multiple machines, this means we have to set up some plumbing to hook up the player devices, don't we?
Once we know all this, we can create the stream, figure out what we need to pass to the players, and craft CMD_Play_Media commands, for example, pointed to the player devices.
Now keep in mind, stream in this case, is a _VERY_ abstract term. You have to handle any stream management yourself, whether you do this in the plugin, or at the players, is up to you.. plugins run on the core, and have access to data structures that you may need... devices are nice and isolated on the media directors, or even running on the core itself (in the case of the squeezebox devices).....
Now, i haven't looked at the slim server streamer stuff yet, but.. this should give you an idea of what's going on behind the scenes...
but why is it this way?
very simple. It's an abstraction pattern.
This allows you to create different devices that may have different transport semantics, but are capable of handling similar data (or the flip flop of that can also be true.)..and be able to swap them out depending on the need...and furthermore, to be able to intelligently handle the same piece of media differently, depending on the device it's being beamed to.
I'm sure you see the power in it now, ;-)
-Thom
