SMF v2 RC 1 Discussion

Jun 11, 2010 at 4:21 PM
Edited Jun 11, 2010 at 7:12 PM

Hey Guys,

Great work on the new player. I've been going through some of the code and have come up with a couple questions and issues I've encountered so far. There's still a bit of migration testing I need to perform, but I figure I would start with what I have now and post more later as I come across them.

-- Questions
1) The marker plugin is a bit odd. I went to implement our SRT subtitle plugin; however we must hardcode "caption" for the marker type and the marker object itself must be of type CaptionMarker, which is part of the SilverlightMediaFramework.Core library. I think the known marker types should be exposed for plugins to use and the CaptionMarker class shouldn't be included as part of the core library.

2) In addition to the above, the Content property of the CaptionMarker class is bound to the UI thead because you create a UIElement. This prevents us from loading subtitles asynchronously, which degrades performance. It also boosts memory requirements because you are creating a UIElement for each subtitle. In our current player, we define a single subtitle region and update the UIElement on the fly when a subtitle marker is triggered. It's both good with performance and efficient with resources. You would also better support live closed captioning.

-- Issues
1) In regards to playlists, the SelectMediaPlugin method in the SMFPlayer should take into account the playlist item's media source to find the correct plug-in when the delivery method property has not been specified. Currently when you pass in a live smooth stream without specifying the delivery method, this method returns the progressive plug-in instead of the smooth streaming plug-in and it fails to render the live stream.

2) I didn't look into it deeply, but the closed captioning doesn't always work. When it starts up, I see the first couple subtitles. As I seek through the video, nothing happens anymore. It's almost as if the CaptionVisibly property in the SMFPlayer was reset back to Hidden (again, I didn't check throughly).


-- Edit. Fixing up the line spacing in the post.

Jun 14, 2010 at 4:22 PM

Hey, me again.

I have a couple more questions.

1) Why does your progressive media plugin not support advertisements? It's more than possible to do it.

2) Could you add a playlist plug-in? We process many types of playlists such as ASX and SMIL. Using the static XML one doesn't suit our needs. Perhaps you could add a PlaylistSource URI property and load it through the playlist plug-in with a matched extension attribute or some such.

3) On the same note about playlists, there should be some way to extend on it without requiring a rewrite of both your playlist classes and the player. For example, we store asset IDs in our playlist items, which in turn are used for metering playback and other server related activities. Our PlaylistCollection also has a title and description field for root-level display (ie: what is this playlist collection you are watching). There are also times when we need to store runtime information in a dictionary object, such as advertisement data that must be submitted to the ad servers for requesting an ad playlist and/or management.  I suppose if you just add a dictionary object of type <string, string>, that would be enough to add in whatever custom data 3rd parties will want to supply.

Jun 14, 2010 at 6:10 PM

Hi TheNut,

1) The reason the ProgressiveMediaPlugin does not support advertising is because it is based on the MediaElement, which does not have native support for the scheduling of advertisements.  The SmoothStreamingPlugin on the other hand is built on the SmoothStreamingMediaElement which does have this support.  I agree that it would be possible to implement ad scheduling on top of the MediaElement but this is not a feature we have had the opportunity to implement.

2) Playlist Plugin - This is a good idea, not the first time I've heard this one.  I'll bring it up when we are planning our next feature set.  Here's a thought regarding your implementation suggestion, I'd like to remove dependence on file extensions to look up a plugin, perhaps instead have another property indicating an id for the Playlist Plugin to use.

3) I'm not sure why you would need to rewrite the Player to extend from PlaylistItem.  Is there something preventing you from creating a subtype of PlaylistItem with title and description fields?  Regarding the storage of runtime information in a dictionary, I don't believe this belongs on the Playlist.