【正文】 靠一些傳統(tǒng)媒體進(jìn)行發(fā)布，如廣播、電視、報(bào)紙等。這些技術(shù)大多已經(jīng)實(shí)施在RealNetworks公司的RealSystem174。例如，缺乏控制率，其中Web服務(wù)器通過網(wǎng)絡(luò)把數(shù)據(jù)以及使用保證交付運(yùn)輸協(xié)議（TCP）造成大幅波動(dòng)，在片段的編碼數(shù)據(jù)的交貨時(shí)間。此外，服務(wù)器通常不知道有多少客戶端訂閱的廣播和/或他們的實(shí)際連接的統(tǒng)計(jì)信息。 8 codec, which we are using throughout the paper to illustrate our results. Terms—Internet media delivery networks, scalable video coding, streaming media, video pression.I EVOLUTION OF STREAMING MEDIA TECHNOLOGIESThe concept of streaming media came at a time when basic multimedia technologies had already established themselves on desktop PCs. Audio and video clips were digitized, encoded(., using MPEG1 pression standard), and presented as files on the puter’s file system. To view the information recorded in such files, PC users ran special software designedto depress and render them on the first and most natural extension of this paradigm on the Internet was the concept of downloadable media. Compressed media files from the Web were expected to be downloaded on local machines, where they could be played back using the standard multimedia software. However, this was not a satisfactory solution for users with limited amounts of disk space, slow connection speeds and/or limited patience. This essentially created the need for streaming media, a technology that enabled the user to experience a multimedia presentation onthefly, while it was being downloaded from the Internet.HTTPBased StreamingThe design of some early streaming media programs, like Vivo Active , was based on the use of the standard (HTTPbased) Web servers to deliver encoded media content. Since all HTTP serverclient transactions are implemented using a guaranteeddelivery transport protocol, such as TCP , the design of these programs was very simple. For example, Vivo Active used a bination of the standard video audio codecs, and a simple multiplexing protocol to bine the audio and video streams in single file. These codecs came from desktop video conferencing, and only minor algorithmic changes (mostly related to rate control) were required to make such a system work.However, being originally designed for serving static documents, HTTP protocol was not particularly suited for realtime streaming. For example, the lack of control over the rate atwhich the Web server pushes data through the network, as well as the use of the guaranteeddelivery transport protocol (TCP), caused substantial fluctuation in the delivery times for the fragments of the encoded data. This is why the Vivo Active player used a quite large (5–20 s) predrill buffer that was meant to pensate for the business of such a delivery process. Nevertheless, if for some reason the delivery of the next fragment of data was delayed by more than the available predrill time, the player had to suspend rendering until the buffer was refilled. This socalled rebuffing process was a frequent cause of diminished user experience.Some other challenges of using standard Web servers were streaming of live presentations and implementing VCRstyle navigation features such as seek, fastforward, and rewind forOn demand streaming.Fig. 1 Communication between RealAudio server and RealAudio playerII. STREAMING MEDIA DELIVERY MECHANISMSIt is important to distinguish between two modes in which video information can be distributed over the Internet, namely, live broadcasting and ondemand streaming. Below, we consider each of these models and the corresponding delivery mechanisms used by modern streaming media systems.Distribution of Live VideoA diagram illustrating various steps in the distribution of live content is presented in Fig. 3. The source of live video information (such as any standard analog video recorder) is connected to the encoder. The encoding engine is responsible for capturing and digitizing the ining analog video information, pressing it, and passing the resulting data down to the server. Alternatively, the server can receive such information from a Simulated Live Transfer Agent (SLTA), a software tool that reads preencoded information from an archive and sends itto a server as if it has just been encoded from a live source.The server is responsible for dispersing the pressed information from the encoder to all connected splitters and/or clients who have joined the broadcast. Splitters are additional servers that can be either part of a dedicated media delivery network, or a publicIPbased multipleaccess delivery network, or can be embedded in network traffic caches, which in case of live streaming broadcasts just pass the information through.In its simplest form, the server (or splitter) unicasts the encoded video information to each of the clients individually using a oneway data stream (bined with twoway RTSP sessioncontrol). In this case, the parameters of the connection between server and each client can be estimated at the beginning of each session and can be systematically monitored during the broadcast.In the case where a network is equipped with multicastenabled routers, the server needs to send only one multicast stream, which is automatically replicated to all subscribed clients on the network. Important limitations of multicasting are oneway transmission and nonguaranteed delivery of information. In addition, the server does not typically know how many clients are subscribed to the broadcast and/or their actual connection statistics. A possible way to serve clients with different connection speeds is to simulcast several independent encoded versions (streams) of the source targeted for different bit rates, and let clients decide which stream to use. In addition to the serverclient transfers, streaming media networks also have to distribute encoded video information between their splitters. There are several possible ways such distribution can be implemented by the network. In one possible implementation, splitting is initiated by the source server, which broadcasts information to all directly connected splitters, and so on. We ca