Zoom的Web客戶端和WebRTC有什么關(guān)系

Zoom是非常出色的視頻會(huì)議平臺(tái)，拿Zoom的web客戶端和WebRTC對(duì)比似乎有失公允。重要的是，未來WebRTC還會(huì)不斷做明智的改進(jìn)。

Zoom有一個(gè)Web客戶端，允許參與者在不下載他們的app的情況下參加會(huì)議。打開chrome://webrtc-internals顯示只有g(shù)etUserMedia用于訪問相機(jī)和麥克風(fēng)，但是沒有像WebRTC那樣調(diào)用RTCPeerConnection。這讓我很感興趣-他們沒有使用WebRTC是如何打電話的？

為什么不使用WebRTC？

就像他們的網(wǎng)站上所說的那樣，Zoom和WebRTC的關(guān)系比較復(fù)雜。

JitSi團(tuán)隊(duì)最近通過比較質(zhì)量回應(yīng)了這件事。Tsahi Levent Levi也對(duì)此發(fā)表了一些有用的評(píng)論。因此，讓我們在Chrome中運(yùn)行這種非常有趣的環(huán)境下快速查看這些“優(yōu)秀特性”。

Zoom web客戶端

Chrome網(wǎng)絡(luò)開發(fā)者工具迅速顯示了兩件事：

WebSocket用于數(shù)據(jù)傳輸

這是一些工作人員加載的WebAssembly (wasm) 文件

基于WebSocket的媒體傳輸

基于WebSocket的媒體傳輸整體設(shè)計(jì)非常有趣。它使用WebSocket傳輸媒體，這當(dāng)然不是最佳選擇。類似于WebRTC中的Turn/TCP——它會(huì)影響傳輸質(zhì)量，并且在很多情況下都不能很好地工作。使用TCP傳輸實(shí)時(shí)媒體的一般問題是丟包，這會(huì)導(dǎo)致重新發(fā)送和增加延遲。Tsahi前一段時(shí)間在TestRTC上描述了這一點(diǎn)，顯示了使用這種方案對(duì)比特率和其他特性的影響。

基于WebSocket傳輸媒體最主要的優(yōu)勢在于，它可以在TURN/TCP和TURN/TLS被防火墻阻塞時(shí)，穿過防火墻。它避免了WebRTC TRUN連接不經(jīng)過認(rèn)證代理的問題。這是Chrome WebRTC實(shí)施中長期存在的問題，去年才得到解決。

在WebSocket上接收的數(shù)據(jù)進(jìn)入基于WebAssembly (WASM)的解碼器。瀏覽器中的AudioWrkLead獲取到音頻數(shù)據(jù)。從那里，解碼的音頻使用WebAudio“magic”目的節(jié)點(diǎn)播放。

視頻被渲染出來，這個(gè)過程出乎意料的順利，質(zhì)量也非常高。

另一方面，WebAudio通過getUserMedia調(diào)用捕獲媒體數(shù)據(jù)，發(fā)送給WebAssembly編碼器編碼，然后通過WebSocket傳輸。640*360分辨率的視頻數(shù)據(jù)在發(fā)送給WebAssembly編碼器之前從畫布中獲取到，這是非常常見的。

WASM文件似乎包含與Zooms本地客戶端相同的編碼器和解碼器，這意味著網(wǎng)關(guān)不必進(jìn)行轉(zhuǎn)碼。相反，它可能只是一個(gè)websocet-RTP中繼，類似于轉(zhuǎn)換服務(wù)器。編碼的視頻有時(shí)有些像素化。雖然編碼器的CPU使用率相當(dāng)高（在640×360分辨率），但這可能并不重要，因?yàn)橛脩艨赡軐栴}歸咎于Chrome，并在下次使用客戶端。

H.264

使用WebAssembly提供媒體引擎是非常有趣的，它允許支持Chrome／WebRTC不支持的編解碼器。用emscripten編譯的FFmpeg以前已經(jīng)做了很多次了，這里似乎也使用了emscripten。通過WebSockets傳輸編碼后的數(shù)據(jù)，可以使用Chrome優(yōu)秀的調(diào)試工具檢查RTP頭和一些幀來顯示H264荷載。

令我驚訝的是，網(wǎng)絡(luò)抽象層單元（NALU）沒有表示H264-SVC。

和WebRTC的比較：

總之，讓我們比較一下Chrome在本例中使用的與WebRTC標(biāo)準(zhǔn)（W3C或者各種IETF草案）不同的地方：

WebRTC下一版

盡管WebRTC 1.0還遠(yuǎn)遠(yuǎn)沒有完成（而且大多數(shù)開發(fā)人員仍在使用被稱為“遺留API”的東西），但是關(guān)于“下一個(gè)版本”的討論仍然很多。

Zoom網(wǎng)絡(luò)客戶端的總體設(shè)計(jì)強(qiáng)烈地提醒了我，在今年早些時(shí)候在斯德哥爾摩召開的工作組面對(duì)面會(huì)議上，Google的Peter Thatcher為WebRTC NV提出的建議。請(qǐng)參閱幻燈片（https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf）。

如果我們要在2018重建WebRTC，我們可能已經(jīng)采取了類似的方法來分離組件。基本上采取以下步驟：

編譯用于wasm的webrtc.org編碼器/解碼器。

將解碼器與畫布連接，WebAudio用于”布局”

將編碼器和getUserMedia連接用于輸入

將編碼后的數(shù)據(jù)通過不可靠的信道發(fā)送

以某種方式連接RTCDataChannel反饋度量和音頻/視頻編碼器

該方法是從工作組會(huì)議幻燈片中看到的：

與Zoom方法相比，該方案具有非常明顯的技術(shù)優(yōu)勢。例如，使用RTCDataChannels傳輸數(shù)據(jù)，這比WebSocket具有更好的擁塞控制特性，特別是當(dāng)存在分組丟失時(shí)。

該設(shè)計(jì)的最大優(yōu)點(diǎn)是可以將編碼器和解碼器（以及相關(guān)的東西，如RTP打包）與瀏覽器分離，從而允許定制版本。主要問題是找到一種好的方法，以包括硬件加速的高性能方式使數(shù)據(jù)處理脫離主線程。這是Chrome早期面臨的一大挑戰(zhàn)，我記得很多關(guān)于沙箱讓事情變得困難的抱怨。Zoom看起來很好，但是我們只嘗試了1:1的聊天，而典型的WebRTC應(yīng)用程序比這個(gè)要求更高一些。重用像MediaStreamTrack這樣的構(gòu)建塊來進(jìn)行從工人到工人的數(shù)據(jù)傳輸也比使用Canvas元素和WebAudio要好。