Video and Media

Re: Re: Windows Media issues that need developer love!

FlashRiver — Thu, 31 Jul 2008 09:09:50 GMT

Ah so in essence, in the future we will have the ability to either use a playlist "playlist.wsx" file or "playlist.asx" file to stream from our WMS mms:// protocol publishing point without having to set WMS to stream as a http:// protocol from a single publishing point?

I am wishing for a near future out of the box experience using the Silverlight media player to stream multiple publishing points.
-FlashRiver

Re: Re: Windows Media issues that need developer love!

vsood — Fri, 04 Apr 2008 22:36:21 GMT

In silverlight the mms:// moniker is used to stream. The underlying protocol used is still http.

Re: Windows Media issues that need developer love!

silverlightnewbie — Sun, 30 Mar 2008 17:50:13 GMT

Can you provide a resource or a documentation link which states that http is not supported? I am just curious because as far as I have looked the documentation is quite explicit about supporting http protocol, even using it as a fallback protocol. There is also a live video stream http://powerhost.live.powerstream.net/00300000_live2 that uses the http protocol which seems to contradict the second part of your statement, although the live streaming appears to be through WMS. I will be at the MSLive conference in May, hopefully I get some more information about the live streaming there from the horse's mouth, so to speak :)

Re: Windows Media issues that need developer love!

nesNYC718 — Sat, 29 Mar 2008 21:38:52 GMT

silverlightnewbie:
I have an app that streams a live video. The video stream works fine in Microsoft Media Player using the "Open Url.." and specifying http://localhost:8080 but the same Uri does not work in SilverLight 1.1, gives an error 1001 (DownloadError). Am I doing something wrong, or is it a SilverLight's issue?

As stated above, http is not hooked up to stream yet. I gather you're running this off the media encoder correct? That only supports http upstream so you'll have to encode to a WMS (Windows Media Services server) and pull the live feed from there as mms:// url.

Re: Windows Media issues that need developer love!

einar — Thu, 27 Mar 2008 22:00:32 GMT

"Server-Side playlists are being worked on." <-- Did Server-Side playlists make it into the SL 2.0 Beta?

Re: Windows Media issues that need developer love!

silverlightnewbie — Thu, 10 Jan 2008 23:22:41 GMT

I have an app that streams a live video. The video stream works fine in Microsoft Media Player using the "Open Url.." and specifying http://localhost:8080 but the same Uri does not work in SilverLight 1.1, gives an error 1001 (DownloadError). Am I doing something wrong, or is it a SilverLight's issue?

Re: Windows Media issues that need developer love!

ajohnson — Mon, 07 May 2007 21:33:19 GMT

It appears that the marker and scriptcommand events do not work at all (progressive or streamed) when the silverlight object is running in the Firefox browser.

Firefox 2.0.0.3
Silverlight 1.1 Alpha

Re: Windows Media issues that need developer love!

m3taverse — Mon, 07 May 2007 19:09:25 GMT

dks, it's possible the Silverlight people will not see your post as this thread is labelled as Answered.
It's better I think if you create a new thread, then you can be sure that there will be an answer.

Re: Windows Media issues that need developer love!

dks — Mon, 07 May 2007 05:16:00 GMT

Thank you for your posts on Silverlight. This is very helpful. A few more questions:

1. Will we see support for Multicast, once streaming and script support for live is in? Normally the URL that we use for a multicast is of the type http://webserver/mediafile.nsc

2. Will we see support for streaming a SAMI file for on-demand?

3. When will we be seeing the next public release? Or will we be seeing the RTM directly.

Thanks

Dks

Re: Windows Media issues that need developer love!

m3taverse — Thu, 03 May 2007 10:28:52 GMT

Thankyou very much for responding so quickly, it's really appreciated.

I think we can get by a while without rtsp support, I'm relieved that it's http based streaming and not the raggity old actual mms protocol that is blocked by 9/10 firewalls out there. In the longer term, for larger scale webcasts, really high bitrate or corporate stuff it wouldn't hurt if we had some UDP based transport, altho i realise that only a percentage of my users will be able to take advantage of it.

While I can't wait for script streams and server sided playlists to be supported, I shall now retreat for making some cool demos :)

Thanks again, and thankyou for Silverlight. Once this stuff starts working it will really change webcasting. I'm excited about that in a way that I haven't been excited about anything in a long time.

Re: Windows Media issues that need developer love!

gillesk — Thu, 03 May 2007 05:44:41 GMT

Thanks for raising these issues and let me give you some clarifications.

You should be able to set the source as http://webserver/file.wmv, we'll take a look to make sure, but this should work without issues.
For streaming, Silverlight only supports http as the streaming protocol, it will not do the actual mms or rstp protocol. In the beta we differentiate between streaming and progressive download by the mms:// vs http:// monikers. This will be addressed for RTM, while we will try progressive and streaming for both, http:// will try progressive first and mms:// will try streaming first, therefore is you keep these monikers as hints to the client, you will get better perf.
Events in the streaming case aren't currently fully hooked up. We are working on fixing this.
Thanks for reporting the Markers and Script command issues while streaming, we'll take a look at what's going on.
Neither Fast Start nor Server Side Playlist are implemented yet. We will be addressing these issues in the near future.

For the needs that you've specified:

We will look at the ScriptCommand issues on streaming scenarios.
Server-Side playlists are being worked on.
mms is really http streaming. You do have the abilty to specify a port by setting your source as mms://server:port/publishingpoint. Since we are really targeting the internet as our primary medium for video distribution rtsp has had a lower focus and is not in the 1.0 plans right now.

I do feel your pain and we are working hard at addressing these issues.

Re: Windows Media issues that need developer love!

winston1000 — Thu, 03 May 2007 02:00:04 GMT

Great post m3taverse one thing you noted previously but was missed on here is that mms is supposed to be depreciated by Microsoft in favor of rtsp. Thanks again hopefully we'll hear from the source soon.

Quoted from http://www.microsoft.com/windows/windowsmedia/licensing/netprokit.aspx

Windows Media Networking Protocols Compatibility

The following table identifies compatibility between protocols in the Windows Media Networking Protocol Kit and recent versions of Windows Media Services and Windows Media Player. For each version of Windows Media Services and Windows Media Player, the table also identifies the platforms on which that version operates.

Supported protocols	WMS 9.5 (Longhorn Server)	WMS 9 Series (Windows Server 2003)	WMS 4.1 (Windows 2000 Server)	Player 11 (Windows Vista and Windows XP)	Player 10 (Windows XP and Windows Server 2003)	Player 9 Series (Windows 98 Second Edition, Windows Millennium Edition, and Windows 2000 Server)
HTTP 1.1	Yes	Yes	No	Yes	Yes	Yes
HTTP 1.0	Yes	Yes	Yes	Yes	Yes	Yes
RTSP	Yes	Yes	No	Yes	Yes	Yes
MSB	Yes	Yes	Yes	Yes	Yes	Yes
MMS	No¹	Yes²	Yes	No¹	Yes³	Yes³

¹ MMS protocol is not supported; however, "mms://" as a "protocol rollover URL" is still used (and highly recommended) when content providers expose their URLs. For additional details, see the MSDN article, Protocol Rollover.

² MMS protocol was deprecated in Windows Media Services 9 Series and is only supported when streaming to a Windows Media Player version prior to Windows Media Player 9.

³ MMS protocol was deprecated in Windows Media Player 9 and is only supported on Windows Media Player 9 and Windows Media Player 10 when streaming from Windows Media Services 4.1 or earlier.

Windows Media issues that need developer love!

m3taverse — Thu, 03 May 2007 01:24:59 GMT

Hello Silverlight team,

The following is based on 1.1 alpha, 1.1 alpha sdk, VS Orcas, IIS6 and Windows Media Server on Enterprise.
I made 2 versions of a 1 minute clip. One version had either a marker or a script command every 5 seconds, all of them placed in the header of the WMV file. The second version contained only script commands, but this time placed in the scriptstream. I tested both files on IIS and WMserver.

As soon as I put Source="http://webserver/file.wmv", 1.1a will refuse to play the file. It will only progressively play files when I just put Source="file.wmv".
If I do Source="http://mediaserver/file.wmv" (note that this is the mediaserver now), 1.1a will not play the file. It will only play the file if I put Source="mms://mediaserver/file.wmv".
This raises questions about how mms is implemented. Does it contain any of it's roll over features to other protocols (http!)? Does it contain the rollover from UDP to TCP? Do we have the ability to override any of this?
The events fired by MediaElement in 1.1a are working well when the file is progressively downloaded, and status can be read reliably. They do not work at all correctly when the same file is streamed. BufferingProgressChanged, BufferingProgress, CurrentState all have problems. The way it works now you can't even establish when the user is done buffering without some dirty code!
Markers and ScriptCommand events are working nicely when the file is progressivly downloaded. They don't work at all when the file is streamed. When queried, MediaElement has 0 TimelineMarkers in its collection while streaming.
ScriptCommands *only* work when they are in the header. They do not work when they're in the script stream.
Fast Start is not currently working, but I understand it'll be there for 1.0 RTM.
Server side playlists do not work, they will not play the next item in the server's playlist.

If you care about webcasting with Windows Media, like myself, you're crying your eyes out right now from reading this list of stuff.
I definitely understand you guys focusing on the progressive experience for adoption purposes, but please give the streaming thing in MediaElement some love!

Here's what webcasters really need:

1. We need (!!) support for ScriptCommands from the script stream, at the very least for live scenario's
2. We also really need to have support for server side playlists. I really believe that I'm not speaking for a mere hand full of people when I say that.
3. mms really must have the ability to roll back to http when needed.
UDP/TCP roll over, rtsp support and the ability to control ports would be a bonus.

Of course we'll need all the faulty events and status stuff fixed, but I'm sure you'll do that anyway.

Thanks for listening, and I look forward to any feedback you can give me on these issues.