【51CTO獨(dú)家特稿】51CTO.com作為中國最大的中文IT技術(shù)網(wǎng)站，為便于一些免費(fèi)技術(shù)講座和沙龍活動視頻發(fā)布，技術(shù)部門和編輯部決定采用視頻直播的方式與更多的網(wǎng)友分享，那么如何才能滿足這樣的視頻直播需求呢？

需求分析

首先，對于51CTO門戶網(wǎng)站上搭建視頻直播的應(yīng)用，需要將音視頻信號實時編碼處理發(fā)送給流媒體服務(wù)器，由流媒體服務(wù)器提供直播、點(diǎn)播服務(wù)，而考慮到易用性方面，首要的要求就是客戶端不用下載專用播放器，采用操作系統(tǒng)中Windows Media Player便可觀看直播服務(wù)。

其次，直播服務(wù)器用于對視音頻節(jié)目要支持編碼設(shè)置、錄制播放時間表制定的管理，播出后的節(jié)目內(nèi)容上載管理，要支持直播編碼器的選擇控制管理，用戶的權(quán)限管理。另外，不但可將現(xiàn)場音視頻信號進(jìn)行網(wǎng)上直播，還要同時還可錄制正在直播的節(jié)目。“最最最”重要的一點(diǎn)，是要在直播的時候支持一些后續(xù)活動的預(yù)告片的播放。

如果你閱讀了前面幾篇Media Services的內(nèi)容，你一定相信“Windows Media Services 2008 + Windows Media encoder編碼器”可以勝任這個平臺吧？沒錯！看來我們唯一要分析的就是“組播”和“插播預(yù)告”了。

技術(shù)分析

IP組播，英語原文IP Multicast ，也可譯為“成組通信”。下面來看一下這個特殊的協(xié)議，我們知道IPv4定義了3種IP數(shù)據(jù)通信方式：點(diǎn)點(diǎn)通信、全網(wǎng)廣播、組播。點(diǎn)點(diǎn)通信是指兩個IP地址間進(jìn)行的數(shù)據(jù)通信，而全網(wǎng)廣播是指在IP子網(wǎng)內(nèi)向所有網(wǎng)內(nèi)IP地址以廣播的方式發(fā)送數(shù)據(jù)包，所有子網(wǎng)內(nèi)的IP站都能收到全網(wǎng)廣播，那么組播就是指在IP網(wǎng)上對一組特定IP地址進(jìn)行數(shù)據(jù)傳送，是居于前兩者之間的通信方式。多媒體視頻流對數(shù)據(jù)可靠性要求不高，適當(dāng)?shù)臄?shù)據(jù)丟失不會過多影響視頻播出的實際效果。雖然多媒體視頻流對網(wǎng)絡(luò)傳輸延時和抖動比較敏感，而IP組播在網(wǎng)絡(luò)中延時與抖動是很少的，所以用IP成組通信來傳輸IP視頻信號是可行的。

在一個單播（Unicast）環(huán)境里，視頻服務(wù)器依次送出 n 個信息流，由網(wǎng)絡(luò)中的用戶接收，共需要 n x 1.5Mbit/s 的帶寬；如果服務(wù)器處于 10Mbit/s 的以太網(wǎng)內(nèi)， 6~7 個信息流就占滿了帶寬；若在一個高速的以太網(wǎng)里，最多只能容納 250~300 個 1.5Mbit/s 的視頻流，所以服務(wù)器與主機(jī)接口間的容量是一個巨大的瓶頸。

而在一個組播（ Multicast ）環(huán)境里，不論網(wǎng)絡(luò)中的用戶數(shù)目有多少，服務(wù)器發(fā)出的一個視頻流，由網(wǎng)絡(luò)中的路由器或交換器同時復(fù)制出 n 個視頻流，廣播到每個用戶，僅需 1.5Mbit/s 的帶寬。 可見， IP 組播能夠有效地節(jié)省網(wǎng)絡(luò)帶寬和資源，管理網(wǎng)絡(luò)的增容和控制開銷，大大減輕發(fā)送服務(wù)器的負(fù)荷，從而高性能地發(fā)送信息。

另外，組播傳送的信息能同時到達(dá)用戶端，時延小，并且網(wǎng)絡(luò)中的服務(wù)器不需要知道每個客戶機(jī)的地址。所有的接收者使用一個網(wǎng)絡(luò)組播地址，可實現(xiàn)匿名服務(wù)，并且 IP 組播具有可升級性，與新的 IP 和業(yè)務(wù)能相兼容。

另外，要在網(wǎng)絡(luò)上實現(xiàn)組播應(yīng)用，必須要有相應(yīng)組播設(shè)備和協(xié)議的支持。按照組播協(xié)議的分類，在三層的組播協(xié)議主要有DVMRP、PIM和IGMP等，而在二層的組播協(xié)議主要用CGMP(Cisco Group Management Protocol)和IGMP監(jiān)聽。三層組播協(xié)議主要用于組播信息的轉(zhuǎn)發(fā)，二層組播協(xié)議主要用于抑制局域網(wǎng)上多余的組播信息。在路由器及多層交換機(jī)上一般實現(xiàn)三層的組播協(xié)議，而在不具備多層交換的交換機(jī)上一般只能實現(xiàn)二層組播協(xié)議。

舉一個例子，我們假設(shè)51CTO內(nèi)部網(wǎng)絡(luò)的設(shè)備都支持組播管理，如果要實現(xiàn)基于Media Server的組播，不但要在Media Server上進(jìn)行配置，還需要在交換機(jī)啟動路由協(xié)議PIM，以及啟動CGMP協(xié)議。例如啟用組播路由需要執(zhí)行在全局模式下配置ip multicast-routing啟用組播路由：Switch(config)# ip multicast-routing ，然后再接口配置模式下配置ip pim dense-mode/sparse-mode/sparse-dense-mode，例如Switch(config-if)# ip pim dense-mode 。

搭建組播平臺要求組播源和組播組成員及其兩者之間的底層網(wǎng)絡(luò)都必須支持組播，我們來看一下實現(xiàn)組播的必要條件：

主機(jī)的TCP/IP支持發(fā)送和接收IP組播數(shù)據(jù)包；

主機(jī)的網(wǎng)卡支持組播；

有一套用于管理成員加入、離開和查詢組成員的組管理協(xié)議，如Internet組管理協(xié)議(IGMP)；

有一套IP組播地址分配策略，并能將IP組播地址映射到組播MAC地址；

有支持IP組播的應(yīng)用軟件；

所有介于組播源和組播組成員之間的路由器、交換機(jī)、TCP/IP協(xié)議棧、防火墻等均須支持組播。

針對這個案例，我們看到一個比較難搞定的問題，這就是51CTO的技術(shù)人員無法控制所有收看客戶端的網(wǎng)絡(luò)設(shè)備，因此實現(xiàn)廣域網(wǎng)環(huán)境下的組播幾乎是不可能的，但如果是在內(nèi)網(wǎng)環(huán)境下實現(xiàn)組播還是可行的。很遺憾，我們只能選擇單播技術(shù)作為直播發(fā)布的屬性。

廣告和插播技術(shù)分析

下面來看看關(guān)于預(yù)告片的需求，其實這說起來就等同于廣告。Windows Media Services 為預(yù)先錄制的內(nèi)容和直播內(nèi)容提供了多個廣告選項供我們選擇：

包裝廣告：在用戶查看直播內(nèi)容之前、之后播放的流廣告。

插播廣告：隨內(nèi)容一起插入在播放列表中的流廣告。你必須通過播放列表來使用插播廣告。

橫幅廣告：顯示在播放機(jī)上的與流內(nèi)容無關(guān)的靜態(tài)或多媒體廣告。

當(dāng)然，光有廣告還不行，我們還可以使用策略來控制用戶接收廣告內(nèi)容的方式。這包括：定義事件和控制播放列表的屬性。對于事件來說，我們可以使用某個事件來觸發(fā)到特定廣告的切換。例如，在實時廣播中，可以使用某個事件在區(qū)域性廣告中插入本地廣告，反之亦然。而對于播放列表屬性，則可以配置播放列表屬性以控制用戶對廣告的體驗。例如，如果將 noSkip 屬性設(shè)置為 True，則用戶播放器上的快進(jìn)和搜索控制會被禁用。若要使用戶繼續(xù)接收播放列表中的內(nèi)容，必須播放完廣告。

針對本案例中的直播項目，Media Services采用包裝廣告是最為適宜的，因為無論用戶在哪個點(diǎn)加入廣播，包裝廣告都會播放，用戶都會看到預(yù)告片的內(nèi)容，包裝廣告是理想之選。

【51CTO獨(dú)家特稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處?！?/p>

【編輯推薦】

1. Media Services管理工具的使用方式與錯誤解決
2. Media Services服務(wù)器部署與流媒體應(yīng)用