In this topic, I will not teach you how to configure Smooth Streaming under IIS for Silverlight, I will not give examples of code to play the video. I set a goal to explain the principle of Smooth Streaming in Silverlight, the lack of IIS in the role of a streaming server and how Microsoft solved this problem. I want to get feedback from the community about the possible applicability of video broadcasting to the Internet in this approach.



I presented the whole process from preparing the video to broadcasting it to the end user in three steps.

Step one.

Video preparation. Video clips of good quality are specially converted (for this you can use Expression Encoder 3, with a special profile settings).



After the conversion, several files with the ism, ismc and ismv extensions are obtained.

Files with the extension .ismv is a video / audio stream in mp4 format. If you want to feed him to the player, then most likely he will refuse to reproduce it, since it lacks the necessary data for reproduction. There may be several such files and it depends on the conversion settings.

')

A file with the ism extension binds the .ismv file to the bitrate of the stream it contains. The file format is intuitive xml.

The .ismc file contains information about the stream being broadcast - the number and type of tracks in the stream (audio and video), as well as additional information about the parameters and capabilities of each track are the number and duration of key frames, the number and quality of video / audio streams, the name of the codec, frame height and width (video only), CodecPrivateData required to play in Silverlight).

To summarize, we have: several files with video / audio data with different bitrate and resolution, as well as a file - a description of the received qualities and a translation description file (metainformation), in which all tracks and available qualities for each track are indicated.

Step two.

Placement or publication on a web server, in our case it is IIS. Before publishing a video, IIS needs to be slightly adjusted, namely, to install a free solution for adaptive broadcasting and create a web site with one folder where we will add our video files. No additional actions are needed, the extension itself will register the necessary handlers for the necessary files. After all the settings, we simply copy / transfer the files received in the first step to the folder that is located in our web site.

If after these not tricky actions in the line of the web explorer specify the address to the file with the extension .ism / manifest, then as a result we will get the contents of the .ismc file.

The server’s task is to distribute .ismc files and form-distribute small fragments of the stream in mp4 format at a given offset in time and bitrate.

Step three.

Broadcast video to the user through the Silverlight player. In my opinion this is the most interesting stage.

I'll start from afar. IIS is designed so that it can quite well handle a large number of short (in terms of the amount of data transmitted) requests, and with long and voluminous requests there is a rapid memory leak. Therefore, to broadcast video, and this is quite a lot of data, will not work, unless of course you are going to serve more than a hundred connections. There are two ways out in this situation, to increase the RAM or use your own or third-party streaming server.

With the release of Silverlight 2, the situation has changed, namely, now for video playback, there is no need for a permanent connection to the server, we can upload videos to even ten requests, and all this is due to the competent approach in the MediaElement data reception architecture in SL. Now IIS does not need to process one large request and transmit the entire video, now one video clip can be divided into many small pieces, where each piece is a separate request and each piece is a separate keyframe. All this, along with the keep-alive mode (makes the web browser keep the connection to the server open), gives very good results, for example: the memory consumption is significantly reduced, in order to remove memory leaks, we can reload the IIS workflow periodically without interrupting video playback etc.

Let's return to the original question - how is the adaptive video broadcasting in Silverlight?

On the client, it occurs in three stages:

1. Download and parse .ism / manifest file meta information. This is necessary in order to:
   
   
   • get information about the request template to the desired broadcast fragment;
   • get maximum resolution;
   • find out the duration;
   • get a list of key frames;
   • find out the number of tracks and the number of levels of image degradation;
   • also get a special PrivateCodecData parameter, etc.
2. Download the first broadcast fragment. To do this, we use the usual HTTP GET request formed on the specified pattern. Next, the formation of the data packet and sending them to the built-in Silverlight decoder for display on the user's screen.
3. Analysis of the network channel capabilities and receiving the bit rate, which will be available for playback without delay, then the address of the next HTTP GET request to the required video fragment is formed, and so on until the broadcast is over.

If you look at it through a sniffer, you will see a lot of HTTP requests, such as .ism / QualityLevels ({bitrate}) / Fragments (video = {time}), sent by the web explorer, these are requests for video fragments. Apparently there are a lot of requests, and the broadcast goes without a break.





Using a similar approach, you can come up with and implement a lot of protocols and improvements to broadcast video on the Internet. Moreover, you can peek at how SmoothStreaming was written in Silverlight and make your own implementation. You can also write the server part yourself, for example, to translate the flv file archive (I described the reasons for this in my topic on Habré Playing FLV in Silverlight - What is it for ).