Hey darthobiwan, first thanks for the feedback. Let me try to address your points one at a time and please, let me know if I've missed anything:
- Media Plugin selection process
You have described the process for selecting a Media Plugin, but I'll recap for clarity:
1. Filter available plugins on supported Delivery Method. If “NotSpecified” Delivery Method is ignored.
2. Filter on PlaylistItem.MediaPluginRequiredMetadata (custom metadata key/value pairs)
3. Filter on whether LiveDvr support is required
4. From the remaining list, select 1, favoring those that have already been instantiated
The goal of this process is not to facilitate the selection of a “specific” media plugin, but instead to simply pick one that will do the job. I wouldn’t use the word “crapshoot” but,
you are correct in that you are not guaranteed that your plugin will be selected if there are others available that have equivalent capabilities. In cases where a specific plugin or more complex filtering is required (i.e. supported containers, etc) use PlaylistItem.MediaPluginRequiredMetadata.
- Why not use the URL to determine the media type and just use that to pick the right plugin?
This is something that we thought about at one point in time but eventually decided the URL isn’t reliable. On the web there’s no requirement that the file extension be part of the string (think URL shortener),
also the “content-type” HTTP header isn’t much better in this respect. Making this a viable (and reliable) solution would be very challenging and potentially error prone, so instead, we decided on DeliveryMethod. While I agree this does not
cover every case, that was not the intent, we wanted simple. We could have expanded on this, made it more robust, but we believed that would make it more complicated for the average developer. Instead, as mentioned above, for more complex scenarios we support
the specification of metadata on the PlaylistItem and the MediaPlugin.
Per your comment about SMF v1.1, this is not something that was supported in that version of SMF either. There was no need for “DeliveryMethod” because there were no plugins to pick from, it was coupled
to the SmoothStreamingMediaElement. In v2, this property only serves to filter available plugins. If you only have 1 plugin available in your XAP, don’t bother with it, the default is “not specified” so it will be ignored and that 1 plugin
will always be used. That said, there’s no reason for you to write a system to determine “DeliveryMethod” from a URL if everything worked fine in v1.1.
- Why not pass “Evidence” to the plugin allowing it to determine if it supports the media?
This is also something we considered, perhaps adding an IMediaPlugin.SupportsPlaylistItem(PlaylistItem) method? Instead we decided to allow the plugins to expose their “evidence” using MEF attributes
and allow the Player to query over the body of evidence that is available at that time. One of the reasons for this was performance. Instead of instantiating each plugin, which we would be required to “pass it evidence”, we use MEF’s built
in support for Lazy<T, TMetadata> which means we don’t have to instantiate anything until it’s selected.
- PlaylistItem support for MediaStreamSource
This is probably a good idea, and one that several people have now expressed an interested in seeing. I'll make sure this is part of the feature discussion for our next release.
- Using PlaylistItem.MediaPluginRequiredMetadata
This property on the PlaylistItem allows you to specify key/value pairs that the player compares to the metadata that is exposed on available plugins. The easiest way to expose metadata on a plugin is simply to add
an ExportMetadataAttribute with a matching key/value pair, like this:
If a PlaylistItem has matching metadata you can be sure this plugin will be selected: