流媒體

　　技術

　　流式傳輸基礎

　　流式傳輸是實現(xiàn)流媒體的關鍵技術。

　　在網(wǎng)絡上傳輸音/視頻等多媒體信息，主要有下載和流式傳輸兩種方案。A/V文件一般都較大，所以需要的存儲容量也較大；同時由于網(wǎng)絡帶寬的限制，下載常常要花數(shù)分鐘甚至數(shù)小時，所以這種處理方法延遲也很大。流式傳輸時，聲音、影像或動畫等時基媒體由音視頻服務器向用戶計算機的連續(xù)、實時傳送，用戶不必等到整個文件全部下載完畢，而只需經(jīng)過幾秒或十數(shù)秒的啟動延時即可進行觀看。當聲音等時基媒體在客戶機上播放時，文件的剩余部分將在后臺從服務器內(nèi)繼續(xù)下載。流式不僅使啟動延時成十倍、百倍地縮短，而且不需要太大的緩存容量。流式傳輸避免了用戶必須等待整個文件全部從Internet上下載才能觀看的缺點。

　　流媒體指在Internet/Intranet中使用流式傳輸技術的連續(xù)時基媒體，如：音頻、視頻或多媒體文件。流式媒體在播放前并不下載整個文件，只將開始部分內(nèi)容存入內(nèi)存，流式媒體的數(shù)據(jù)流隨時傳送隨時播放，只是在開始時有一些延遲。流媒體實現(xiàn)的關鍵技術就是流式傳輸。

　　流式傳輸定義很廣泛，主要指通過網(wǎng)絡傳送媒體（如視頻、音頻）的技術總稱。其特定含義為通過Internet 將影視節(jié)目傳送到PC機。實現(xiàn)流式傳輸有兩種方法：實時流式傳輸（Real time streaming）和順序流式傳輸（progressive streaming）順序流式傳輸是順序下載，在下載文件的同時用戶可觀看在線媒體，在給定時刻，用戶只能觀看已下載的那部分，而不能跳到還未下載的前頭部分，在傳輸期間不根據(jù)用戶連接的速度對下載順序做調(diào)整。實時流式傳輸指保證媒體信號帶寬與網(wǎng)絡連接匹配，使媒體可被實時觀看到。實時流式傳輸根據(jù)網(wǎng)絡情況調(diào)整輸出音視頻的質(zhì)量從而實現(xiàn)媒體的持續(xù)的實時傳送，用戶可快進或后退以觀看前面或后面的內(nèi)容。

　　一般說來，如視頻為實時廣播，或使用流式傳輸媒體服務器，或應用如RTSP的實時協(xié)議，即為實時流式傳輸。如使用HTTP服務器，文件即通過順序流發(fā)送。采用哪種傳輸方法依賴你的需求。當然，流式文件也支持在播放前完全下載到硬盤。

　　順序流式傳輸

　　順序流式傳輸是順序下載，在下載文件的同時用戶可觀看在線媒體，在給定時刻，用戶只能觀看已下載的那部分，而不能跳到還未下載的前頭部分，順序流式傳輸不象實時流式傳輸在傳輸期間根據(jù)用戶連接的速度做調(diào)整。由于標準的HTTP服務器可發(fā)送這種形式的文件，也不需要其他特殊協(xié)議，它經(jīng)常被稱作HTTP流式傳輸。順序流式傳輸比較適合高質(zhì)量的短片段，如片頭、片尾和廣告，由于該文件在播放前觀看的部分是無損下載的，這種方法保證電影播放的最終質(zhì)量。這意味著用戶在觀看前，必須經(jīng)歷延遲，對較慢的連接尤其如此。對通過調(diào)制解調(diào)器發(fā)布短片段，順序流式傳輸顯得很實用，它允許用比調(diào)制解調(diào)器更高的數(shù)據(jù)速率創(chuàng)建視頻片段。盡管有延遲，畢竟可讓你發(fā)布較高質(zhì)量的視頻片段。順序流式文件是放在標準HTTP或FTP服務器上，易于管理，基本上與防火墻無關。順序流式傳輸不適合長片段和有隨機訪問要求的視頻，如：講座、演說與演示。它也不支持現(xiàn)場廣播，嚴格說來，它是一種點播技術。

　　實時流式傳輸

　　實時流式傳輸指保證媒體信號帶寬與網(wǎng)絡連接配匹，使媒體可被實時觀看到。實時流與HTTP流式傳輸不同，他需要專用的流媒體服務器與傳輸協(xié)議。實時流式傳輸總是實時傳送，特別適合現(xiàn)場事件，也支持隨機訪問，用戶可快進或后退以觀看前面或后面的內(nèi)容。理論上，實時流一經(jīng)播放就可不停止，但實際上，可能發(fā)生周期暫停。實時流式傳輸必須配匹連接帶寬，這意味著在以調(diào)制解調(diào)器速度連接時圖象質(zhì)量較差。而且，由于出錯丟失的信息被忽略掉，網(wǎng)絡擁擠或出現(xiàn)問題時，視頻質(zhì)量很差。如欲保證視頻質(zhì)量，順序流式傳輸也許更好。實時流式傳輸需要特定服務器，如：QuickTime Streaming Server、RealServer與Windows Media Server。這些服務器允許你對媒體發(fā)送進行更多級別的控制，因而系統(tǒng)設置、管理比標準HTTP服務器更復雜。實時流式傳輸還需要特殊網(wǎng)絡協(xié)議，如：RTSP (Realtime Streaming Protocol)或MMS (Microsoft Media Server)。這些協(xié)議在有防火墻時有時會出現(xiàn)問題，導致用戶不能看到一些地點的實時內(nèi)容。

　　產(chǎn)品

　　1、編碼器：它由一臺普通計算機、一塊microvision高清視頻采集卡和流媒體編碼軟件組成。Microvision流媒體采集卡負責將音視頻信息源輸入計算機，供編碼軟件處理；編碼軟件負責將流媒體 采集卡傳送過來的數(shù)字音視頻信號壓縮成流媒體格式。如果做直播，它還負責實時地將壓縮好的流媒體信號上傳給流媒體服務器。

　　2、服務器：由流媒體軟件系統(tǒng)的服務器部分和一臺硬件服務器組成。這部分負責管理、存儲、分發(fā)編碼器傳上來的流媒體節(jié)目。

　　3、終端播放器，也叫解碼器： 這部分由流媒體系統(tǒng)的播放軟件和一臺普通PC組成，用它來播放用戶想要收看的流媒體服務器上的視頻節(jié)目。

　　原理

　　流式傳輸?shù)膶崿F(xiàn)需要緩存。因為Internet以包傳輸為基礎進行斷續(xù)的異步傳輸，對一個實時A/V源或存儲的A/V文件，在傳輸中它們要被分解為許多包，由于網(wǎng)絡是動態(tài)變化的，各個包選擇的路由可能不盡相同，故到達客戶端的時間延遲也就不等，甚至先發(fā)的數(shù)據(jù)包還有可能后到。為此，使用緩存系統(tǒng)來彌補延遲和抖動的影響，并保證數(shù)據(jù)包的順序正確，從而使媒體數(shù)據(jù)能連續(xù)輸出，而不會因為網(wǎng)絡暫時擁塞使播放出現(xiàn)停頓。通常高速緩存所需容量并不大，因為高速緩存使用環(huán)形鏈表結(jié)構(gòu)來存儲數(shù)據(jù)：通過丟棄已經(jīng)播放的內(nèi)容，流可以重新利用空出的高速緩存空間來緩存后續(xù)尚未播放的內(nèi)容。——流式傳輸?shù)膶崿F(xiàn)需要合適的傳輸協(xié)議。由于TCP需要較多的開銷，故不太適合傳輸實時數(shù)據(jù)。流式傳輸?shù)倪^程一般是這樣的：用戶選擇某一流媒體服務后，Web瀏覽器與Web服務器之間使用HTTP/TCP交換控制信息，以便把需要傳輸?shù)膶崟r數(shù)據(jù)從原始信息中檢索出來；然后客戶機上的Web瀏覽器啟動A/VHelper程序，使用HTTP從Web服務器檢索相關參數(shù)對Helper程序初始化。這些參數(shù)可能包括目錄信息、A/V數(shù)據(jù)的編碼類型或與A/V檢索相關的服務器地址。

　　A/VHelper程序及A/V服務器運行實時流控制協(xié)議（RTSP），以交換A/V傳輸所需的控制信息。與CD播放機或VCRs所提供的功能相似，RTSP提供了操縱播放、快進、快倒、暫停及錄制等命令的方法。A/V服務器使用RTP/UDP協(xié)議將A/V數(shù)據(jù)傳輸給A/V客戶程序（一般可認為客戶程序等同于Helper程序），一旦A/V數(shù)據(jù)抵達客戶端，A/V客戶程序即可播放輸出。

　　需要說明的是，在流式傳輸中，使用RTP/UDP和RTSP/TCP兩種不同的通信協(xié)議與A/V服務器建立聯(lián)系，是為了能夠把服務器的輸出重定向到一個不同于運行A/VHelper程序所在客戶機的目的地址。實現(xiàn)流式傳輸一般都需要專用服務器和播放器。

　　智能流

　　今天，28.8Kbps調(diào)制解調(diào)器是Internet連接的基本速率，cable modem、 ADSL、DSS、ISDN等發(fā)展快，內(nèi)容提供商不得不要么限制發(fā)布媒體質(zhì)量，要么限制連接人數(shù)。根據(jù)RealNetwork站點統(tǒng)計，對28.8Kbps調(diào)制解調(diào)器，實際流量為10bps到26Kbps，呈鐘形分布，高峰在20Kbps。這意味著若內(nèi)容提供商選擇20Kbps固定速率，將有大量用戶得不到好質(zhì)量信號，并可能停止媒體流而引起客戶端再次緩沖，直到接收足夠數(shù)據(jù)。一種解決方法是服務器減少發(fā)送給客戶端的數(shù)據(jù)而阻止再緩沖，在RealSystem 5.0中，這種方法稱為“視頻流瘦化”。這種方法的限制是RealVideo文件為一種數(shù)據(jù)速率設計，結(jié)果可通過抽取內(nèi)部幀擴展到更低速率，導致質(zhì)量較低。離原始數(shù)據(jù)速率越遠，質(zhì)量越差。另一種解決方法是根據(jù)不同連接速率創(chuàng)建多個文件，根據(jù)用戶連接，服務器發(fā)送相應文件，這種方法帶來制作和管理上的困難，而且，用戶連接是動態(tài)變化的，服務器也無法實時協(xié)調(diào)。 智能流技術通過兩種途徑克服帶寬協(xié)調(diào)和流瘦化。首先，確立一個編碼框架，允許不同速率的多個流同時編碼，合并到同一個文件中；第二，采用一種復雜客戶/服務器機制探測帶寬變化。

　　針對軟件、設備和數(shù)據(jù)傳輸速度上的差別，用戶以不同帶寬瀏覽音視頻內(nèi)容。為滿足客戶要求，Progressive networks公司編碼、記錄不同速率下媒體數(shù)據(jù)，并保存在單一文件中，此文件稱為智能流文件，即創(chuàng)建可擴展流式文件。當客戶端發(fā)出請求，它將其帶寬容量傳給服務器，媒體服務器根據(jù)客戶帶寬將智能流文件相應部分傳送給用戶。以此方式，用戶可看到最可能的優(yōu)質(zhì)傳輸，制作人員只需要壓縮一次，管理員也只需要維護單一文件，而媒體服務器根據(jù)所得帶寬自動切換。智能流通過描述I現(xiàn)實世界Internet上變化的帶寬特點來發(fā)送高質(zhì)量媒體并保證可靠性，并對混合連接環(huán)境的內(nèi)容授權提供了解決方法。

　　智能流

　　在RealSystem G2中是對所謂自適應流管理(ASM)API的實現(xiàn)，ASM描述流式數(shù)據(jù)的類型，輔助智能決策，確定發(fā)送那種類型數(shù)據(jù)包。文件格式和廣播插件定義了ASM規(guī)則。用最簡單的形式分配預定義屬性和平均帶寬給數(shù)據(jù)包組。對高級形式，ASM規(guī)則允許插件根據(jù)網(wǎng)絡條件變化改變數(shù)據(jù)包發(fā)送。每個ASM規(guī)則可有一定義條件的演示式，如演示式定義客戶帶寬是5，000到15，000Kbps，包損失小于2.5%。如此條件描述了客戶當前網(wǎng)絡連接，客戶就訂閱此規(guī)則。定義在規(guī)則中的屬性有助于RealServer有效傳送數(shù)據(jù)包，如網(wǎng)絡條件變化，客戶就訂閱一個不同規(guī)則。

　　流媒體格式

　　聲音流、視頻流、文本流、圖像流、動畫流

　　RA：實時聲音

　　RM：實時視頻或音頻的實時媒體

　　RT：實時文本

　　RP：實時圖像

　　SMIL：同步的多重數(shù)據(jù)類型綜合設計文件

　　SWF：macromedia的real flash 和shockwave flash動畫文件

　　RPM：HTML文件的插件

　　RAM：流媒體的元文件，是包含RA、RM、SMIL文件地址（URL地址）的文本文件

　　CSF：一種類似媒體容器的文件格式，可以將非常多的媒體格式包含在其中，而不僅僅限于音、視頻。

　　它可以把ppt和教師講課的視頻完美結(jié)合， 很多大學和大型企業(yè)使用這套軟件進行教學錄像和遠程教育。

　　1、realnetwork公司：三種

　　2、apple公司：quicktime\mov

　　3、microsoft公司

　?。?）asf\wmv\wma

　?。?）avi

　　（3）mpeg\mpg\dat

　　4、micromedia公司

　?。?）flash的swf格式

　?。?）metastream的mts格式

　　（3）aam多媒體教學課件格式，可將authorware生成的文件壓縮為aam和aas流式文件播放

　　傳輸協(xié)議

　　1、RSVP：資源預留協(xié)議

　　2、RTP：實時傳輸協(xié)議

　　3、RTCP：實時傳輸控制協(xié)議

　　4、MMS：微軟流媒體服務協(xié)議

　　5、RTSP：實時流傳輸協(xié)議

　　6、MIME：多目因特網(wǎng)電子郵件擴展協(xié)議

　　7、RTMP(RTMPE/RTMPS/RTMPT)：Adobe實時消息協(xié)議簇

　　8、RTMFP：Adobe實施消息流協(xié)議（P2P協(xié)議）

　　播放方式

　　單播

　　在客戶端與媒體服務器之間需要建立一個單獨的數(shù)據(jù)通道，從一臺服務器送出的每個數(shù)據(jù)包只能傳送給一個客戶機，這種傳送方式稱為單播。每個用戶必須分別對媒體服務器發(fā)送單獨的查詢，而媒體服務器必須向每個用戶發(fā)送所申請的數(shù)據(jù)包拷貝。這種巨大冗余首先造成服務器沉重的負擔，響應需要很長時間，甚至停止播放；管理人員也被迫購買硬件和帶寬來保證一定的服務質(zhì)量。

　　組播

　　IP組播技術構(gòu)建一種具有組播能力的網(wǎng)絡，允許路由器一次將數(shù)據(jù)包復制到多個通道上。采用組播方式，單臺服務器能夠?qū)资f臺客戶機同時發(fā)送連續(xù)數(shù)據(jù)流而無延時。媒體服務器只需要發(fā)送一個信息包，而不是多個；所有發(fā)出請求的客戶端共享同一信息包。信息可以發(fā)送到任意地址的客戶機，減少網(wǎng)絡上傳輸?shù)男畔目偭?。網(wǎng)絡利用效率大大提高，成本大為下降。

　　點播與廣播

　　點播連接是客戶端與服務器之間的主動的連接。在點播連接中，用戶通過選擇內(nèi)容項目來初始化客戶端連接。用戶可以開始、停止、后退、快進或暫停流。點播連接提供了對流的最大控制，但這種方式由于每個客戶端各自連接服務器，卻會迅速用完網(wǎng)絡帶寬。

　　廣播指的是用戶被動接收流。在廣播過程中，客戶端接收流，但不能控制流。例如，用戶不能暫停、快進或后退該流。廣播方式中數(shù)據(jù)包的單獨一個拷貝將發(fā)送給網(wǎng)絡上的所有用戶。 使用單播發(fā)送時，需要將數(shù)據(jù)包復制多個拷貝，以多個點對點的方式分別發(fā)送到需要它的那些用戶，而使用廣播方式發(fā)送，數(shù)據(jù)包的單獨一個拷貝將發(fā)送給網(wǎng)絡上的所有用戶，而不管用戶是否需要，上述兩種傳輸方式會非常浪費網(wǎng)絡帶寬。組播吸收了上述兩種發(fā)送方式的長處，克服了上述兩種發(fā)送方式的弱點，將數(shù)據(jù)包的單獨一個拷貝發(fā)送給需要的那些客戶。組播不會復制數(shù)據(jù)包的多個拷貝傳輸?shù)骄W(wǎng)絡上，也不會將數(shù)據(jù)包發(fā)送給不需要它的那些客戶，保證了網(wǎng)絡上多媒體應用占用網(wǎng)絡的最小帶寬。

　　技術應用　　

　　互聯(lián)網(wǎng)的迅猛發(fā)展和普及為流媒體業(yè)務發(fā)展提供了強大市場動力，流媒體業(yè)務正變得日益流行。流媒體技術廣泛用于多媒體新聞發(fā)布、在線直播、網(wǎng)絡廣告、電子商務、視頻點播、遠程教育、遠程醫(yī)療、網(wǎng)絡電臺、實時視頻會議等互聯(lián)網(wǎng)信息服務的方方面面。流媒體技術的應用將為網(wǎng)絡信息交流帶來革命性的變化，對人們的工作和生活將產(chǎn)生深遠的影響。

　　一個完整的流媒體解決方案應是相關軟硬件的完美集成，它大致包括下面幾個方面的內(nèi)容： 內(nèi)容采集、 視音頻捕獲和壓縮編碼、內(nèi)容編輯、內(nèi)容存儲和播放、應用服務器內(nèi)容管理發(fā)布及用戶管理等。

　　流媒體技術和聲音信息經(jīng)過壓縮處理后放上網(wǎng)站服務器，讓用戶一邊下載一邊觀看、收聽，而不要等整個壓縮文件下載到自己的計算機上才可以觀看的網(wǎng)絡傳輸技術。該技術先在使用者端的計算機上創(chuàng)建一個緩沖區(qū)，在播放前預先下一段數(shù)據(jù)作為緩沖，在網(wǎng)路實際連線速度小于播放所耗的速度時，播放程序就會取用一小段緩沖區(qū)內(nèi)的數(shù)據(jù)，這樣可以避免播放的中斷，也使得播放品質(zhì)得以保證。

　　傳輸流程

　　在流式傳輸?shù)膶崿F(xiàn)方案中，一般采用HTTP/TCP來傳輸控制信息，而用RTP/UDP來傳輸實時聲音數(shù)據(jù)。具體的傳輸流程如下：

　　(1)Web瀏覽器與Web服務器之間使用HTTP/TCP交換控制信息，以便把需要傳輸?shù)膶崟r數(shù)據(jù)從原始信息中檢索出來。

　　(2)用HTTP從Web服務器檢索相關數(shù)據(jù)，由A/V播放器進行初始化。

　　(3)從Web服務器檢索出來的相關服務器的地址定位A/V服務器。

　　(4)A/V播放器與A/V服務器之間交換A/V傳輸所需要的實時控制協(xié)議。

　　(5)一旦A/V數(shù)據(jù)抵達客戶端，A/V播放器就可播放。

　　技術方式

　　主流的流媒體技術有三種，分別是RealNetworks公司的RealMedia、Microsoft公司的WindowsMediaTechnology和Apple公司的QuickTime。這三家的技術都有自己的專利算法、專利文件格式甚至專利傳輸控制協(xié)議。

　　1.Apple公司的QuickTime

　　QuickTime是一個非常老牌的媒體技術集成，是數(shù)字媒體領域事實上的工業(yè)標準。之所以說集成這個詞是因為QuickTime實際上是一個開放式的架構(gòu)，包含了各種各樣的流式或者非流式的媒體技術。QuickTime是最早的視頻工業(yè)標準，1999年發(fā)布的QuickTime4.0版本開始支持真正的流式播放。由于QuickTime本身也存在著平臺的便利(MacOS)，因此也擁有不少的用戶。QuickTime在視頻壓縮上采用的是SorensonVideo技術，音頻部分則采用QDesignMusic技術。QuickTime最大的特點是其本身所具有的包容性，使得它是一個完整的多媒體平臺，因此基于QuickTime可以使用多種媒體技術來共同制作媒體內(nèi)容。同時，它在交互性方面是三者之中最好的。例如，在一個QuickTime文件中可同時包含midi、動畫gif、flash和smil等格式的文件，配合QuickTime的WiredSprites互動格式，可設計出各種互動界面和動畫。QuickTime流媒體技術實現(xiàn)基礎是需要3個軟件的支持，QuickTime播放器、QuickTime編輯制作、QuickTimeStreaming服務器。

　　2.RealNetworks公司的RealMedia

　　RealMedia發(fā)展的時間比較長，因此具有很多先進的設計，例如，ScalableVideoTechnology可伸縮視頻技術可以根據(jù)用戶電腦速度和連接質(zhì)量而自動調(diào)整媒體的播放質(zhì)素。Two—passE ncoding兩次編碼技術可通過對媒體內(nèi)容進行預掃描，再根據(jù)掃描的結(jié)果來編碼從而提高編碼質(zhì)量。特別是SureStream自適應流技術，可通過一個編碼流提供自動適合不同帶寬用戶的流播放。RealMedia音頻部分采用的是RealAudio，該編碼在低帶寬環(huán)境下的傳輸性能非常突出。RealMedia通過基于smil并結(jié)合自己的RealPix和RealText技術來達到一定的交互能力和媒體控制能力。Real流媒體技術需要3個軟件的支持，RealPlayer播放器、RealProducer編輯制作、RealServer服務器。

　　3.Microsoft公司的WindowsMedia

　　WindowsMedia是三家之中最后進入這個市場的，但憑借其操作系統(tǒng)的便利很快便取得了較大的市場份額。WindowsMediaVideo采用的是mpeg-4視頻壓縮技術，音頻方面采用的是WindowsMediaAudio技術。WindowsMedia的關鍵核心是MMS協(xié)議和ASF數(shù)據(jù)格式，MMS用于網(wǎng)絡傳輸控制，ASF則用于媒體內(nèi)容和編碼方案的打包。目前WindowsMedia在交互能力方面是三者之中最弱的，自己的ASF格式交互能力不強，除了通過IE支持smil之外就沒有什么其他的交互能力了。WindowsMedia流媒體技術的實現(xiàn)需要3個軟件的支持，WindowsMedia播放器、WindowsMedia工具和WindowsMedia服務器?？偟膩碚f，如果使用Windows服務器平臺，WindowsMedia的費用最少。雖然在現(xiàn)階段其功能并不是最好，用戶也不是最多。

　　存在問題

　　流媒體技術不是一種單一的技術，它是網(wǎng)絡技術及視/音頻技術的有機結(jié)合。在網(wǎng)絡上實現(xiàn)流媒體技術，需要解決流媒體的制作、發(fā)布、傳輸及播放等方面的問題，而這些問題則需要利用視音頻技術及網(wǎng)絡技術來解決，具體如下：

　?。?）流媒體制作技術方面解決的問題

　　在網(wǎng)上進行流媒體傳輸，所傳輸?shù)奈募仨氈谱鞒蛇m合流媒體傳輸?shù)牧髅襟w格式文件。因為通常格式存儲的多媒體文件容量十分大，若要在現(xiàn)有的窄帶網(wǎng)絡上傳輸則需要花費十分長的時間，若遇網(wǎng)絡繁忙，還將造成傳輸中斷。另外，通常格式的流媒體也不能按流媒體傳輸協(xié)議進行傳輸。因此，對需要進行流媒體格式傳輸?shù)奈募M行預處理，將文件壓縮生成流媒體格式文件。這里應注意兩點：一是選用適當?shù)膲嚎s算法進行壓縮，這樣生成的文件容量較小。二是需要向文件中添加流式信息。

　?。?）流媒體傳輸方面需解決的問題

　　流媒體的傳輸需要合適的傳輸協(xié)議，在internet上的文件傳輸大部分都是建立在tcp協(xié)議的基礎上，也有一些是以ftp傳輸協(xié)議的方式進行傳輸，但采用這些傳輸協(xié)議都不能實現(xiàn)實時方式的傳輸。隨著流媒體技術的深入研究，實時傳輸協(xié)議。

　　為何要在udp協(xié)議而不在tcp協(xié)議上進行實時數(shù)據(jù)的傳輸呢？這是因為udp和tcp協(xié)議在實現(xiàn)數(shù)據(jù)傳輸時的可靠性有很大的區(qū)別。tcp協(xié)議中包含了專門的數(shù)據(jù)傳送校驗機制，當數(shù)據(jù)接受方收到數(shù)據(jù)后，將自動向發(fā)送方發(fā)出確認信息，發(fā)送方在接收到確認信息后才繼續(xù)傳送數(shù)據(jù)，否則將一直處于等待狀態(tài)。而udp協(xié)議則不同，udp協(xié)議本身并不能做任何校驗。由此可以看出，tcp協(xié)議注重傳輸質(zhì)量，而udp協(xié)議則注重傳輸速度．因此，對于對傳輸質(zhì)量要求不是很高，而對傳輸速度則有很高的要求的視音頻流媒體文件來說，采用udp協(xié)議則更合適。

　?。?）流媒體的傳輸過程中需要緩存的支持

　　因為interent是以包為單位進行異步傳輸?shù)模虼硕嗝襟w數(shù)據(jù)在傳輸中要被分解成許多包，由于網(wǎng)絡傳輸?shù)牟环€(wěn)定性，各個包選擇的路由不同，所以到達客戶端的時間次序可能發(fā)生改變，甚至產(chǎn)生丟包的現(xiàn)象．為此，必須采用緩存技術來糾正由于數(shù)據(jù)到達次序發(fā)生改變而產(chǎn)生的混亂狀況，利用緩存對到達的數(shù)據(jù)包進行正確排序，從而使視音頻數(shù)據(jù)能連續(xù)正確地播放．緩存　中存儲的是某一段時間內(nèi)的數(shù)據(jù)，數(shù)據(jù)在緩存中存放的時間是暫時的，緩存中的數(shù)據(jù)也是動態(tài)的，不斷更新的．流媒體在播放時不斷讀取緩存中的數(shù)據(jù)進行播放，播放完后該數(shù)據(jù)便被立即清除，新的數(shù)據(jù)將存入到緩存中．因此，在播放流媒體文件時并不需占用太大的緩存空間。

　?。?）流媒體播放方面需解決的問題

　　流媒體播放需要瀏覽器的支持，通常情況下，瀏覽器是采用mime來識別各種不同的簡單文件格式，所有的web瀏覽器都是基于http協(xié)議，而http協(xié)議都內(nèi)建有mime．所以web瀏覽器能夠通過http協(xié)議中內(nèi)建的mime來標記web上眾多的多媒體文件格式，包括各種流媒體格式。