從2016開始，騰訊啟動將傳統(tǒng)的音視頻解決方案逐步部署在騰訊云上，從傳統(tǒng)的FFmpeg、OBS、RTMP開始提供了第一代直播服務。隨后演進到以QUIC與HLS低延遲直播。最后在網(wǎng)絡擁塞算法與Codec層面做進一步調(diào)優(yōu)，進一步提升復雜場景下用戶的QoE體驗。本文根據(jù)騰訊視頻云終端研發(fā)總經(jīng)理常青在LiveVideoStack2019北京音視頻技術大會上的分享整理而成。

文 / 常青

整理 / LiveVideoStack

大家好，我是騰訊視頻云終端研發(fā)負責人常青，本次分享的主題和內(nèi)容是關于騰訊音視頻終端這些年來的進化演化以及在客戶方面的實踐應用，所以“進化”也是本次分享的主題詞，說到進化大家可能首先聯(lián)想到的是達爾文的進化論，因此我會先以一段故事來引出之后的內(nèi)容。

達爾文在剛剛公布進化論的一段時間，在當時的社會引起了軒然大波，尤其是在“神創(chuàng)論”占據(jù)主流思想的情況下，很多名流都更愿意相信人是神創(chuàng)造出來的，并且舉了很多反例來挑戰(zhàn)達爾文。比如有人就提出：像人眼如此復雜的器官是如何進化出來呢？受限于當時人類的認知，達爾文本人也未必能夠回答的清楚，但隨著科技的進步以及科學的驗證已經(jīng)可以嘗試的去解答這樣的問題。

1. 簡介

地球上生物的進化首先是由單細胞生物進化為多細胞生物，多細胞生物（浮游生物）在某些特定條件下發(fā)生基因突變形成感光細胞，可以在感應光線變化的同時驅(qū)動鞭毛避開海面周圍的紫外線。感光細胞聚集成細胞群并形成凹陷，使得此時浮游生物不僅可以感受到光線強弱，甚至可以感受到光線的方向。之后凹陷越來越大，逐步加深形成帶孔眼球，但成像效果并不好，此時的眼球已經(jīng)可以通過空隙收縮完成“小孔成像”，但光線進入量有所減少。之后通過角膜覆蓋和產(chǎn)生晶狀體完成光線進入量和成像效果增加，逐步形成一個簡單的生物版照相機。

2. LiteAVSDK技術演進之路

2.1 LiteAVSDK技術架構圖

回到本次分享的主角LiteAV音視頻框架，它是騰訊云線上音視頻產(chǎn)品的總框架。稱為LiteAV也是在開發(fā)之初對它的愿景，希望它能做到很輕、很小、很簡單，而在四年的發(fā)展歷程中，它也像我們剛才提到的眼睛一樣，從一個小小的感光細胞開始，不斷進化，最終形成了一個功能強大的音視頻產(chǎn)品。。它的設計思路是采用統(tǒng)一的架構，包括統(tǒng)一的底層框架、一系列可復用的音視頻模塊和工作組，最后再加上網(wǎng)絡協(xié)議就可以包裝出一系列基礎性的功能，包括直播的推流和拉流、小程序音視頻方案、短視頻、播放器以及融合音視頻解決方案的TRTC都是基于這一整套的框架去實現(xiàn)，所以目前整個騰訊音視頻的產(chǎn)品線都逐漸使用這套整體框架提供服務。

2.2 Step1：始于播放器，自研播放引擎

時間跳轉(zhuǎn)到2016年，騰訊開始從傳統(tǒng)的音視頻解決方案轉(zhuǎn)到云上的音視頻解決方案。在開發(fā)初期，團隊的立足點是最先解決播放問題，當時云上的客戶推流大多采用OBS的解決方案，但在播放中被詬病最多的是播放卡頓和延遲不可控等問題，因此騰訊開始從這個角度思考如何去解決，在調(diào)研中我們發(fā)現(xiàn)絕大多數(shù)客戶播放器的解決方案都是基于FFmpeg，FFmpeg的解碼能力非常強，但在網(wǎng)絡層設計之初是用于本地文件播放以及遠程點播文件，緩存機制為“下載-積攢-播放”，由此產(chǎn)生了延遲不可控的問題，因此我們決定在播放器上做文章。

騰訊在很多年前就開始做音視頻方面的產(chǎn)品，QQ 和 微信的視頻通話中有很多技術都可以直接搬過來用，比如延時控制、語音聲學變化以及人聲和背景聲的分離等技術等，同時還可以針對客戶的訴求和場景，做一些針對直播場景下音畫同步的邏輯，最終構建出一套自研播放引擎，它最大的優(yōu)勢則是在延遲控制方面做得很好。

比如相對于常規(guī)播放器，觀看直播的觀眾之間進度是不同的——有些觀眾與主播的時差是三秒，而有些則達到五秒以上，這樣的延遲在諸如答題直播場景中無法滿足用戶需求，而LiteAV在當時可以很好解決這個問題。

2.3 Step2：QUIC協(xié)議優(yōu)化助力推流加速

在播放器方面有成績之后，下半年騰訊云將目光投向了推流部分，推流方面的難點相比播放還要更大。由于RTMP協(xié)議太過標準，以至于沒有太多發(fā)揮的空間，RTMP是基于TCP的解決方案，所以有些主播家里網(wǎng)絡出現(xiàn)問題時，就會導致推流質(zhì)量很差，從而影響到觀看質(zhì)量。既然TCP不可靠，我們就換成谷歌的QUIC協(xié)議，QUIC協(xié)議是使用UDP去實現(xiàn)TCP的方案，在質(zhì)量和效果上都要好很多。

QUIC技術是七層協(xié)議，對外接口都是HTTP這樣的請求/響應，RTMP推流是通過流式把數(shù)據(jù)發(fā)送到服務器上，因此首先需要解決的問題就是把七層協(xié)議改成四層。除此之外，把QUIC全部打包進SDK會使App體積要增加一、兩倍，因此需要對QUIC協(xié)議進行裁剪，在保持主流程不變的情況下對關鍵部件進行替換，甚至采用HOOK和一些偽實現(xiàn)的方式來盡可能將體積壓在1M以內(nèi)，這是團隊在2016年下半年做一件很重要的事情。整個完成之后推流質(zhì)量相較于友商有很大提升，而且服務端有很多GPN加速節(jié)點去配合，加上QQ、微信積攢了大量的動態(tài)路由數(shù)據(jù)，因此可以找到最合適的加速節(jié)點，保證推流質(zhì)量。

2.4 Step3：直播+連麥，低延遲鏈路優(yōu)化

在推拉流協(xié)議都做了優(yōu)化之后，我們在“最后一公里”的問題上已經(jīng)有了一些進展，接下來，我們開始將目光投向“延時”這個老大難問題。上[青1]?圖是騰訊云的直播架構，主播通過RTMP協(xié)議推流到服務器上，服務器通過轉(zhuǎn)碼集群——由于RTMP協(xié)議秒開效果太差，所以會優(yōu)先轉(zhuǎn)碼成FLV和適合網(wǎng)頁播放的HLS格式，有些高清碼流也會轉(zhuǎn)碼為不同分辨率的流，這些數(shù)據(jù)經(jīng)過CDN強大的擴散集群，最后到達每個觀眾。這樣的操作延遲很多都在2-3秒以上，如果碼率過高延遲會達到4-5秒甚至更高。

我們發(fā)現(xiàn)整個直播場景下關于延時存在很大問題，因此通過大幅降低延遲通過取消轉(zhuǎn)碼和CDN擴散集群，直接用騰訊的骨干網(wǎng)資源，每個主播/觀眾到云上節(jié)點中間最不確定的部分用QUIC加速，可以把延遲縮短到500ms以內(nèi)，而線上的平均數(shù)據(jù)還要更低。

在此基礎上，當主播之間延遲都很低的情況下，我們就可以把雙向的通話拉起，這其中需要解決的不僅僅是網(wǎng)絡上的問題，還要做一些聲音上的處理，比如回聲的抵消、降噪以及聲音的自動增益，完成聲音處理之后，一個簡單的直播連麥方案就創(chuàng)造出來了。

前面提到的這些技術，在騰訊云LiteAVSDK 的 TXLivePusher 和 TXLivePlayer 組件中都已經(jīng)提供，并且為很多的騰訊云客戶提供著穩(wěn)定的服務，事實上，它是如此的簡單和高效，以至于微信的小程序也成為了我們的一個很重要的“客戶”和“partner”。上[青2]?圖中小程序API有兩個標簽——<live-pusher>和<live-player>，都是基于LiteAVSDK實現(xiàn)的。通過與微信的合作也實現(xiàn)了很多輕量級的訴求，比如用戶并不想安裝App時就可以使用小程序喚醒來完成訴求。除此之外，現(xiàn)在的新零售、保險理賠、政務庭審以及在線問診場景，目前BMW的在線銷售場景可以實現(xiàn)導購員直接帶著用戶看車，用戶可以在家里指示導購員將鏡頭對著用戶需要觀看的部分。

2.5 Step4：視頻特效編輯系統(tǒng)構建

2017年下半年短視頻市場非常火爆，因此我們沒有繼續(xù)在網(wǎng)絡上投入更多精力，而是將重心放在視頻特效編輯系統(tǒng)上。這套視頻特效編輯系統(tǒng)框架除了很多“積木”（模塊）的堆積，還做了編輯引擎類的構建，像抖音里的“動感光波”、“時光倒流”等特效就是通過SDK中編輯子引擎來實現(xiàn)和構建的。整體效果，不僅是在錄制中的變速、多段的播放，還包括視頻在處理過程中的特效加持，甚至連足夠商業(yè)化的UI界面，在整個系統(tǒng)中都是一氣合成的。

2.6 Step5：弱網(wǎng)優(yōu)化與無線網(wǎng)絡的新挑戰(zhàn)

2018年直播場景更多強調(diào)互動和低延時，互動不僅體現(xiàn)在彈幕和禮物系統(tǒng)，更多擴展到連麥K歌、聊天和游戲中，傳統(tǒng)直播的標準方案在應對這些需求時也顯得有些吃力。

騰訊云團隊在將之前的技術應用于新的直播場景時，發(fā)現(xiàn)關于弱網(wǎng)優(yōu)化的技術仍舊固有在ARQ、FEC和擁塞控制。ARQ和TCP的思路很像，但不同的是在傳輸過程中出現(xiàn)丟包時，丟掉哪一個包就需要重新請求這個數(shù)據(jù)包，沒有出現(xiàn)則就此放過。FEC技術則采用了生物界里面繁衍下一代常用的“光撒種”的策略，通過增加榮譽的信息來減少丟包帶來的影響，比如原始圖像有五個數(shù)據(jù)包從發(fā)送方通過網(wǎng)絡傳輸?shù)浇邮辗?#xff0c;發(fā)送方將數(shù)據(jù)包傳到網(wǎng)絡之前會通過冗余算法加一些冗余，把五個數(shù)據(jù)包變成六個、七個甚至更多，這些冗余數(shù)據(jù)包的作用是在網(wǎng)絡傳輸過程中一旦出現(xiàn)丟包，就會通過冗余數(shù)據(jù)包盡快恢復出丟失數(shù)據(jù)包，然后再通過解碼顯示圖像。FEC技術看似很好，但實際代價卻很大：首先FEC算法計算量會很大。其次，FEC技術在現(xiàn)實中表現(xiàn)得并不高效，即使較好的FEC算法也只能以30%的冗余解決10%的數(shù)據(jù)丟失問題。當然，除了ARQ 和 FEC，還有一個常用思路就是通過擁塞控制應對網(wǎng)絡情況的變化：在帶寬非常充裕時可以隨意揮霍，但在帶寬非常緊張時，整體會通過控制編碼器減少發(fā)送數(shù)據(jù)量，讓編碼器適應帶寬。

最近幾年網(wǎng)絡環(huán)境的改變除了帶寬的提升，還有從有線網(wǎng)絡到無線網(wǎng)絡的切換。無線網(wǎng)絡（802.11）具有一個特點，在共享一個熱點的狀態(tài)下，終端相互之間會搶資源，這是因為無線網(wǎng)絡下的通訊是排它的，資源的分配很大程度上由使用量和分配算法決定，這就造成了很大的不確定性。物理網(wǎng)絡雖然不方便，但是穩(wěn)定而且抗干擾能力強，所以不管是好是壞，網(wǎng)絡質(zhì)量都更像一個穩(wěn)重的lady，不會動不動就跟你“鬧情緒”。相比之下，無線網(wǎng)絡更像是一個年青愛撒嬌的girl，這一段時間WiFi信號滿格，但只是因為你的手機轉(zhuǎn)動了一下方向，或者在客廳和臥室里來回走了幾步，網(wǎng)絡質(zhì)量就可以隨著信號強度一起泛起“軒然大波”。在這種情況下協(xié)議理念需要作出變革，不止關注網(wǎng)絡層的恢復率和能力，更多應該關注上層音視頻處理的容錯性。

2.7 Step6：提升編解碼器容錯能力，建立基于云端決策的調(diào)控系統(tǒng)

2018年下半年騰訊云團隊開始專注基于Codec的卡頓優(yōu)化和基于云端決策的調(diào)控系統(tǒng)。比如在現(xiàn)在編碼時就不能再像直播一樣采取標準參考關系：假設一秒的畫面15幀，在最開始編一個關鍵幀（I幀），再編一系列的非關鍵幀/參考幀（P幀），每一個P幀參考前面一幀來把變化的部分編進去，編碼部分預測的越準，編碼算法越強，所得的視頻越小。但如果簡單采取上面這種標準參考關系，當其中一個P幀丟失后，后面所有的幀都無法解開，造成這段影像卡頓。如果在編碼時多考慮容錯性，相應來說在解碼端的容錯性也會更強，表現(xiàn)在播放畫面中也只卡頓一下，對于一秒鐘20幀的影像相當于卡了50毫秒，用戶在觀看時幾乎不會感知，這對于觀看體驗會有不小的提升。

同樣的思路也可以用在聲音上。人聲是通過聲帶振動發(fā)出聲音，對聲音容錯性的要求會更加苛刻，但聲帶的振動本身是物理振動，如果聲音信號切的非常細——比如20毫秒一個，會發(fā)現(xiàn)其中存在很多規(guī)律，如果只是簡單丟掉一兩個數(shù)據(jù)包，是可以通過預測來填補，這也是最簡單的音視頻丟包異常處理。

視頻和音頻可以接受一定程度丟包的前提下，網(wǎng)絡層相對就不用照顧所有的數(shù)據(jù)，整個音視頻體系就可以不再局限于原來在有線網(wǎng)絡積累的思路，而是更多關注最終的收益和效果，比如下圖中橙色部分的實際恢復率、失敗反饋和無參考評分，綜合這些信息交給云端完備的統(tǒng)計分析系統(tǒng)和決策系統(tǒng)，就可以通過實時調(diào)控甚至迭代版本去優(yōu)化網(wǎng)絡的擁塞算法和發(fā)送策略，這樣一系列的改變來提升產(chǎn)品的體驗和效果。

所以像騰訊的TRTC和目前做的比較優(yōu)秀的音視頻系統(tǒng)，都是體積化去優(yōu)化的過程。首先它有最基礎的線路質(zhì)量要求，僅靠三四臺服務器想要撐起全國各處無縫低延遲連接都是不可能的，線路質(zhì)量主要依靠于全國各地機房布點以及骨干網(wǎng)專線的打通，都是好的音視頻解決方案的基礎，有了這樣的基礎設施建設才有軟件方面的加分項。同時要有比較基礎的理論體系支撐，比如FEC、ARQ和QUIC這些基礎算法支撐，但要想做好產(chǎn)品體驗更多的是靠一系列的工程和細分領域上的優(yōu)化。

2.8 Now

騰訊云在2019年上半年開始打造一些新的玩法，比如低延時大房間的解決方案。之前講到直播CDN的方案是流式從左到右非常清晰的鏈路，逐級將信號放大，但是在TRTC這種混合方案中，鏈路就沒辦法做到像CDN那樣清晰，更多是靠強大的音視頻節(jié)點（騰訊內(nèi)部稱為接口機），通訊鏈路重拾了UDP協(xié)議，對于要求低延時和互動性高的使用場景會用UDP方案和很強大的接口去做，而對于低延時、高并發(fā)觀看場景則會使用對并發(fā)能力支持更強的代理機來做。最后這套服務還可以通過旁路集群與標準的直播CDN進行打通，同時能支持對直播CDN的結合，這樣一套復合解決方案能夠越來越多的滿足解決不同場景下的不同需求。

目前很多客戶在使用音視頻場景解決方案時，逐漸開始追求更高的互動性和更低的延時。以陌陌舉例，在交友方面涉及到各種各樣的玩法，以互動性來說就包括多人聊天/PK和KTV聊天室，這樣的使用場景對延時的要求非常高，這樣的產(chǎn)品想要真正落地需要大量的優(yōu)化，因此，我們今年上半年也在功能、流暢度、延時和轉(zhuǎn)推效果方面做了大量的努力。

也有很多應用場景對于玩法花樣沒有太多的要求，只是需要有很高的視頻通話質(zhì)量，比如VIPKID，在教育方面表現(xiàn)為很多海外老師對中國學生進行視頻教學，這部分的視頻卡頓率都是可以度量和統(tǒng)計的，有一些參考評分，比如視頻渲染幀間隔不能超過200ms、視頻清晰度評分、POLQA分、端到端延時以及全年不可用時間<10分鐘，這就可以在客戶和我們之間畫出一條“紅線”，只要逾越這條紅線就要出局。如果可以滿足要求，那就可以成為服務提供商。

線路質(zhì)量有海外專線支撐，但專線在一些特殊情況下也會出問題，所以要有多條VPN線路備份，再包括光纖斷了之后需要多集群分布式容災。在聲音流暢度方面，教育領域?qū)σ糍|(zhì)的要求近兩年也在不斷提升，尤其不僅局限于英語教學，在聲樂教學場景中對于聲音傳輸中鋼琴的音色也提出了很高的要求。關于弱網(wǎng)抗性中首幀加載速度以及對端質(zhì)量決策和視頻丟幀預測，這其中都有很多規(guī)律可循。在網(wǎng)絡策略上全局的動態(tài)路由表，這其中有很多事情都可以落地。

總的來說，在很多客戶訴求隨著市場競爭的加劇，用戶需求的提升，不斷地追求質(zhì)量的精益求精，在此期間騰訊云也在不斷地完善音視頻體系。

LiveVideoStackCon 2019深圳招募講師

12月13-14日，LiveVideoStackCon將首次來到深圳，將全球前沿多媒體技術實踐與深圳本地產(chǎn)業(yè)結合，觸發(fā)技術與商業(yè)靈感。歡迎將你的技術實踐、踩坑與填坑經(jīng)歷、技術與商業(yè)創(chuàng)業(yè)的思考分享出來，獨樂不如眾樂。請將個人資料和話題信息郵件到?speaker@livevideostack.com?或點擊【閱讀原文】了解成為LiveVideoStackCon講師的權益與義務，我們會在48小時內(nèi)回復。

LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態(tài)發(fā)展。同時，也歡迎你利用業(yè)余時間、遠程參與內(nèi)容生產(chǎn)。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

總結

以上是生活随笔為你收集整理的腾讯云实时音视频技术发展简史 — 从编解码器容错优化到云端决策系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。