【文章內(nèi)容簡介】 erver我公司 IPTV MediaServerwindows mediaserverFocusVision全球移動運營商市場份額%%%全球?qū)拵б曨l市場份額%%%標準制定者3rd GenerationPartnership Project標準化組織，中國無線microsoft 私有標準FocusVision 私有標準通信標準組(CWTS)Windows NTWindows NT,支持的操作Windows Server。WindowsWindows NT, Windows server平臺FreeBSD。 Linux。 MacServerOS。 Solaris單臺支持并發(fā)數(shù)用戶訪問方式2000電腦 web/手機 wap智能：WindowsMobile、Android、 ophone、電腦 web20002000電腦 web支持手機平臺現(xiàn)在手機支linux、symbian、Palm…非智能手機windowsmobilenokia S60 V3持數(shù)量未來手機支持播放器存在情況1800 款出廠內(nèi)置出廠內(nèi)置realpalyer、VLC、QuickTime Player、200 款出廠內(nèi)置出廠內(nèi)置windows media40 款出廠內(nèi)置出廠內(nèi)置播放器nexpalyer、Pvplayer、 PlayerHTC Streaming player服務(wù)器集群擴展yesyesyes現(xiàn)場直播點播（VOD）RTSP （實時yesyesyesyesyesnoyesyesno12流控制）運行狀況報告服務(wù)運行狀況記錄（LOG）防火墻和代YesYesYesYesYesYes理服務(wù)器支YesYesYes持—碼率音頻格式—2000MbsAMRNB、AMRWB、AAC、MP32000MbsWMA、MP3—2000MbsAAC、MP3視頻格式文件格式文件名后綴實時流協(xié)議、Mpeg43GPP、3GPP2.3gp、.3g.mp4RTSP、RTP、RTCPWMVWMV、WMA.WMV、.WMAMMS私有格式私有格式私有協(xié)議 3GPP標準介紹第三代合作伙伴計劃(3GPP)是由歐洲的 ETSI，日本的 ARIB 和 TTC，韓國的 TTA 以及美國的 T1 共同在 1998 年底發(fā)起成立的 3G 技術(shù)規(guī)范機構(gòu)，旨在研究制定并推廣基于演進的 GSM核心網(wǎng)絡(luò)的 3G 標準，即 WCDMA，TDSCDMA，EDGE 等。目標是實現(xiàn)由 2G 網(wǎng)絡(luò)到 3G 網(wǎng)絡(luò)的平滑過渡，保證未來技術(shù)的后向兼容性，支持輕松建網(wǎng)及系統(tǒng)間的漫游和兼容性。3GPP 系列標準分為以下幾個版本，R99，R4，R5，R6 和 R7，其中 R7 尚未凍結(jié)。這幾個版本的主要差別在于核心網(wǎng)的架構(gòu)。R99 的核心網(wǎng)與 GSM/GPRS 基本相同；R4 的核心網(wǎng)中引入了軟交換，實現(xiàn)控制與承載分離；R5 的核心網(wǎng)以 IMS 為主，采用 SIP 協(xié)議進行網(wǎng)元間的通信；R6 的核心網(wǎng)里，IMS 得到了進一步完善，定義了 IMS 與電路交換的網(wǎng)絡(luò)互通，與 IP 的網(wǎng)絡(luò)互通；R7 著眼于加強固定網(wǎng)與移動網(wǎng)的融合，定義了 IMS 對 xDSL 等固定接入方式的支持。從 R4 版本起，3GPP 標準 中包含了終端上能夠支持的音視頻文件格式的定義，由13，一般就稱為 3GP 文件，為手機上的主流音視頻文件格式。不同版本中對于 3GP 文件支持的音視頻編碼器有所不同。我們的無線流媒體平臺支持 3GPP 的 RRR7 版本。 通信協(xié)議描述通訊協(xié)議采用 IETF 標準，RTSP/RTP/RTCP(一)RTSPRTSP 協(xié)議是由 IETF 制訂的媒體會話建立協(xié)議（RFC2326），用于在 IP 網(wǎng)絡(luò)中的兩個網(wǎng)元之間協(xié)商媒體參數(shù)，建立單向的媒體流會話。(二)RTP/RTCPRTP 協(xié)議是由 IETF 制訂的媒體流封包格式協(xié)議（RFC3550），還包括了一系列擴展協(xié)議，定義了各種媒體數(shù)據(jù)的封包格式，包括 、MPEGAMR、DTMF、 等等。RTP 廣泛應用在各種基于 IP 網(wǎng)絡(luò)的多媒體通信系統(tǒng)中。(三)傳輸協(xié)議為了適應各種可能的網(wǎng)絡(luò)應用環(huán)境，流媒體服務(wù)器支持多種傳輸協(xié)議。(四) RTP over UDP采用 UDP 作為 RTP 數(shù)據(jù)包的承載層，是 RTP 協(xié)議 RFC3550 的缺省選項。由于 UDP 無連接，傳輸速度快，比較適合實時媒體數(shù)據(jù)傳輸?shù)囊蟆＿@種傳輸協(xié)議的優(yōu)點在于傳輸效率高，速度快，但缺點是可能產(chǎn)生丟包，并且在存在防火墻或網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）的網(wǎng)絡(luò)環(huán)境中，需要一些輔助的協(xié)議才能夠通過。(五) RTP over RTSP采用 RTSP 協(xié)議所建立的 TCP 連接作為 RTP 數(shù)據(jù)包的承載層，這種傳輸協(xié)議是在 RFC2326中定義的。每個 RTP 數(shù)據(jù)包前面增加標識符’$’以及子信道號，放在同一個 TCP 連接上發(fā)14送出去。這種傳輸協(xié)議主要應用在 UDP 傳輸被防火墻或 NAT 封堵的情況下，只要 RTSP 連接能夠建立，媒體數(shù)據(jù)就可以在 RTSP 連接上傳輸過去。這種傳輸協(xié)議是可靠傳輸，不會產(chǎn)生丟包，但它的效率略低，速度也略慢。(六)RTP over HTTP采用 HTTP 協(xié)議作為 RTP 數(shù)據(jù)包的承載層，這種傳輸協(xié)議尚未標準化，但已被業(yè)內(nèi)廣泛采用。各個廠商所采用的具體協(xié)商參數(shù)以及 包頭格式略有差別。在某些網(wǎng)絡(luò)環(huán)境下，防火墻的設(shè)置封掉了除 80 以外的絕大多數(shù)端口，因此采用 HTTP 協(xié)議作為 RTP 數(shù)據(jù)包的承載層就成為穿越這類防火墻一個常用的解決方案。 流媒體技術(shù)手段(一)事件任務(wù)模型服務(wù)器軟件的內(nèi)核是按照事件任務(wù)模型構(gòu)建的。內(nèi)核所要完成的工作包括對 RTSP 消息的處理，對于 RTP 數(shù)據(jù)包的處理，對于客戶端的管理以及對于網(wǎng)絡(luò)事件的處理等。所有這些工作都被分解成多個小的工作片斷，稱為任務(wù)。每個任務(wù)中不能包含長時間的 IO 阻塞操作，能夠被內(nèi)核迅速處理并返回。每個任務(wù)的啟動是由特定的事件觸發(fā)。每個任務(wù)對象包括兩個主要的函數(shù)接口，Signal 和 Run。當特定事件發(fā)生時，內(nèi)核會調(diào)用 Signal 把事件發(fā)送給任務(wù)線程。而 Run 函數(shù)中是對事件的處理，由任務(wù)線程調(diào)度。(二)線程池調(diào)度模型服務(wù)器的內(nèi)核是基于多線程的。內(nèi)核在啟動后會創(chuàng)建以下幾個線程：llll主線程。主線程的工作是檢查服務(wù)器是否需要關(guān)閉，打印狀態(tài)信息，打印統(tǒng)計信息等。事件線程。事件線程偵聽各類事件的觸發(fā)，并轉(zhuǎn)發(fā)給對應的任務(wù)線程。空閑線程。空閑線程的工作是處理實時性不高或周期性的任務(wù)，比如超時觸發(fā)的任務(wù)，或周期性的數(shù)據(jù)統(tǒng)計等。一個或多個任務(wù)線程。任務(wù)線程的工作是接收來自事件線程的事件，根據(jù)事件的類15型，調(diào)用對應的任務(wù)處理流程，必要時調(diào)用附加模塊的處理流程對事件進行處理。內(nèi)核的主要工作都是在任務(wù)線程中完成的。一般說來，任務(wù)線程的數(shù)量可以按照 CPU的個數(shù)進行配置，由于多個任務(wù)線程是相互獨立的，這樣可以充分利用多處理器平臺的硬件能力。(三)網(wǎng)絡(luò)異步 IO由于流媒體服務(wù)器涉及到大量并發(fā)數(shù)據(jù)流的網(wǎng)絡(luò) IO 操作，因此網(wǎng)絡(luò) IO 架構(gòu)設(shè)計的優(yōu)劣往往成為影響流媒體服務(wù)器性能的最直接因素。網(wǎng)絡(luò) IO 通信模式分為兩種，同步 IO 和異步 IO。同步 IO 是指每次網(wǎng)絡(luò) IO 調(diào)用，都要等到其結(jié)束后才返回，在等待的過程中，當前線程處于阻塞狀態(tài)。一般說來，在同步 IO 模式下，服務(wù)器要與多個客戶端保持通信，就需要為每個客戶端創(chuàng)建一個線程。異步 IO 模式中，網(wǎng)絡(luò) IO 調(diào)用是非阻塞的，可以立即返回。IO 操作的結(jié)果通過輪詢得到。異步 IO 模式下，服務(wù)器要與多個客戶端保持通信，只需要為每個客戶端創(chuàng)建一個上下文結(jié)構(gòu)，而不需要為每個客戶端創(chuàng)建一個線程。在大量客戶端并發(fā)的情況下，異步 IO 的效率明顯高于同步 IO，因為它避免了多個線程之間的頻繁上下文切換。因此，主流的流媒體服務(wù)器都不約而同采用了異步 IO 模式來處理網(wǎng)絡(luò)通信。(四)跨平臺設(shè)計公司流媒體平臺 IPTV Media Server 在設(shè)計之初就堅持跨平臺的設(shè)計理念，將所有與平臺相關(guān)的底層 API 都封裝起來，向上提供統(tǒng)一的調(diào)用接口，使得所有的上層業(yè)務(wù)邏輯都與平臺無關(guān)。IPTV Media Server 能夠支持以下操作系統(tǒng)平臺：lllFreeBSDLinuxWindows 2003/ 2008其中需要做跨平臺封裝的函數(shù)庫主要包括：lll網(wǎng)絡(luò) Socket 相關(guān)函數(shù)調(diào)用線程，互斥鎖，信號量等相關(guān)函數(shù)調(diào)用文件訪問，目錄操作相關(guān)函數(shù)調(diào)用16ll(五)系統(tǒng)時間相關(guān)函數(shù)調(diào)用動態(tài)鏈接庫的加載、釋放等相關(guān)函數(shù)調(diào)用模塊化設(shè)計流媒體服務(wù)平臺采用模塊化設(shè)計，在內(nèi)核中集成了對于各種外圍模塊的支持，非核心的內(nèi)容都可以放在外圍模塊中實現(xiàn)。這種架構(gòu)一方面保證了內(nèi)核的穩(wěn)定，另一方面也帶來了很強的可擴展性。內(nèi)核啟動后，將所有外圍模塊加載進來。這時模塊需要向內(nèi)核注冊它對哪幾類事件感興趣，并完成必要的初始化操作。在特定事件發(fā)生時，內(nèi)核就可以找出需要通知哪些模塊，并調(diào)用這些模塊的函數(shù)接口。模塊的實現(xiàn)可以與內(nèi)核集成在同一個可執(zhí)行文件中，也可以在一個單獨的庫文件中。模塊中可以實現(xiàn)的功能包括但不限于以下幾類：llllllllRTSP 消息的處理RTP 數(shù)據(jù)包的處理寫日志文件訪問權(quán)限控制媒體文件流化統(tǒng)計流量控制調(diào)試 縮略語llllMMSSMSCMPPWAPMultimedia Messaging ServiceShort Message SystemChina Mobile PeertoPeer ProtocolWireless Application Protocol17llllMMSCMMSEMOMTMultimedia Messaging Service CenterMultimedia Messaging Service EnvironmentMobile OriginatedMobile Terminated 技術(shù)方案 平臺邏輯架構(gòu)邏輯結(jié)構(gòu)圖系統(tǒng)架構(gòu)介紹252。252。252。內(nèi)容源：主要是獲取各種直播采集編碼設(shè)備的實時信號，以及現(xiàn)有的視音頻文件，為平臺提供視頻直播和點播業(yè)務(wù)提供內(nèi)容；視頻平臺：主要是負責直播信號源的分發(fā)和轉(zhuǎn)播；視頻文件轉(zhuǎn)碼、點播、視頻分發(fā)等；業(yè)務(wù)管理：主要是對視頻欄目，業(yè)務(wù)頻道等進行審核與管理，對業(yè)務(wù)的運營進行統(tǒng)計管理與分析18252。252。252。252。業(yè)務(wù)門戶：主要是業(yè)務(wù)展示