Faster Streaming

Traditionally, multimedia content over the Internet has been delivered using the download-and-play approach. This can be quite frustrating, as you have to wait for the entire audio and video file to download from the server onto your system before you can experience it. 

Streaming, on the other hand, delivers multimedia content in real time. You get to see or listen to your clip even as it is being downloaded. Some initial parts of the clip are buffered and then made available to you. The remaining clip is downloaded in the background even as you enjoy the clip in the foreground. The effective waiting period (time spent before you begins to see/hear the clip) is, thus, much less in streaming.

But things are not as simple as they may look. The most important issue with streaming is to ensure that once a clip has started playing, it does not suffer any interruptions due to network delays or the likes. With the download-and-play approach, you are oblivious of any network delays as you see the clip only when it is completely on your hard disk. On the other hand, network delays can wreak havoc with streaming–you may experience jerky audio/video due to lost frames and may even be left stranded in the middle of a clip. This, amongst several other issues, needs to be considered to successfully provide streaming content over a modern-day network.

There are two major ways of delivering streaming content over the Web. The first, called HTTP (or Web) streaming, uses the standard Web server while the second, called RTSP (Real Time Streaming Protocol), uses a dedicated streaming server. 

HTTP Streaming



HTTP streaming is not too different from the download-and-play approach. The compressed media is stored on the Web server, as any other file that is served via the HTTP server. When you ask for this file (by clicking on the relevant link, for example), the client-side player gets launched and requests the specific file from the Web server. The Web server, in turn, starts sending the contents of the file back to the client. This is where the similarity with the download-and-play model ends.

The client player, when it has received sufficient amount of data to act as a buffer, starts to play the clip, even as it continues to receive more and more data in the background. 

Such a streaming method has the advantage of being able to use HTTP, a technology that is already in place and is a proven technology as a carrier of majority of the traffic on the Web. This saves the additional overheads (of cost and time) that would result from trying to implement other protocols on your network. HTTP runs over TCP. The TCP/IP set was designed to provide reliable communication, but works under no real time constraints. If it needs to transfer a file from A to B, it doesn’t (really) bother how long it takes to transfer that file, but concentrates only on that it is done reliably. It cannot assure fixed bandwidth between the sender and the receiver and contains no timing information. This is where RTSP steps in.

RTSP Streaming



RTSP is an application-level protocol, designed to be used as a carrier protocol for multimedia traffic. It is a much simpler protocol than TCP, but can ensure delivery of data packets within a stipulated time period. It is ideal for use by multicast applications and is intelligent enough to sense the bandwidth requirements of the client-server connection. Various implementations of RTSP are used in dedicated streaming servers, which are used to dish out large volumes of streaming content and provide an alternative to the HTTP streaming.

After a streaming server (running on RTSP) receives a request for a particular clip from a client, it detects the quality of the connection with that particular client and serves it the file best suited for that connection. Users with slower connections (like dial-up) may get to see a lower resolution video compared to those on broadband connects. This is not possible with HTTP streaming as there is no way to detect the quality of connection, and, thus, the decision of which video to see rests with the user. The streaming server continues to send the file to the client (which is pretty much the same as in Web streaming), but constantly receives feedback from the client, and thus can better adjust to changing requirements of the client and/or network conditions. RTSP also makes it possible for streaming servers to provide several multimedia specific features, such as VCR controls (rewind, forward, seek, etc). 

Streaming servers also provide for better copyright protection of the content as the data is not explicitly downloaded onto the client’s machine (as is the case with the download-then-play model or with Web streaming), but is streamed. This prevents you from accessing the content later and allows the content provider to implement the pay-per view model.

Considering all this, it is no surprise that most (if not all) major content providers use dedicated streaming servers that implement RTSP. Server solutions from major vendors like Real, Apple and Microsoft, too, fall in this category.

Kunal Dua