當前位置:
首頁 > 最新 > iOS Airplay Screen Mirroring 同屏技術詳解

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接收端的實現原理,並揭示相關協議交互過程。

Airplay Mirroring客戶端的同屏交互過程,分為三個主要步驟:

設備廣播與發現

信息交互與能力協商

音視頻數據接收與解擾

設備廣播與發現

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#http://gmail.com


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 LiveVideoStack 的精彩文章:

深度學習在視頻分析中的架構、演算法及應用

TAG:LiveVideoStack |