天天看點

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

阿裡妹導讀:

受疫情影響,各中國小校延遲開學,優酷宣布發起“在家上課計劃”,為無法到校教學的老師們提供免費的直播授課工具,直播課程将于2月10日開始陸續上線,在直播過程中如何提升和保障流暢的互動體驗?優酷直播流媒體團隊做了低延時流媒體技術的探索實踐,實作了在使用者體驗不下降的基礎上,讓主播與主播延時<300ms,播與粉絲延時<600ms,解決了直播間各類互動問題。接下來,阿裡文娛的乾戒将具體介紹探索過程。

一、行業的使用者體驗分析

互動直播場景中有主麥主播、輔麥主播、粉絲三個要素,這三者之間關系構成了直播間的各種互動場景。

1.主麥主播、輔麥主播可以無障礙地進行音視訊通話,通常延時在300ms以内;

2.(主麥、輔麥)主播與粉絲互動場景;主播說話,而粉絲以文字、圖檔、送禮物等方式進行互動;這種差别造成一次互動的延時在3000ms以上,想象一下如下互動場景:

進場特效播放完依然沒有收到問候;

當主播與粉絲一起玩“王者榮耀”時需要偷塔時,無法滿足;

當主播與主播PK時,其中一個主播最後幾秒想拉票時,無法滿足;

... ...

如何提升直播過程中三個要素之間的互動,讓主播與主播之間、主播與粉絲之間達到一緻的使用者體驗?優酷直播流媒體團隊做了低延時流媒體技術的探索實踐,實作了在使用者體驗不下降的基礎上,讓主播與主播延時<300ms,播與粉絲延時<600ms,解決了直播間各類互動問題。

二、作繭自縛:傳統解決方案

傳統直播解決方案中主播之間以實時通信的方式傳輸延時小于300ms,但是主播與觀衆之間通過鍊路傳輸、CDN分發整個延時往往在3000ms左右,如下圖:

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

從圖上我們可以看到産生延時的主要原因就是RTMP傳輸鍊路、CDN環節、觀衆播放器緩存三個環節産生;如果想要提升使用者的體驗,就必然從這三個環節上做改動,尤其是CDN把持了傳輸鍊路環節,然而CDN不是你想改就能改的。

基于這樣的分析我們可以得出這樣的結論:

  • 視訊CDN大大減少了開發人員的工作量;
  • 你能做多好,取決于你控制的鍊路有多長;
  • CDN側不可控,是以等待CDN的改變也遙遙無期;
  • CDN側不可控,是以做一個和伺服器互動的低延時播放器也沒戲;
  • 傳統的解決方案是一張溫柔而又可怕的溫床。

三、蛻變之痛:低延時直播系統

針對上面的問題,我們解決方案簡單粗暴:做一個全鍊路都可以控制的流媒體傳輸系統,如下圖:

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

1. 山重水複疑無路——項目挑戰

想好就做,但是蠻幹往往沒有好結果。這個設計使用CDN的思想改造了整個實時通信系統,既兼顧CDN的大并發分發,又兼顧實時通信的低延時。無論是談實時通信系統還是談CDN都不是個小題目,何況兩個融合的系統,這裡面“水很深”“坑很多”。

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

然而挑戰還不止這些,實際的工程中,如何降低延時、如何保證流暢率往往有是互相沖突的話題,降低延時就要降低播放側buffer和服務側的buffer,随之卡頓率就會上升;而想流暢率上升就要增大buffer,随之延時就變得更長;無論怎麼調整buffer,問題都這裡,如何解決呢?

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

2. 柳暗花明又一村——解決方案

低延時直播系統根據具體業務需求,融合CDN、私有實時通信協定、WebRTC、雲原生等技術完美解決了項目的各類苛刻要求,把問題模型轉換為技術角度看:

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

2.1 延時的産生及可控性分析:

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

從上圖我們可以看出來,可控的唯二也就是傳輸層、播放器buffer兩部分了。在低延時項目中RDN系統控制了整個傳輸過程,優化了每一個細節,把延時降至118ms以内,低延時播放器自适應動态控制buffer大小、嚴格控制音視訊加減速,保證流暢率的基礎上又使延時在415ms以内。通過控制播放側目标延時實作流暢優先、延時優先兩種政策,滿足主播連麥互動、粉絲互動兩種業務場景。

2.2 CDN進階為RDN系統

傳統的CDN、視訊會議系統可以自行檢視網上的方案,RDN系統是一個融合CDN架構,并以視訊會議媒體伺服器為節點的系統。RDN在進行媒體傳輸采用懶加載的方式進行,當主播把流傳輸至接收的邊緣節點,此時如果有觀衆播放流,會通過GSLB傳回最近的邊緣節點并進行資源的索引把流快速的下發至播放側的傳輸SDK。媒體流的分發示意圖如下:

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

2.2.1 唯快不破——傳輸延時如何降至最低

傳輸延時、播放側延時是唯二可控的部分,且看我們如何把傳輸降到最低:

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

2.3 播放器進階為低延時播放器

低延時播放器是系統中延時控制的重要環節,是系統中唯一延時可控且可調的部分。相比于傳統播放器功能既要滿足流暢率、秒開率、音畫同步等使用者名額,又要保證延時足夠低。低延時播放器架構圖:

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

2.3.1 使用者體驗第一——低延時場景下如何保證使用者體驗

低延時播放器通過定制優化後的neteq,抵抗網絡的抖動、丢包等問題,顯著提升弱網情況下的使用者體驗,通過濾波後的音畫同步方案,保證在音視訊快速加減速同時又能保證使用者的體驗。

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

2.4 扁鵲全鍊路監控系統

扁鵲系統收集端側、伺服器側日志,不但整個鍊路的服務品質,也用于排查各類線上問題。

停課不停學,優酷直播如何将網課點名延遲降到0.6s?

四. 羽化之美:資料報告

在流暢率、秒開率不低于傳統直播方案的場景下,互動延時名額大幅降低86%。系統自2017年穩定運作至今,為直播使用者提供了低延時互動、點選即見、清晰、流暢的高品質互動直播間。并支撐了來瘋秀場PK,低延時直播各類場景,保證了來瘋兩年多的各類比賽順利進行。

五. 回顧曆史:我的思考

低延時直播系統是由傳統直播技術、實時通信技術、WebRTC技術融合,專為互動直播而生的系統。達到了文字和音視訊同步的效果,像“歡迎大哥”“拉拉票”、“打他”這些歡迎、拉票等直播互動再也不需要等待。回顧整個系統的誕生,我的技術思想也在逐漸的變化,回想初次接觸這三個技術:

  • 傳統直播技術 = RTMP、CDN、ijkplayer
  • 實時通信技術 = MCU、SIP、RTP/RTCP
  • WebRTC技術 = JSEP、P2P 、SFU、ICE、SDP、neteq

後來深入了解這些技術細節、互動直播業務的需求、開發過程中的痛點,開始思考可以用這些技術再往前走一步,自研一套低延時直播系統一勞永逸的解決這些問題。經過前期詳細論證确定正确方向後,雖然過程困難重重,秉着“隻要路對了就不怕遠”“隻要精神不滑坡,方法總比困難多的”精神,最終還是安全的抵達了對岸。