微軟Media Services助力技術沙龍現場直播
原創【51CTO獨家特稿】51CTO.com作為中國最大的中文IT技術網站，為便于一些免費技術講座和沙龍活動視頻發布，技術部門和編輯部決定采用視頻直播的方式與更多的網友分享，那么如何才能滿足這樣的視頻直播需求呢？
需求分析
首先，對于51CTO門戶網站上搭建視頻直播的應用，需要將音視頻信號實時編碼處理發送給流媒體服務器，由流媒體服務器提供直播、點播服務，而考慮到易用性方面，首要的要求就是客戶端不用下載專用播放器，采用操作系統中Windows Media Player便可觀看直播服務。
其次，直播服務器用于對視音頻節目要支持編碼設置、錄制播放時間表制定的管理，播出后的節目內容上載管理，要支持直播編碼器的選擇控制管理，用戶的權限管理。另外，不但可將現場音視頻信號進行網上直播，還要同時還可錄制正在直播的節目。“最最最”重要的一點，是要在直播的時候支持一些后續活動的預告片的播放。
如果你閱讀了前面幾篇Media Services的內容，你一定相信“Windows Media Services 2008 + Windows Media encoder編碼器”可以勝任這個平臺吧？沒錯！看來我們唯一要分析的就是“組播”和“插播預告”了。
技術分析
IP組播，英語原文IP Multicast ，也可譯為“成組通信”。下面來看一下這個特殊的協議，我們知道IPv4定義了3種IP數據通信方式：點點通信、全網廣播、組播。點點通信是指兩個IP地址間進行的數據通信，而全網廣播是指在IP子網內向所有網內IP地址以廣播的方式發送數據包，所有子網內的IP站都能收到全網廣播，那么組播就是指在IP網上對一組特定IP地址進行數據傳送，是居于前兩者之間的通信方式。多媒體視頻流對數據可靠性要求不高，適當的數據丟失不會過多影響視頻播出的實際效果。雖然多媒體視頻流對網絡傳輸延時和抖動比較敏感，而IP組播在網絡中延時與抖動是很少的，所以用IP成組通信來傳輸IP視頻信號是可行的。
在一個單播（Unicast）環境里，視頻服務器依次送出 n 個信息流，由網絡中的用戶接收，共需要 n x 1.5Mbit/s 的帶寬；如果服務器處于 10Mbit/s 的以太網內， 6~7 個信息流就占滿了帶寬；若在一個高速的以太網里，最多只能容納 250~300 個 1.5Mbit/s 的視頻流，所以服務器與主機接口間的容量是一個巨大的瓶頸。
而在一個組播（ Multicast ）環境里，不論網絡中的用戶數目有多少，服務器發出的一個視頻流，由網絡中的路由器或交換器同時復制出 n 個視頻流，廣播到每個用戶，僅需 1.5Mbit/s 的帶寬。 可見， IP 組播能夠有效地節省網絡帶寬和資源，管理網絡的增容和控制開銷，大大減輕發送服務器的負荷，從而高性能地發送信息。
另外，組播傳送的信息能同時到達用戶端，時延小，并且網絡中的服務器不需要知道每個客戶機的地址。所有的接收者使用一個網絡組播地址，可實現匿名服務，并且 IP 組播具有可升級性，與新的 IP 和業務能相兼容。
另外，要在網絡上實現組播應用，必須要有相應組播設備和協議的支持。按照組播協議的分類，在三層的組播協議主要有DVMRP、PIM和IGMP等，而在二層的組播協議主要用CGMP(Cisco Group Management Protocol)和IGMP監聽。三層組播協議主要用于組播信息的轉發，二層組播協議主要用于抑制局域網上多余的組播信息。在路由器及多層交換機上一般實現三層的組播協議，而在不具備多層交換的交換機上一般只能實現二層組播協議。
舉一個例子，我們假設51CTO內部網絡的設備都支持組播管理，如果要實現基于Media Server的組播，不但要在Media Server上進行配置，還需要在交換機啟動路由協議PIM，以及啟動CGMP協議。例如啟用組播路由需要執行在全局模式下配置ip multicast-routing啟用組播路由：Switch(config)# ip multicast-routing ，然后再接口配置模式下配置ip pim dense-mode/sparse-mode/sparse-dense-mode，例如Switch(config-if)# ip pim dense-mode 。
搭建組播平臺要求組播源和組播組成員及其兩者之間的底層網絡都必須支持組播，我們來看一下實現組播的必要條件：
主機的TCP/IP支持發送和接收IP組播數據包；
主機的網卡支持組播；
有一套用于管理成員加入、離開和查詢組成員的組管理協議，如Internet組管理協議(IGMP)；
有一套IP組播地址分配策略，并能將IP組播地址映射到組播MAC地址；
有支持IP組播的應用軟件；
所有介于組播源和組播組成員之間的路由器、交換機、TCP/IP協議棧、防火墻等均須支持組播。
針對這個案例，我們看到一個比較難搞定的問題，這就是51CTO的技術人員無法控制所有收看客戶端的網絡設備，因此實現廣域網環境下的組播幾乎是不可能的，但如果是在內網環境下實現組播還是可行的。很遺憾，我們只能選擇單播技術作為直播發布的屬性。
廣告和插播技術分析
下面來看看關于預告片的需求，其實這說起來就等同于廣告。Windows Media Services 為預先錄制的內容和直播內容提供了多個廣告選項供我們選擇：
包裝廣告：在用戶查看直播內容之前、之后播放的流廣告。
插播廣告：隨內容一起插入在播放列表中的流廣告。你必須通過播放列表來使用插播廣告。
橫幅廣告：顯示在播放機上的與流內容無關的靜態或多媒體廣告。
當然，光有廣告還不行，我們還可以使用策略來控制用戶接收廣告內容的方式。這包括：定義事件和控制播放列表的屬性。對于事件來說，我們可以使用某個事件來觸發到特定廣告的切換。例如，在實時廣播中，可以使用某個事件在區域性廣告中插入本地廣告，反之亦然。而對于播放列表屬性，則可以配置播放列表屬性以控制用戶對廣告的體驗。例如，如果將 noSkip 屬性設置為 True，則用戶播放器上的快進和搜索控制會被禁用。若要使用戶繼續接收播放列表中的內容，必須播放完廣告。
針對本案例中的直播項目，Media Services采用包裝廣告是最為適宜的，因為無論用戶在哪個點加入廣播，包裝廣告都會播放，用戶都會看到預告片的內容，包裝廣告是理想之選。
【51CTO獨家特稿，合作站點轉載請注明原文譯者和出處。】
【編輯推薦】
