流媒體

流式傳輸是實現流媒體的關鍵技術。

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

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

流式傳輸定義很廣泛，主要指通過網路傳送媒體（如視頻、音頻）的技術總稱。其特定含義為通過Internet 將影視節目傳送到PC機。實現流式傳輸有兩種方法：實時流式傳輸（Real time streaming）和順序流式傳輸（progressive streaming）順序流式傳輸是順序下載，在傳輸期間不根據用戶連接的速度對下載順序做調整。實時流式傳輸指保證媒體信號帶寬與網路連接匹配，使媒體可被實時觀看到。實時流式傳輸根據網路情況調整輸出音視頻的質量從而實現媒體的持續的實時傳送，用戶可快進或後退以觀看前面或後面的內容。

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

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

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

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

2、伺服器：由流媒體軟體系統的伺服器部分和一台硬體伺服器組成。這部分負責管理、存儲、分發編碼器傳上來的流媒體節目。

3、終端播放器，也叫解碼器: 這部分由流媒體系統的播放軟體和一台普通PC組成，用它來播放用戶想要收看的流媒體伺服器上的視頻節目。

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

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

需要說明的是，在流式傳輸中，使用RTP/UDP和RTSP/TCP兩種不同的通信協議與A/V伺服器建立聯繫，是為了能夠把伺服器的輸出重定向到一個不同於運行A/VHelper程序所在客戶機的目的地址。實現流式傳輸一般都需要專用伺服器和播放器，其基本原理如圖所示。

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

針對軟體、設備和數據傳輸速度上的差別，用戶以不同帶寬瀏覽音視頻內容。為滿足客戶要求，Progressive networks公司編碼、記錄不同速率下媒體數據，並保存在單一文件中，此文件稱為智能流文件，即創建可擴展流式文件。當客戶端發出請求，它將其帶寬容量傳給伺服器，媒體伺服器根據客戶帶寬將智能流文件相應部分傳送給用戶。以此方式，用戶可看到最可能的優質傳輸，製作人員只需要壓縮一次，管理員也只需要維護單一文件，而媒體伺服器根據所得帶寬自動切換。智能流通過描述I現實世界Internet上變化的帶寬特點來發送高質量媒體並保證可靠性，並對混合連接環境的內容授權提供了解決方法。流媒體實現方式如下： * 對所有連接速率環境創建一個文件 * 在混合環境下以不同速率傳送媒體 * 根據網路變化，無縫切換到其它速率 *關鍵幀優先，音頻比部分幀數據重要 *向後兼容老版本RealPlayer

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

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

RA：實時聲音

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

RT：實時文本

RP：實時圖像

SMIL：同步的多重數據類型綜合設計文件

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

RPM：HTML文件的插件

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

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

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

1、realnetwork公司：三種

2、apple公司：quicktime\mov

3、microsoft公司

（1）asf\wmv\wma

（2）avi

（3）mpeg\mpg\dat

4、micromedia公司

（1）flash的swf格式

（2）metastream的mts格式

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

1、RSVP：資源預留協議

2、RTP：實時傳輸協議

3、RTCP：實時傳輸控制協議

4、MMS：微軟流媒體服務協議

5、RTSP：實時流傳輸協議

6、MIME：多目網際網路電子郵件擴展協議

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

8、RTMFP：Adobe實施消息流協議（P2P協議）

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

IP組播技術構建一種具有組播能力的網路，允許路由器一次將數據包複製到多個通道上。採用組播方式，單台伺服器能夠對幾十萬台客戶機同時發送連續數據流而無延時。媒體伺服器只需要發送一個信息包，而不是多個；所有發出請求的客戶端共享同一信息包。信息可以發送到任意地址的客戶機，減少網路上傳輸的信息包的總量。網路利用效率大大提高，成本大為下降。

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

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

網際網路的迅猛發展和普及為流媒體業務發展提供了強大市場動力，流媒體業務正變得日益流行。流媒體技術廣泛用於多媒體新聞發布、在線直播、網路廣告、電子商務、視頻點播、遠程教育、遠程醫療、網路電台、實時視頻會議等網際網路信息服務的方方面面。流媒體技術的應用將為網路信息交流帶來革命性的變化，對人們的工作和生活將產生深遠的影響。一個完整的流媒體解決方案應是相關軟硬體的完美集成，它大致包括下面幾個方面的內容：內容採集、視音頻捕獲和壓縮編碼、內容編輯、內容存儲和播放、應用伺服器內容管理髮布及用戶管理等。

流媒體技術和聲音信息經過壓縮處理後放上網站伺服器，讓用戶一邊下載一邊觀看、收聽，而不要等整個壓縮文件下載到自己的計算機上才可以觀看的網路傳輸技術。該技術先在使用者端的計算機上創建一個緩衝區，在播放前預先下一段數據作為緩衝，在網路實際連線速度小於播放所耗的速度時，播放程序就會取用一小段緩衝區內的數據，這樣可以避免播放的中斷，也使得播放品質得以保證。

傳輸流程

在流式傳輸的實現方案中，一般採用HTTP/TCP來傳輸控制信息，而用RTP/UDP來傳輸實時聲音數據。具體的傳輸流程如下：

(1)Web瀏覽器與Web伺服器之間使用HTTP/TCP交換控制信息，以便把需要傳輸的實時數據從原始信息中檢索出來。

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

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

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

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

技術方式

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

1.Apple公司的QuickTime

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

2.RealNetworks公司的RealMedia

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

3.Microsoft公司的WindowsMedia

WindowsMedia是三家之中最後進入這個市場的，但憑藉其操作系統的便利很快便取得了較大的市場份額。WindowsMediaVideo採用的是mpeg-4視頻壓縮技術，音頻方面採用的是WindowsMediaAudio技術。WindowsMedia的關鍵核心是MMS協議和ASF數據格式，MMS用於網路傳輸控制，ASF則用於媒體內容和編碼方案的打包。目前WindowsMedia在交互能力方面是三者之中最弱的，自己的ASF格式交互能力不強，除了通過IE支持smil之外就沒有什麼其他的交互能力了。WindowsMedia流媒體技術的實現需要3個軟體的支持，WindowsMedia播放器、WindowsMedia工具和WindowsMedia伺服器。總的來說，如果使用Windows伺服器平台，WindowsMedia的費用最少。雖然在現階段其功能並不是最好，用戶也不是最多。

存在問題

流媒體技術不是一種單一的技術，它是網路技術及視/音頻技術的有機結合。在網路上實現流媒體技術，需要解決流媒體的製作、發布、傳輸及播放等方面的問題，而這些問題則需要利用視音頻技術及網路技術來解決，具體如下：

（1）流媒體製作技術方面解決的問題

在網上進行流媒體傳輸，所傳輸的文件必須製作成適合流媒體傳輸的流媒體格式文件。因為通常格式存儲的多媒體文件容量十分大，若要在現有的窄帶網路上傳輸則需要花費十分長的時間，若遇網路繁忙，還將造成傳輸中斷。另外，通常格式的流媒體也不能按流媒體傳輸協議進行傳輸。因此，對需要進行流媒體格式傳輸的文件應進行預處理，將文件壓縮生成流媒體格式文件。這裡應注意兩點：一是選用適當的壓縮演演算法進行壓縮，這樣生成的文件容量較小。二是需要向文件中添加流式信息。

（2）流媒體傳輸方面需解決的問題

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

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

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

因為interent是以包為單位進行非同步傳輸的，因此多媒體數據在傳輸中要被分解成許多包，由於網路傳輸的不穩定性，各個包選擇的路由不同，所以到達客戶端的時間次序可能發生改變，甚至產生丟包的現象．為此，必須採用緩存技術來糾正由於數據到達次序發生改變而產生的混亂狀況，利用緩存對到達的數據包進行正確排序，從而使視音頻數據能連續正確地播放．緩存　中存儲的是某一段時間內的數據，數據在緩存中存放的時間是暫時的，緩存中的數據也是動態的，不斷更新的．流媒體在播放時不斷讀取緩存中的數據進行播放，播放完后該數據便被立即清除，新的數據將存入到緩存中．因此，在播放流媒體文件時並不需佔用太大的緩存空間．

（4）流媒體播放方面需解決的問題

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

● 網路廣播

● 網上直播