經(jīng)過五年的努力，騰訊云終端團(tuán)隊不斷完善并積累出了一套完整的終端SDK方案體系，包含即時通信，主播推流，直播播放、點播播放、RTC實時互動、短視頻錄制，特效編輯等一系列音視頻和實時通信相關(guān)的功能特性。在這些功能背后，團(tuán)隊是如何完成了框架設(shè)計、組件打磨、數(shù)據(jù)流轉(zhuǎn)、性能優(yōu)化的呢？本次LiveVideoStackCon 2021北京站我們邀請到了騰訊云的常青來從產(chǎn)品能力、架構(gòu)設(shè)計、以及技術(shù)原理等多個角度進(jìn)行剖析分享。

文 | 常青

整理 | LiveVideoStack

我們團(tuán)隊在騰訊云主要做音視頻通訊類的SDK，這一部分包含功能相對比較豐富，包括RTC通訊、直播推流、播放器、短視頻的錄制、音視頻的特效處理、還包括IM的技術(shù)通訊，種類方方面面，符合各種場景下的需求?，F(xiàn)在大熱的全真互聯(lián)網(wǎng)會對業(yè)務(wù)產(chǎn)生新機(jī)遇、挑戰(zhàn)。如何去面對機(jī)遇、迎接挑戰(zhàn)是我本次分享重點，是技術(shù)部分內(nèi)容和思想內(nèi)容的融合。

1. 全真互聯(lián)網(wǎng)

首先說一下全真互聯(lián)網(wǎng)，不同的人有不同的理解，我以我的角度說一下對其的理解。全真互聯(lián)網(wǎng)在我看來是四個更加，更加清晰、更加沉浸、更加強(qiáng)互動、更加低延時。

1.1 更清晰的畫質(zhì)

上圖左邊是騰訊云統(tǒng)計的所有端包括PC、PAD、手機(jī)全網(wǎng)流媒體平均觀看碼率?？梢钥闯鰪?018年上半年到現(xiàn)在，每年平均碼率都在慢慢增長。大家對觀看清晰度的需求越來越高，在碼率變高同時，壓縮效率也在提升，從H.264到H.265到最近提交的100多個技術(shù)預(yù)案H.266技術(shù)，都是讓碼率的壓縮比變得更好。比方說現(xiàn)在H.266可以比H.265多出50%的壓縮率。

1.2 更好的沉浸感

沉浸式體驗也在逐步拓展，例如3D導(dǎo)覽、3D模型構(gòu)建、AR、VR游戲、多點位賽事自由觀看都是新交互體驗創(chuàng)新。

1.3 更強(qiáng)的互動能力

更強(qiáng)的實時互動性方面例如可以通過手機(jī)采集面部點云，通過云端回饋到觀眾端做到很強(qiáng)的實時交互。

1.4 更低的互動延時

過去幾年中感受最深的更快的延時方面，幾年前網(wǎng)頁上是十幾、幾十秒的延時，現(xiàn)在可以做一些幾十毫秒級別的直播間實時合唱延時，可以看出延時在不斷降低。

1.5 全真互聯(lián)網(wǎng)的四大要素

所以更高的清晰度、更強(qiáng)的互動性、更佳的沉浸式體驗、更低的延時共同構(gòu)成了我所理解的全真互聯(lián)網(wǎng)。這一塊在背后云端和終端需要付出更多的努力，迎接更多的挑戰(zhàn)。我們需要處理一些繞不開的困難。

2. 一座塔的故事

我是一個比較喜歡講故事的人，我將從一座塔的故事開始分享我的一些感受。

2.1 《圣經(jīng)》中的巴比倫塔

《圣經(jīng)·舊約》中講的是猶太教的故事。舊約中有七約，故事比較有意思，兩個年輕男女亞當(dāng)和夏娃，因偷吃禁果，創(chuàng)造孩子，由于孩子越來越多，相互斗爭，上帝怒發(fā)洪水，上帝派諾亞造了一艘船救了動物，而諾亞的子孫們吸取前人的教訓(xùn)，齊心協(xié)力想要創(chuàng)造一個功績—–一座塔，希望可以直通上帝。塔越造越高，上帝認(rèn)為如果塔建成了，就沒有他們搞不定的事情了，于是就讓人類說不同的語言，相互產(chǎn)生隔閡猜忌，果然大家就放棄了造塔。

這是開場的第一個小故事，其中的問題在軟件研發(fā)中也頻繁出現(xiàn)，當(dāng)團(tuán)隊在一起做一件事情時，隨著項目的推進(jìn)，發(fā)現(xiàn)面對的困難不僅僅是時間成本和需求還有思想的不一致，團(tuán)隊之間溝通成本很高，來自不同Team的成員有會不同習(xí)慣架構(gòu)框架。

2.2 不同的“語言”

團(tuán)隊成員各自有非常喜歡的語言和設(shè)計理念。其中java和C++語言不是很對付還要寫jni進(jìn)行互通。在團(tuán)隊管理方面，有些人認(rèn)為研發(fā)流程太少了不靠譜，而有些人覺得團(tuán)隊研發(fā)流程太復(fù)雜，不要那么頑固。以上方面都會導(dǎo)致整個團(tuán)隊心不齊，當(dāng)事情惡化，就會導(dǎo)致“通天塔”造不起來。失敗的項目太多了，即使克服了這些克服，是否其他問題能解決了呢。

2.3 小說中的巴比倫塔

再來說說第二個故事。一位華裔美籍科幻作家姜峯楠的處女作《通天塔》講得是一個叫南尼的工人加入到造塔運(yùn)動中，人人都很努力盡責(zé)，大家萬眾一心，幾個世紀(jì)的時間一點點地將塔直通天庭。到了天庭之后，發(fā)現(xiàn)天頂是一個光滑的大理石穹頂，南尼和眾人先用火燒，再用冷水快速冷卻，讓這些光滑的外殼逐漸碎裂，一層層撥開。直到主人翁南尼從一個年輕小伙干到了一個老人，他相信一定能夠鑿穿。終于有一天，天庭外殼鑿穿，南尼九死一生后，看了一束光亮，穿過這道光亮，他爬了出來，是一片沙漠，沙漠中有一座塔，就是他們造的通天塔。當(dāng)我讀完這個故事之后，我感受到了無奈和無助，這是無法抗衡的宿命。

在軟件研發(fā)過程中很常見，一群人聚在一起，立項后進(jìn)入敏捷迭代，快速上線，不斷地升級一個又一個版本，功能堆積，出現(xiàn)維護(hù)困難，直到發(fā)現(xiàn)實在難以維護(hù)，一致要求重構(gòu)。于是，我們又開始一次斗志昂揚(yáng)的立項，并且開始了新一輪的輪回。我在騰訊13年很少打破這個宿命，不知道大家是否遇到過這個問題。

2.4 產(chǎn)品研發(fā)是一個系統(tǒng)性工程

那我們怎么解決“語言不通”的問題，怎么打破“無限輪回”的宿命呢？其實工程學(xué)的老前輩們給我們指明了道路，產(chǎn)品研發(fā)是一個系統(tǒng)性的工程，我們應(yīng)該更多地運(yùn)用“系統(tǒng)取勝”的設(shè)計思路，比如我們熟知的兩款國之重器，J20戰(zhàn)斗機(jī)和99A坦克，就是系統(tǒng)取勝的典型代表。在這兩款武器的設(shè)計之初，沒有世界一流的技術(shù)可以使用。99A 坦克炮比不過萊茵金屬，動力比不過豹2，裝甲也拼不過 M1A1 的貧鈾裝甲，通過系統(tǒng)性優(yōu)化讓整輛坦克的綜合素質(zhì)是世界頂尖的。J20裝鴨翼會讓隱身性變差，但可以通過鴨翼提升氣動性能，讓飛機(jī)在動力一般的情況下也能完成非常高難度的機(jī)動性，滿足防衛(wèi)要求。所以將各個部件折中揚(yáng)長避短，出來的系統(tǒng)非常有競爭力。

回到騰訊云現(xiàn)在的音視頻服務(wù)，也是類似的一種思路，就是通過打通各個子系統(tǒng)和子服務(wù)，通過統(tǒng)一的架構(gòu)設(shè)計、統(tǒng)一的通信語言以及統(tǒng)一的基礎(chǔ)設(shè)施，完成整個音視頻和通信服務(wù)的互聯(lián)互通。這包括兩個方面：

一個是 RT-ONE? 音視頻網(wǎng)絡(luò)，它由 TRTC 實時音視頻網(wǎng)絡(luò)，IM 通信網(wǎng)絡(luò)和 CDN 流媒體分發(fā)網(wǎng)絡(luò)共同構(gòu)成，在這些網(wǎng)絡(luò)的互通過程中，我們將賬號系統(tǒng)，無縫音視頻數(shù)據(jù)的流轉(zhuǎn)，以及監(jiān)控系統(tǒng)和控制臺都進(jìn)行了打通和融合。效果比原來好很多。

另一個是 RT-Cube? 視立方解決方案，完成了基礎(chǔ)框架，架構(gòu)設(shè)計、消息總線、線程模型、編譯環(huán)境、監(jiān)控模塊以及測試系統(tǒng)的統(tǒng)一，在整個端上的組件進(jìn)行很好的協(xié)同增強(qiáng)，無論使用一個或是多個功能，整個運(yùn)轉(zhuǎn)效果都會比之前好很多。

我主要是負(fù)責(zé)端方面，將與大家分享這些部分我們是如何達(dá)到協(xié)同統(tǒng)一系統(tǒng)化效果。

3. 面臨的技術(shù)挑戰(zhàn)

先說一下我們所面臨的挑戰(zhàn)，再去聊一聊如何解決。

3.1 挑戰(zhàn)一：RT—Cube? 的架構(gòu)設(shè)計

挑戰(zhàn)有很多比較有意思的東西。

第三個故事是機(jī)械手表中的陀飛輪，它被用來抵消地球引力對表芯中的“擒縱系統(tǒng)”的影響。這個模塊要把游絲，叉式杠桿和“擒縱系統(tǒng)”都放在同一個軸上運(yùn)作，而且還要能在運(yùn)動時不停地轉(zhuǎn)動，讓地心引力的影響達(dá)到最小。它是人類設(shè)計的精密機(jī)械設(shè)備中的皇冠級產(chǎn)品。在兩個世紀(jì)前，有個設(shè)備比它還復(fù)雜，英國數(shù)學(xué)家查爾斯·巴貝奇發(fā)明差分機(jī)，它可以用來算多項式求值，可以理解為這個機(jī)器可以給一組輸入數(shù)字套計算公式，而且精度很高，很適合用來做 excel 里面的表格計算。機(jī)械設(shè)備能做到的精密程度是有天花板的，英國政府撥了很多錢這臺機(jī)器完成了 1/7 ，但是每次演示都能驚掉一群人的下巴。每個部件都需要動力驅(qū)動它轉(zhuǎn)動，部件與部件之間的銜接處會有誤差，誤差會被一層層的傳遞和放大，部件與部件之間的銜接處還會摩擦，以至于這臺設(shè)備最終在 1985 年被做出來的時候，需要一個壯漢才能驅(qū)動。

我拿這個例子要講的是第一個挑戰(zhàn)。我們在做大到操作系統(tǒng)，小到SDK功能時，需要做到協(xié)同和運(yùn)轉(zhuǎn)和諧是很難的，SDK有很多模塊。左下角是音視頻的引擎，我只畫了很小一部分，可以看出非常多。右下角是TIM的部分，上端的是TUI級的組件。多模塊協(xié)同運(yùn)作時會發(fā)生很多協(xié)同、咬合、CPU拼搶的問題。

以音頻為例，上圖是在 RT-Cube? 中的音視頻引擎的架構(gòu)設(shè)計，它由很多個核心模塊組成，而這些核心模塊的內(nèi)部又會有很多的子模塊構(gòu)建，模塊之間會有大量的數(shù)據(jù)通信和控制邏輯。如果僅僅是這樣，那么當(dāng)系統(tǒng)處于平穩(wěn)運(yùn)行階段，可能暫時不會有什么問題。但如系統(tǒng)的 CPU 出現(xiàn)降頻，或者內(nèi)存不太夠用，各個模塊的各自為戰(zhàn)很快就會讓整個系統(tǒng)快速進(jìn)入崩潰的邊緣。所以我們引入了一個中心控制模塊，通過它來實時監(jiān)控和協(xié)調(diào)各個模塊的狀態(tài)，并在必要的時刻采取干預(yù)，讓各模塊能夠更好的協(xié)同以免發(fā)生雪崩。這是模塊間協(xié)作解決的方法論。

3.2 挑戰(zhàn)二：RT-Cube? 的版本管理

第二個挑戰(zhàn)是版本的問題，提供的功能非常多，不是所有客戶都需要所有功能，要組合需要的功能。我們需要面對要有多少版本的問題。

為解決這個問題，引入德國數(shù)學(xué)家康托，他發(fā)明了集合論，子集，空子集，非空子集。假設(shè)如果一個集合有 n 個元素，那么就可以用這個公式算出這個集合的所有非空子集的個數(shù)。集合論的意義遠(yuǎn)不與此，它奠定現(xiàn)代數(shù)學(xué)的理論基礎(chǔ)，真正意義是在于能夠用集合論定義和解釋幾乎所有傳統(tǒng)數(shù)學(xué)的理論定義。現(xiàn)代科學(xué)基于數(shù)學(xué)構(gòu)建。但由于康托理論太過超前，被人當(dāng)成了神經(jīng)病，被送進(jìn)哈雷-維滕貝格大學(xué)的附屬醫(yī)院。但他的理論是不能被駁倒的。

如果SDK中有 9 個功能，按照客戶需要要進(jìn)行自由組合，根據(jù)公式，可以算出大概需要提供510 種版本，且還要提供四個平臺的實現(xiàn)將510*4，2000多個版本。當(dāng)我跟產(chǎn)品團(tuán)隊的同事們介紹這個數(shù)字的時候，他們覺得我不僅僅認(rèn)同康托的理論，而且也應(yīng)該獲得跟康托先生晚年一樣的待遇。

為了解決這一問題，需要拋棄傳統(tǒng)的平臺相關(guān)的編譯工具，比如 Xcode、Android Studio等，建立一套全新的編譯平臺，它可以使用一套編譯方案，同時輸出不同平臺的 SDK，而且可以做到自由組合，通過這種方式使版本功能組合更加靈活容易。

3.3 挑戰(zhàn)三：RT-Cube? 的質(zhì)量監(jiān)控

第三個挑戰(zhàn)是質(zhì)量監(jiān)控，要解決這個問題，引出一個老奶奶，她叫勒維特，是哈佛大學(xué)天文臺的一名計算員，每天對著星空的感光膠片監(jiān)控星星，記錄其亮度變化和運(yùn)動情況，恒星是不會動的，一旦運(yùn)動，肯定是行星。不過大家要注意，這是在1893 年的時候，偉大的毛爺爺剛剛出生，那時女性的地位非常低，她本著興趣一天到晚重復(fù)枯燥的工作，最終她發(fā)現(xiàn)越亮的恒星，亮度變化周期也就越長，周光關(guān)系的公式規(guī)律，被后來的天文學(xué)家發(fā)現(xiàn)可以用來檢測我們地球和星星之間的距離遠(yuǎn)近，且銀河系不是宇宙中唯一的星系，還有很多系外星系。

上述的這個故事的問題對于我們也非常難。假設(shè)做一個產(chǎn)品，現(xiàn)有6個人看一場直播或視頻會議，其中一人在20分鐘時間內(nèi)卡頓10秒，其他5個人在20分鐘時間內(nèi)都沒卡，在監(jiān)控中卡頓率是0.13%。10秒的卡頓是很糟糕的，如果按照人數(shù)來算占16.7%，很多時候，質(zhì)量監(jiān)控解決的問題是將不好Case在很多數(shù)據(jù)中眼尖的挑出，是決定產(chǎn)品好壞的關(guān)鍵點。解決單個用戶的糟糕體驗會被海量的上報數(shù)據(jù)淹沒的辦法，首先基礎(chǔ)設(shè)施不能變，每天都要上報上一條數(shù)據(jù)包括卡頓、大小、畫面不流暢、模糊、有回聲。數(shù)據(jù)要用細(xì)致算法基于用戶指標(biāo)算出體驗糟糕。接下來對它的數(shù)據(jù)進(jìn)一步分析，找出大概的用戶數(shù)量、占比數(shù)量增長或減少、變差原因。從萬繁星中找到改進(jìn)點。

3.4 挑戰(zhàn)四：模塊間通信的效率

第四個挑戰(zhàn)是模塊間的通信效率。這次是可能很多人都知道的例子——著名的阿波羅13號，原本要成為第三艘在月球著陸的宇宙飛船。在半路上飛船的3個氧氣罐中有兩個爆了，導(dǎo)致飛船的電能和氧氣供應(yīng)都非常緊張。三人擠到登月艙，由于這里的氧氣是多出來給給兩個人登月用的，多了一個人，呼出來的二氧化碳也就多了一份，二氧化碳濾芯提早用完。從指令艙拿出濾芯用，發(fā)現(xiàn)一個是圓的，一個是方的，不匹配。最后是休斯頓基地指揮中心讓其用塑料袋膠帶湊合，一路回來。

這個問題在游戲端非常常見，后臺系統(tǒng)很多公司都會統(tǒng)一，例如SDP標(biāo)準(zhǔn)協(xié)議，微服務(wù)概念語言等。但端iOS、Android、Windows不是我們所能改變的，想要用C++進(jìn)行跨平臺統(tǒng)一，面對的問題挑戰(zhàn)巨大。其中蘋果視頻處理紋理圖像格式、安卓格式、Windows的D3D都有很多差異，到C++上都是二進(jìn)制的Buffer來解決問題，所以要想保證之間通訊不出現(xiàn)如阿波羅十三號拿方形濾芯往圓形的孔塞的情況，需要進(jìn)行很多統(tǒng)一適配和努力。這個問題最終被克服，數(shù)據(jù)在各平臺間的流轉(zhuǎn)也沒有太多性能損耗。

4. 完成的優(yōu)化與改進(jìn)

上述是面對挑戰(zhàn)及面對措施。接下來說一說在這一套基礎(chǔ)設(shè)施革新升級完成后半年到一年內(nèi)的優(yōu)化與改進(jìn)。這一部分偏技術(shù)一些。

4.1 改進(jìn)一：音頻模塊的進(jìn)化

4.1.1 功能

通過對架構(gòu)的升級，我們最新版本中的音頻模塊支持了很多新的能力，比如對聲音全頻帶得支持，對3D空間音頻特效得支持，基于深度學(xué)習(xí)的 AI 降噪以及信源信道相融合的抗損傷技術(shù)?；谶@些新的能力，我們可以實現(xiàn)更多更有挑戰(zhàn)的實時交互需求，比如對音視頻通信延遲要求極低的在線實時合唱功能；再比如在音樂直播場景中，我們針對音樂模式進(jìn)行了諸多優(yōu)化，可以最高還原度地保證高解析度的音樂音質(zhì)。同時，我們也通過一系列大數(shù)據(jù)分析手段，對聲音的各種問題進(jìn)行定向監(jiān)控和實時分析，在音頻質(zhì)量上不斷地壓低故障率和投訴率。

4.1.2 使用

在音頻使用上進(jìn)行人性化改造。我們給出一些比較容易選擇檔位，對于會議通訊場景可以使用Speech模式；對于不太確定的場景可以使用Default，比較“萬金油”；對于主打音樂可以用Music音質(zhì)模式；還提供如游戲般全定制設(shè)置，自定義所有想要的參數(shù)。

4.2 改進(jìn)二：視頻模塊的進(jìn)化-效果

我們對視頻模塊的整體效果也進(jìn)行了一定的提升，比如在色彩空間上優(yōu)化了對 bt601 和 bt709 這兩種色彩空間的的處理算法，同時也增加了對 bt2020 等 HDR 相關(guān)色彩空間的支持。這使得畫面的亮度更加飽滿。同時，在清晰度方面我們也進(jìn)行了一系列的定向優(yōu)化，使得在同碼率水平下，我們的 SDK 可以獲得更好的清晰度效果。

4.3 改進(jìn)三：網(wǎng)絡(luò)模塊的改進(jìn)

4.3.1 架構(gòu)

最后是網(wǎng)絡(luò)模塊，是我們賴以生存，最拿得出手的核心技術(shù)。這一部分對于流控，整體化改造做了大幅度升級。上圖中可以看出云和端一體，整個系統(tǒng)都不是單獨模塊戰(zhàn)斗，是由很多模塊共同協(xié)助。中控大腦做了多輪基于數(shù)據(jù)的改進(jìn)。

4.3.2 推流

網(wǎng)絡(luò)模塊還有一些較為細(xì)節(jié)的部分。我們把場景主要分成兩種直播類和通訊類。直播類在上行算法處理更加注重清晰，保證平滑。到RTC通訊類，例如騰訊會議，更偏重于實時，盡量保證中間流暢，不出現(xiàn)延時變高、卡頓問題。

4.3.3 播放

播放這一部分，騰訊在直播場景非常靠前，CDN競爭力很強(qiáng)，與此同時在不斷拓展新場景，例如快直播，除了標(biāo)準(zhǔn)瀏覽器，可以通過SDK實現(xiàn)比瀏覽器更好性能、更多格式支持的效果體驗，可以做到將近1s左右延時，對苛刻場景適用。如果假設(shè)延時要更低更強(qiáng)互動，如語言聊天場景，更多去優(yōu)化上下麥的平滑，開麥到不開麥場景的無縫銜接。

4.4 改進(jìn)四：TUI組件庫

我們還進(jìn)行TUI組件庫的升級和補(bǔ)充。用這些PaaS組件最痛苦的是每個組件都很專業(yè)，上百個接口需要投入很大心血，做出的不一定比一些標(biāo)準(zhǔn)產(chǎn)品好。我們提供面向各平臺的組件庫，需要花的努力大概只有幾分鐘，將庫導(dǎo)入，幾行代碼牽動。這一部分如上圖界面，大多數(shù)一個上午甚至一個上午就能夠構(gòu)建出，非常容易，不需要很有經(jīng)驗就能作出好的效果。

5. 總結(jié)

最后做一下總結(jié)。

本次主要講的是系統(tǒng)化設(shè)計，將各個部件進(jìn)行整合，完成1+1>2的過程。

在云端，我們成功地完成了三網(wǎng)的融合，即 TRTC 實時音視頻網(wǎng)絡(luò)、IM 即時通信網(wǎng)絡(luò)以及 CDN 流媒體分發(fā)網(wǎng)絡(luò)。

在終端，我們一方面不斷地優(yōu)化已有功能的穩(wěn)定性和性能表現(xiàn)，比如通過更多應(yīng)用場景和大數(shù)據(jù)分析的夾逼，讓 RTC SDK 的各方面素質(zhì)都達(dá)到業(yè)內(nèi)一流水準(zhǔn)。與此同時，我們也將新推出的快直播 SDK 和新內(nèi)核的IM SDK融入到這個體系中，共同構(gòu)成強(qiáng)大的 RT-Cube? SDK 架構(gòu)。

再加上界面完成度很高的 TUI 組件庫，共同構(gòu)成一個強(qiáng)大且易用的 PaaS 體系，為構(gòu)建全真互聯(lián)網(wǎng)提供更多的基礎(chǔ)能力組件。

視立方可以在上圖網(wǎng)站上下載，現(xiàn)在放的是比較常用版本，后續(xù)定制能力會在隨后編譯系統(tǒng)健壯性更強(qiáng)后逐步開放，可以根據(jù)自身需要，隨意組合功能，生成最需要的版本。

以上是我本次分享的主要內(nèi)容，非常感謝。