iOS Airplay Screen Mirroring 投屏技術詳解

投屏技術已經被大量用在身邊的產品, 好比電視投屏, 投影儀, 視頻會議產品中. 在iOS平臺外的其餘平臺中都已經有很是成熟的標準和實現. 但在封閉的蘋果iOS和Mac系統中, 蘋果使用私有的Airplay協議進行多屏互動, 只開放給本身生態中的產品. 對此相關技術限制比較嚴格，甚至在iOS9中加上了更嚴格的加密算法, 直接致使不少投屏的產品不可用.

iOS中的投屏方案:

1, ReplayKit

iOS9中引入了ReplayKit, 讓開發者有了必定的獲取屏幕數據的能力. 並在iOS10和iOS11中繼續擴展了ReplayKit的能力. 但仍是有很大的限制, 好比在使用ReplayKit的api時只能錄製當前應用的應用, 沒法在應用進入後臺以後繼續錄屏. 若是使用系統級別的屏幕錄製,又沒法得到每一幀的數據,只能得到最後錄取的單個視頻. 這樣對第三方的開發有了很是大的限制.

2, Airplay

Airplay是蘋果提供的一種多屏互動技術, 能夠將音頻照片,視頻, 屏幕從iOS設備或者Mac電腦上投射到支持airplay接受的設備上，如Apple TV。這樣能夠將小屏映射到大屏，能夠無線音樂，能夠圖片分享等等. 可是Airplay屬於蘋果私有協議方案，設備間的協商與傳輸過程都進行了加密處理，並不能用於其餘平臺中。咱們已經完整的逆向了Airplay的所有協議棧，並破解了其加密方案，能夠提供跨平臺Airplay接收方案。這樣能夠方便實現跨平臺的多屏共享。

同時，經過研究，咱們也能夠經過Airplay Mirroring技術，作到在iPhone上把本身的屏幕的內容投送給當前iPhone，在某些狀況下這種airplay的破解卻很是有用處,好比手遊直播。這中投屏方案使用了iOS原生的投屏能力，而且是徹底的軟件方案，很是方便進行集成和使用。

下面將介紹Airplay Mirroring接收端的實現原理，並揭示相關協議交互過程。

Airplay Mirroring客戶端的同屏交互過程，分爲三個主要步驟：

1, 設備廣播與發現

2, 信息交互與能力協商

3, 音視頻數據接收與解擾

設備廣播與發現:

Airplay設備間的廣播與發現經過Bonjour協議進行。Bonjour也被稱爲ZeroConf, mDNS等，能夠用來在局域網內進行數據記錄廣播與發現。該協議比較成熟，網上能夠找到諸多介紹。對於實現的Airplay（包括Mirroring）接收端而言，首先須要註冊兩類服務，即airtunes和airplay。 Airtunes服務主要用來處理廣播視音頻接收能力協商，是最爲重要的服務內容，對應Bonjour記錄名稱爲'_raop._tcp'，註冊服務端口不限，通常爲了不衝突，建議採用較高的端口數；Airplay服務主要用來兼容傳統的streaming等服務，對應記錄名稱爲'_airplay._tcp'，註冊端口通常爲7000。

具體的服務廣播內容，能夠進行局域網抓包，找到對應記錄內容。

當接收端經過Bonjour廣播器服務能力後，發送端（如iPhone等各種iOS設備）就能夠發現該接收端。

信息交互與能力協商:

當發送端發現接收端後，能夠開始信息交互與能力協商過程。該部分協議協議格式相似rtsp協議格式。主要分爲兩個階段，設備匹配與和能力協商。

當發送端連接服務端後，設備匹配過程即開始。通訊雙方會進行fairplay加密協議進行信息交換，當完成信息交換後，客戶端後續必須使用這部分信息來處理加密過的密鑰，才能得到進一步視音頻解密密鑰。在iOS9以後，在fairplay過程以前，增長一個設備匹配過程，即pair-setup、pair-verify過程，其主要算法是較爲標準的非對稱公鑰交換算法。

當兩端成功匹配後，開始進行能力協商與信息交換，這些信息包括，設備名稱、代號，音視頻接收相關端口配置，視頻接收能力以及加密密鑰等，相關信息使用binary plist格式進行封裝。

能夠參考https://github.com/espes/Slave-in-the-Magic-Mirror找到相關協議交互的一些細節。

音視頻數據接收與解密:

雙方協商成功後，發送端開始向接收端發送視音頻數據，mirroring數據是經過TCP進行發送，爲h.264 ES流格式。音頻是經過RTP協議進行發送，根據內容的不一樣音頻編碼爲ALAC或者AAC-ELD。

音視頻流都是經過AES進行了加密處理，密鑰須要經過上面一步的進過信息交互後的fairplay模組對setup過程當中接收到的加密密鑰進行解密，得到的AES解密須要的IV和KEY，而後通過AES解擾，便可以得到最終的視音頻清流。

其餘須要注意的地方:

Airplay沒過Session傳送過來的視頻h264碼流，只有開頭一個關鍵幀. 所以這種狀況並不適合直播這種須要固定GOP的場景. 還須要作進一步的轉碼的工做，或者直接在壓縮域進行處理，得到合理的GOP結構。

咱們對Airplay相關協議的逆向工程已經封裝成了跨平臺的類庫和框架, 支持windows/Mac/Android/iOS/linux, 在本身內部產品中使用已經很是穩定, 若是有須要能夠聯繫咱們. 也歡迎各種技術與應用場景討論。個人郵箱 leeoxiang@gmail.com

相關連接:

1)咱們的投屏SDK AirCast github.com/AirCastLab

2)Airplay Protocol nto.github.io/AirPlay.htm…

3)AirCast website aircast.cc