Silverlight still doesn't allow media to be streamed using server-side playlists. In other words, Microsoft's latest client-side technology, Silverlight, is not truly compatible with their own current back-end server technology. Surely this situation is untenable and should be rectified quickly? When will Silverlight be able to work with server-side playlists, including the WSX format?

This essential functionality should not be difficult for Microsoft to implement; it would be a natural extension to the basic streaming capability already provided by Silverlight.

I work for a major commercial media company where we use Windows Media Services on the server-side to stream content to Windows Media Player on the client-side. This is a typical enterprise-level architecture for serving media content. We cannot use Silverlight until it supports server-side playlists, and many other companies are in the same situation.

Many professionals and members of this community have been lobbying hard about this issue, and raising it online and with their contacts and Microsoft. Yet we still have no timeline for a solution. I can only conclude that Microsoft fails to appreciate what a serious issue this is, and how easily it could be fixed.

The online media sector is growing explosively, and Microsoft is at risk of being left behind. If the present situation continues, people will have no option but to turn their backs on Microsoft and seek alternative long-term solutions.

The current Silverlight release has a big cross domain issue, basically they want to create a closed sandbox thus not allowing web calls to other domains. Now, for the future release, Scott Guthrie (you do read his blog right? http://weblogs.asp.net/scottgu/ ) mentioned that SL2.0 will have rich networking support:

Rich Networking Support: Silverlight 2 includes rich networking support.  It includes out of the box support for calling REST, WS*/SOAP, POX, RSS, and standard HTTP services.  It supports cross domain network access (enabling Silverlight clients to directly access resources and data from resources on the web).  Beta1 also includes built-in sockets networking support.

I wouldn't be surprised if your server side playlists will also start working (considering the "WS*" part in the quote). 

I fear that the improved networking support expected in Silverlight 2 will not include server-side streaming. As yet there is no unambiguous indication that SL2 will support server-side playlists.

I've raised this question on Scott Guthrie's initial blog page exploring Silverlight 2, in the hope of a specific answer about server-side playlist support.

http://weblogs.asp.net/scottgu/archive/2008/02/22/first-look-at-silverlight-2.aspx

Hello all,

I am curious what types of SSPLs you use. What tags do you use most and what attributes? What are you attempting to accomplish with each playlist ? Do you have any examples you can share? Are there any specific behaviors you would want in the client to work with SSPLs?

If you have answers to these questions that you want to share, please select my profile and send me an email message.

Thanks all,

Larry Olson
Silverlight PM
Microsoft

Hi Larry,

Thanks so much for your reply.

I'm collecting the information that you have asked for and will get back to you very soon.

I can't think of a better showcase for Silverlight than the online audio and video players I work on for a major UK media company.

Thanks,

Tim.

Larry -- answers to all of your questions below.

To clarify what we're talking about here, Silverlight doesn't really need to know about the server-side playlist. The SSPL just tells Windows Media Services which content to stream. WMS reads the server-side playlist and sends a stream to the client (e.g. Windows Media Player or Silverlight). So all Silverlight needs to do, for this to work, is connect to a Windows Media Services publishing point and play the stream. But it doesn't work with server-side playlists. The difference with a server-side playlist is the gaps between each piece of content coming from the publishing point. I suspect the problem is Silverlight not waiting for the next item of content, or not playing the next item for some other reason.

> I am curious what types of SSPLs you use.

As far as I'm concerned there is only one type of server-side playlist or dynamic playlist in this context, and that is Microsoft's own implementation. We're using it in the very normal and conventional way, we're not doing anything special or unusual.

As well as what's below, I'll send you one of our real-life examples by email as well as a URL where you can play a real-life stream based on a SSPL in Windows Media Player (but sadly not Silverlight).

SSPL example:-

<?wsx version="1.0"?>
<smil>
    <media src="httpd://localhost/DynamicPlaylist.aspx" />
    <media src="C:\WMPub\WMRoot\ContentClip.wmv"/>
</smil>

Details of Microsoft's server-side playlist solution, which is based on the SMIL syntax, with examples, advantages, uses, etc:

https://www.microsoft.com/windows/windowsmedia/howto/articles/adinsertion.aspx

Details of SMIL, including specifications, etc:

http://www.w3.org/AudioVideo/

> What tags do you use most and what attributes?

We only use the one default tag and the one default attribute (see above).

It might be nice to use other standard tags too, e.g. copyright:-

<media src="...">
    <clientData copyright="..." artist="..." title="..."/>
</media>

> What are you attempting to accomplish with each playlist?

We just want Silverlight to play through the media items, just like Windows Media Player does. Because the SSPL is dynamic we can do various things with it, like inserting an advert at the beginning for instance. Simple audio would be fine for now. Silverlight already works with static playlists, so it shouldn't be hard, and could perhaps even be considered a bug if that helps to get SSPL support in version 2.0.

As Vic Martins wrote a while back:

    "However, currently, Silverlight is of no use to professional streaming providers exactly because of what Simon Andrews points out. We have done a lot of testing with Silverlight 1.0 and Server Side Play Lists and have observed it working fine on a number of occasions, which suggests to us that the problem is actually bug related and not a matter that 1.0 doesn't support SSPLs. If Microsoft were to fix the bug (if that's what it is) then Silverlight adoption in the streamed media market would rocket TODAY!"

http://community.irritatedvowel.com/blogs/pete_browns_blog/archive/2008/01/08/Why-Silverlight-2.0-will-Change-How-We-Build-Applications.aspx

> Do you have any examples you can share?

Yes, see above.

> Are there any specific behaviours you would want in the client to work with SSPLs?

Yes, see above.

 Larry,

 Nice to see you here.  I'm looking for a capability which is not SSPLs, but simply true streaming.  I want to utilize Silverlight as a client support rapid random access to large video media files (e.g. 250 megs).  I would very much appreciate your comments on if/when the Silverlight MediaElement will support true streaming in conjunction with Windows Media Services.  Additional layers above the Media Element will be utilized to superimpose additional content on top of (and synchronized with) the video.

Utilizing a) Windows Media Services 9 b) Silverlight 2 beta, c) VS2008 

 Thanks so much,

 
Martin.

 

Hi Tim

I am glad Larry is helping out here. SSPL has been one of my favorite features in WMS.

I also wanted to mention another playlist solution offered through IIS. It works in progressive download scenarios so may not help in your case. However, if you have some progressive download scenarios, IIS Media Pack - Web Playlist offers capabilities similar to SSPL and uses ASX to send data to a client. More details here.

I hope it helps in some way in future maybe.

Does anyone know what Vic Martins means exactly by "We have done a lot of testing with Silverlight 1.0 and Server Side Play Lists and have observed it working fine on a number of occasions...". What are these occasions since the most common ways of writing a SSPL, like mentioned above, do not work?

Are there any known workarounds for tricking Silverlight 1.0 / 2.0 into streaming from a SSPL?

We would love to have WSX playlist functionality back, please, or for the whole ASX spec to be supported.  One or the other, preferably both.  For reference, we do real-time scheduled playout with viewer-and-content-contextual advertising clips as pre-roll, post-roll, and intermingled within the content-clips of a playlist. We secure our playlists via a combination of encrypted requests and time-to-lives on both the playlist-requests and the media-requests.

We dynamically generate both ASX client-side playlists, and now our own proprietary format (heh; not exactly proprietary, it's JSON...) to get around several of the limitations of SL's ASX/playlist support:

• no support for STARTTIME element
• no support for fallback URLs
• no support for playlist look-ahead
• no support for mixed-protocol playlist
• no support for communicating with WMS and dynamically adjusting the bitrate of the stream according to network QoS (which albeit would be a completely new, and killer feature) without needing to restart the stream and thus avoid a buffering-wait
  
• no support for nesting past 5 levels (which is a bit of a problem for long-form continuous schedules from a single playlist-entrypoint)

It looks like the IIS Media Pack's Web-Playlists is just a server-verified version of ASX that maintains session-state; this doesn't help us, because so much of the ASX spec that is interesting and useful to us is unsupported by Silverlight.

We would love to use WSX playlists containing SMIL; it would simplify our architecture dramatically as well as improve our security model.

MS has previous said they will support server-side playlists; there are discussions dating back to last year. However, they haven't said they will specifically support WSX/SMIL, and this is also still absent from the SL2 beta SDK documentation.  It would be really useful to us to have some concrete feedback on this.

In case this isn't already obvious, I just wanted to point out that a simple Windows Media Services publishing point will in fact be configured as a server-side playlist. All publishing points (e.g. the online version of the on air broadcast from radio stations) in a serious enterprise-level streaming operation will consist of a smil with a series of switches -- first the primary source for the stream, then one or more secondary sources for resilience in case of problems with the primary source, and finally a catch call to play silence or a standard message if the previous sources are not available.

Yet Silverlight 2.0 Beta doesn't support server-side playlists! In other words, Silverlight 2.0 is unable to play a simple continuous stream from a typical Windows Medias Services publishing point. In other words, Microsoft's latest client-side technology doesn't support Microsoft’s own server-side technology.

For example, major radio stations and media companies who committed to and invested in a Microsoft architecture and a Microsoft's streaming infrastructure can't deliver their service on line using Silverlight. Not unless they scrap their existing infrastructure and adopt an alternative -- which from this point onwards might as well not be Microsoft.

The web development community can only conclude that this serious oversight by Microsoft is an accident -- one which must be corrected immediately. This must surely be a classic case of the left-hand (Silverlight) not knowing what the right-hand (Windows Media) is doing. If this is not rectified before Silverlight 2.0 is released, Microsoft will have shot themselves in the foot and alienated every serious media company that chose Microsoft technologies.

And the delivery of rich media is clearly an integral part of the future of the Internet. This issue will be a significant factor in determining which technologies companies adopt for web development in the foreseeable future.

I'll keep lobbying until Silverlight 2.0 is released, but like many other media companies we're already having to consider alternatives to Microsoft for all future front-end and back-end web development projects.

Hi {petemounce},

By real time do you mean live? Could you elaborate a little more on your scenarios? I believe (unless it is live) web Playlists should be able to help here but as they say devil is in the details, I would like to uderstand the scenario better.

Here is what Web Playlists can do:

1. Web Playlists sends out an asx to the end user and that asx contains obfuscated (tokenized) entries. Each entry is computed at the time it is requested. This allows you to dynamically change based on the context (Details)
2. It can support pre-roll / post-roll and intermediate ads (Details)
3. SL2.0 allows extram params in asx. The web playlists can make use of this feature and you can write code in SL to interpret extra params. (Details)
4. It supports integration with existing applications - in this scenario, an external web app can determine what is to be played for each request (Details)
5. it allows you to totally change the way playlists are stored, computed or retrieved with custom providers (Details and example)
6. The session has controllable time to live and idle timeouts. These can be controlled at the level of playlists too.

Here is what it can't do:

1. It supports only progressive download, no streaming, no live. If you use live you would need SSPL in WMS. If you use streaming, look at Bit Rate Throttling also.
2. Since we give out an asx the skeleton (no. of entries) in the playlist cannot change dynamically. There are ways of working around this using custom providers. If you are interested I can go into details.

I would really love to hear more about your scenario here.

Hi Vishal

By "real-time", I meant, according to a fixed timeline - though we do live-events too.

I don't think web-playlists will help us, for two reasons

a) we exclusively do streaming (both real-time (as in, live-event broadcasts) and on-demand) for our WM delivery.  We're one of those "enterprise-level streaming operations" that Tim mentions, in fact, and we had to entirely replace our SMIL playlist-generator with a new one that renders to ASX (which is fine; the old one was ... at the end of its life, let's say). We will not replace our playlist-generator twice in one year!  ;-)

b) our new playlist-generator supports all the features that web-playlists currently do, and a few besides.  And doesn't require us to wait for SL 2 for some of them (which would be an entirely show-stopping thing).  It will also be pretty trivial to make it render to SMIL once the Silverlight team remember to support server-side-playlists (we have a pretty pluggable framework at this point).

Sorry, I don't mean to sound like I'm bragging, but we are kinda proud of it ;-) 

We differ in our approach, though; we wrote a WMS plugin to handle security, authorisation, statistics-logging and a couple of other things (and we would dearly hope that the 2008 release of WMS improves the API and brings the SDK up to date - we haven't deployed any Windows 2008 boxes yet to fiddle with it.  At the moment, for example, the Win2003 R2 Platform SDK includes the microsoft.windowsmediaservices.dll that is a version behind, and does not highlight the fact that there are breaking changes - what's going on with that?).  We can enable this plugin on both on-demand and broadcast publishing-points, which allows us to secure live-events "for free", because we're securing at the publishing-point level as well as the playlist ("gateway") level.  In theory, this plugin is also deployable to third-party servers at short notice should the need for more capacity arise (though we haven't had the opportunity to try that out yet...  ;-)  ).

We do on-demand content; we dynamically generate playlists of video, interspersed with ads that get pulled in from third-party ad-servers (like Atlas AdManager, though we wish it were more flexible with what it returns).  The ads may be rendered inline or from nested playlists (and, for the love of all that's holy, we need a bug [1] fixed!!). Please feel free to email me ((pmounce {at} narrowstep {dot} com)) for more details, or have a look at out website (http://www.narrowstep.com) (though it's rather light on technical details at present until the wiki goes online).  There are too many scenarios to go into, here, honestly.

However - we really really really would like support for SMIL server-side-playlists!  Oh, and a fix for [1] below.

[1]

http://silverlight.net/forums/p/6514/20102.aspx - basically, when we have a nested playlist, Silverlight reports the meta-data of the first element as the parent entry's.  This largely hamstrings our third-party ad-server feature, because:

• either we have to render the ads inline (at which point we lose the opportunity to cache since it's viewer-contextual, and we're doing network calls at playlist-rendering time, and stats show all of the ads being served to our servers, not the viewers' IPs),
  
• or we have to render a short blank playlist-entry prior to the ad, inside the nested playlist (which sucks for the viewer-experience, because suddenly they're not seeing continuous, no-buffering-after-the-first-time content, but a couple of black seconds before each advert) (and it turns out Silverlight's MediaElement really doesn't like that, and often craps out without an error message saying why in any decipherable way)
• we have to ensure that every ad is encoded with a unique ID at the 0th second, then listen for that TimelineMarker and call a web-service to supply the meta-data (a URL to navigate to, for example, to buy the advertised thing) - and hope it arrives before the viewer decides to click on the ad.  This incurs an unnecessary network+DB hit per ad which would be really nice to avoid!
  
• or we have to say "sorry, but you can't monetise your content with ads at the moment", which, as you might imagine, is not really a compelling thing to try and sell.

Basically, this bug is our highest need for a fix in SL 1.  We came to see the team at the problem resolution workshop back in November 2007, and raised this, and their QA said they knew about it but didn't think anyone would notice.  We've raised it since, several times, via several different channels and contacts, yet still no fix. 

This is very discouraging from a receiving-support-from-the-vendor point of view.  It's like MS doesn't realise that if people can't make money off supporting SL, they won't support it.

It would be great, too, to see smaller releases, but far more often, in general, out of MS.  The ASP.NET MVC team seems to be moving in that direction, and being highly lauded for it.

It gives me great pleasure to be able to answer my own question.

Q: When will Silverlight support server-side playlists?
A: Silverlight now will support server-side playlists!

As Scott Guthrie reports, "Silverlight 2 Beta2 includes some significant Media related feature work":-

Server Side Playlists

Beta2 adds support for server side playlists (previous releases only supported client-side playlists). 

http://weblogs.asp.net/scottgu/archive/2008/06/06/silverlight-2-beta2-released.aspx

Microsoft has now put Silverlight in its rightful place as a serious client technology with enterprise-level streaming capabilities including server-side playlists and adaptive streaming!

Thanks Microsoft, we're grateful to you for listening.

Hi Tim

I've been watching your comments with interest, and yes, you're right, Silverlight2 does now (in Beta 2) support SSPLs. However, there are still some serious holes. We're currently doing some deep testing and we're having problems with Client Side Playlists insomuch as many of the features aren't supported (such as <REPEAT>). We're still testing it with SMIL with some problems too... We've written a SMIL CSPL which works fine with Media Player but doesn't work at all with SL

Also, Silverlight 2 does not run on non-intel based MACs. This makes it less than ideal in the MAC community, as the huge majority of MACs are still non-intel. Which large scale media publisher would want to (or even agree to) cut out the majority of MACs for the next few years (until they all die out and become Intel based)?

 However, Things are improving. It certainly looks like Release 2 will be pretty good, so long as you are on a PC or Intel MAC

Cheers,

Vic

From what ive been reading silverlight 2 now should support server side playlists, i cant get any server side playlists to run through silverlight. Even the standerd playlists that are generated when you install windows media services do not work.I use  smil and excl, also tried just streaming a directory of files none of them work through my silverlight player for me. I have the latest version downloaded today.

The only time it works is if the publishing point is directed to play 1 audio/video file or if its push. Any help would be greatly apreciated.