Android WiFiDisplay探究

1 WiFiDisplay簡介

1.1WiFiDisplay概述

    WiFiDisplay(WFD)是WiFi聯盟在已有技術的基礎上，為了加速視/音頻的傳輸分享而提出來的一個新概念。WiFi聯盟對此成立了一個認證項目：Miracast-- 用來認證一個裝置是否支援WiFiDisplay功能。

    下圖是WiFiDisplay功能的技術支撐體系，實際上最重要的部分就是WiFi Direct：也就是兩個裝置無需AP(AccessPoint)的情況下直接相連，這就奠定了兩個帶WiFi功能的裝置能夠随時傳遞高質/高清視訊的前提。另外，其他深藍色的技術是必須支援的：

11n：即802.11n協定，支援最高傳輸速度540Mbit/s；

WMM：即WiFi Multimedia的簡稱，主要針對不同的資料内容保證其傳輸的穩定和品質；

WPA2：是WiFi聯盟對于采用802.11i協定并采用更為複雜加密算法的認證項目；

WiFi ProtectedSteup：也是一個WiFi聯盟的一個認證項目：簡化使用者安裝無線區域網路和對安全性能的配置工作；

WiFi Direct：表示裝置可以實作直接互聯，無需AP的參與；

WiFi Miracast：即為是否可以實作wifi-display功能的認證項目。

圖 1 WiFiDisplay技術支撐架構

另外，WiFi聯盟還描述了WiFiDisplay的簡化工作模型(圖2)。在這個工作模型中，Miracast定義傳輸視/音頻資料的一方為source端；接受資料并重新呈現的為sink端。從圖中可以看到，source端要有資料内容的存儲和下載下傳/生成能力；對資料進行編碼能力。而sink端則需要對資料的解碼能力；對視/音頻進行再度呈現的能力。而Miracast則是定義了這兩個裝置之間，怎樣保持會話；可以傳輸資料的格式标準；會話控制等内容。

圖 2 WiFiDisplay的工作模型

1.2  WiFiDisplay重要規範及标準

   WiFi聯盟定義了Miracast支援的視/音頻格式标準：

圖 3 Miracast支援的顯示、視訊、音頻格式标準

同時，Miracast也規範了裝置連接配接後進行協商(圖4)、建立會話的流程(圖5)。較長的描述了裝置在建立實體連接配接後，通過标準步驟來完成WiFi Display的會話建立，然後開始資料傳輸。關于各個标準步驟的詳細資訊，請見Miracast官方解釋。

圖 4  Miracast定義的裝置協商标準過程

圖5  Miracast定義的顯示會話建立過程标準

2  主要子產品介紹

    由于WFD功能主要涉及wifiP2P功能和display功能，現對Android中涉及的兩個子產品wifiP2pService和SurfaceFlinger做一些介紹。

2.1  WiFiP2P

2.1.1  WiFiP2P簡介

    WiFiP2P是WiFi聯盟提出的一項重要技術規範，它定義了兩個wifi裝置如何在沒有路由的情形下連接配接并通信。根據定義，支援WiFiP2P的裝置需要扮演P2P GroupOwner或P2P Client角色來形成一個P2P Group：

圖6  WiFiP2P工作組模型

其中P2P Group Owner的裝置需要發揮傳統路由的功能：控制WiFiP2P工作組，使能裝置通信等；P2PClient裝置則需要連接配接上P2P Group Owner裝置來形成一個工作組來通信。

    在以上的工作模型基礎上，WiFiP2P細化了以下技術項：

圖7  WiFiP2P定義的P2PDiscovery規範

在P2P Discovery規範中，定義了發現裝置(Device Discovery )并建構工作組(GroupFormation )的細節。其中發現裝置規定裝置首先進入掃描階段(ScanPhase)，去發送Probe Request幀；然後進入尋找階段(Find Phase)，在這個階段中裝置會在SearchState和Listen State中切換：兩個階段分别是發送Probe Request幀、監聽ProbeRequest幀并發送Probe Response幀。當找到附近的P2P裝置後，就可以來建構一個工作組：包括決定誰是Group Owner的協商(GONegotiation )和裝置交換安全配置資訊(Provisioning)，用于Client裝置利用安全配置資訊連接配接GO。

    另外，WiFiP2P還定義了GroupOperation技術項，具體描述了和工作組互動的場景和流程：

·P2P Device Join GO(Group Owner)

·P2P Device Join GC(Group Client)

·GC invite P2P Device

·GO invite P2P Device

… …

2.12  Android中WiFiP2P

    Android中關于WiFiP2P子產品主要涉及以下幾個部分：

圖8  Android中WiFiP2P涉及子產品

WiFiP2PSettings 是用來和使用者互動的部分，主要是提供UI給使用者選擇打開/開閉WiFiP2P功能、呈現搜尋到的P2P裝置給使用者等；WiFiP2PSettings實作的功能調用的是WiFiP2PManager中的接口；WiFiP2PManager最終會與WiFiP2PService互動，它們依靠Android的Binder機制來實作程序間的通信，WiFiP2PService則是用來管理Android中WiFiP2P功能的核心子產品：

圖9  Android中WiFiP2P涉及子產品

在WiFiP2PService類中有一個内部類P2pStateMachine(狀态機)用來管理WiFiP2P的不同狀态然後執行不同的操作；另外WiFiP2PService還會建立一個WifiMonitor對象用于接收來自wpa_supplicant的消息并根據接收到的消息給P2pStateMachine傳值來推動狀态機的工作。從圖中可以看到，WiFiP2PService或WifiMonitor互動的是WiFiNative.java中的接口，這裡面的都是一些native函數；這是因為wap_supplicant程序是C語言實作，Android是通過JNI機制調用android_net_wifi_Wifi.cpp 裡面的本地接口，這些本地接口來最終和wpa_supplicant互動(wifi.c裡面是對發送到wpa_supplicant裡面消息的封裝)。

    wpa_supplicant是一個開源項目，實作了WiFi聯盟規範中的衆多功能，詳見官方文檔。下圖是wpa_supplicant及與下層部件的一個草圖：

圖10  wpa_supplicant及底層部件草圖

2.2  SurfaceFlinger

    總所周知，SurfaceFlinger是Android中對圖形畫面進行管理并交由FrameBuffer實際顯示的重要子產品，它需要收集系統中所有應用程式繪制的圖像資料，然後集中處理後顯示到實體螢幕上。下圖是Android下圖形顯示的一個簡略框圖：

圖11  Android顯示系統簡略框圖

上圖描述的是使用OpenGL ES圖形開發規範下的情況。首先，每個應用程式在自己的視窗上進行繪圖，這裡的視窗(Window-2)實際上對應的是一些緩沖區；然後SurfaceFlinger則會對這些緩沖區進行統一管理；最後每一幀的圖形資料會被送到FrameBuffer上并實際顯示在裝置上。

    對于上層應用來說，Window-2在Android中的實作為SurfaceTextureClient類。由于是在OpenGL ES的開發架構下，SurfaceTextureClient實際上是繼承自ANativeWindow同時在本地實作了一些接口(參見EGL知識)：

圖12  上層應用的window實作

hook_dequeueBuffer()和hook_queueBuffer()是架構定義中需要實作的本地函數，上層應用作圖時需要從緩沖隊列得到緩沖區；作圖完成後需要把緩沖區送還給緩沖隊列。具體情形如下：

圖13  本地視窗和緩沖隊列互動圖

如上圖，本地視窗實際上是從BufferQueue來得到緩沖區；畫圖後再将緩沖區入列到緩沖隊列。而BufferQueue是在應用程式建立Surface(在SurfaceFlinger端對應Layer)的時候生成的，本地視窗通過傳回的ISurface對象得到ISurfaceTexture對象來最終和BufferQueue互動。

    對于SurfaceFlinger側的本地視窗Window-1(圖11)來說，SurfaceTextureClient也是作為本地視窗的功能。不過在SurfaceFlinger端通過标準的OpenGL ES接口進行請求緩沖區操作和入列緩沖區操作的對象就不一樣了；而且在入列緩沖區後所進行的操作也不一樣：

圖14 SurfaceFlinger的本地視窗

如上圖，在SurfaceFlinger端的本地視窗Window-1，會有自己的BufferQueue對象，而最終和HAL層的Gralloc子產品互動實際配置設定緩沖區的時候，會根據功用不同來配置設定不同類型的緩沖區：上層應用配置設定的緩沖區是給OpenGL繪圖用的；SurfaceFlinger這邊配置設定的緩沖區是要送顯FrameBuffer的(詳見gralloc.h中定義)。

    對于上層應用來說，填充好緩沖區後處理端(consumer&producter模型)會調用到Layer檔案的onFrameQueued()函數，如果需要渲染圖形這時候需要等待一個VSYNC信号(詳見Android的Project Butter)，收到VSYNC信号後會對需要渲染的Buffer按照Z軸計算可見區域并進行圖像混合；而對于SurfaceFlinger端來說，緩沖區入列後consumer會最終調用fb的HAL層接口完成實際顯示。

3  Android下實作詳述

     Android自從4.2後就支援WiFiDisplay功能了。以下是Miracast官方公布的WFD工作子產品框圖：

圖15WiFiDisplay的工作子產品框圖

在以上工作模型的基礎上，Android主要做了以下工作：

·新加了WiFiDisplay的setting部分，用來為使用者提供操作選項；

·新加DisplayDevice類用來描述不同的顯示裝置，WiFiDisplay作為一個虛拟顯示裝置；

·修改了SurfaceFlinger子產品來支援WiFiDisplay，通過SF把顯示内容投放到不同的裝置上；

·新加了DisplayManagerService來對系統的顯示裝置進行統一管理

·根據Miracast規定的會話建立管理流程，實作了source端和sink端的程式

3.1  應用程式端

    對于WiFiDisplay功能，Android提供了相應接口給應用程式使用，以實作在第二顯示裝置上進行顯示。具體内容參考官方描述，其中關鍵步驟見圖16：

圖16 Android上WFD應用程式設計簡要步驟

可以看到主要包括Presentation和MediaRouter兩個class。實際上它們都會調用一個重要的class提供的功能 – DisplayManager，而DisplayManager接口的具體實作在另外一個程序中的DisplayManagerService.java檔案中。

 3.2  DisplayManagerService及相關

    DisplayManagerService是Android中管理WiFiDisplay功能的核心服務：

圖17  DisplayManagerService簡圖

每一種顯示裝置(LocalDisplayDevice、WiFiDisplayDevice)都有一個對應的DisplayAdapter，DisplayManagerService通過管理這些Adapter來管理不同的顯示裝置。比如DisplayManager發起的對WiFiDisplay的操作請求，都會由DisplayManagerService轉給WifiDisplayAdapter來實際完成。另外DisplayManagerService服務還通過WindowManagerFuncs視窗管理功能接口直接調用WindowManagerService的函數，實作視窗内容的重新整理；同樣DisplayManagerService服務還通過InputManagerFuncs接口直接調用InputManagerService的函數，用來設定輸入系統需要的顯示器的顯示視圖資訊。

    而WifiDisplayAdapter的操作最終會實作在WifiDisplayController中，去實作裝置掃描、裝置連接配接等操作：

圖18  WifiDisplayController簡圖

     關于和其他裝置的WiFiDirect連接配接，Android有專門的一個WifiP2pService來管理，這裡對于裝置的連接配接就是直接調用WifiP2pManager(和WifiP2pService互動)所提供的接口來完成。

3.3   Source/Sink裝置會話管理端

    在裝置建立WiFi連接配接後，會在RemoteDisplay上監聽RTSP的連接配接，用于後續建立session和傳輸實時流資料。

圖19  監聽RTSP連接配接流程簡圖

如上圖，實際的監聽最終流程會走到RemoteDisplay中，即一個RemoteDisplay對象的建立。通過建立這個本地的RemoteDisplay對象将會建立一個ANetworkSession對象，用于管理網絡部分的操作；建立一個ALooper對象，實作各類消息的派發和處理；建立一個WifiDisplaySource對象(由于搭載Android系統的大多數裝置在WiFiDisplay場景中，多數會扮演source端的角色，是以這裡建立的是WifiDisplaySource對象)，具體處理各類消息：

圖20  RemoteDisplay簡圖

另外，Source目錄還包括PlaybackSession.cpp、MediaPuller.cpp、Converter.cpp、TSPacketizer.cpp、Sender.cpp等C++類檔案和相應的頭檔案，分别負責Source端的會話過程管理、鏡像媒體讀取、編碼、TS打包及RTP打包發送等過程。Converter 對象中包括一個MediaCodec對象具體負責編碼過程，MediaCodec對象實際通過ACodec對象調用IOMX接口使用OPENOMX媒體架構完成鏡像資料的編碼。

3.4  視/音頻資料擷取方式

圖21  source端的媒體資料擷取簡圖

    如圖，source裝置端程式對要在遠端裝置進行呈現的視/音頻資料通過MediaSource類進行管理。上圖中的SurfaceMediaSource和AudioSource都是繼承自MediaSource類，它們分别對應視訊資料和音頻資料，根據不同的情景，source裝置端程式可以添加視訊或者音頻資料源到目前程式中來，而且每一個MediaSource會對應建立一個Converter對象和一個MediaPuller對象，用于媒體資料的編碼和資料讀取等操作。下圖是擷取視訊資料的程式片段，調用MediaSource的通用接口read來實作。

圖22  擷取視訊資料程式片段

3.4.1  視訊資料源

    由圖22可知，視訊資料是從一個BufferQueue中讀取的。上層應用正是将需要顯示的視訊資料放到和這個BufferQueue對應的Surface中，實作視訊資料的遠端裝置投遞。

圖23  SurfaceFlinger管理不同顯示裝置簡圖

較詳細來說，上文中的surface是由WiFiDisplayDevice所持有的，這部分内容還和SurfaceFlinger為支援畫面投遞到不同的裝置上而進行的改動有關。如圖23，主要是抽象了DisplayDevice來表述本地顯示裝置和WiFiDisplay等顯示裝置，在SurfaceFlinger.cpp的handleTransactionLocked函數中可以看到：

圖24 SurfaceFlinge對不同顯示裝置處理代碼片段

對于virtualDisplay的話(WiFiDisplay裝置)，mFramebufferSurface為空；SurfaceTextureClient直接使用了State資訊中攜帶的surface變量。這個Surface正是當RTSP建立後，在回調函數onDisplayConnected中注冊到SufaceFlinger中的(3.3節描述監聽連接配接)，這樣SurfaceFlinger會将上層應用的顯示資料投遞到這個Surface上面，而source端的程式則會從這個surface上取出資料。

3.4.2  音頻資料源

    由圖21可以看到，音頻資料的擷取是通過AudioRecod來得到。Android系統對于Audio系統抽象了AudioTrack對象和AudioRecord對象來分别用于音頻資料的輸出和音頻資料的采集/擷取。對于WiFiDisplay情景下的音頻資料處理，Android也是在不破壞原有架構的情況進行的：

圖25 WFD情景下音頻簡單架構圖

AudioRecord通過AudioSystem對象來獲得AudioFlinger和AudioPolicyService的遠端接口進行操作，最終和HAL層的module互動，實際上完成的是從一個管道中的讀取操作；而AndroidTrack也是基于同樣的模型，隻不過流程相反，完成的是向HAL層的一個對應管道中的寫操作。其中AudioPolicyService在Android關于Audio的各個元件中扮演着核心角色：

圖26  AudioPolicyService核心與其他元件互動圖

如上圖，詳細來說：AudioPolicyService直接互動的是一個稱為‘POLICY’的HAL層子產品，這個子產品提供了通用接口；然後通用接口會調用到一個具體的政策管理類中提供的接口，對應上圖的AudioPolicyManagerALSA；最終，會根據不同的調用參數來擷取真正的HAL層子產品，和硬體互動，而AudioFlinger得到具體的HAL層子產品後，就可以直接對其操作了。

    這些具體的HAL子產品，ID名稱都為AUDIO_HARDWARE_MODULE_ID ，隻是被編譯成了不同名稱的庫檔案，而對應于WiFiDisplay的HAL層子產品不需要和具體的硬體打交道，實際實作為一個管道：

圖27  WiFiDisplay的HAL子產品程式片段

是以，對于需要通過WiFiDisplay到遠端裝置進行呈現的音頻資料，隻需要使用AudioTrack的接口來把音頻資料放到上文HAL子產品中的管道；而WiFiDisplay的source程式端也隻需要調用AudioRecord的接口取出資料即可。最發送前的編碼，音頻/視訊打包則專門去處理，不破壞原有的系統架構。

4 WiFiDisplay應用場景及相關産品

4.1  主要應用場景

    WiFiDisplay技術實作視/音頻資料的無線遠端呈現，目前涉及視/音頻資料處理的裝置較多，常用的應用場景有：

1、數字播放器和數字電視工作場景：在這個應用場景下，由于source端裝置不具有使用者互動螢幕，是以sink端裝置需要和使用者互動完成裝置的配對、傳輸的控制等工作；

圖28 WFD應用場景1

2、下圖描述的是一個數字機頂盒和DTV加上一個AP的工作模型，source裝置在這個模型中同時連接配接到AP和sink裝置，source端的資料此時是從網絡擷取的。這在WiFiDirect模型中是允許的，對于P2P連接配接在底層實際上對應的一個虛拟位址。

圖28 WFD應用場景2

3、下圖是描述的是有兩個sink端裝置的應用場景，此時source裝置需要發現和連接配接兩個sink裝置，并發送視訊/音頻資料到不同的sink裝置上。同時兩個sink裝置也需要彼此通信，來做同步和其他資訊交換。

圖28 WFD應用場景3

4.2  相關應用産品

    WiFiDisplay的應用産品，市場上已經有一些，比如百度推出的百度影音棒、小米盒子等。其中百度影音棒的工作情況如下：(官方說明)

圖29  百度影音棒2S工作簡圖

百度開發出的百度影音棒系列，實際上一種充分考慮現實情況的一套無線視訊播放方案。由上圖可知，考慮到現有電視的實際情形(大多數隻帶HDMI功能)，這套方案對于TV還是使用HDMI和BaiDu 2S有線連接配接，而真正的無線子產品則是這裡的BaiDu 2S。這裡的source裝置即為手機，sink端裝置其實就是BaiDu 2S。

     小米盒子和上圖的工作模型基本一緻，不過根據官方說明支援音樂遠端播放以及AirPlay協定和DLNA協定(官方說明)。

5  DLNA技術和AirPlay技術

5.1  DLNA技術

    DLNA(Digital Living Network Alliance)是由Sony、Intel、Microsoft等發起成立的一個認證組織，其目的也是實作消費電子産品通過有線/無線網絡實作裝置互聯、資料互通。相比于Miracast認證項目，DLNA有着自己的一套架構和相應标準：首先DLNA将市場上幾乎所有的電子産品進行了分類(圖30)，一方面可以便于DLNA對衆多的裝置進行規範認證，另一方面也是DLNA為不同裝置間進行互動制定标準的基礎。

圖30  DLNA定義的裝置類别和類型

其次DLNA定義了裝置工作架構(圖31)，其中UpnP是實作裝置裝置發現、連接配接、控制的重要協定層(參考文章)，而媒體資料的傳輸則是使用HTTP傳輸協定或者是RTP協定。

圖31 DLNA系統架構圖

5.2  AirPlay技術

    AirPlay是蘋果公司實作的在蘋果産品或是其認證産品之間傳輸媒體資訊的一套解決方案。AirPlay技術可以實作産品之間自動地互相發現，并且輕松地互相傳輸音樂、圖檔及視訊檔案。    

    AirPlay以多點傳播DNS(Multicast DomainName Server—mDNS)協定和DNS服務發現(DNS Service Discovery，簡稱DNS-SD)協定為基礎，它們是IETFn Zeroconf工作組提出的用于自動尋找裝置及服務的網絡協定，蘋果公司以這兩個協定為基礎，實作了蘋果公司數字家庭網絡架構。

    AirPlay協定消息發送格式及規則基于mDNS協定，mDNS協定基于多點傳播技術，定義了家庭各個裝置之間的消息的基本格式和接收/發送規則。該協定以DNS協定為基礎，并對其消息格式和消息收發順序作出了一些修改。例如對DNS消息標頭進行了簡化，使其專注于實作家庭裝置的互相發現；另外，考慮到使用多點傳播技術，mDNS在降低網絡擁塞和消息備援方面也作出了很多改進，使得區域網路内裝置和服務的發現不會引起過多的消息互動。

     在mDNS協定的基礎上，DNS-SD協定規定了一個服務宣告及使用的完整過程。即裝置必須發送什麼樣的mDNS消息才能完整地宣告并描述自己服務。DNS-SD協定使用PTR、SRV和TXT三種類型的記錄全面描述了一個服務的類型，名稱以及所在主機的IP和端口号等。

當使用DNS-SD協定實作了對裝置及服務的發現和描述後，蘋果公司的AirPlay協定規定了圖檔、音頻及視訊的傳輸和控制消息格式，進而實作了智能裝置之間的媒體共享和協同動作。在通過DNS-SD獲得了其他裝置及服務的資訊（即裝置或服務的IP位址及端口号）之後，AirPlay使用HTTP消息實作了圖檔和視訊的傳輸及控制，使用RSTP協定實作了音頻的傳輸和控制

    AirPlay工作模型和WiFiDisplay技術和DLNA技術基本一緻，隻不過它是蘋果公司的私有方案，是以沒有公開的規範資料(非官方協定協定标準)。

PDF下載下傳：http://download.csdn.net/detail/srw11/7645371

---------------------  

作者：srw11  

來源：CSDN  

原文：https://blog.csdn.net/srw11/article/details/38902717  

版權聲明：本文為部落客原創文章，轉載請附上博文連結！