Introduction
Comparing with the Adobe Flash Player, Microsoft has provided the first step to support the live voice/video chatting through the web By Supports dealing with the Microphone and the Camera in Silverlight 4. Yes it was a great step but still not enough, there is more of a problem that is still unresolved, and as a programmer you have to rely on yourself to make your own programming solutions if you decided to go ahead with working on Silverlight techniques to create your own live voice/video chatting software. It can be summarized as follows:
Comparing with the Adobe Flash Player, Microsoft has provided the first step to support the live voice/video chatting through the web By Supports dealing with the Microphone and the Camera in Silverlight 4. Yes it was a great step but still not enough, there is more of a problem that is still unresolved, and as a programmer you have to rely on yourself to make your own programming solutions if you decided to go ahead with working on Silverlight techniques to create your own live voice/video chatting software. It can be summarized as follows:
- There isn't any Managed Library for coding/decoding the Video/Audio data for compression to be suitable to send it via the Internet, comparing with Adobe technologies it supports dealing with the H.263 and H.264 to compress the audio and Video on high resolution, unfortunately it's still not available in Silverlight4.
- There isn't any support for the real time transport protocols, such as RTP. Therefore you just have two options, either through using the transport protocol TCP or UDP, or to program your own real time transport protocol. Comparing with Adobe, it supports transport through a custom protocol for this purpose in the RTMP.
- There isn't any real streaming server For Live Video/Audio streaming directly from Silverlight to the Media Server and from the media server to Silverlight clients, so you only have two solutions. You have to either use Microsoft Windows Media Server or use the Smooth Streaming through IIS, and will thus be obliged to renounce Silverlight, because Silverlight does not support dealing with these servers for sending and the only solution is also to create your own server. Compared to Adobe, they have a great product which is The Flash Media Server that deals perfectly with the Flash player.
Background
In general, all Voice/Video Chatting Systems must go through these phases:
In general, all Voice/Video Chatting Systems must go through these phases:
- Connecting with a camera and/or microphone and then returning the output as Binary Data, then converting it to Bytes to make it easier to deal for the next step.
- The data will be returned as a Raw Format, therefore its size would be too large so we need first to code it into a compressed format. For example, coding the captured image into a JPEG format as well as the voice data can turn into a Wave Format or compress it into any well-known audio compression format such as G.711 ,GSM, speex or any other format standard. Also we can integrate the video/voice together using a special standard such as H.263 or H.264. This step is the most important thing we would be doing, it simply will determine the bandwidth requirements of your chatting system.
- Sending the compressed data using one of both transport protocols TCP, UDP or RTP/UDP transport protocol and this step is also important as it depends on the importance of data quality that is transferred on the one hand and the importance of the transfer in Real Time on the other hand. The goal of any system is to transfer the data in real time and in the best quality as possible.
- Receiving the sent data through the Server has specific functions depending on what you want from the application, as an example in the chatting software. The received data on the server side should send it back to the connected clients in the chat room. Usually if the software is working on the internet and if the clients are behind a NAT, the Server should be on a Public IP. Fortunately the Socket in Silverlight supports this process without any problem as you will see in this article.
- The Client would receive the data as a compressed format, so we need to decode it first and then display it on an output device.