Android Wi-Fi Display(Miracast)介紹

火星人 @ 2014-03-12 , reply:0


  

201211月中旬,Google發布了Android 4.2。雖然它和Android 4.1同屬Jelly Bean系列,但卻添加了很多新的功能。其中,在顯示部分,Android 4.2Project Butter基礎上再接再厲,新增了對Wi-Fi Display功能的支持。由此也導致整個顯示架構發生了較大的變化。

本文首先介紹Wi-Fi Display的背景知識,然後再結合代碼對Android 4.2Wi-Fi Display的實現進行介紹。

一背景知識介紹

Wi-Fi Display經常和Miracast聯繫在一起。實際上,MiracastWi-Fi聯盟(Wi-Fi Alliance)對支持Wi-Fi Display功能的設備的認證名稱。通過Miracast認證的設備將在最大程度內保持對Wi-Fi Display功能的支持和兼容。由此可知,Miracast考察的就是Wi-Fi Display(本文後續將不再區分MiracastWi-Fi Display)。而Wi-Fi Display的核心功能就是讓設備之間通過Wi-Fi無線網路來分享視音頻數據。以一個簡單的應用場景為例:有了Wi-Fi Display后,手機和電視機之間可以直接藉助Wi-Fi,而無需硬連線(如HDMI)就可將手機中的視頻投遞到TV上去顯示[①]。以目前智能設備的發展趨勢來看,Wi-Fi Display極有可能在較短時間內幫助我們真正實現多屏互動。

從技術角度來說,Wi-Fi Display並非另起爐灶,而是充分利用了現有的Wi-Fi技術。圖1所示為Wi-Fi Display中使用的其他Wi-Fi技術項。

1 Miracast的支撐體系結構

由圖1可知,Miracast依賴的Wi-Fi技術項[②]有:

  • Wi-Fi Direct,也就是Wi-Fi P2P。它支持在沒有APAccess Point)的情況下,兩個Wi-Fi設備直連並通信。
  • Wi-Fi Protected Setup:用於幫助用戶自動配置Wi-Fi網路、添加Wi-Fi設備等。
  • 11n/WMM/WPA2:其中,11n就是802.11n協議,它將11a11g提供的Wi-Fi傳輸速率從56Mbps提升到300甚至600MbpsWMMWi-Fi Multimedia的縮寫,是一種針對實時視音頻數據的QoS服務。而WPA2意為Wi-Fi Protected Acess第二版,主要用來給傳輸的數據進行加密保護。

上述的Wi-Fi技術中,絕大部分功能由硬體廠商實現。而在Android中,對Miracast來說最重要的是兩個基礎技術:

  • Wi-Fi Direct:該功能由Android中的WifiP2pService來管理和控制。
  • Wi-Fi Multimedia:為了支持MiracastAndroid 4.2MultiMedia系統也進行了修改。

下邊我們對Miracast幾個重要知識點進行介紹,首先是拓撲結構和視音頻格式方面的內容。

Miracast一個重要功能就是支持Wi-Fi Direct。但它也考慮了無線網路環境中存在AP設備的情況下,設備之間的互聯問題。讀者可參考如圖2所示的四種拓撲結構。

2  Miracast的四種拓撲結構

2所示內容比較簡單,此處就不再詳述。另外,在Wi-Fi Display規範中,還存在著SourceVideoAudio內容分別傳送給不同Render Device的情況。感興趣的讀者可參考Wi-Fi Display技術規範。

另外,Miracast對所支持的視音頻格式也進行了規定,如表1所示。

1  Miracast 視音頻格式支持

解析度

17 CEA格式,解析度從640*4801920*1080,幀率從2460

29VESA格式,解析度從800*6001920*1200,幀率從3060

12種手持設備格式,解析度從640*360960*540,幀率從3060

視頻

H.264高清

音頻

必選:LPCM 16bits48kHz採樣率,雙聲道

可選:

LPCM 16bits44.1kHz採樣率,雙聲道

Advanced Audio coding

Dolby Advanced Codec 3

最後,我們簡單介紹一下Miracast的大體工作流程。Miracastsession為單位來管理兩個設備之間的交互的工作,主要步驟包括(按順序):

  • Device Discovery:通過Wi-Fi P2P來查找附近的支持Wi-Fi P2P的設備。
  • Device Selection:當設備A發現設備B后,A設備需要提示用戶。用戶可根據需要選擇是否和設備B配對。
  • Connection SetupSourceDisplay設備之間通過Wi-Fi P2P建立連接。根據Wi-Fi Direct技術規範,這個步驟包括建立一個Group Owner和一個Client。此後,這兩個設備將建立一個TCP連接,同時一個用於RTSP協議的埠將被創建用於後續的Session管理和控制工作。
  • Capability Negotiation:在正式傳輸視音頻數據前,SourceDisplay設備需要交換一些Miracast參數信息,例如雙方所支持的視音頻格式等。二者協商成功后,才能繼續後面的流程。
  • Session Establishment and streaming:上一步工作完成後,SourceDisplay設備將建立一個Miracast Session。而後就可以開始傳輸視音頻數據。Source端的視音頻數據將經由MPEG2TS編碼后通過RTP協議傳給Display設備。Display設備將解碼收到的數據,並最終顯示出來。
  • User Input back channel setup:這是一個可選步驟。主要用於在傳輸過程中處理用戶發起的一些控制操作。這些控制數據將通過TCPSourceDisplay設備之間傳遞。
  • Payload Control:傳輸過程中,設備可根據無線信號的強弱,甚至設備的電量狀況來動態調整傳輸數據和格式。可調整的內容包括壓縮率,視音頻格式,解析度等內容。
  • Session teardown:停止整個Session

通過對上面背景知識的介紹,讀者可以發現:

  • Miracast本質就是一個基於Wi-Fi的網路應用。這個應用包括服務端和客戶端。
  • 服務端和客戶端必須支持RTP/RTSP等網路協議和相應的編解碼技術。

 

  Android 4.2 Miracast功能實現介紹

MiracastAndroid實現涉及到系統的多個模塊,包括:

  • MediaPlayerService及相關模塊:原因很明顯,因為Miracast本身就牽扯到RTP/RTSP及相應的編解碼技術。
  • SurfaceFlinger及相關模塊:SurfaceFlinger的作用是將各層UI數據混屏並投遞到顯示設備中去顯示。現在,SurfaceFlinger將支持多個顯示設備。而支持Miracast的遠端設備也做為一個獨立的顯示設備存在於系統中。
  • WindowManagerService及相關模塊:WindowManagerService用於管理系統中各個UI層的位置和屬性。由於並非所有的UI層都會通過Miracast投遞到遠端設備上。例如手機中的視頻可投遞到遠端設備上去顯示,但假如在播放過程中,突然彈出一個密碼輸入框(可能是某個後台應用程序發起的),則這個密碼輸入框就不能投遞到遠端設備上去顯示。所以,WindowManagerService也需要修改以適應Miracast的需要。
  • DisplayManagerService及相關模塊:DisplayManagerService服務是Android 4.2新增的,用於管理系統中所有的Display設備。

由於篇幅原因,本文將重點關注SurfaceFlingerDisplayManagerService以及Miracast的動態工作流程。

2.1  SurfaceFlingerMiracast的支持

相比前面的版本,Android 4.2SurfaceFlinger的最大變化就是增加了一個名為DisplayDevice的抽象層。相關結構如圖3所示:

3  SurfaceFlinger家族類圖

由圖3可知:

  • Surface系統定義了一個DisplayType的枚舉,其中有代表手機屏幕的DISPLAY_PRIMARY和代表HDMI等外接設備的DISPLAY_EXTERNAL。比較有意思的是,作為Wi-Fi Display,它的設備類型是DISPLAY_VIRTUAL
  • 再來看SurfaceFlinger類,其內部有一個名為mDisplays的變數,它保存了系統中當前所有的顯示設備(DisplayDevice)。另外,SurfaceFlinger通過mCurrentStatemDrawingState來控制顯示層的狀態。其中,mDrawingState用來控制當前正在繪製的顯示層的狀態,mCurrentState表示當前所有顯示層的狀態。有這兩種State顯示層的原因是不論是Miracast還是HDMI設備,其在系統中存在的時間是不確定的。例如用戶可以隨時選擇連接一個Miracast顯示設備。為了不破壞當前正在顯示的內容,這個新顯示設備的一些信息將保存到CurrentState中。等到SurfaceFlinger下次混屏前再集中處理。
  • mCurrentStatemDrawingState的類型都是SurfaceFlinger的內部類State。由圖3可知,State首先通過layerSortedByZ變數保存了一個按Z軸排序的顯示層數組(在Android中,顯示層的基類是LayerBase),另外還通過displays變數保存了每個顯示層對應的DisplayDeviceState
  • DisplayDeviceState的作用是保存對應顯示層的DisplayDevice的屬性以及一個ISurfaceTexure介面。這個介面最終將傳遞給DisplayDevice
  • DisplayDevice代表顯示設備,它有兩個重要的變數,一個是mFrameBufferSurfacemNativeWindowmFrameBufferSuraceFrameBufferSurface類型,當顯示設備不屬於VIRTUAL類型的話,則該變數不為空。對於Miracast來說,顯示數據是通過網路傳遞給真正的顯示設備的,所有在Source端的SurfaceFlinger來說,就不存在FrameBuffer。故當設備為VIRTUAL時,其對應的mFrameBufferSurface就為空。而ANativeWindowAndroid顯示系統的老員工了。該結構體在多媒體的視頻I/OOpenGL ES等地方用得較多。而在普通的UI繪製中,ISurfaceTexture介面用得較多。不過早在Android 2.3Google開發人員就通過函數指針將ANativeWindow的各項操作和ISurfaceTexture介面統一起來。

作為VIRTUALMiracast設備是如何通過DisplayDevice這一層抽象來加入到Surface系統中來的呢?下面這段代碼對理解DisplayDevice的抽象作用極為重要。如圖4所示。

4  SurfaceFlinger代碼片段

由圖4代碼可知:

  • 對於非Virtual設備,DisplayDeviceFrameBufferSurface不為空。而且SurfaceTextureClient的構造參數來自於FrameBufferSurfacegetBufferQueue函數。
  • 如果是Virtual設備,SurfaceTextureClient直接使用了State信息中攜帶的surface變數。

憑著上面這兩點不同,我們可以推測出如圖5所示的DisplayDevice的作用

5  DisplayDevice的隔離示意圖

最後再來看一下SurfaceFlinger中混屏操作的實現,代碼如圖6所示:

6  SurfaceFilnger的混屏操作

由圖5可知,SurfaceFlinger將遍歷系統中所有的DisplayDevice來完成各自的混屏工作。

 

2.2  FrameworkMiracast的支持

為了徹底解決多顯示設備的問題,Android 4.2乾脆在Framework中新增了一個名為DisplayManagerService的服務,用來統一管理系統中的顯示設備。DisplayManagerService和系統其它幾個服務都有交互。整體結構如圖7所示。

7  DisplayManagerService及相關類圖

由圖7可知:

  • DisplayManagerService主要實現了IDisplayManager介面。這個介面的大部分函數都和Wi-Fi Display操作相關。
  • 另外,DisplayManagerServiceWindowManagerService交互緊密。因為WindowManagerService管理系統所有UI顯示,包括屬性,Z軸位置等等。而且,WindowManagerService是系統內部和SurfaceFlinger交互的重要通道。
  • DisplayManagerService通過mDisplayAdapters來和DisplayDevice交互。每一個DisplayDevice都對應有一個DisplayAdapter
  • 系統定義了四種DisplayAdapterHeadlessDisplayAdapterOverlayDisplayAdapter針對的都是Fake設備。其中OverlayDisplay用於幫助開發者模擬多屏幕之用。LocalDisplayAdapter代表主屏幕,而WifiDisplayAdapter代表Wi-Fi Display

2.3  AndroidMiracast動態工作流程介紹

當用戶從Settings程序中選擇開啟Miracast並找到匹配的Device,系統將通過WifiDisplayController




[火星人 via ] Android Wi-Fi Display(Miracast)介紹已經有643次圍觀

http://www.coctec.com/docs/program/show-post-71270.html