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

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

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

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

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

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