視頻通信RTMFP協議運用綜述

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

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

lRTMFP協議研究

1．1RTMFP工作原理

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

1．2RTMFP優勢

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

1．3RTMFP協議的實現及技術支持

1．3．1組的概念及實現

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

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

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

1．3．3服務端支持

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

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

2．1應用系統設計

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

2．1．2客戶端技術

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

2．1．3客戶端ID共享技術

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

2．2應用系統實現

現將本應系統實現過程上的關鍵部分述如下。

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

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

2．2．2用戶連接

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

2．2．3邀請用戶通話與結束通話

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

2．2．4流的發送與接收

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

2．2．5文本聊天

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

3結語

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