架設流媒體的一些文章（1）

一、前言

隨著越來越多的朋友開始選擇ADSL、Cable Modem或FTTB+ LAN作為首要的上網方式，寬頻時代即將到來，這使我們“寬頻 KTV、影音聊天室、線上電影院、遠程教育”的夢想即將成為現實，而與其密切相關的“流媒體(Streaming Media)”也成了許多人談論的熱門話題，因為“流媒體”正是實現這些寬頻應用的技術動力。

寬頻時代的到來還使得網民們不再滿足於僅僅作為一項服務的受眾，他們需要更大規模的交流，從中體現個體的價值，因此，許多朋友開始用自己的電腦，搭建網路廣播和點播網站。他們充滿著滿腔的熱情，但不可否認的是，中國網民先天技術上的不足，讓他們在建設這樣的網站時遇到重重險阻，以至於放棄。如何將這種熱情在技術的引導下成為動力，這正是我們家用電腦所要做的，所以，在今天，在這裡，我就將給大家介紹如何打造屬於自己的流媒體伺服器。

不過，在開始正式的流媒體伺服器架設之前，請讓我們先瞭解一下流媒體伺服器的基礎知識。

二、流媒體基礎知識

什麼是流媒體？

目前，在網路上傳輸音/視頻等多媒體資訊有兩種解決方案，即http或ftp下載以及串流。

http或ftp下載使用標準的http和ftp協議，但由於多媒體資訊個頭巨大，下載一個多媒體檔案一般需要幾分鐘或幾小時的時間，這就造成為了看一個並不知道內容的視頻，首先需要耗費可能比整個視頻都要長的時間來完成下載。這些被下載的檔案還必須在下載前製作完成，放在網路伺服器上，這樣造成的直接後果就是：網路頻寬不斷提高，人們下載的等待時間越來越少，但最終還是不能觀看網上現場直播。

串流時，聲音、影像或動畫等多媒體資訊由流媒體伺服器向使用者電腦連續、即時傳送，它首先在使用者端的電腦上建立一個緩衝區，於播放前預先下載一段資料作為緩衝，使用者不必等到整個檔案全部下載完畢，而只需經過幾秒或十數秒的啟動延時即可進行觀看。當多媒體資訊在客戶機上播放時，檔案的剩餘部分將在後台從伺服器內繼續下載。如果網路連接速度小於播放的多媒體資訊需要的速度時，播放程式就會取用先前建立的一小段緩衝區內的資料，避免播放的中斷，使得播放品質得以維持。

串流除了能夠發送已經製作完成的檔案外，還可以通過採集伺服器即時採集現場音視頻，推送到流媒體伺服器端，即時提供給使用者。因此，流媒體除了能夠更好的承擔如下載一樣的多媒體點播服務外，更能夠應用在現場直播、電視轉播、突發事件報道等多種對即時性傳輸要求較高的領域。

有關流媒體的廠商

流媒體的市場巨大，世界上許多優秀的廠商都加入此行列，現階段更是系統整合商競爭的風水寶地。而在通用市場上，競爭的公司主要有三個：Microsoft、RealNetworks、Apple，而相應的產品就是：Windows Media、Real Media、QuickTime。而近來，以開發Winamp著名的Nullsoft公司也在自己的MP3伺服器中加入了視頻支援，欲在流媒體市場分一杯羹。

由於Apple的伺服器和編輯軟體一般都以Mac為操作平台，Nullsoft的流媒體伺服器屬於新生不成熟事務，所以今天在這裡我主要給大家介紹一下Microsoft和RealNetworks的產品。

流媒體的傳輸協議

大家在觀看網上電影或者電視時，一般都會注意到這些檔案的串連都不是用http或者ftp開頭，而是一些rtsp或者mms開頭的東西，為什麼是這樣呢？實際上，這些和http和ftp一樣，都是資料在網路上傳輸的協議，只是它們是專門用來傳輸串流式媒體的協議而已。下面，讓我們來看一下現在使用的主要的流媒體協議：

1. RTSP（Real Time Streaming Protocol），即時資料流媒體協議，它是由RealNetworks和Netscape共同提出的，現在用於RealNetworks的Real Media產品中；

2. PNM（Progressive Networks Audio），這也是Real專用的即時傳輸協議，它一般採用UDP協議，並佔用7070連接埠，但當你的伺服器在防火牆內且7070連接埠被擋，且你的伺服器把SmartingNetwork設為真時，則採用http協議，並佔用預設的80連接埠；

3. MMS（Microsoft Media Server protocol），這是微軟的流媒體伺服器協議，MMS 是串連 Windows Media 單播服務的預設方法。

介紹了主要的三個，可能您還會問，Apple的QuickTime使用哪種協議呢？在多數情況下，QuickTime使用http協議，但實際上它也由標準的流媒體傳輸協議，這就是標準RTSP協議，而Real公司使用的RTSP是自己經過開發的。

在流媒體傳輸中，標準的協議就是RTP（Real time Transport Protocol，即時傳輸協議）、RTCP(Real-time Transport Control Protocol，即時傳輸控制通訊協定)、RTSP（Real Time Streaming Protocol，即時資料流媒體協議）和RSVP（Resource Reserve Protocol, 資源預訂協議），廠商們的產品都是在這些協議的基礎上進行研究與開發，限於篇幅，在這裡我們就不再深入討論了。

流媒體檔案和發布格式

有了即時的傳輸協議，我們應該還能夠想到，只有較小的檔案才適合網路即時傳輸，那麼，流媒體檔案採用了什麼樣的壓縮演算法呢？

而使用Windows作業系統的朋友可以看到，我們觀看網上流節目時，它們的尾碼名一般是rm、asf、wmv等，這些就是流媒體的格式。流媒體檔案格式經過特殊編碼，不僅採用較高的壓縮比，還加入了許多控制資訊，使其適合在網路上邊下載邊播放，而不是等到下載完整個檔案才能播放。

常見的流媒體格式大致有以下幾種：

流媒體檔案格式擴充(Video/Audio) 媒體類型與名稱
asf 　　　　　　　　　　　　　　Advanced Streaming format. (Microsoft).
rm　　　　　　　　　　　　　　　Real Video/Audio 檔案 (Progressive Networks).
ra　　　　　　　　　　　　　　　Real Audio 檔案 (Progressive Networks).
rp　　　　　　　　　　　　　　　Real Pix 檔案 (Progressive Networks).
rt　　　　　　　　　　　　　　　Real Text 檔案 (Progressive Networks).
swf 　　　　　　　　　　　　　　Shock Wave Flash (Macromedia).
mov 　　　　　　　　　　　　　　QuickTime（Apple公司格式）
viv 　　　　　　　　　　　　　　Vivo Movie 檔案(Vivo Software).

另外還有一個wmv格式，是Windows Media Video的簡稱，它與asf檔案有稍許區別，wmv一般採用window media video/audio 格式，asf視頻部分一般採用Microsoft MPG4 V(3/2/1?)，音頻部分是windows media audio v2/1，不過現在很多製作軟體都沒有把它們分開，所以直接更改尾碼名就能夠互相轉換為對方格式。

製作完成的流媒體檔案需要發布到網路上才能夠被別人使用，這就需要以特定方式安排壓縮好的流媒體檔案，而安排流媒體檔案的格式就被成為流媒體發布格式。常見的發布格式主要有以下幾種：

流媒體發布格式擴充 媒體類型和名稱

asf　　　　　　　　Advanced Streaming format.
smil　　　　　　　 Synchronised Multimedia Integration Language.
ram　　　　　　　　RAM File.
rpm　　　　　　　　Embedded RAM File.
asx　　　　　　　　ASF Stream Redirector/ASF流轉向器檔案
xml　　　　　　　　eXtensible Markup Language

MPEG-4與流媒體

說到流媒體就不能不提及MPEG-4。MPEG-4是當前討論的焦點之一，只因為它能夠在大的壓縮比下實現近似DVD品質的視頻和音頻效果，這也是許多朋友認為MPEG-4格式肯定比rm清晰的原因。但事實上並不是如此，MPEG-4隻是一種視頻編碼技術，它的清晰度也根據壓縮時所選擇的碼率的不同有較大的改變（我們見到的MPEG-4格式檔案通常為500Kbps壓縮產生，品質當然高了），並且，MPEG-4還有多種壓縮標準，如Microsoft的asf視頻部分就是基於MPEG-4的Discrete Cosine Transform (DCT)，另外還有DivX的免費MPEG-4版本（開始是破解微軟的格式而來）。至於音頻部分，更是混亂，Microsoft採用windows media audio v2/1，DivX採用MP3或者更高品質的AC3等。相比而言，Real或者Apple的格式使用的是自己開發的編碼，在相同碼率，特別是低碼率下，不見得就比MPEG-4差，採取高碼率的rm格式照樣清晰可人，所以大家以後說rm格式清晰度差的觀念要改變一下：），至少也要加上條件。而且，最新的Helix Producer中的Real Video 9採用VP5壓縮格式進行編碼，這可比DivX優秀多了！

不過，流媒體伺服器開始向MPEG-4格式靠攏是不爭的事實，Real最新的Helix就開始支援mp4格式檔案的服務，而RealOne Player更是只需安裝一個外掛程式便可實現MPEG-4格式的播放。

點播與廣播

在架設流媒體伺服器之前，我們一定要瞭解一些點播與廣播的知識。

點播是用戶端與伺服器之間的主動的串連，在點播串連中，使用者通過選擇內容項目來初始化用戶端串連，一個用戶端從伺服器接收一個媒體流（這個串連是唯一的，其它使用者不能佔用），並且能夠對媒體進行開始、停止、後退、快進或暫停等操作，用戶端擁有流的控制權，就像在看影碟一樣。這種方式由於每個用戶端各自串連伺服器，伺服器需要給每個使用者建立串連，對伺服器資源和網路頻寬的需求都比較大。

廣播指的是使用者被動接收流。在廣播過程中，用戶端接收流，但不能控制流程，使用者不能暫停、快進或後退該流，廣播使用的資料發送手段有單播與廣播。使用單播發送時，伺服器需要將資料包複製多個拷貝，以多個點對點的方式分別發送到需要它的那些使用者，而使用廣播方式發送，資料包的單獨一個拷貝將發送給網路上的所有使用者，而不管使用者是否需要，上述兩種傳輸方式會非常浪費網路頻寬和伺服器資源，因此產生了組播（多播）技術。

組播（多播）吸收了上述兩種發送方式的長處，克服了上述兩種發送方式的弱點，將資料包的單獨一個拷貝發送給需要的那些客戶，組播不會複製資料包的多個拷貝傳輸到網路上，也不會將資料包發送給不需要它的那些客戶，保證了網路上多媒體應用佔用網路的最小頻寬。但組播不僅需要伺服器端支援，更需要有多播路由器乃至整個網路結構的支援。

單播與組播（多播）

在上面我們已經瞭解了一些單播和組播的概念，這也是現在流媒體方面討論的焦點之一。以我的認識，點播與廣播是一組概念，它們和用戶端媒體互動的手段；單播和組播又是另外一組概念，它們是流媒體資料在伺服器端和網路上的傳輸方式。

單播發送時，需要在用戶端與媒體伺服器之間需要建立一個單獨的資料通道，從一台伺服器送出的每個資料包只能傳送給一個客戶機，每個使用者必須分別對媒體伺服器發送單獨的查詢，而伺服器必須向每個使用者發送所申請的資料包拷貝。這種巨大冗餘會造成伺服器沉重和網路頻寬的沉重負擔，響應需要很長時間，甚至出現不能服務的情況。單播可以用在點播和廣播上。

組播發送時，伺服器將一組客戶請求的流媒體資料發送到支援組播技術的路由器上，然後由路由器一次將資料包根據路由表複製到多個通道上，再向使用者發送。這時候，媒體伺服器只需要發送一個資訊包，所有發出請求的用戶端都共用同一資訊包，並且資訊可以發送到任意地址的客戶機，沒有請求的客戶機不會收到資訊包，網路上傳輸的資訊包的總量沒有廣播那麼多，大大提高了伺服器和網路線路的利用率。不過組播也有自己的特點，首先是必須要開始支援組播技術的路由器，另外就是一般只能用作廣播，因為用作點播會存在使用者控制問題。

好了，說了這麼多，您可能都嫌我煩了，那麼，就讓我們開始架設流媒體伺服器之旅吧。