抖音官方平臺會不定期發布各種各樣的話題、活動的挑戰，這個挑戰面向所有用戶，主要圍繞某個主題拍攝相關的短視頻，以此獲得曝光度、贏取對應獎品。大家拍同樣的視頻，看誰的作品效果更好，同時還可以很好的引導用戶，通過話題的方式來引爆流量。隨著這項活動人氣的不斷增長，如今不管是企業也好，還是個人也好，也都積極的參與了進來。對于企業而言，參加話題挑戰可以向消費者傳遞品牌信息，傳播品牌核心價值觀，與受眾形成共鳴和價值鏈接。

對于個人來說，參加官方的話題討論同樣也是為自己賬號引流漲粉一個不錯的途徑，因為官方話題討論和挑戰往往參與的人都是非常多的，覆蓋的人群越廣泛，那么作品獲得關注的概率也會大大提高。當然了，總的來說要想迅速漲粉并不是一件容易的事情，都有一個積累的過程，所以建議大家需要在短時間內積累大量粉絲的話不妨可以考慮買一個現成的抖音號，這樣可以省去中間很多過程，直接帶貨直播變現。抖音賬號交易平臺“索狐”海量賬號任您挑選！

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

文 | 常青

整理 | LiveVideoStack

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

1. 全真互聯網

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

1.1 更清晰的畫質

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

1.2 更好的沉浸感

沉浸式體驗也在逐步拓展，例如3D導覽、3D模型構建、AR、VR游戲、多點位賽事自由觀看都是新交互體驗創新。

1.3 更強的互動能力

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

1.4 更低的互動延時

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

1.5 全真互聯網的四大要素

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

2. 一座塔的故事

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

2.1 《圣經》中的巴比倫塔

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

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

2.2 不同的“語言”

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

2.3 小說中的巴比倫塔

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

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

2.4 產品研發是一個系統性工程

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

回到騰訊云現在的音視頻服務，也是類似的一種思路，就是通過打通各個子系統和子服務，通過統一的架構設計、統一的通信語言以及統一的基礎設施，完成整個音視頻和通信服務的互聯互通。這包括兩個方面：

一個是 RT-ONE? 音視頻網絡，它由 TRTC 實時音視頻網絡，IM 通信網絡和 CDN 流媒體分發網絡共同構成，在這些網絡的互通過程中，我們將賬號系統，無縫音視頻數據的流轉，以及監控系統和控制臺都進行了打通和融合。效果比原來好很多。

另一個是 RT-Cube? 視立方解決方案，完成了基礎框架，架構設計、消息總線、線程模型、編譯環境、監控模塊以及測試系統的統一，在整個端上的組件進行很好的協同增強，無論使用一個或是多個功能，整個運轉效果都會比之前好很多。

我主要是負責端方面，將與大家分享這些部分我們是如何達到協同統一系統化效果。

3. 面臨的技術挑戰

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

3.1 挑戰一：RT—Cube? 的架構設計

挑戰有很多比較有意思的東西。

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

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

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

3.2 挑戰二：RT-Cube? 的版本管理

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

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

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

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

3.3 挑戰三：RT-Cube? 的質量監控

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

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

3.4 挑戰四：模塊間通信的效率

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

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

4. 完成的優化與改進

上述是面對挑戰及面對措施。接下來說一說在這一套基礎設施革新升級完成后半年到一年內的優化與改進。這一部分偏技術一些。

4.1 改進一：音頻模塊的進化

4.1.1 功能

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

4.1.2 使用

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

4.2 改進二：視頻模塊的進化-效果

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

4.3 改進三：網絡模塊的改進

4.3.1 架構

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

4.3.2 推流

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

4.3.3 播放

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

4.4 改進四：TUI組件庫

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

5. 總結

最后做一下總結。

本次主要講的是系統化設計，將各個部件進行整合，完成1+1>2的過程。

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

在終端，我們一方面不斷地優化已有功能的穩定性和性能表現，比如通過更多應用場景和大數據分析的夾逼，讓 RTC SDK 的各方面素質都達到業內一流水準。與此同時，我們也將新推出的快直播 SDK 和新內核的IM SDK融入到這個體系中，共同構成強大的 RT-Cube? SDK 架構。

再加上界面完成度很高的 TUI 組件庫，共同構成一個強大且易用的 PaaS 體系，為構建全真互聯網提供更多的基礎能力組件。

視立方可以在上圖網站上下載，現在放的是比較常用版本，后續定制能力會在隨后編譯系統健壯性更強后逐步開放，可以根據自身需要，隨意組合功能，生成最需要的版本。

以上是我本次分享的主要內容，非常感謝。