【正文】 RTCP/TCP(UDP) 數(shù)據(jù)信息RTP/UDP 流媒體傳輸基本原理流媒體實現(xiàn)的基本原理[1]是將原來的媒體文件使用高效的壓縮算法進(jìn)行壓縮以后，應(yīng)用合適的流式傳輸，經(jīng)過流媒體服務(wù)器的配置，采用一定的實時協(xié)議來傳輸數(shù)據(jù)。它會將連續(xù)的聲音和影像等多媒體信息進(jìn)行壓縮編碼處理分成了一個個小的數(shù)據(jù)包，從而降低了對時延、抖動和傳輸帶寬的要求，它會把連續(xù)的音頻和視頻信息經(jīng)過壓縮分割后放到網(wǎng)絡(luò)服務(wù)器上，網(wǎng)絡(luò)用戶在客戶端只需要短暫的緩存就能夠觀看部分下載下來的文件，而未下載的文件則繼續(xù)緩存，從而達(dá)到邊下載邊觀看的效果。還指出流媒體在企業(yè)應(yīng)用中出現(xiàn)的問題，最后對流媒體技術(shù)在企業(yè)中應(yīng)用發(fā)展進(jìn)行展望。它會將連續(xù)的聲音和影像等多媒體信息進(jìn)行壓縮編碼處理分成了一個個小的數(shù)據(jù)包，從而降低了對時延、抖動和傳輸帶寬的要求，它會把連續(xù)的音頻和視頻信息經(jīng)過壓縮分割后放到網(wǎng)絡(luò)服務(wù)器上，網(wǎng)絡(luò)用戶在客戶端只需要短暫的緩存就能夠觀看部分下載下來的文件，而未下載的文件則繼續(xù)緩存，從而達(dá)到邊下載邊觀看的效果本文介紹了流媒體技術(shù)的基本特征，詳細(xì)闡述了流媒體技術(shù)在企業(yè)中的應(yīng)用，包括職工培訓(xùn)、產(chǎn)品介紹、視頻會議、信息發(fā)布等，及其核心技術(shù)—智能流技術(shù)。 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 de