近年來，直播改變了許多行業模式，其形態在不斷的演進中也逐漸豐富起來。直播在字節跳動中衍生出了KTV歌房、直播答題、互動遊戲、電商拍賣及企業直播等不同場景。本次分享我們邀請到火山引擎視頻雲音視頻直播客戶端研發負責人——徐鴻，向大家介紹直播場景中沉澱下的優秀架構能力和技術能力。
我從2013年開始從事直播相關工作，曾就職於百度貼吧，微視，之後加入了創業公司，創業公司被雲廠商收購後先後爲小米直播和字節直播提供服務，包括第一版火山直播的能力也由雲廠商所提供。
從雲廠商到字節跳動這樣一個以用戶爲中心的公司之後，工作也從“唯技術論”轉變爲“唯實際效果論”。本次爲大家介紹的直播新玩法也已在抖音及海外業務做過AB測試，並達到一定實際業務效果如用戶使用時長及滲透的增長。
![]()
分享主要分爲三部分：直播玩法的演進，直播新玩法背後的挑戰和技術演進，未來的新玩法和火山引擎所做的準備。
這三張圖中的場景應該是大家在2014年左右對直播的認知，（1圖）主播在家裏開啓直播，用戶可以在評論區留言或打賞，這也是早期的PC廠商如歪歪所做的業務。（2圖）新聞主播在專業的新聞直播間中播送新聞。（3圖）遊戲直播包括PC端遊戲直播和手遊直播，目前手遊直播佔比越來越多。
隨着用戶對直播場景的需求越來越廣，直播領域的更多玩法也湧現了出來，如連麥、K歌、聊天房等。
上圖中左2的兩位主播正在PK，此時觀衆可以去喜歡的主播直播間裏進行打賞，PK模式下的直播互動性很強，氣氛非常火熱。電商直播也衍生出了很多形式，但始終存在一個問題—端到端的延遲較大，這會導致主播上架商品時，有些觀衆無法及時看到商品鏈接而一定程度上影響購物體驗。直播拍賣如3圖中的玉石競拍也是新的電商直播形式，主播和用戶需要保持溝通互動，對延遲要求更高。圖中右1的主播正在直播探店，在直播間實時測評菜品、環境，氛圍等，觀衆根據自身感受選擇是否購買套餐。
K歌功能得到了許多年輕人的青睞，疫情期間的數據顯示K歌用戶數量處於遞增狀態。K歌場景比較複雜，因爲主播可能配置了聲卡和話筒，屏幕前的觀衆可能戴或沒戴耳機，由於此場景需要做RTC，涉及到3A處理（AEC、ANS、AGC），而安卓手機設備種類很多可能會出現各類問題。抖音用戶還可以使用右圖中的“一起看”功能，邀請夥伴一起觀看自己正在看的抖音視頻，並且支持實時語音對話。
左圖是使用JS引擎渲染的“小遊戲直播，”我們現在也有能力做一些答題小遊戲，甚至可以將能力開放出去。
兩位主播正在玩的是我和CV團隊聯合開發的彈球小遊戲，主播通過移動面部控制彈板接住來自對方的小球。這只是抖音小遊戲的示例，此外我們還在對產品進行探索，創造出更多有新奇的遊戲形式。小遊戲直播場景也比較複雜，其中涉及到JS引擎、特效、接入SDK能力、多路音頻輸入等（需要進行回聲消除等操作）。
今年抖音上線了“付費直播/線上演唱會”，至今已有陳奕迅、孫燕姿等歌手完成了直播，用戶可以在家中享受到高質量的音頻，該功能目前也正處於探索階段。
上文只列舉了部分已上線的玩法，火山引擎的直播不僅能提供以上玩法，更有能力支持其他未開發的新玩法。在探索過程中，火山引擎也遇到了許多新挑戰。
這些挑戰有：更穩定（這同時是所有業務最基本的要求），更動聽（“K歌”及“線上演唱會”對音質的需求很高），更清晰，更流暢（電商直播需要做到低延遲），更安全（保障“線上演唱會”付費用戶權益），更合規（國外已不允許使用Http做直播，國內工信部也在逐步進行規範），個性化（更懂用戶，幫助有需要的主播達到更好的直播效果）。
爲了做到“更穩定”，首先我們搭建了完善的問題快速診斷系統，線上出現問題時系統能夠第一時間診斷出故障所在的環節如推流編碼階段、特效渲染階段、CDN的上行、某一節點、下行或是觀衆端。目前此係統已經在普通直播或週年直播中進行保障實踐。其次完善的質量統計和自動歸因系統能夠在直播質量發生變化時，從多維度出發判斷故障所在地。最後，對於“K歌”，“一起看”場景，靈活的組件化設計使客戶能夠很快將娛樂能力複製到自己的業務中。
右圖展示了小遊戲場景的音頻鏈路，主要有三路輸入，分別是麥克風，遊戲音樂播放，遠端音頻輸入，輸入後進行3A處理，最後輸出的聲音可能從用戶的設備揚聲器播放，也可能從有線或藍牙耳機中播放。在上線小遊戲場景的過程中，我們也積累了許多解決音頻鏈路中出現問題的經驗。
針對右圖的音頻場景，我列舉了以下幾個可能遇到的問題：
使用場景對音頻要求複雜，不同場景走不同的音頻路由，路由切換會帶來聲音小，無聲，卡頓等問題。
存在多套Android audio api，使用複雜，兼容性不夠好，硬件3A效果參差不齊。
可插拔硬件設備多，聲卡、藍牙耳機、有線耳機質量參差不齊，引入較多物理問題如雜音、漏回聲。
每位用戶對聲音的主觀感受上不同，用戶反饋的信息不夠專業，工程師難以理解從而無法解決問題。
我們評價音頻的維度包括音質、響度、音畫同步、語音音質、音樂音質、雙講、耳返延遲。目前iOS的耳返延遲可控制在30ms，和廠商合作能將Android的耳返延遲控制在50ms之內。多媒體音頻評價實驗室的同事每個雙月會做一份專業的音頻評價，評價內容包括主觀專家測試、客觀mos分，AB測試（驗證優化後的收益）。
不僅“線上演唱會”需要做到更清晰，普通直播場景中我們也在不斷嘗試提升清晰度。
首先提升分辨率及碼率，分辨率已從2017年的360p、540p、720p，到現在有部分比例的主播可以達到1080p。提升分辨率的同時還需要適應性提升碼率，兩者之間需要進行配合，從國內外的上線情況來看，分辨率和碼率的提升對於用戶側的播放時長等都是顯著正向的。
此外，美顏算法的優化也關係到清晰度的提升。編碼上的調優這裏不再贅述。“線上演唱會”等場景需要轉碼，目前的窄帶高清技術可以在轉碼時爲用戶提供更高清的視頻。經過AB測試後，我們發現超分對於用戶的很多QoE指標都有正向指引。
清晰度的評價標準包括VMAF和自研的VQSCORE。
面對“更流暢”的挑戰，我們分別對上下行自行網絡做了優化。目前國內網絡環境較好，數據顯示抖音的卡頓率已降至非常低。火山引擎在QUIC上投入比較多，沒有去研發私有傳輸算法。在QUIC上也遇到了許多穩定性及性能方面的問題，通過不斷的探索，今年也獲得了顯著的收益，QoE也都顯著正向。主要工作包括參數調優，客戶端和服務端的性能優化（UDP傳輸在性能上比TCP更復雜），自研了擁塞控制算法，個性化策略（針對不同用戶網絡情況制定相應的策略）。
右上圖是在GQUIC中的實踐，之後會逐漸演化到IQUIC，HTTP/3目前也在跟進，整體來看，上線QUIC之後，首幀時長和百秒卡頓時長都有顯著的收益。另外，0-RTT率在海外更是達到了95%。我們也在上行使用QUIC，將其估計的網絡帶寬反饋至編碼器後在上行做網絡自適應，對卡頓的優化效果很明顯。
上文提到了電商場景下的需求是更低的延遲，行業內有三種主流降低延遲的方法：第一種是使用FLV，目前有一些廠商在做嘗試，我們新上線後測試延遲從8s降至3s左右，業務收穫了顯著的收益。第二種是切片式，字節剛開始做低延遲的時候，Apple還未提出LL-HLS，考慮到業務量級較大需要用到海外CDN，而海外CDN節點最多的服務商是Akamai，他提出了CMAF FOR DASH方案，於是我們最終選擇了CMAF。第三種RTS比較熱門，是使用RTC做直播，我們也在線上進行了大量的實踐。
CMAF將每個切片切成了更小的chunk，切片在沒有完全生產出來時就可以開始傳輸並在播放端開始解碼，CMAF要求chunk作爲傳輸單位，和原始的HLS和DASH相比，延遲可以降到更低。
綜合上線CMAF之後的數據可以發現其質量和FLV存在較大差距，左圖可以看到首幀很長，建立連接時需要經過3個RTT，我們也就這點與CMAF的作者進行了多次探討。最後經過優化，建立連接時如右圖，在請求時同時把第一個視頻和mpd信息、init信息和視頻數據返回客戶端，此外我們還在探索Server Push的方案。由於以上優化上線之後還存在差距，所以我們將CMAF的底層傳輸協議切換爲了QUIC，還支持了HTTP/2，切換之後的首幀及卡頓都獲得了不錯的收益。
在低延遲上，我們也上線了基於RTC的RTS方案，RTS方案也需要在RTC基礎上做許多改動，以下列舉了幾個方面：
編解碼類型的擴展，原始的RTC只支持H.264類的編碼標準，需要拓展，音頻也需要做一些拓展。
信令的改造，RTC建立連接的過程相較於CMAF更爲複雜，所以其RTT更多，需要對其進行採點、改造、定義SDP。首幀優化包括簡化ICE，信令底層切換爲QUIC傳輸，目前首幀時長和FLV的差距越來越小。
RTC播放器和傳統播放器的結合，方案如右圖，收到RTP包後經過音視頻jitter buffer做音視頻同步，後面的解碼、後處理、音視頻渲染都是由傳統播放器組件進行。一定程度上避免重複超分和音量均衡操作。
信令加密，進行海外業務時在部分場景下需要做加密協議的傳輸，需要將其切換爲QUIC或者HTTPS。
在“線上演唱會”中提到了保障付費用戶權益，防止盜播也是需要注意的地方，我們在打擊黑產中積累了許多經驗。除了更安全之外，海外業務中也需要注意更合規，在推拉流過程中要進行加密傳輸。保護直播內容方面字節採取了DRM方案（數字版權管理解決方案（Digital Rights Management）。
如何做到個性化也就是更懂用戶，首先需要針對不同的場景、網絡類型、網絡級別、機型打分等
定製不同的參數。
其次是端智能，利用
AI
推理引擎進行參數個性化。
隨着直播間形式越來越多，主播也有了更多手機端無法完成的需求如綠幕摳圖，字節正在嘗試研發硬件—自研直播一體機，在視頻編碼及音頻方面做了許多優化。
通過完善的質量監控和問題診斷系統做到“更穩定”，通過音視頻鏈路的優化方案和強大的音頻團隊做到“更動聽”，同時RTC團隊不斷進行清晰度優化實踐，在網絡傳輸及網絡優化方面持續探索。應用CMAF方案和RTS直播技術應用做到3s以下和1s以下的低延遲直播。在安全合規方面使用RTMPS和HTTPS進行加密傳輸。利用端智能實現個性化。嘗試研發硬件爲主播提供更專業的服務。
大家應該注意到今天Facebook更名爲了Meta，所以我認爲VR直播領域有很大前景。
圖中是聯通列舉的VR直播全鏈路架構圖，在專業VR攝像機進行拼圖或由攝像機採集並在本地PC進行拼圖後推流到服務器，這兩種方案對應的傳輸方式也不同。可以在播放端做拼接，也可以通過傳輸多路流後在播放端做拼接。目前這些方法都處於探索階段，近期會支持全景播放，不久後也會支持VR播放。
圖中是劉德華在抖音的直播，直播使用專業的影視級攝像機進行拍攝，清晰度非常高，並且背景是虛擬的，實現了混合現實的效果，這次直播的觀看人數達到一億次。整體來看，清晰度和混合現實直播的效果都很不錯。
右圖展示了從不同角度看比賽，觀看體驗相較於固定角度有明顯提升，在採集端需要做許多工作，如左圖用手機做自由視角直播採集推流，用更專業的設備也可以達到更好的效果。
谷歌發佈的starline項目，在直播端用高分辨率攝像頭和數十個定製深度傳感器，在觀衆端用高清顯示器，使用戶身臨其境。對光場視頻感興趣的同學可以訪問https://blog.google/technology/research/project-starline/。
雲遊戲也是火山引擎正在探索的方向，圖中的玩家正在操作遊戲，但實際上游戲是在雲端服務器中運行，並由雲端服務器將遊戲場景渲染爲視頻音頻流，通過網絡傳輸給玩家遊戲終端。
除了視頻方面，各大廠也在嘗試在音頻方面使用戶更有現場感，如Apple現在已經能夠支持空間音頻。圖中分別是空間音頻的兩種採集方式。
LiveVideoStackCon 2022 音視頻技術大會 上海站，正在面向社會公開招募講師，無論你所處的公司大小，title高低，老鳥還是菜鳥，只要你的內容對技術人有幫助，其他都是次要的。歡迎通過 [email protected] 提交個人資料及議題描述，我們將會在24小時內給予反饋。
本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
