Comments on: The Birth of Smooth Streaming

By: Alex Zambelli

Alex Zambelli — Sat, 17 Jul 2010 01:00:07 +0000

It’d be fairly straightforward to write a .NET app that parses the manifest for stream info and timestamps and then issues a series of HTTP requests which download all the video/audio chunks of the highest bitrate. In fact, you could probably do it with just Jscript and WGET.

The tricky part would be writing an app (or finding some existing code – I’m thinking something like ffmpeg) which then muxes those chunks together into a single MP4 file. A lot of MP4 parsers don’t implement the fragmented format, so you’d probably need to also rearrange the media data into a single box for greater compatibility, in order to get a vanilla MP4 file.

By: Eddie

Eddie — Fri, 16 Jul 2010 09:03:56 +0000

Hi Alex,

Is there a way to play the chunks without silverlight? E.g. downloading all the chunks of a selected bit-rate.

By: Alex Zambelli

Alex Zambelli — Fri, 25 Jun 2010 08:00:13 +0000

@Carine: Not for RTSP, but IIS Media Services 4.0 (currently in Beta) does support Smooth Streaming over IP Multicast (UDP). Also, good old Windows Media Services supports streaming multi-bitrate video over RTSP, though unfortunately that’s only supported in the WMP client but not in Silverlight.

If you’re streaming over the Internet, HTTP adaptive is always going to be more efficient and scalable than RTSP. If you’re streaming over intranets, Multicast Smooth Streaming will be a better choice.

By: Alex Zambelli

Alex Zambelli — Fri, 25 Jun 2010 07:55:40 +0000

@Abdullah:
I haven’t tried this myself, but it does sound like Smooth content is getting cached by IIS. I wouldn’t say that’s necessarily a scalability issue because that cache buffer isn’t infinitely large – I am guessing that if you stream some more content and then try to go back to the first content at some later time it will no longer be available because it will have been wiped out from the cache.

In the case of live streaming, live content will remain available for DVR access as long as the pub point is in a “Started” or “Stopped” state. The moment you shut down the pub point, the content will no longer be available. If you enabled the Archive option, the archive copy will be indexed and ready as soon as the live pub point enters a Shutdown state.

Yes, “Allow client connections” needs to be enabled if you want to allow playback from the pub point. The option exists because there are indeed certain scenarios where client access might not be desirable, such as when creating “ingest” pub points. Those are pub points whose role is only to ingest streams (from an encoder, for example) and then push them to other origin pub points (on the same or different server). An example of this would be when you want to push the same video stream from the encoder to multiple pub points: rather than creating multiple outbound connections from the encoder, you can use just a single uplink connection and then multiply the streams on the server itself.

By: abdullah

abdullah — Mon, 07 Jun 2010 21:00:27 +0000

Hi, I use pushencoder tool to push the content from an external harddisk connected to IIS server via USB port onto the publishing point. Test is successful. I can stream the video smoothly. When I disconnect the external hdd from IIS server, I can still watch the movie. I was expecting not to be able to do so. I disabled the archive media option on publishing point settings. Even if I do that, IIS server caches some content under C:\inetpub\media\archives\Default Web Site Maybe this makes it possible to watch? I cleared the cache of the browser, I can still watch. ~~~DOES THIS MEAN, ALL THE ON-DEMAND CONTENT WILL/SHOULD RESIDE ON IIS SERVER? If that is the case, there is a scalability problem, isn’t there?~~~ Before I push the content, the state of the publishing point is “starting”. OK During push, it is “started”. OK After the pushencoder command does it’s job, the status is “stopped”. But I can still watch the movie? And what does “Wait status is 0″ mean which is displayed at the end of the result logs of pushencoder? And, if I deselect both “Archive media” and “Allow client connections” checkboxs under Publishing Point Details/Advanced Settings, I get the following error on my browser: “Failed to download manifest: d” It doesn’t work…
Thanks a lot!

By: Carine

Carine — Tue, 11 May 2010 08:09:40 +0000

Hi Alex,

Thanks for this interesting article. my question will be : is there any solution of adaptive streaming for RTP/RTSP, wich is the most used protocole in IPTV streamings?

By: domain kaydi

domain kaydi — Wed, 30 Dec 2009 07:32:31 +0000

thank you for this article. Ive looked at the end.

By: server

server — Sun, 04 Oct 2009 15:55:46 +0000

thank you alex..

By: Alex Zambelli

Alex Zambelli — Mon, 28 Sep 2009 01:52:48 +0000

Windows Media Services uses traditional RTSP and WMS HTTP stateful protocol streaming, whereas IIS Media Services is entirely HTTP based. WMS is better suited for small networks, controlled networks, enterprise environments, etc. IISMS, on the other hand, is what you want to use if you’re, say, trying to deliver live HD video to 50,000 concurrent users over the Internet.

Furthermore, WMS is based exclusively on the ASF file format, whereas IIS is largely format agnostic (e.g. for progressive download) though Smooth Streaming itself is MP4-based.

By: Michael

Michael — Thu, 17 Sep 2009 08:21:56 +0000

so why have 2 products that deliver streaming from Microsoft? IIS with extensions and Windows Media Services? Will smooth streaming be rolled into Windows Media Services 2008? When should I use Windows Media Servics and when should I use the new extension to IIS for streaming?