基於瀏覽器客戶端的流式渲染技術難點一覽

本文首發於個人博客（點此查看），歡迎關注。

流式渲染技術，不一樣於傳統意義上前端領域的服務端渲染（即 SSR），指的是雲端性能強勁的機器進行畫面渲染，將渲染完成的數據傳送至客戶端，客戶端只負責播放及處理和上傳用戶輸入信號至服務端的一種技術，谷歌的雲遊戲平臺便是使用案例之一。在開源社區也有一些相關的方案，在拜讀了 Parsec 公司的這篇博文——A Look at Game Streaming Tech in the Browser後，對整個技術體系中尤爲是客戶端（此處即瀏覽器）方面可能遇到的難點有了一個初步的認識，如下是一些相關的記錄。

整體流程

1. 經過 WebRTC 技術實現點對點（更常見的說法：P2P）鏈接；
2. 將客戶端配置發送至服務端，初始化流；
3. 開始接收服務端發來的視頻、音頻及控制信息；
4. 使用 Opus 音頻格式對音頻進行解碼並經過 Web Audio API 播放；
5. 使用 Media Source Extensions 將視頻內容塞進 <video> 元素中;
6. 採集輸入事件，將其打包爲二進制形式併發送至服務端。

網絡

瀏覽器中的 P2P 鏈接只能依賴 WebRTC 實現，WebSockets 不適合的緣由是其在 NAT 遍歷及基於 TCP 的擁塞控制等多方面存在劣勢。parsec 的 web 客戶端使用 RTCDataChannels 與服務端通訊。RTCDataChannel 被 UDP 封裝於 STCP 流中。出於安全考慮，STCP 流又被 DTLS 封裝。

NAT 遍歷和 P2P 的初次鏈接（後來發現其能夠歸結爲 UDP 穿孔過程當中的一部分，就是一個簡單的 STUN ping/pong）在技術實現上很複雜。初次握手須要預先交換安全憑證，這一操做經過 WebSocket 發送信號實現。

parsec 的原生客戶端採用了本身基於 UDP 封裝的 BUD 協議。出於開放心態，web 客戶端使用了默認的 DTLS/SCTP。雖然能夠保證理想情況下的使用，但其顯然沒有 BUD 協議來的魯棒性好，因此後期可能會被 BUD 替換。

視頻

在瀏覽器中（實際上只在 Chrome 中），咱們使用 Media Source Extensions 將視頻幀裝載進 HTML <video> 元素。Chrome 爲 MSE 實現了『低延遲』模式，該模式使用視頻流推送模型以支持任意低延遲視頻流。

音頻

音頻以原始 Opus 編碼格式傳入，而後經過由 Web Assembly 編譯而來的 Opus 庫進行解碼，最後由 Web Audio API 播放。Chrome 在 70 版本後會支持經過 MSE 處理 mp4/opus，採用這一方式將是更好的解決方案，實現上就相似視頻推送，只不過是推送到了 <audio> 元素中。

輸入/信號

輸入事件（包括鍵盤、鼠標、遊戲手柄）以及任意信息（光標、對話）都在各自信道處理。各類信息被打包爲二進制格式發送至服務端。

我的總結

1. 網絡

   網絡是很是重要的一點，關係到是否可以保證整個應用正常使用。爲了適應流式渲染技術對網絡高吞吐、零緩衝的特色，可能須要對現有網絡協議進行改造（主要針對 UDP）。此外，公網環境下須要面對的 NAT 遍歷問題，若是前期只考慮局域網環境，該難點能夠被繞過。

2. 視頻

   基於 Chrome 的 MSE，視頻在客戶端的播放會相對較爲容易。只須要熟悉 MSE API。

3. 音頻

   一樣能夠基於 Chrome MSE 實現。

4. 輸入/信號

   各自隔離處理便可，瀏覽器端對常見的輸入信號幾乎都有支持。

瀏覽器爲 web 客戶端的實現作了大量的工做，前期若是以快速落地爲主要訴求，能夠考慮基於瀏覽器的 web 客戶端實現。