Streaming Comparison, Part II: Web Server

Web Server / Streaming Server Comparison, Part 2

Using A Web Server

Uploading and Storing

While it may appear vastly different to the user, the use of a Web server to stream audio and video media is actually only slightly different from the outdated model where an entire file is downloaded before it can be played. First, the deliverer compresses the audio and/or video into a combined media file, slated for delivery over a specific bandwidth. (For instance, the producer may create one file for low bandwidth like 28.8K phone lines, one for medium speed connections such as low lever DSL, and a third for high-speed access points like cable or FIOS.)

Next, the producer uploads those files onto the same server that hosts his/her web pages. From this point, all the producer needs to do is add a link to any one of those media files from any one of his/her web pages. As you’ll notice, not only is this relatively simple for the producer, it’s also essentially no different form the old download-then-play model. Where does the streaming come in? Actually, it happens on the other end of the procedure: within the user’s media player.

Delivering the Media

The difference between the old model and the web server version of streaming lies in the buffering process of the user’s media player. Buffering is a process whereby the media player collects the initial portion of a file, then begins playing that file, while still collecting the rest of the file from the web server. Because there is a small stored portion of data, the media player can continue to play the file, even though the speed of delivery may vary. Not every media player supports this progressive model of data delivery and playback, but the major ones do.

There are two technologies involved in web server streaming: Hyper Text Transport Protocol (HTTP), and Transmission Control Protocol (TCP). Both technologies are well established in the Internet world.

Web Server Streaming Technology

HTTP, used by all web servers and browsers, enables communication between the server (web server) and client (user’s browser). This works in conjunction with TCP, which basically takes care of all the data transfers. TCP was actually developed to handle procedures that are not “real time,” the most important one of which is file transfer.

TCP’s main purpose is to deliver data over the Internet at the highest rate possible, while maintaining the integrity of that data. The way it achieves this is to start transferring data at a relatively low speed, then gradually increase that rate until it detects that data is being lost. When that happens, it “shifts” back down to a lower transfer speed, and begins the process all over again. In addition, any portion of the data that has been “lost” during the transfer is re-sent later. And therein lies the main drawback of using this technology to “stream” media: the lost data may not be detected and re-sent in order to keep time with speed of the media player. Thus, user’s experience interrupted playing of files, which is very frustrating.

A much better way to stream video is by using a dedicated streaming server, as detailed in the next article:

 

Web Server / Streaming Server Comparison, Part 3

Using a Streaming Server

 

2 Comments

2 Responses to “Streaming Comparison, Part II: Web Server”

  1. Streaming Says:

    Hey, this blog is really happening! It took me quite a while to read through all the replies. I appreciate the idea of tweeting the post so that more readers find it!

  2. Great Blog Says:

    Must appreciate your time you put into your blog :)

Leave a Reply