Archives
-
Smooth Streaming Case Studies
Here are a few links to smooth streaming case studies based on some real world solutions that we helped build over the years. Hopefully you would find them interesting:
-
Fragmented MP4 vs. MPEG2-TS
Today there are a few popular HTTP adaptive streaming solutions in the industry including Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming and Apple HTTP Live Streaming (HLS). One important difference among these solutions is the file format that’s being used. More specifically, both Microsoft Smooth Streaming and Adobe HTTP Dynamic Streaming use Fragmented MP4 file format while Apple HLS uses MPEG2-TS.
-
File Write-Through Behavior in Live Smooth Streaming Archiving
In IIS Media Services 4.0, we introduced the file write-through behavior with Live Smooth Streaming when doing DVR/Archiving from the publishing point. What does file write-through mean? Here is a bit of background:
-
Performance Tuning for On-Demand Smooth Streaming
This is another blog post that has been long due. I’ve written a lot about Live Smooth Streaming in my past blog posts but so far very few on On-Demand Smooth Streaming. Well, partially because getting On-Demand Smooth Streaming to work is quite simple. You just need to copy your content to the server and then everything should just work. For low volume usage, that’s pretty much all you need to care about. But if you are doing serious production systems with a large content library and significant client traffic, you would want to tune the system to its best performance in which case this blog post should be helpful to you.
-
IIS Media Services 4.1 just released!
We just released IIS Media Services 4.1 that adds support for REST services API's for management of publishing points as well as performance improvements for both on demand and live scenarios. Read more from here.
-
IIS Smooth Streaming getting deployed for Comcast Xfinity
Yes, the news is out and we can finally talk about it! Our IIS Smooth Streaming platform, together with Microsoft PlayReady DRM technology, is being deployed for Comcast’s Xfinity online service. We’re very excited about this opportunity and the statement below says it all:
-
How to authenticate ONLY the encoder streams but not the clients for live smooth streaming?
This question was asked quite a few times from our customers and on the media forum. The scenario is that I, as an site administrator, want to authenticate encoder streams that are pushing in for live smooth streaming. However, I don’t really want all the smooth streaming players having to do the same authentication. This is definitely a valid and reasonable scenario. An analogy is that I want to authenticate users who want to upload content to my web site without the need to authenticate the browsers.
-
How to Troubleshoot Live Smooth Streaming Issues? – Part 7 (Putting It Together)
In previous sections, we discussed many different ways of diagnosing live smooth streaming issues. Now, let’s go through a troubleshooting example to see how to use them in real world debugging.
-
How to Troubleshoot Live Smooth Streaming Issues? – Part 6 (IIS Logs and Others)
Since smooth streaming client requests are all standard HTTP requests going through IIS pipeline, all these requests are being logged by IIS logs which are located in %systemdrive%\inetpub\logs\LogFiles\. An example of the log entries is shown below:
-
How to Troubleshoot Live Smooth Streaming Issues? – Part 5 (Client Manifest)
As we discussed earlier, smooth streaming client starts streaming by first requesting the client manifest from the server using URL template: http://{serverName}/{PublishingPointPath}/{PublishingPointName}.isml/manifest . The client manifest contains information such as stream types, parameters, bitrates and fragment timestamps. By simply examining the client manifest, you could get some useful information for troubleshooting live smooth streaming issues. In IIS Media Services 4.0, we made some tweaks to the client manifest format for better efficiency. The discussion below is based on IIS Media Services 4.0 release.
-
How to Troubleshoot Live Smooth Streaming Issues? – Part 4 (Performance Counters)
-
How to Troubleshoot Live Smooth Streaming Issues? – Part 3 (Event Logs )
The next important place to check for live smooth streaming diagnostic information is the event viewer for windows event logs. In Event Viewer, go to “Windows Logs” –> “Application” and look for events from “IIS Live Smooth Streaming” source.
-
How to Troubleshoot Live Smooth Streaming Issues? – Part 2 (Publishing Point UI and States)
In Part one, we discussed basic data flow and protocols being used in IIS Live Smooth Streaming. In this blog, we will discuss where all the diagnostic information for live smooth streaming is available and how to make sense out of it.
-
How to Troubleshoot Live Smooth Streaming Issues? – Part 1 (Basics)
This is a blog that I’ve been thinking about writing for a long time. Ever since the first IIS Live Smooth Streaming event (French Open in spring 2009), I’ve been directly involved in supporting many online events powered by our technologies. We have also helped our customers solve many issues through support emails and forum posts. In general, troubleshooting live smooth streaming issues isn’t that difficult once you understand the technology and know where to look and what to look for. Hopefully after reading this blog, you will feel more confident and empowered working with your live streaming servers. I would also like to suggest you reading my other blogs here and here if you haven’t done so since they’re very related.
-
How to Configure HTTP Proxy Settings for Publishing Point Push/Pull Connections
If you use push/pull connection feature on IIS Live Smooth Streaming publishing points, you might run into a problem where somehow those connections failed to be established even though the same URLs work fine from your desktop applications (say Expression Encoder). If your server is behind a HTTP proxy, there is a good chance that it’s caused by the lack of HTTP proxy setting for your IIS worker process. IIS worker process by default runs under a lower privileged account and is not able to pick up the Internet Connection settings from your desktop user. The way to fix this problem is to use “netsh” command to set a machine level HTTP proxy for WinHTTP which the publishing point uses for establish push/pull connections.
-
New White Paper Released on The Performance Of Adaptive Streaming Over HTTP
Cisco and The Georgia Institute of Technology just released a technical white paper on adaptive streaming here. It has some very in-depth performance analysis and comparison between Smooth Streaming, Netflix player and Adobe’s OSMF. While there are some interesting findings about all three platforms, I think it clearly shows that Smooth Streaming is far more superior than Adobe’s OSMF’s default implementation in those tests.
-
Vote for future IIS Media Services features!
Tell us what features you want to see in future IIS Media Services releases and we will try our best to make it happen!
-
EventID support in Expression Encoder SP1
The newly released Expression Encoder SP1 now supports EventID feature to work with IIS Media Services for live smooth streaming publishing points. Jamie Lang from the Expression Encoder team wrote a nice blog about this support.
-
How to do network auto-recovery from Expression Encoder 4?
If you use Expression Encoder 4 for live smooth streaming, you probably have already hit this situation a few times. Say you’ve set up your live encoder to push to a remote publishing point on an IIS Media server and everything is running fine. All of a sudden, somehow the network connection between your encoding facility and the remote IIS ingest servers gets broken. Because today Expression Encoder 4 does not support network auto-recovery, even if the network gets back to normal, Expression Encoder will still show the error message while the remote publishing point keeps waiting for failover streams. The end result is that the live streaming has to stop. And the only way to fix that problem would be to restart everything (encoders, servers and clients) which also means the clients would lose access to all the DVR data that belongs to the previous session.