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

    數(shù)據(jù)接收端保持?jǐn)?shù)據(jù)同步播放主要依靠如下技術(shù)：
    (1)RTP數(shù)據(jù)報(bào)文的數(shù)據(jù)序號(hào)用于排序RTP報(bào)文分組，以消除重復(fù)分組，保持流文件同步并連續(xù)地播放。
    (2)RTP數(shù)據(jù)報(bào)文的時(shí)戳字段可作為流間同步標(biāo)識(shí)，以保持視頻和音頻流間同步并連續(xù)地播放。
    (3)發(fā)送者可以根據(jù)接收者反饋的RTCP數(shù)據(jù)來(lái)實(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é)議，在沒(méi)有接入點(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)用程序通過(guò)創(chuàng)建類BroadcastReceiver的繼承類模塊WiFiBroadcastReceive來(lái)通知WiFi的狀態(tài)及事件[4]。模塊WiFiBroadcastReceive類作為一個(gè)廣播接收器,監(jiān)聽(tīng)WiFi Direct事件并把結(jié)果傳遞給模塊WiFiActivity,通過(guò)WifiP2pManager類的行為描述函數(shù)來(lái)請(qǐng)求可用的節(jié)點(diǎn),在請(qǐng)求連接成功后獲得組用戶的IP。模塊DeviceList用來(lái)實(shí)現(xiàn)顯示活動(dòng)的節(jié)點(diǎn)和狀態(tài)。表示設(shè)備的5種狀態(tài)：設(shè)備可用（AVAILABLE）、無(wú)可用設(shè)備（UNAVAILABLE）、設(shè)備已邀請(qǐng)（INVITED）、設(shè)備已連接（CONNECTED）、設(shè)備連接失敗（FAILED）。模塊DeviceDetail用來(lái)顯示被選擇設(shè)備的細(xì)節(jié)，同時(shí)進(jìn)行驅(qū)動(dòng)設(shè)備連接、斷開和數(shù)據(jù)傳輸。當(dāng)設(shè)備連接時(shí)，應(yīng)用程序通過(guò)WiFiP2pConfig.deviceAddress函數(shù)獲取設(shè)備的地址及WiFiP2pConfig.wps.setup函數(shù)來(lái)設(shè)置WPS的連接方式。
3.2 屏幕鏡像實(shí)現(xiàn)
    手機(jī)通過(guò)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用來(lái)控制當(dāng)前正在繪制的顯示層的狀態(tài)，mCurrentState表示當(dāng)前所有顯示層的狀態(tài),DisplayDevice表示顯示設(shè)備。變量mFrameBufferSurface是FrameBufferSurface類型，若顯示設(shè)備不屬于虛擬顯示設(shè)備類型，則該變量不為空。顯示數(shù)據(jù)通過(guò)網(wǎng)絡(luò)傳遞給真正的顯示設(shè)備,對(duì)于源設(shè)備端的SurfaceFlinger來(lái)說(shuō)，不存在FrameBuffer變量。故當(dāng)設(shè)備為虛擬顯示設(shè)備時(shí)，其對(duì)應(yīng)的變量mFrameBufferSurface則為空。SurfaceFlinger類將遍歷系統(tǒng)中所有的顯示設(shè)備，來(lái)完成各自的混屏工作，由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)
    編碼模塊主要功能是通過(guò)從應(yīng)用層獲取傳輸流文件，并對(duì)其壓縮編碼，將產(chǎn)生的編碼碼流通過(guò)客戶端傳輸出去。通過(guò)調(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。通過(guò)函數(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ù)順序號(hào)、時(shí)間標(biāo)記、傳輸控制等。RTCP與RTP一起工作，負(fù)責(zé)對(duì)RTP的通信和會(huì)話進(jìn)行帶外管理（如流量控制、擁塞控制、會(huì)話源管理等）。
    數(shù)據(jù)傳輸?shù)牧鞒倘鐖D5所示，實(shí)現(xiàn)步驟如下：

    (1) RTP_INITIAL(RTPSession *session)對(duì)RTP會(huì)話進(jìn)行初始化操作，利用Create(int u)函數(shù)方法指明會(huì)話所采用的端口號(hào)。如果調(diào)用失敗，具體的出錯(cuò)信息則可以通過(guò)調(diào)用 RTPGetErrorString()函數(shù)得到。同時(shí)調(diào)用函數(shù)SetTimestampUnit(double u)方法來(lái)實(shí)現(xiàn)設(shè)置時(shí)戳單元，完成RTP會(huì)話的初始化。
    (2)創(chuàng)建RTP連接，由函數(shù)CreateSocket( )完成，先調(diào)用socksrv = socket(AF_INET,SOCKET_DGRAM,0)來(lái)創(chuàng)建套接字，創(chuàng)建成功后用函數(shù)bind(socksrv,(SOCKADDR*)&addrSrv, sizeof(SOCKADDR))綁定套接字。
    (3)當(dāng)RTP會(huì)話建立之后,函數(shù)AddDestination( )、DeleteDestination() 和ClearDestinations()建立和刪除目標(biāo)地址。然后通過(guò)SetDefaultPayloadType()函數(shù)來(lái)設(shè)置負(fù)載類型，SetDefaultMark()設(shè)置標(biāo)識(shí),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按順序連接起來(lái)。
    (5)判斷傳輸會(huì)話是否結(jié)束，若是，則結(jié)束這次會(huì)話。
3.5 測(cè)試結(jié)果
    本文通過(guò)將FFmpeg類進(jìn)行優(yōu)化并移植到Android平臺(tái)作為視頻流文件的編解碼庫(kù)。由于視頻傳輸要消耗大量的帶寬，因此利用H.264壓縮效率高的特點(diǎn)，對(duì)其進(jìn)行優(yōu)化可以實(shí)現(xiàn)文件的實(shí)時(shí)傳輸，減少延遲時(shí)間。經(jīng)測(cè)試，本文方法解決了對(duì)于適應(yīng)客戶端內(nèi)存不足，硬件資源有限的問(wèn)題，提高了系統(tǒng)處理器資源的利用率。最終實(shí)現(xiàn)了多屏環(huán)境下的文件實(shí)時(shí)、高清傳輸顯示。
    本文基于RTP/RTCP協(xié)議的多屏互動(dòng)中多媒體文件的網(wǎng)絡(luò)傳輸實(shí)時(shí)共享技術(shù),詳細(xì)介紹了WiFi Direct的實(shí)現(xiàn)方法。通過(guò)屏幕鏡像，流文件的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)的跨平臺(tái)性以及先進(jìn)、可靠、便利的優(yōu)點(diǎn)。在無(wú)線局域網(wǎng)傳輸速度不高的情況下，本文的多屏融合技術(shù)必將在圖片分享、高清在線視頻、電視游戲和商務(wù)演示中具有廣闊的發(fā)展前景。
參考文獻(xiàn)
[1] 張欣宇. 三屏互動(dòng)業(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的對(duì)等的移動(dòng)社交網(wǎng)絡(luò)軟件平臺(tái)設(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平臺(tái)軟件開發(fā)方法的研究與應(yīng)用[M].北京:北京郵電大學(xué)出版社，2011.