抖音大型直播畫質優化實踐:「62 億人次觀看的亞運會直播」有哪些創新領域

2023-10-25     InfoQ

原標題:抖音大型直播畫質優化實踐:「62 億人次觀看的亞運會直播」有哪些創新領域

作者 | 魯冬雪

亞運會、大運會、中國網球公開賽、上海網球大師賽……2023 年可謂是「體育大年」。在拿下世界盃轉播的版權後,抖音這次又成為了亞運會持權轉播商、中央廣播電視總台直播合作夥伴,對亞運會比賽全程進行 4K 超高清直播,並支持回放。在「轉播」的背後,火山引擎作為抖音亞運會直播背後的主力技術服務商,在整個賽事轉播過程中通過自研 BVC 編碼器、畫質優化、超低延時等視頻雲技術和 VR 觀賽等互動玩法,幫助用戶實現了更高清、更交互、更沉浸的觀賽震撼感,切實打造了新一代觀賽新體驗。

1極致的直播低延遲體驗勇攀「領域新峰」

亞運會期間的抖音直播擁有億萬級的流量,在這樣大規模並發下,火山引擎視頻雲想要提供 4K 超高清超低延遲看播能力,首先要克服的就是「穩定流暢地做到更低延遲」這樣的巨大挑戰。

其實從亞運會直播的整個信號分發鏈路我們就能看出各個節點可能會出現延遲的機率有多麼大。生產環節延遲其實主要來源於兩部分,其一是信號源,網絡流信號源在給到抖音之前存在多個環節,每個環節都可能會對最終的延遲有影響,但這一部分技術團隊可以影響的比較少;其二是演播室製作環節,演播室在收到媒體的源流之後,需要加上解說和包裝,會引入一定的延遲。在直播的傳輸環節里,對延遲影響大的主要是轉碼、分發和播放緩衝和 CDN 的分發環節。

圖:信號分發鏈路

為此,在低延遲方面,火山引擎視頻雲團隊(下文稱「團隊」)做了許多攻堅和優化工作。在攻堅之前,最主要的是測量出有效的全鏈路延遲數據,找到最優的測量方法——而團隊在經過多次探索後,最終採取了以下兩個方法(僅適用演播室推流到抖音播放鏈路):

  • 方法一(拍照):視頻畫面中有時鐘展示,通過同時拍照兩個播放畫面的方式,記錄同一時刻兩個畫面,然後通過照片中的時鐘做差來計算;
  • 方法二(手動秒表計算):視頻畫面中無時鐘相關內容,則從延遲低的視頻畫面中選取具有標誌性易識別的幀啟動秒表,然後觀察延遲高的畫面出現同樣的幀畫面時,停止秒表,記錄秒表結果為延遲對比結果。

圖:延遲測量手冊

在有了衡量延遲的基準線後,團隊便展開了「低延遲」攻堅工作。這次亞運會的轉播,抖音的多個演播室是由多家第三方公司負責的,第三方公司的製作規格不一。雖然在正式比賽之前經過大量的溝通,基本確認最重要的兩個演播室的技術方案和使用的編碼系統是一致的,但是在演播室環節仍然引入秒級別的延遲,和供應商工程師溝通後,短期內為了保證穩定,沒有再進一步壓縮,這部分引入的延遲和行業同類產品也是一致的。同時,使用實時的轉碼模式,轉碼器引入的延遲一般在幾百毫秒以內甚至更短。

圖:一次直播的簡化的流程

在整個項目中,團隊主要採用了兩個低延時直播方案——FLV 方案和 RTM 方案。關於 FLV 方案,FLV 是現在國內主流直播播放使用的協議,為了滿足亞運會轉播需求,團隊在世界盃賽事轉播過程中已經驗證過的 FLV-3s 方案和基於基於 FLV 方案做更低延遲下探的基礎上,配合輸出了精細的追幀、丟幀策略。

要知道,播放器音視頻數據流轉時序一般是「網絡 IO 下載音視頻數據到播放器緩存 buffer解碼器從 buffer 中取數據解碼並降解碼後的數據存入待播放緩存音畫同步等播控策略渲染播放音視頻幀」。由於進一步下探延遲,卡頓也會隨之惡化,反而延遲逐漸累積增加達不到低延遲的效果,因此延遲下探必須配合延遲追趕播控策略來確保延遲增大後可及時追趕恢復到低延遲。於是團隊在亞運會項目上總結出了一套兼顧延遲與 QoE 指標平衡的播控策略:

  • 輸入:播放器當前 Buffer 時長、歷史 Ns 內 buffer 抖動、歷史 Ns 內卡頓信息以及追幀參數配置。
  • 輸出:基於 buffer 抖動 & 歷史卡頓信息,來定性衡量網絡質量,判斷是否可以追趕,只有在網絡質量良好時才能觸發追趕邏輯避免卡頓;同時追幀採用雙閾值,並且支持可配置,可以控制追幀持續時長不超過 Ks,同時也可以保證不頻繁變速。此外,追幀速度可配置,保證倍速變化不超過一定輻度。三管齊下,達到了目標播放速度。

圖:策略可配置參數以及含義映射

關於 RTM 方案,參考了 WebRTC,可以讓端到端延遲直接進入 1s 以內,RTM 優化的目標是在延遲降低的情況下,用戶核心體驗指標對齊或者優於大盤的 FLV 方案。在世界盃的多場比賽中,RTM 方案也承擔了一定量級的 CDN 容量,核心鍵指標上都對齊了大盤,穩定性和質量得到了充分的驗證。

首先,為了讓 RTM 的綜合指標對齊 FLV,從若干角度來進行 RTM 的播控邏輯定製化,於是所有的優化都是圍繞著核心用戶體驗指標進行展開:

  • DNS 節點優選、SDK 信令預加載、UDP 連通性預探測主要解決的拉流成功率相關問題。
  • SDP 信令相關優化主要解決信令時間消耗的問題(首幀時間)與成功率問題。
  • RTC 內核播控定製化主要解決播放的卡頓問題。
  • 播放器播控邏輯結合解決的音畫同步與渲染策略的問題。

其次,團隊優化了「首幀時間」。我們都知道,傳統的 RTC 技術採用 SDP 信令方式進行媒體能力協商,但是 HTTP SDP 信令交互存在許多弊端,比如弱網環境下,HTTP 信令建聯成功率不理想;導致播放請求響應緩慢或超時;又比如,SDP 交互傳輸 SDP 文本的內容很大、建聯的成本較高,初始化的成本無法忍受。所以相較於 FLV 的 HTTP 請求完成後直接完成建聯和媒體數據直接傳輸,我們可以採用新的信令模式——MiniSDP 信令。這種基於二進位編碼的壓縮協議,提供對標準 SDP 協議進行壓縮處理,可以降低信令交互時間,提高網絡傳輸效能,降低直播拉流首幀渲染時間,提高拉流秒開率 / 成功率等 QoS 統計指標。利用 UDP 網絡傳輸的 MiniSDP 壓縮信令方式,單個 UDP 數據包請求即可完成 SDP 完整壓縮信息的傳輸,信令建聯的成功率和首幀時間可得到大幅優化。

圖:採用 MiniSDP 信令進行媒體協商通信的信令交互流程

第三,經過線上的 AB 實驗,團隊發現 RTM 拉流成功率相比 FLV 持續存在著一定的差距,經過分析,大家發現用戶的網絡等級質量和用戶的拉流成功率存在一定的正相關性。於是,團隊拉流網絡等級篩選基於網絡質量預估信息,評估 TCP/UDP RTT 和數據下行吞吐率,為用戶確定網絡等級,選擇優質網絡質量的用戶採用 RTM 拉流以降低失敗率。在拉流前,根據用戶請求的 URL 所屬的 CDN 邊緣節點,發起 UDP 探測。在一段時間內發送數據包觀察對應 CDN 節點的 RTT 和丟包率,只有滿足 RTT 和包率兩者在特定的閾值範圍內才會認為 UDP 傳輸可以保證質量和組幀成功率。同時,通過信令預加載,在當前的點播 / 直播房間中預先加載下一個直播間的信令信息,提前做好 SDP 加載,降低下一個房間的首幀上屏時間。就這樣,團隊完成了「拉流成功率」的優化。

第四,團隊完成了「卡頓」、「播控邏輯」的優化。團隊通過對比 FLV 和 RTM 的播控策略,發現傳統的 RTC 場景優先保時延,全鏈路會觸發各種丟幀,FLV 直播場景會優先保證「不丟幀、良好的音畫同步」的良好觀播體驗。那 RTM 要想減少卡頓,取得 QoE 的收益,播控策略就需要進行定製化。在播控邏輯方面,團隊完成了以下優化:

  • RTM 網絡傳輸 SDK 的抽象:將內核進行改造,復用引擎中的網絡傳輸 - 組包 -JitterBuffer/NetEQ 模塊;去掉解碼 / 渲染等模塊;將音視頻的裸數據拋出供播放器 demuxer 集成。
  • 解碼器復用:降低解碼器重新初始化的時間,降低解碼首幀延時;復用解碼器 - 渲染器的播放緩衝區控速邏輯。
  • 音畫同步的優化:RTC 音視頻出幀後在播放器側按照 FLV 的播控邏輯進行二次音畫同步處理;按照 audio master clock 主時鐘進行渲染校準,視頻幀渲染同步到音頻時間軸上。

此外,本屆亞運會超高清檔位的解析度達到了 4K,對 RTM 方案的性能帶來了很大的挑戰,但團隊都很好地解決了。比如 4K 高清檔位卡頓嚴重卡頓的問題,團隊優化了 NACK 策略,保證了更大幀的組幀成功率;又比如針對 CPU/GPU 內存問題,團隊優化了 video 傳輸 pipeline,減少了不必要的 raw 數據格式轉換。

在團隊的支持下,在亞運會的轉播過程中,抖音的延遲一直領先於相同信號源的其它產品 30s 左右。這也看出了團隊的強悍之處,能夠根據具體業務需求和技術挑戰不斷完成自我疊代。目前,火山引擎視頻雲在 FLV、RTM 、切片類協議的延遲優化、XR 直播的延遲優化等方面已經有了較為完整的疊代方向。

2新一代 BVC 編碼器成功實現「降本增效」

視頻基礎體驗的關鍵要素包括清晰度、流暢度、低延遲等,而視頻編碼是整個技術體系的基座,編碼效率的顯著提升能夠在同等碼率下極大提高畫質以改善用戶體驗。但編碼效率的提升並非易事。如何在保證畫質不變的情況下,顯著提高壓縮率,同時滿足實時性、低延遲的要求,是當下持續性的技術挑戰。

在世界盃的轉播過程中,抖音基於 BVC 編碼器給數億觀眾帶來了極致的視頻體驗,而本屆亞運會中,抖音首次採用了團隊自研的新一代編碼器 BVC。相比上一代編碼器 BVC,新一代編碼器 BVC 引入了大量新編碼工具和算法,具有低碼率高計算複雜度特點,在本屆亞運會轉播過程中,新一代編碼器 BVC 實現了 1080P+50FPS 的實時編碼,在畫質不變的情況下,相比上一代編碼器 BVC 實現了 20% 左右的碼率節省,提升了用戶體驗,降低了帶寬成本。

圖:BVC 編碼視頻與新一代編碼器 BVC 編碼視頻對比

據悉,新一代編碼器 BVC 擁有簡潔的工程架構,團隊測試了直播場景下的所有編碼工具和算法,篩選出了性價比高的工具和算法集合,並基於這個集合重新了設計輕量級的架構,其能最大化減少計算流程損耗。新的編碼器架構對整個編碼流程進行了重新梳理,去除原先複雜的情況耦合,為特殊工具單獨設計流程,實現了編碼流程的最簡化。在算法基本不變的情況下,為新一代編碼器 BVC 節省了超過 30% 的複雜度。同時,新一代編碼器 BVC 針對直播場景進行了並行框架的重新設計,優化後的新一代編碼器 BVC 在 CPU 利用率方面相比上一代編碼器提升 50% 以上。

除了工程架構外,新一代編碼器 BVC 還增加了大量的快速算法,以達到高解析度 + 高碼率 + 高幀率的實時編碼。其還重構了編碼塊劃分的框架,根據周圍塊和歷史劃分劃分信息,靈活決定自上而下或者自下而上的劃分順序,並自適應決策劃分深度的嘗試方向,大幅減少了無效的劃分嘗試,降低了編碼複雜度。新一代編碼器 BVC 為直播場景增加的上百個快速算法,將整體編碼速度提高了 2 倍以上,同時壓縮率的損失在 5% 以內。

因為本屆亞運會還有電競項目,所以新一代編碼器 BVC 便分別針對運動、遊戲這兩種場景進行了優化。新一代編碼器 BVC 開發團隊調整了數十個編碼參數來控制不同編碼算法在運動、遊戲場景中的性價比,在獲得壓縮率提高的同時實現了編碼加速。此外,還對碼率控制進行了調優,減少了高運動場景中畫面模糊的情況。

3增強插幀多項技術繪製「畫質美學」

對於媒體平台轉播來說,不同賽事節目涉及鏈路眾多,且不同賽事之間存在差異,如何保障各鏈路的畫質穩定並進一步提升畫質是一個巨大的挑戰。大型賽事直播涉及鏈路較長,不同賽事鏈路存在一些差異,但基本都是現場信號經過演播室的製作傳輸給 CDN 再進一步分發到用戶側。從畫質角度來看,整個鏈路可分為畫質檢測與畫質優化兩個部分,對於 CDN 之前的鏈路以畫質監測為主,以發現問題 / 定位問題 / 推動對應鏈路人員解決問題為目的。

隨著賽事錄製技術的提升,越來越多的大型賽事都用上了 4K HDR 錄製標準,畫質清晰度也不斷提升,那隨之而來的是更大的帶寬壓力;而且,為了兼容消費端不同的看播設備和不同的帶寬條件,服務端需要轉出多種不同解析度不同碼率的版本供看播端選擇。

相比 SDR 信號,HDR 拍攝的片源擁有更廣的色域,更大的動態範圍。但對很多終端顯示設備而言,並不支持 HDR 信號播放,所以團隊通過 ToneMapping 算法將 HDR 信號轉換為 SDR(標準動態範圍)信號。

HDR 在轉換到 SDR 信號的過程中不可避免地會產生一些信息損失,常用的一些 ToneMapping 方法(如 Reinhard、Filmic、Hable),本質都是設計固定的映射曲線實現從 HDR 信號 到 SDR 信號的轉換,同時儘量保持對 HDR 效果的還原。但直播賽事場景多變,且現場動態範圍跨度極大,團隊便提出了內容自適應 ToneMapping 算法,通過統計視頻內容的實際光照情況動態地進行 ToneMapping,從而得到更優效果。

圖:左 - 內容自適應 ToneMapping;右 -Hable 算法

隨著音視頻行業和攝影設備的發展,高解析度的視頻源占比日益增多,大部分視頻需要在服務端進行降採樣來配合自適應碼率策略,因此降採樣算法的優化也是提升 QoE 的關鍵。在過去的業界實踐中,視頻處理算法往往專注於提高解析度(如超分算法)或者保持解析度(如降噪算法)的處理範式,而幾乎忽視了對降低解析度方法的研究。所以團隊自研了一種基於深度學習的圖片 / 視頻下採樣算法——BAS(Byte AI Scaling)算法。不同於固定運算元的 bicubic 等降採樣算法,BAS 算法基於深度學習使用高精度數據訓練模型,緩解傳統方法帶來的頻域混疊與頻域截斷問題,降低鋸齒感、減少細節丟失。

圖:4K 超高清圖源降採樣到 480p 解析度,左圖 -BAS 算法處理結果,右圖 - 傳統 bicubic 算法處理結果

在與 bicubic 算法的定量對比中,BAS 基於 PSNR 指標取得了 -20.32% 的 BD-Rate 收益,意味著相同重建誤差水平下可以節省 20% 以上碼率,而同等碼率下則可以提升畫質水平。而對於更符合人眼感知特性的 VMAF 指標,BAS 同樣取得了 -20.89% 的 BD-Rate 收益。

此外,因為現在消費者已經習慣了高幀率的流暢視頻體驗,所以針對低幀率場景,團隊使用了智能插幀技術,通過對前後幀的內容進行光流估計,根據光流信息將前後幀像素都轉換到中間幀,然後進行整合、生成中間幀,提升視頻幀率,減少觀看時的卡頓感。而針對電競類對幀率要求較高的場景,該技術團隊做了額外優化:

  • faster 光流模塊和 faster 修正模塊使用 部分通道卷積代替普通卷積,在保持效果的同時減少卷積運算;
  • 採用推理下採樣的方式,對輸入進行內容自適應下採樣,作為光流模塊和修正模塊的輸入,再將輸出上採回原解析度用於原始輸入的 warp 和整合,以達到進一步減少計算量的效果;
  • 工程上通過運算元融合、半精度的方式減少 IO 和浮點運算,相比工程化前加速 1 倍多;
  • 通過多 GPU 部署的方式拓展智能插幀能力,使得視頻插幀能在更高解析度(4k)的場景下能實施部署。

在本屆亞運會的轉播過程中,智能插幀在處理電競項目場景中複雜運動的「英雄名字」小文字時,通常會因為光流估計不夠準確而導致插出來的幀文字的位置不夠準確,導致偽像出現,於是團隊在訓練過程中加入更多的隨意移動或者靜止的較小文字,使得模型能夠在訓練過程中更多地注意處理小文字的複雜運動,從而達到更好地插幀效果。

圖:左 - 優化後;右 - 優化前

另外值得一提的是,為了兼顧視頻碼率和主觀畫質,團隊使用了基於 LSTM(長短期記憶網絡)的時域 ROI 技術,通過人眼顯著性區域檢測和編碼相結合的方式,讓碼率在畫面上的分配更加合理。除了模型設計之外,ROI 算法中另一大難點是 saliency(顯著性物體檢測)數據的獲取,通用的 saliency 數據集在大型賽事中的表現並不理想。針對這一問題,團隊收集製作了自己的專用數據集,並且對一些大型賽事做了專用數據集。

同時,為了提升低檔位、低解析度的視頻清晰度,團隊為本屆亞運會轉播提供了「超分算法」。該算法是一種基於機器學習 / 深度學習方法,根據視頻信息對其進行空域、時域建模重構出缺失的細節,將低解析度的視頻重建出高解析度視頻的技術。當用戶看播端網速較慢切換到 480P/720P 等低分辨檔位時,端上超分算法就會被觸發以提升畫面清晰度。

圖:左 - 源流 1080P,右 -720p 超分後

4創新的 VR 直播技術實現「沉浸式現場」

今年杭州亞運會的火炬點燃儀式是歷史上首個「數實融合」點火儀式,在觀賽方式上,PICO 推出的 PICO4VR 一體機作為一種虛擬現實設備,以其雙目 4K 清晰度和 105 度的超大視角,無論是比賽過程還是賽後回放,觀眾都可以切換到多個不同的觀看視角,給觀眾帶來了更加真實的觀賽體驗。

觀眾佩戴 PICO4VR 一體機觀賽,不僅能夠通過視覺感受到沉浸感,還可以通過觸覺的反饋來增強身臨其境的感覺。比如,在頒獎典禮上,觀眾不僅能看到會場上空綻放的煙花,還可以揮動手中的螢光棒為選手加油助威,同時手柄的馬達模擬了充氣棒或螢光棒碰撞時的震動感,使觀眾能夠在家中感受到與現場觀賽相仿的熱情氛圍。

VR 直播的沉浸感以及高交互性是普通直播無法比擬的,但是這也導致了傳輸層需要承擔更大的壓力——解析度為 8K x 4K 或 8K x 8K,源流碼率達到 50M 甚至 120M,非常容易因為擁塞導致卡頓、延遲增大,甚至無法正常解碼播放。

為了解決這個問題,團隊將 8K 的視頻切分成多個塊(tile),只傳輸用戶視角(viewport)內的部分超高清塊,其它區域只傳輸 2K 或 4K 解析度的縮小後的背景流,在用戶切換視角的時候再去重新請求新的超高清塊。同時團隊基於 UDP 的內容優先級感知傳輸方案,優先保障高優數據的傳輸,對於低優數據可選擇非可靠傳輸,即使丟失也無需重傳,保證 XR 直播低延遲的同時也杜絕了過大的「視覺失真」。

另外值得一提的是,Pico 還在本屆亞運會中打造了一個用戶專屬的賽事社交空間,觀眾可以邀請遠方的好友一起觀看比賽,在虛擬空間中共同分享運動的激情。這個過程中,Pico 就是基於火山引擎多媒體實驗室沉浸音頻與 RTC 空間音效能力,讓用戶可以隨著位置的移動、頭部姿勢的變化,差異化地感受到節目聲音與同場觀眾的聲音對應的空間變化。

5寫在最後

在不斷升級的觀賽體驗和極致追求中,視頻雲技術的每一次細緻入微的技術疊代和追求極致的產品突破,無疑為用戶帶來了不斷進化的感官體驗,使得賽事直播的極致追求成為可能。通過電視、電腦、手機、平板等各種終端設備,全球億萬觀眾足不出戶,就能第一時間、自由視角觀賽,身臨其境感受賽場氛圍。這是科技與體育賽事的完美結合,也是技術進步為觀眾帶來的獨特體驗。大家如果想了解更多關於視頻雲在大型直播過程中的實踐細節,可以點擊「閱讀原文」獲取《身臨其境 沉浸互動——大型賽事直播實戰白皮書》進行閱讀。

在未來,我們期待看到更多的賽事直播能夠藉助視頻雲技術突破物理空間的限制,讓觀眾獲得如臨現場,甚至超越現場的暢爽體驗。當然,我們也非常期待火山引擎視頻雲能夠繼續領跑這一趨勢,為全球的觀眾帶來更多令人滿意的賽事直播體驗。

文章來源: https://twgreatdaily.com/zh-hk/7f61889a42daa3e4d75982b88b4a136c.html