視頻通信RTMFP協(xié)議運用綜述

導語：視頻通信RTMFP協(xié)議運用綜述一文來源于網(wǎng)友上傳，不代表本站觀點，若需要原創(chuàng)文章可咨詢客服老師，歡迎參考。

隨著網(wǎng)絡技術(shù)的發(fā)展，網(wǎng)絡用戶的期望越來越高，對于實時高質(zhì)量視頻通信的需求不斷上升。據(jù)LifeSize公司2011年年的報告顯示，視頻通信在全球的市場規(guī)模已達到2O億美元，并將保持l5％一20％的年增長率逐年攀升，市場前景十分廣闊。然而，基于傳統(tǒng)的媒體流協(xié)議的視頻應用對于網(wǎng)絡帶寬的占用相對較高，從而限制了視頻的清晰程度和傳輸速度。針對該問題，P2P對等網(wǎng)絡技術(shù)的產(chǎn)生為視頻通信的發(fā)展打開了新思路。P2P技術(shù)自產(chǎn)生至今已逾十年，經(jīng)歷了全面的發(fā)展和完善，已在實時交流、視頻點播／直播、文件共享、分布式計算等領域得到了廣泛應用。采用P2P技術(shù)實現(xiàn)視頻通信，將極大地減小運營商的壓力，同時提高用戶的使用體驗。從而，基于P2P對等網(wǎng)絡技術(shù)的視頻通信協(xié)議成為該領域研究的熱點問“。至20l0年12月，AdobeFlashPlayer10的客戶端裝機率已高達到97％。由此可知，F(xiàn)lashPlayer已成為當今使用最為廣泛的播放器之一。Adobe公司在其最新產(chǎn)品FlashPlayer10和AIr1．5中，率先使用了對等協(xié)議聯(lián)網(wǎng)實時媒體流協(xié)議(rtmfp)，并在最新的Flashmediaserver中提供了服務端的支持，使FlashPlayer可以實現(xiàn)應用層組播和P2P功能。這一解決方案，對硬件平臺要求不高，而且具有跨平臺的特性，甚全可以支持移動設備平臺，其優(yōu)勢不言而喻。本文針對這一最新的發(fā)展趨勢，對RTMFP協(xié)議進行深入研究，并給出了該協(xié)議在P2P視頻通信領域的應用原型。

lRTMFP協(xié)議研究

1．1RTMFP工作原理

RTMFP協(xié)議全稱為對等協(xié)議聯(lián)網(wǎng)實時媒體流協(xié)議(Real-TimeMediaFlowProtoco1)。始現(xiàn)于AdobePlayerl0與AIR1．5，并在AdobePlayerl0．1中得到了進一步的完善。該協(xié)議基于UDP(UserDatagramProtoco1)，允許客戶端之間建立點對點的通訊連接，即FlashPlayer用戶之間可以不通過服務器端直接建立連接，從而實現(xiàn)客戶端之間的數(shù)據(jù)傳輸[。其基本工作原理及實現(xiàn)過程描述如下：首先，客戶端在進行直接數(shù)據(jù)傳輸之前，必須連接到AdobeCirrus服務或者支持RTMFP協(xié)議的AdobeFlashMediaServer，以獲得一個惟一的ID，作為客戶端的惟一標識；之后，該客戶端就可以通過UDP流音頻，視頻或者數(shù)據(jù)信息。任何連接到同一服務端的其它客戶端，可以根據(jù)ID直接接收之前客戶端的各種流信息，具體流程如圖1所示。

1．2RTMFP優(yōu)勢

根據(jù)Adobe公司的官方解釋，與RTMFP協(xié)議最為相似的是RTMP協(xié)議，因而本文通過與RTMP協(xié)議的對比來分析RTMFP協(xié)議的優(yōu)點。RTMP協(xié)議全稱是實時消息傳送協(xié)議(RealTimeMessagingProtoco1)，…個專門為傳輸視頻、音頻和數(shù)據(jù)而設計的TCP／IP協(xié)議，最早在FlashPlayer6中。RTMP協(xié)議可以在客戶端與服務端保持一個持久的連接，并允許實時通信。協(xié)議定義了多個可以獨立動作的通道，分別負責不同的功z月~l-,[。根據(jù)客戶端與服務端的連接環(huán)境，RTMP協(xié)議將音視頻等數(shù)據(jù)分割為一定大小的數(shù)據(jù)包，并在數(shù)據(jù)包加入頭部信息，指定數(shù)據(jù)將被傳送到的通道ID，如果有必要的話，還會注明數(shù)據(jù)生成的時間戳，然后進行傳輸，其工作原理如圖2所示。圖2RTMP協(xié)議工作圖相對于基于TCP的RTMP協(xié)議，基于UDP的RTMFP協(xié)議具有以下優(yōu)勢：，①較低的延遲：UDP協(xié)議的實時性明顯要優(yōu)于TCP協(xié)議，在端對端通信中，更低的延遲就意味著更良好的用戶體驗；②P2P的通信：RTMP協(xié)議中，所有客戶端通過FMS傳送數(shù)據(jù)，而RTMFP協(xié)議則允許客戶端之間進行直接的通信，從而進一步減少了通信延遲；③更低的帶寬開銷：顯而易見，端對端的音視頻流直接傳輸，對作為中央服務器的FMS的帶寬占用會更少。另外在FlashPlayer10中，添加了對于Speex音頻編碼的支持，從而在同等通話質(zhì)量的前提下可以實現(xiàn)更高的壓縮率，使用更少的帶寬，同時，Speex編碼方案還有較強的容錯性，在部分數(shù)據(jù)包丟失的情況下仍然可以良好運行，這一特性尤其適用于基于UDP協(xié)議的通信環(huán)境下；④迅速的連接恢復功能：基于RTMFP協(xié)議的網(wǎng)絡連接，可以在斷開后迅速地重建，具有更強大的環(huán)境適應性；⑤允許IP變動：基于RTMFP協(xié)議的網(wǎng)絡會話允許客戶端動態(tài)切換，同時保持會話處于激活狀態(tài)不被打斷。基于以上分析，可見RTMFP協(xié)議在實時媒體流傳輸方面有著巨大的優(yōu)勢，加之客戶端為互聯(lián)網(wǎng)上使用和安裝率最高的FlashPlayer，其發(fā)展及應用前景更加讓人充滿期待。

1．3RTMFP協(xié)議的實現(xiàn)及技術(shù)支持

1．3．1組的概念及實現(xiàn)

在RTMFP協(xié)議里，每一個連接到服務器的客戶端都被當作一個節(jié)點(peer)，多個相互可見的節(jié)點在服務端組成一個組(group)。組內(nèi)同時保存著各成員之間的路由信息，從而使組內(nèi)任意兩節(jié)點之間存在一條直接或間接的連接路徑。而一個新的節(jié)點可以通過自定義代碼處理或者FlashMediaServer自動處理的方式加入一個組。作為客戶端的FlashPlayer，負責與組進行通信，組織和優(yōu)化，以減少延遲，同時維護整個組的連接狀態(tài)。‘組內(nèi)成員可以實現(xiàn)如下功能：①組播通信流：一個或者多個發(fā)送者可以向組中全體成員發(fā)送組播流數(shù)據(jù)；②直接路由信息到某一節(jié)點：③通過對象復制技術(shù)，在組內(nèi)共享對象。

1．3．2AnctionScript3．0中對RTMFP的支持

ActionScript是Flash中的腳本語言，為flash內(nèi)容及應用程序提供強大的交互支持、優(yōu)秀的用戶體驗以及數(shù)據(jù)處理等多種功能。ActionScript代碼通常先被編譯成字節(jié)碼格式，然后嵌入到SWF文件中，由FlashPlayer中的ActionScript虛擬機(AVM)執(zhí)行。ActionScript3．0在原有版本的基礎上進行了全面升級，除了更加符合標準和規(guī)范之外，其使用的新型虛擬機AVM2提升了執(zhí)行的整體效率。與ActionScript密不可分的還有Flex，一個企業(yè)級的富互聯(lián)網(wǎng)應用(RIA)表示層解決方案。另外，在AS3．0中提供了諸多工具類支持基于RTMFP協(xié)議的應用的開發(fā)，例如NetConnection，NetStream，NetGroup，NetGrouplnfo，GroupSpecifier等類。

1．3．3服務端支持

在Adobe的實驗網(wǎng)站上，研發(fā)代號為Cirrus的技術(shù)對使用RTMFP協(xié)議的開發(fā)應用提供了支持【4】。最新版的Cirrus2支持RTMFP組，覆蓋網(wǎng)絡，對象復制等特性。這-N務方便了用戶開發(fā)基于RTMFP的應用，不過需要先向網(wǎng)站申請developerID才能進行測試開發(fā)。目前只支持用戶開發(fā)實現(xiàn)P2P實時通訊的應用。除Cirrus之外，在最新版的FlashMediaServer中，已經(jīng)提供了對RTMFP的支持，用戶可以安裝開發(fā)者版本進行相應的開發(fā)研究。

2應用探索：P2P視頻通信應用

2．1應用系統(tǒng)設計

開發(fā)基于RTMFP協(xié)議的視頻P2P通信應用，需要使用到服務器端和客戶端的相關(guān)技術(shù)。該應用系統(tǒng)。2．1．1服務器端技術(shù)服務器方面，現(xiàn)在有兩種方案可選，一足直接中請developerID使用Adobe官方提供的Cirrus服務，另一種是下載并安裝最新的FlashMediaServer4151，然后創(chuàng)建RTMFP應用。本示例采用Cirrus服務。

2．1．2客戶端技術(shù)

客戶端方面由HTML嵌入SWF實現(xiàn)，要求至少使用FlashPlayerlO，本示例采用1O．3版本，住打開用頁面時，會進行對FlashPIayer插件的檢測，如果／f符合要求則會提示用戶到相應網(wǎng)站升級。正確運行的客戶端中，用戶可以使用自己的用戶名連接服務器，連接成功后，獲得惟一的PeerID；一個成功連接的用戶可以根據(jù)另一個用戶注冊名對相用戶進行視頻電話請求；收到請求的用戶可以選擇接受或者拒絕邀請：在建立連接以后，兩用戶除了進行音視頻通話之外，還可以相互發(fā)送文本信息。

2．1．3客戶端ID共享技術(shù)

客戶端ID管理服務提供客戶合法性驗汪和PeerlD共享功能，通過該服務可以實現(xiàn)客戶端lD的共享，并對末注冊用戶進行蔽。具體的實現(xiàn)方式可以采用ActionScript中的RemoteShare0biect或者其他的WebService實現(xiàn)。本例采用基于Python的cgi實現(xiàn)lD管理的webservice。

2．2應用系統(tǒng)實現(xiàn)

現(xiàn)將本應系統(tǒng)實現(xiàn)過程上的關(guān)鍵部分述如下。

2．2．1客戶端ID管理服務

客戶端ID管理服務采用Python實現(xiàn)，數(shù)據(jù)存儲使用sqlite數(shù)據(jù)庫。建立了一張用戶注冊表，存儲所有活動用戶的信息，表的字段內(nèi)窬包括用戶的用戶名，用戶的ID以及修改時間。該服務提供對用戶ID信息的增、刪、改、查操作，該服務有效地保護了系統(tǒng)用戶的安全，凡是非本系統(tǒng)注冊用戶，均無法查詢到個人的相關(guān)信息，進而也無法與本系統(tǒng)內(nèi)用戶進行通信。具體的實現(xiàn)代碼中，通過判斷請求中附帶的參數(shù)，從而選擇對數(shù)據(jù)庫進行相應的操作，并將操作結(jié)果以XML的形式返回給調(diào)用者，如在進行用戶查詢時，會以如下形式返回結(jié)果，供客戶端解析：<result><user>username<user><identity>id<／identity><registered><／registered><／result>在本系統(tǒng)中，采用ActionScript編寫IdManager類提供ID相關(guān)的增刪改查操作。

2．2．2用戶連接

具體的用戶連接操作，通過ActionScript中的NetConnection類實現(xiàn)。NetConnection類建立服務器與應用程序之間的雙向連接，建立了連接之后，可以NetStream對象通過該連接發(fā)送流，也可以通過NetConnection．call0來對服務端或客戶端的應用進行調(diào)用l6J。NetConnection調(diào)用connect(url，parameters)方法連接服務器時，服務器會調(diào)用application．onConnect來處理該客戶端的請求，如果返回true或者執(zhí)行acceptConnection(client)~,lJ連接成功，返回false或者執(zhí)行rejectConnection《~lient)則拒絕連接，如果返回null或者不返回則將進入未決狀態(tài)。連接過程及可能的狀態(tài)如圖4所示：圖4客戶連接狀態(tài)圖連接成功后，NetConnection對象將獲得nearlD和fID屬性，其中nearlD為客戶端的惟一標識，farlD為服務端相對應的應用實例的標識。在本系統(tǒng)中，用戶進行功能連接之后，會調(diào)用IdManager中的register方法，將用戶名及用戶獲得的nearID插入到lD管理服務中。

2．2．3邀請用戶通話與結(jié)束通話

用戶在成功連接服務器之后，輸入欲聯(lián)系的用戶名稱，點擊Call按鈕，服務器將根據(jù)所邀請的用戶名到客戶端ID管理服務去查詢相應的用戶lD，如果用。戶ID不存在，則邀請失敗；如果成功查詢到用戶ID，則觸發(fā)looupSuccess事件，事件處理中使用netConnection．call0方法，嘗試與相應的用戶lD建立連接。如果對方拒絕邀請，則建立通信失敗；如果對方接受邀請，則建立通信，開始流的發(fā)送與接收。在用戶選擇結(jié)束通話以后，先將用戶名從客戶端ID管理服務注銷，然后分別將用于發(fā)送和接收的NetStream對象的close方法進行關(guān)閉，則兩節(jié)點問的連接關(guān)閉，通話結(jié)束。

2．2．4流的發(fā)送與接收

對于視頻流和音頻流的處理，我們使用NetStream類，該類的實例可以看作是NetConnection對象實例中的一個通道，使用此通道可以通過publish方法流，也可以使用play訂閱其他用戶的流，該流數(shù)據(jù)的內(nèi)容可以是實時的數(shù)據(jù)，也可以以先前錄制好的數(shù)據(jù)文件。在建立基于RTMFP的P2P直連時，可以使用NetStream．DIRECTCONNECT1ONS參數(shù)傳入NetStream的構(gòu)造參數(shù)。同類節(jié)點的連接請求，會通過netstream．client．onPeerConnect方法進行處理，該方法返回true表示與節(jié)點建立連接，否則拒絕連接。具體到發(fā)送視頻和音頻流方面，發(fā)送者通過生成NetStream實例，使用其attach_Audio和atachVideo方法連接本地的視頻和音頻流，然后可以使用punish(“streamname”''''1的方法一個名為streamname包含了音頻和視頻的流。而在接收數(shù)據(jù)流的時候，接收者同時使用NetStream對象，傳入主叫者ID作為構(gòu)造參數(shù)，然后通過play(“streamname”o1方法播放由發(fā)相應ID發(fā)送者的相應名稱流數(shù)據(jù)。最終將該NetStream對象通過Video對象的attachNetStream方法傳入到一個Video實例里，就可以將接收到的音視頻數(shù)據(jù)正常播放。如下圖5：

2．2．5文本聊天

除了音視頻流的處理，還可以進行消息發(fā)送。使用NetStream的send方法，將可以將消息發(fā)送給對方。例如，使用發(fā)送者的發(fā)送流實例，調(diào)用其send方法，傳入接收方消息處理函數(shù)的名稱，以及消息內(nèi)容，如outgoingStream．send("onReceive”，name，text)，那么接收方相應的onReceive函數(shù)就可以接收到name和text，進行顯示和其他相應的處理了。這樣就實現(xiàn)了P2P的文本聊天功能。

3結(jié)語

本文深入研究了Adobe最新的RTMFP協(xié)議的原理、內(nèi)容，及特點，并對其在P2P視頻通信方面的應用進行了初步的探索，最后結(jié)合示例對具體的應用過程進行了說明。研究表明，P2P與FlashPlayer的結(jié)合具有很強的應用前景和市場潛力，有著強大的競爭力。相信今后隨著RTMFP協(xié)議的日漸成熟以及應用范圍的不斷擴大，對于P2P應用領域，特別是音視頻等多媒體內(nèi)容服務，將產(chǎn)生極大的推動作用在企業(yè)級應用中，基于Flash的P2P多媒體協(xié)作系統(tǒng)以其高效率、低成本且跨平臺的特點，將對現(xiàn)有企業(yè)的工作方式產(chǎn)生巨大的影響。