|
Abstract
There are two major methods of delivering streaming audio and video
content over the Web. The first method uses a standard Web server to
deliver the audio and video data to a media player. The second method
uses a separate streaming media server specialized to the audio/video
streaming task. This paper shows that, while Web server streaming can be
an effective interim solution, a streaming server is more efficient and
flexible and provides a better user experience.
Introduction
Until recently, audio and video on the Web was
primarily a download-and-play technology. You had to first download an
entire media file before it could play. It was like pouring milk into a
glass and then drinking it. But because media files are usually very
large and take a long time to download, the only content found on the
Web was short 30-second clips—often even shorter. Even these files could
take 20 minutes or longer to download. In other words, it took a long
time to pour the milk, and then it would barely quench your thirst.
Watching audio and video files that stream is more like drinking
straight from the carton; streaming media files begin playing almost
immediately, while the data is being sent, without having to wait for
the whole file to download. Other than a few seconds of delay before the
file starts to play, you don't have to wait to start watching, no matter
if the file lasts 30 seconds or 30 minutes.
As audio and video streaming over the Internet has become more popular,
two primary methods for streaming content have emerged. The first method
is the Web server approach, in which a standard Web server is used to
supply data to the client. The second method is the streaming media
server approach, in which a specialized streaming server delivers the
data to the client. Both methods have advantages that we will discuss,
but first let's take a look at the way each process works.
Streaming with a Web Server
Posting and Hosting
Deploying streaming media content with the Web server approach is
actually only a small evolutionary step away from the download-and-play
model. Uncompressed audio and video is first compressed into a single
"media file" for delivery over a specific network bandwidth such as a
28.8 kilobits per second (Kbps) modem. This media file is then placed on
a standard Web server. Next, a Web page containing the media file's URL
is created and placed on the same Web server. This Web page, when
activated, launches the client-side player and downloads the media file.
So far, the actions are identical to those in the download-and-play
case. The difference lies in how the client functions.
Data Delivery
Unlike the download-and-play client, the streaming client starts playing
the audio or video while it is downloading, after only a few seconds
wait for buffering, the process of collecting the first part of a media
file before playing. This small backlog of information, or buffer,
allows the media to continue playing uninterrupted even during periods
of high network congestion. With this delivery method, the client
retrieves data as fast as the Web server, network and client will allow
without regard to the bit-rate parameter of the compressed stream. Only
certain media file formats support this type of "progressive playback".
Microsoft's Advanced Streaming Format (ASF) is one of the most popular.
Web server streaming uses the Hyper Text Transport Protocol (HTTP), the
standard Web protocol used by all Web servers (such as Microsoft®
Internet Information Server) and Web browsers (such as Microsoft
Internet Explorer) for communication between the server and the client.
HTTP operates on top of the Transmission Control Protocol (TCP), which
handles all the data transfers. Optimized for non-real-time applications
such as file transfer and remote log-in, TCP's goal is to maximize the
data transfer rate while ensuring overall stability and high throughput
of the entire network. To achieve this, using an algorithm called slow
start, TCP first sends data at a low data rate, and then gradually
increases the rate until the destination reports packet loss. TCP then
assumes it has hit the bandwidth limit or network congestion, and
returns to sending data at a low data rate, then gradually increases,
repeating the process. TCP achieves reliable data transfer by
re-transmitting lost packets. However, it cannot ensure that all resent
packets will arrive at the client in time to be played in the media
stream.
Streaming with a Streaming
Media Server
Posting and Hosting
In the streaming media server approach, the initial steps are similar to
the Web server approach, except that the compressed media file is
produced and copied to a specialized streaming media server (such as
Microsoft Windows Media Services) instead of a Web server. Then a Web
page with a reference to the media file is placed on a Web server.
Windows Media Services and the Web server may run on the same computer.
Data Delivery
The rest of the streaming media server delivery process differs
significantly from the Web server approach. In contrast to the passive
burst methodology employed in Web server streaming, the data is actively
and intelligently sent to the client, meaning that it delivers the
content at the exact data rate associated with the compressed audio and
video streams. The server and the client stay in close touch during the
delivery process, and the streaming media server can respond to any
feedback from the client.
While streaming media servers can use the HTTP/TCP protocols used by Web
servers, they can also use specialized protocols such as the User
Datagram Protocol (UDP) to greatly improve the streaming experience.
Unlike TCP, UDP is a fast, lightweight protocol without any
re-transmission or data-rate management functionality. This makes UDP an
ideal protocol for transmitting real-time audio and video data, which
can tolerate some lost packets. As a bonus, because of the back-off
policies implicit in the TCP protocol, UDP traffic gets higher priority
than the TCP traffic on the Internet. And instead of the blind
retransmission scheme employed by TCP, streaming media servers such as
Microsoft's Windows Media Services use an intelligent retransmission
scheme on top of UDP. Windows Media Services' UDP Resend feature
ensures that the server only retransmits lost packets that can be sent
to the client in time to get played.
The differences between the Web server and
streaming media server solutions translate into clear distinctions in
both ease of implementation, ease of management, and quality of user
experience. For the remainder of this white paper, the comparison will
be between a generic Web server and Microsoft's streaming media server,
Windows NT Server Windows Media Services (hereafter referred to as a
Windows Media server).
Streaming with a Web Server: the Advantages
There is really only one major advantage to
streaming with a Web server rather than with a streaming media
server—utilizing existing infrastructure. Because the Web server
approach uses only the standard Web server--that presumably already
exists in the organization—no new software infrastructure need be
installed or managed. The Windows Media server approach, on the other
hand, requires the content producer and/or the systems administration
staff to install and manage additional server software. This can result
in incremental training and staffing costs to learn and manage the more
complex, but also more powerful, Windows Media server environment.
It is important to note that the increased load that Web server-based
streaming puts on existing Web server infrastructure often results in
the need for additional Web server hardware to service the client
requests. Choosing Web server streaming over a dedicated streaming media
server based on hardware cost alone usually does not result in any
financial savings.
Streaming with a Windows Media Server: the
Advantages
Designed specifically for the
task of delivering live or on-demand streaming media rather than many
small HTML and image files, a Windows Media server offers many
advantages over standard Web servers.
This
paper has evaluated the two primary methods for streaming
media content to users. The first, the Web server approach,
uses a standard Web server and the associated HTTP and TCP
protocols to request and deliver the content for the client.
The second approach uses a streaming media server
specialized to the audio/video-streaming task. The
specialization takes many forms, including optimized
routines for reading the huge media files from disk, the
flexibility to choose any of UDP/TCP/Multicast protocols to
deliver data, and the option to exploit continuous contact
between client and server to dynamically improve content
delivery to the client.
The primary advantage of the Web server approach is that it
requires one less software component (the streaming media
server) to learn and manage. This method can be an effective
first step in developing a streaming solution.
The streaming media server approach, using Microsoft Windows
NT Server Windows Media Services, has these advantages:
- More efficient use of the network
bandwidth.
- Better audio and video quality to the
user.
- Advanced features like detailed
reporting and multi-stream multimedia content.
- Supports large number of users.
- Multiple delivery options.
- Content copyright protection.
The tradeoffs clearly indicate that, for
virtually all providers of streaming media content, the
Windows Media server approach is the superior solution.
|
|
|
|