隨著智能手機、平板電腦的出現(xiàn)，人們能夠更方便地跨時空獲取信息，同時設備的屏幕顯示分辨率也從240像素提高到1040像素，達到全高清分辨率，但手機的屏幕大小是一個重要的瓶頸。將手機的圖片、影音文件傳輸?shù)诫娨暽铣蔀楫斀癖仨毥鉀Q的問題[1],而無線傳輸技術(shù)使這一問題的解決成為可能。WiFi Direct可在無需路由器的的情況下，以點對點實時的形式互聯(lián)，從而傳送不同設備系統(tǒng)中的文件，方便用戶便利地實現(xiàn)文件打印、資源共享和顯示等任務。
1 WiFi Display簡介
    Miracast是WiFi聯(lián)盟對支持WiFi Display功能的設備認證名稱。隨著手機處理功能的提高，多媒體編解碼技術(shù)的完善，具備了解碼高清圖像的能力。但由于手機的便攜性，使得屏幕不可能做到太大，也就無法充分展示視頻圖像的高清效果。如果采用微型投影的方法，將手機作為投影儀，將手機里的圖像投影到墻上，則可以不受物理尺寸的限制。但該方案受到了技術(shù)本身的成熟度以及手機電池等因素的限制。
　    WiFi Display技術(shù)是媒體之間文件共享的業(yè)務，可以方便地將手機上的文件投影到電腦、電視機上。通信中的多個設備分別擔任服務器和客戶機的互動模式，WiFi Display可在沒有連接有線時進行影像無線顯示，方便地享受高畫質(zhì)影像效果。通過壓縮3D視頻，進行WiFi傳輸，數(shù)據(jù)的傳輸率達到300 Mb/s，傳送的影像采用壓縮方式，壓縮/解壓處理采用H.264格式。高通和博通等半導體廠商已經(jīng)發(fā)布了支持WiFi Display的整合芯片組[2]。
2 WiFi Display體系結(jié)構(gòu)
    WiFi Display是一種無需WLAN連接也可在設備間直接通信的標準，底層以WiFi Direct(WiFi直連)為基礎(chǔ)，上層由協(xié)議棧軟件構(gòu)成。設備終端的服務發(fā)現(xiàn)和連接通過WiFi Direct進行處理，管理數(shù)據(jù)流的傳輸層則通過WiFi Display進行處理。
2.1 WiFi Display的主要設備和協(xié)議棧
    WiFi Display主要設備如圖1所示。

2.2 RTP/RTCP協(xié)議
    多媒體數(shù)據(jù)需要將應用層、傳輸層、網(wǎng)絡層的數(shù)據(jù)報文進行封裝，以便傳輸。RTP(Real-time Transport Protocol)是一種應用層傳輸實時數(shù)據(jù)的協(xié)議， RTCP(RTP Control Protocol)的功能是保證媒體數(shù)據(jù)的同步、服務質(zhì)量QoS的監(jiān)視與反饋以及多播組中成員的標識。在RTP會話過程中，設備終端周期性地傳送RTCP數(shù)據(jù)包[3]。RTCP包頭中含有已發(fā)送的數(shù)據(jù)包的數(shù)量及丟失數(shù)據(jù)包的數(shù)量等統(tǒng)計資料。因此，可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。多媒體數(shù)據(jù)在傳輸過程中的封裝格式如圖3所示。

    數(shù)據(jù)接收端保持數(shù)據(jù)同步播放主要依靠如下技術(shù)：
    (1)RTP數(shù)據(jù)報文的數(shù)據(jù)序號用于排序RTP報文分組，以消除重復分組，保持流文件同步并連續(xù)地播放。
    (2)RTP數(shù)據(jù)報文的時戳字段可作為流間同步標識，以保持視頻和音頻流間同步并連續(xù)地播放。
    (3)發(fā)送者可以根據(jù)接收者反饋的RTCP數(shù)據(jù)來實施端到端的強制性同步控制, 改善當前網(wǎng)絡傳輸?shù)姆召|(zhì)量。
3 多屏融合軟件實現(xiàn)
    WiFi Display的軟件實現(xiàn)遵循TCP/IP協(xié)議。物理層采用WiFi協(xié)議，在沒有接入點(AP)的情況下采用WiFi Direct協(xié)議；網(wǎng)絡層采用IP協(xié)議，在傳輸層數(shù)據(jù)傳輸采用UDP協(xié)議。
3.1 WiFi Direct實現(xiàn)
    WiFi Direct是兩個不同設備直連時傳輸數(shù)據(jù)的主要模塊。主要設計如下：模塊WiFiActivity類實現(xiàn)可用設備的發(fā)現(xiàn)和連接及斷開連接，并且顯示設備連接的詳情，應用程序通過創(chuàng)建類BroadcastReceiver的繼承類模塊WiFiBroadcastReceive來通知WiFi的狀態(tài)及事件[4]。模塊WiFiBroadcastReceive類作為一個廣播接收器,監(jiān)聽WiFi Direct事件并把結(jié)果傳遞給模塊WiFiActivity,通過WifiP2pManager類的行為描述函數(shù)來請求可用的節(jié)點,在請求連接成功后獲得組用戶的IP。模塊DeviceList用來實現(xiàn)顯示活動的節(jié)點和狀態(tài)。表示設備的5種狀態(tài)：設備可用（AVAILABLE）、無可用設備（UNAVAILABLE）、設備已邀請（INVITED）、設備已連接（CONNECTED）、設備連接失?。‵AILED）。模塊DeviceDetail用來顯示被選擇設備的細節(jié)，同時進行驅(qū)動設備連接、斷開和數(shù)據(jù)傳輸。當設備連接時，應用程序通過WiFiP2pConfig.deviceAddress函數(shù)獲取設備的地址及WiFiP2pConfig.wps.setup函數(shù)來設置WPS的連接方式。
3.2 屏幕鏡像實現(xiàn)
    手機通過SurfaceFlinger類將各層UI數(shù)據(jù)混屏并投遞到顯示設備中顯示。SurfaceFlinger類支持多個顯示設備，系統(tǒng)定義了一個DisplayType的枚舉類型，其中包括代表手機屏幕的主要顯示設備，代表高精晰度多媒體接口(HDMI)等外接設備的外部顯示設備及以WiFi Display設備定義的虛擬顯示設備。如圖4所示。

    SurfaceFlinger類定義變量保存了系統(tǒng)中當前所有的顯示設備。其中mDrawingState用來控制當前正在繪制的顯示層的狀態(tài)，mCurrentState表示當前所有顯示層的狀態(tài),DisplayDevice表示顯示設備。變量mFrameBufferSurface是FrameBufferSurface類型，若顯示設備不屬于虛擬顯示設備類型，則該變量不為空。顯示數(shù)據(jù)通過網(wǎng)絡傳遞給真正的顯示設備,對于源設備端的SurfaceFlinger來說，不存在FrameBuffer變量。故當設備為虛擬顯示設備時，其對應的變量mFrameBufferSurface則為空。SurfaceFlinger類將遍歷系統(tǒng)中所有的顯示設備，來完成各自的混屏工作，由DisplayManagerService函數(shù)統(tǒng)一管理系統(tǒng)中的顯示設備，WindowManagerService函數(shù)管理系統(tǒng)中每個UI層的位置和屬性。當手機把播放內(nèi)容傳送至遠端設備時,彈出的密碼框就不能投遞到顯示設備上。
3.3 編解碼模塊H.264的優(yōu)化及實現(xiàn)
    編碼模塊主要功能是通過從應用層獲取傳輸流文件，并對其壓縮編碼，將產(chǎn)生的編碼碼流通過客戶端傳輸出去。通過調(diào)用方法SetPreviewcallback(new H264Encoder(int width, int height))實現(xiàn)流文件的編碼。編碼模塊接收到傳遞的參數(shù)width(寬度)和height(高度)時，即可給緩沖區(qū)大小buffer分配width×height字節(jié)。利用BeginEncode(int width, int height)編碼，同時輸出碼流，EndEncode( )編碼結(jié)束。
    解碼模塊的主要功能是實現(xiàn)解碼壓縮流文件。首先要將FFmpeg移植到Android手機中，Init( )和SetFFmpeg( )實現(xiàn)初始化和設置FFmpeg。通過函數(shù)FindStream( )和FindDecoder( )查找音視頻流文件和解碼器。Convert( )實現(xiàn)碼流解碼，如果解碼未結(jié)束，則繼續(xù)執(zhí)行函數(shù)Convert( )，否則關(guān)閉解碼器，釋放資源。
3.4 數(shù)據(jù)傳輸實現(xiàn)

    數(shù)據(jù)封裝主要是在應用層采用RTP協(xié)議封裝，傳輸層采用UDP協(xié)議封裝，網(wǎng)絡層采用IP協(xié)議封裝[5-6]。傳輸時最大傳輸單元為1 500 B，當數(shù)據(jù)大于1 460 B時，采用IP數(shù)據(jù)報分片。
    RTP側(cè)重數(shù)據(jù)傳輸?shù)膶崟r性，此協(xié)議提供的服務包括數(shù)據(jù)順序號、時間標記、傳輸控制等。RTCP與RTP一起工作，負責對RTP的通信和會話進行帶外管理（如流量控制、擁塞控制、會話源管理等）。
    數(shù)據(jù)傳輸?shù)牧鞒倘鐖D5所示，實現(xiàn)步驟如下：

    (1) RTP_INITIAL(RTPSession *session)對RTP會話進行初始化操作，利用Create(int u)函數(shù)方法指明會話所采用的端口號。如果調(diào)用失敗，具體的出錯信息則可以通過調(diào)用 RTPGetErrorString()函數(shù)得到。同時調(diào)用函數(shù)SetTimestampUnit(double u)方法來實現(xiàn)設置時戳單元，完成RTP會話的初始化。
    (2)創(chuàng)建RTP連接，由函數(shù)CreateSocket( )完成，先調(diào)用socksrv = socket(AF_INET,SOCKET_DGRAM,0)來創(chuàng)建套接字，創(chuàng)建成功后用函數(shù)bind(socksrv,(SOCKADDR*)&addrSrv, sizeof(SOCKADDR))綁定套接字。
    (3)當RTP會話建立之后,函數(shù)AddDestination( )、DeleteDestination() 和ClearDestinations()建立和刪除目標地址。然后通過SetDefaultPayloadType()函數(shù)來設置負載類型，SetDefaultMark()設置標識,SetDefaultTimeStampIncrement() 函數(shù)設置時戳增量。
    (4)接收RTP數(shù)據(jù)包時，遍歷攜帶有數(shù)據(jù)的源，接收時由函數(shù)RTPDataReceive(RTPSession *session, int u, char *payload, int *num, struct sockaddr *addr)完成，將接收到的RTP數(shù)據(jù)包由RTCP按順序連接起來。
    (5)判斷傳輸會話是否結(jié)束，若是，則結(jié)束這次會話。
3.5 測試結(jié)果
    本文通過將FFmpeg類進行優(yōu)化并移植到Android平臺作為視頻流文件的編解碼庫。由于視頻傳輸要消耗大量的帶寬，因此利用H.264壓縮效率高的特點，對其進行優(yōu)化可以實現(xiàn)文件的實時傳輸，減少延遲時間。經(jīng)測試，本文方法解決了對于適應客戶端內(nèi)存不足，硬件資源有限的問題，提高了系統(tǒng)處理器資源的利用率。最終實現(xiàn)了多屏環(huán)境下的文件實時、高清傳輸顯示。
    本文基于RTP/RTCP協(xié)議的多屏互動中多媒體文件的網(wǎng)絡傳輸實時共享技術(shù),詳細介紹了WiFi Direct的實現(xiàn)方法。通過屏幕鏡像，流文件的H.264優(yōu)化編解碼模塊和應用RTP/RTCP實現(xiàn)數(shù)據(jù)傳輸。WiFi Direct可以兼容現(xiàn)有的WiFi設備,使設備能夠互聯(lián)。終端設備采用了開放源碼，具有很強的跨平臺性以及先進、可靠、便利的優(yōu)點。在無線局域網(wǎng)傳輸速度不高的情況下，本文的多屏融合技術(shù)必將在圖片分享、高清在線視頻、電視游戲和商務演示中具有廣闊的發(fā)展前景。
參考文獻
[1] 張欣宇. 三屏互動業(yè)務解決方案研究[D]. 北京:北京郵電大學，2011.
[2] WiFi Alliance. Wi-Fi CERTIFIED Miracast:Extending the WiFi experience to seamless video display[EB/OL].[2012-09-19].http://www.wi-fi.org/knowledge-center/white-pa-pers/wi-fi-certified-miracast?-extending-wi-fi-experience-seamless-video.
[3] 張海軍,吳克捷,楊印根,等.一個基于RTP/RTCP的手機報警系統(tǒng)[J].電子技術(shù)應用, 2008,34(10):142-145.
[4] 谷丁云.基于WiFi Direct的對等的移動社交網(wǎng)絡軟件平臺設計與原型實現(xiàn)[M]. 南京:南京郵電大學出版社，
2013.
[5] 林強,黃建華,毛軍鵬. 基于多源的P2P流媒體傳輸系統(tǒng)的設計[J].電子技術(shù)應用,2007,33(5):91-93.
[6] 吳想想.基于Android平臺軟件開發(fā)方法的研究與應用[M].北京:北京郵電大學出版社，2011.