“易 +”開源計劃丨基於標準 WebRTC 低延遲直播開源實踐

自上世紀末，流媒體直播技術興起以來，伴隨著網路基礎設施的發展腳步，直播也同頻共振般地起勢。而近年來 AI、雲端計算、音影片等技術日趨成熟，以及新冠肺炎疫情帶來的“宅經濟”刺激，使直播行業的發展勢頭被進一步啟用。

通過網路直播，你可以輕鬆觀看到大洋彼岸正在進行的緊張體育賽事，也可以足不出戶就閱盡祖國的大好河山、日出日落，甚至與 6000 萬陌生人一起“雲監工”火神山醫院建設進度，為疫情防控力量點贊。

直播是個好東西，但，直播延時並不是。

或許你曾熬夜守在電商直播間，在秒殺倒計時中，因延時被人捷足先登；也或許在上網課時，因延時錯過了重要的知識點；還或許在體育比賽關鍵時刻，因延時被提前“劇透”了結果。

凡此種種的破壞性體驗， 皆是「延時」惹的禍 ，市場對低延時的直播方案提出了需求。

在介紹低延時直播方案前，我們先來看看當下典型的直播架構。

一.典型的直播架構

在典型直播架構中，左邊是推流客戶端，協議上才採用 RTMP 上行。右邊是拉流客戶端，支援不同的拉流協議拉流，比較常見的是：RTMP、FLV,、HLS。

現有架構的優點

這套框架很好的利用了 CDN 廠商或者說雲廠商的能力。儘管拉流協議沒有統一，但由於 rtmp/flv/hls 等拉流協議是比較成熟的流媒體協議，經過多年的發展，各家 CDN 廠商廣泛支援。在雲端能力的支援下，服務端併發能力和拉流端加速能力大大增加了，直播行業蓬勃發展。

二.低延遲直播的現狀

直播行業裡卡頓和延遲就像是天平的兩端。 延遲做的越短，卡頓越高。延遲越長，卡頓越少。

一般場景下都是客戶端用更大的 buffer 時長，犧牲延時來滿足流暢性。隨著行業的發展，在某一些應用場景對延時時間的要求越來越苛刻，比如體育比賽直播，教育場景下老師學生互動等，這時候現有常見的直播流媒體協議的缺點就體現出來了。

一般 rtmp 協議直播延時在 3-10s，如果經過層層 CDN 的快取和轉發，超過 10 秒也是常有的事，flv 和 hls 協議的延時更高。就拉流端來說，延遲很大一部分源自網路傳輸：

rtmp 在傳輸媒體前的 tcp 3 次握手和 c0/c1/c2 握手協議，無端引入了好幾個 RTT 的延遲；由於 rtmp/flv/hls 的傳輸層都是基於 tcp 協議的，在網路不穩定的情況下，受限於 tcp 協議的擁塞控制不能充分利用網路頻寬，客戶端為了保持流暢性，只能加大快取時間，更進一步加大了延遲。

其實認識到現有流媒體直播協議的侷限性，各大友商也紛紛推出了自己的低延時直播，也比較好的起到了對抗弱網和加快首屏的作用 。

但目前大家大都基於私有的信令協議和基於私有的 UDP 的流媒體傳輸協議，各大雲廠商沒法互相相容，這就限制了低延遲直播的大規模發展。

三.基於標準 WebRTC 的低延遲直播開源實現

我們在探索如何能做一個開放的低延時直播方案，將來各家雲廠商也能夠比較方便的實現，就像現有 rtmp/hls 協議一樣，推動整個直播行業低延遲化。

要實現這種方案需要做兩件事情：

• 開放的信令協議

信令協議需要滿足絕大多數廠商的媒體協商需求，同時又能儘可能的簡潔。

• 開放的媒體協議

媒體傳輸協議需要滿足在各大廠商之間有通用性的，在這之上的 QoS 能力也需要是開放的，而不能是私有的。

依據上面的要求我們選擇了 RTC 領域成熟的解決方案：WebRTC。下圖就是我們現在的實踐架構。

上圖中 WE-CAN 是雲信的全球加速 RTC 大網，媒體在 Server 間的網路傳輸依賴 WE-CAN。

邊緣媒體伺服器從 CDN 拉流到 WE-CAN 大網邊緣節點，再從 WE-CAN 大網邊緣節點發送給客戶端。

3.1 開源的信令協議實現

信令協議 上採用：HTTP+SDP 的方式。

即客戶端 POST 一個 SDP Offer

然後媒體伺服器經過協商返回 SDP Answer。

3.2 標準的 WebRTC 媒體協議

客戶端拿到 SDP Answer 以後，就是標準的 WebRTC 媒體互動流程：ICE，DTLS 加密連線，接收 RTP 流媒體。

下面是一個基本的 Web 端的拉流程式碼 Demo：

3.3 開源的 Native 媒體播放器

為了讓 Native 客戶端能夠更加方便的接入 WebRTC，我們同樣開源了一個集成了標準 WebRTC 的低延遲直播播放器： We-Can-Player ，輸入流地址，就能實現接收 WebRTC 流播放。

客戶端的架構：

開源地址： http://github.com/GrowthEase/LLS-Player

只要廠商實現了類似的協議，用這個播放器稍作修改就可以拉到 WebRTC 的流。從架構上可以看到：媒體伺服器和拉流客戶端之間互動大都是基於標準的 WebRTC，沒有私有的 RTP 擴充套件和私有的 QOS 協議，CDN 廠商甚至可以沒有自己的 RTC 大網， 只需在 CDN 邊緣節點實現自己的標準的 WebRTC 閘道器+一個簡單的 HTTP Server 就可以擁有同樣的能力。

為了優化直播體驗，我們還在 Server 端做了大量的優化。

四.優化直播體驗

4.1 首屏時間優化

GOP 快取首屏優化

假設使用者推流端的 GOP 是 5 秒，在某些情況下，拉流端需等待接近 5 秒才能收到第一個 I 幀，首屏才能開始渲染。這對強互動性直播場景來說是不可接受的。

網易雲信的解決方案是在媒體伺服器裡進行 GOP 快取，快取最近 1-2 個 GOP 的媒體包在 Server 端。當客戶端和媒體器媒體連線成功後，先發送 GOP 快取裡的媒體包，再發送當前的媒體資料。客戶端在收到媒體包後，需要根據一定的策略對齊音影片包，再加速追幀。

在具體的實踐過程中，需注意 GOP 快取大小、客戶端的 Jitter buffer 大小的配合、GOP 快取裡音影片的對齊、不同的推流端不同 GOP 長度的適配等情況。

Pacer 平滑傳送

如果推流端設定的 Gop 比較大，當拉流客戶端媒體連線成功後，一股腦的給客戶端傳送全部的 Gop 裡資料，可能造成客戶端緩衝溢位以及其他問題。這時候就需要 Server 的 Pacer 平滑傳送發揮作用了。

具體的實踐過程中，要注意 Pacer 追幀速率和客戶端追幀速率的配合。

4.2 延遲優化

WE-CAN 全球智慧路由網路

直播行業之所以能夠蓬勃發展，在技術方面，CDN 廠商的雲端能力起到了很大的推動作用。CDN 加快了邊緣節點的回源速度，邊緣節點又加快了拉流終端的接入速度。

為了加快回源速度，回源媒體服務的選擇會盡可能接近 CDN 的區域中心節點；為了優化客戶端的接入效能，拉流媒體伺服器也要儘可能的接近拉流客戶端，因此媒體如何迅速地 從回源媒體服務傳輸給拉流媒體服務 就至關重要。

WE-CAN 很好地承擔起了職責。 作為網易雲信自研的大規模分散式傳輸網路，WE-CAN 通過對各種資源智慧排程，來實現全球任意兩個媒體伺服器之間的快速、穩定傳輸。WE-CAN 起到了對比傳統 CDN 更迅捷，更穩定，更智慧，覆蓋範圍更廣的加速傳輸的作用。

4.3 卡頓率優化

網易雲信支援標準 WebRTC 媒體流接入，並通過深度優化 GCC，ARQ，FEC，RED 等各類 QoS 策略達到自適應匹配各種複雜網路的能力，在 40% 丟包的情況下，依然能流暢直播。

4.4 全鏈路延時監控

如何全鏈路的監控拉流測引入的延遲？ 媒體流在 WE-CAN 大網裡經過層層轉發，如果任何一段路由引入不必要的延遲，就會影響最終的低延遲效果。我們的做法是在 RTP 頭裡加上一個 extension，記錄 RTP 包到達每個機器的毫秒級的 NTP 時間，最後在轉發給客戶端的最後一個媒體伺服器上彙報每跳路由的時間消耗以及邊緣伺服器和客戶端之間的 RTT 時間，在最終發給客戶端的客戶端的 RTP 裡再剝掉這個 extension。儘管各個機器的 NTP 時間沒有絕對對齊，但依賴 WE-CAN 大網 的全域性 NTP 時間同步功能， 差距控制在 1ms ，這個精度足夠在工程實踐中發揮監控作用。

五.效果和後續工作

第一階段在網路 QoS 方面暫時只支援 ARQ 和 Opus 的 inband-FEC 能力。由於 WebRTC 原生支援的基於 XOR 的 FEC 能力，在抗連續丟包方面很弱，所以暫時沒有開啟 FEC，但較 RTMP 有了巨大的改進。實現了 1 秒左右的延遲，200~400ms 的首屏，0.5% 以下的卡頓。在 40% 丟包情況下，依然能流暢直播。

我們後面的計劃包括：加入包括 FEC 在內的更多的 WebRTC 標準 Qos 能力，推流測的 WebRTC 改造等。

網易智企【易+】開源計劃已正式釋出網易雲信低延時直播方案。

檢視網易雲信低延時播放器原始碼等：

http://github.com/GrowthEase/LLS-Player

http://gitee.com/GrowthEase/lls-player

其他已開源專案：

網易會議開原始碼：

http://github.com/GrowthEase/NetEase_Meeting

http://gitee.com/GrowthEase/NetEase_Meeting