How is streaming a multimedia file different from downloading a multimedia file?

Executive Summary

The Internet offers content providers a vast potential audience. However, the traditional Internet protocols constrained data delivery to a client-initiated pull model such that every client had its own connection to the data source. To facilitate a push model of delivery while avoiding bandwidth saturation, the IETF approved a new set of protocols designed to provide IP multicast capabilities. Applications built on top of these protocols can stream data across the network and any interested client node can receive it without an explicit connection to the source. Two such applications, Microsoft ® NetShow ™ and RealVideo™ from Progressive Networks, are competing in both the Internet and corporate Intranet arenas. Both applications have wide industry support. NetShow currently provides a wider range of data types and compression mechanisms, but RealVideo may still influence future developments of the technology because it is the first member of the RealMedia architecture family.

The Challenges of Multimedia Streaming

The World Wide Web (WWW) is built on the Internet, a giant heterogeneous network built on the IP protocol. For a typical WWW client to view multimedia data from a source, it has to download the entire stream as one file, usually in MPEG or AVI format, and display its contents after the entire file has been saved locally. The user experiences a long delay while the file downloads. This paradigm is thus not suited for viewing of realtime data sources - it is optimized for viewing static data.

One possible alternative to the WWW model is IP broadcast. The data stream could be sent to every node on the network, regardless if each node actually wants that data. This method may be suitable for small LANs, but not for the Internet. Network traffic would escalate to the point where many more packets are lost than are received. The vast majority of nodes would prefer to ignore the broadcast stream anyway.

Another method is for all interested recipient nodes to "register" with the source server, which then sends a copy of the data stream to each interested host. While useful for a small number of clients, this solution does not scale well for large numbers of clients. The server resources could quickly become exhausted, and it could still saturate the network.

A useful and effective multimedia streaming product should avoid the problems described above. It should provide low-latency delivery of realtime data without saturating the network or the resources of the data server. It should scale well as the number of clients increases, such that network and hardware requirements don't increase as the number of clients increases (or at least increase at a slower rate).

Another metric by which to compare products is the richness of the data streams they support. Audio and video are but two possible data types. Others include files, still images, sensor readings, stock tickers, and slides for presentations. Some other questions to ask before buying a product may include:

1. How easily can I add new data types to the stream as my needs evolve?
2. Will the product support new codecs as compression technology improves?
3. Does the product adhere to widely accepted standards, or use proprietary protocols?

IP Multicasting - the Groundwork

IGMP - Internet Group Management Protocol

Client nodes use IGMP to join multicast "groups". These groups are denoted by class-D IP addresses, ranging from 224.0.0.0 to 239.255.255.255. The local multicast router in turn monitors the network for traffic addressed to the group and then forwards these packets to the local subnet. The local router may use some other routing algorithm such as PIM or DVMRP to update adjacent routers that it wants to receive the multicast. Ethernet is well suited to class-D IP addresses because the addresses are easily mapped to IEEE-802 Ethernet multicast addresses.

An IGMP packet header is shown below. There are three basic IGMP message types - group membership queries between router and nodes, group membership reports between nodes and router, and IGMP routing updates between routers.

Much of the burden of using these addresses efficiently falls to the routers on the Internet. Efficient delivery paths route data only to clients that want to receive the data and take the shortest path to those clients. Routers stop sending data to their own subnetworks when it is not wanted. Several algorithms have been designed to optimize routing table updates for multicast, including MOSPF, DVMRP, and PIM.

RTP - Real Time Protocol

RTP is a content-independent protocol that provides channel and content identification for multicast content, as well as sequencing and time stamp information. The packet outline is shown here.

The IETF has defined several values for Content type, such as 26 for JPEG and 27 for CU-SeeMe. Thus any RTP-compliant application can determine which decoding algorithm to use for a given packet.

The Option bit is used to determine if the Options field contains one or more variable-length structures which provide extra information that may be application specific. An Option has 4 fields.

Several types of Options are in use, such as Source Description. It contains a 16-bit content source ID which is used to distinguish multiple streams from a single host, a 32-bit IP address field for the sender, and a variable length string name of the sender.

RTP is more suitable for real-time data transmission over the Internet than other protocols, such as HTTP. It's header is small, only 28 bytes. However, even this overhead may saturate a slow modem link - PPP + IP + UDP + RTP could overwhelm bandwidth if the actual data size is small. The time stamp and sequencing fields also improve performance in congested conditions by helping to maintain synchronization.

NetShow vs. RealVideo

We can now address the substantive differences between the competing products from Microsoft and RealVideo. Their relative strengths can be described in terms of the value they add to the existing Internet technologies. Both have application layers that sit atop RTP or UDP in the protocol stack. Both use IP Multicast if available, but can fail over to unicast transmission if multicast is not available. Let's return to the questions posed in the introduction and reply to them in the context of each product.

At the time of this paper, Progressive Networks was developing a new platform for multimedia streaming, known as RealMedia. Unlike NetShow, however, it is not a released product and is only available as an SDK. Therefore this paper will focus on the RealVideo product from Progressive and will address some of the proposals in the RealMedia architecture at the end.

Scalability is one of the most important elements of an Internet multimedia streaming solution. Use of multicasting helps reduce the amount of sender resources allocated per recipient. Ideally, only one copy of a stream is transmitted and every client can receive it with no overhead on the server end.

RealVideo offers several approaches to achieving scalability. First, Progressive Networks claims that one Pentium-based RealVideo server can deliver 500 to 1000 28.8-Kbps streams over multicast. Second, it provides distributed processing capabilities. For example, multiple RealVideo servers can reside in a cluster and respond to on-demand requests in parallel, thus dividing the work. Finally, if multicasting is not available, a RealVideo Splitter system can stream live video supplied by another server. Efficient use of Splitters can reduce the number of unicast connections maintained by the originating server.

NetShow is also rated to support 1000 28.8-Kbps streams on a Pentium server. It is multi-threaded to take advantage of multiple processors in a single computer. RealVideo's documentation doesn't mention any support for multiprocessing.

Both systems use installable codecs (compression/decompression algorithms) to reduce the size of transmitted data. Both claim to be codec independent - anyone can write and install a new codec in the system. The difference lies in the details. RealVideo comes standard with a handful of codecs for audio and video streams. NetShow ships with a wide variety of codecs, from various vendors. NetShow uses standard Video Compression Manager (VCM) and Audio Compression Manager (ACM) codecs for the Windows platform, which means other Windows applications. The RealVideo documentation is not clear about the usefulness of its codecs outside of RealVideo.

NetShow currently sets the standard for breadth of formats that can be streamed. It supports most standard graphic, audio, and video file formats, from JPEG to WAV and URL for on-demand streaming. Content developers can use the new ASF format to provide synchronized data transmittal, such as synchronization of a sound stream with a slide show. ASF files can also open web pages and transmit script commands. Any type of data file can be streamed via multicast, with a "best-effort" level of service, reducing the net traffic needed to download large amounts of data to a large set of clients.

RealVideo is strictly a video and audio system. The RealMedia architecture that Progressive has recently announced will be a big step forward. That system will provide a means for a content developer to provide client and server code to stream and play back any sort of data it wants to. It also supports synchronization of content of different media types. The client-side player is a minimal module that downloads new codecs and media players as they become available, automatically.

The content differences between NetShow and RealMedia lead into the next discussion - openness and standards.

NetShow is built on well-defined standards of protocols (RTP) and codecs (ACM/VCM). A NetShow player can receive any MBone multicast and play it. RealVideo (and RealMedia) uses a different transmission control protocol called RTSP, which is a draft proposal that Netscape and Progressive recently put in front of the IETF. The value of RTSP is yet to be determined, although several content developers have embraced it, as well as the RealMedia architecture. RTSP is a protocol for coordination, the data streams travel on a different protocol, such as UDP. RealMedia codecs, while installable, are proprietary.

Unlike NetShow, RealVideo is a cross-platform solution. The server and player software is available for Windows NT, Macintosh, and various versions of UNIX. NetShow is only available for Windows NT. The integration of NetShow with Windows NT does lend it several advantages on that platform. NetShow server management functions are tightly coupled to the NT Server Performance Monitor and to the IIS Internet Service Manager, such that a NetShow server can be configured remotely using a web browser.

The definition of "open" for these technologies is a rich source for debate. The NetShow approach seems to convert any proprietary format to a standard one, such as JPEG or AVI, and stream the standard format so that any NetShow client can play it without caring how it originated. RealMedia takes the approach that the content developer can provide a server and player of the proprietary data type; openness lies in the means for installing the code. Note that this means the content developer has to provide a Macintosh, Windows, and UNIX version of each module in order to reach all the target audience. Of course, the target audience is potentially much wider than just the Windows crowd that NetShow reaches.

If RTSP becomes widely accepted, RealVideo (and RealMedia) becomes the model for how to structure an RTSP application. As such it could have a great influence on how future standards evolve.

Data streaming is most useful if the clients receive it in its entirety. Both NetShow and RealVideo append Forward Error Correcting (FEC) information to transmitted data. Both products use client feedback to help control jitter and latency. NetShow also provides a set of management tools, such an adjustable redundancy factor and a "knob" to control the bandwidth of transmissions.

Both systems also rely on good playback algorithms combined with loss-resistant codecs to prevent degradation of video playback. For example, NetShow has a "Loss-Tolerant" JPEG filter that allows a client to display JPEG images even if many image packets are lossed in transit.

Conclusion

The battle for Internet and corporate multimedia streaming markets is on. Progressive Networks and Netscape are challenging Microsoft with the RealMedia architecture. They are betting heavily on a multi-platform solution that allows any content developer to provide code to transmit and play back proprietary data types. Microsoft is relying on the increasing market penetration of Windows NT to deliver NetShow, a free package that allows content developers to convert proprietary formats to a standard format for delivery to any NetShow player, which needs no extra code download.

Naturally, which product to buy depends on many factors. A company with a heterogeneous network that is using existing products like Liquid Audio or Macromedia (which have RealMedia Plug-ins) could easily standardize on RealMedia. One that is purchasing NT Server and Windows clients in volume can make a natural transition to NetShow without any extra cost for the software. The licensing structure for RealMedia will be an important factor, especially if each supplier of server Plug-ins charges its own license fee. NetShow is free regardless of the number of clients.

Honan, Jamie. (Sept. 27, 1996). RTP, Multicasting, Video and Audio Conferencing [Online]. Available:

Lanphier, Rob and Rao, Anup. (Feb. 24, 1997). Real Time Streaming Protocol (RTSP) [Online]. Available: