正文字數：6185 ?閱讀時長：9分鐘

TRTC（Tencent Realtime Communication）全稱是騰訊實時音視頻，是在騰訊云上以SDK和REST API的方式提供售賣的云服務。騰訊云TRTC客戶端的產品架構師蔣磊，將從疫情影響下在線教育市場的變化情況出發(fā)，介紹實時音視頻實踐過程中的踩坑與填坑以及一些新的嘗試。

文 / 蔣磊

整理 /?LiveVideoStack

各位朋友大家好，今天主要是來分享關于實時音視頻與教育的結合。本來最開始的標題是“TRTC與在線教育的那些事兒”，但考慮大家都是做技術的，所以改為“實時視頻助力在線教育的新風口”，能力有限，如果有錯誤與問題，還請多多指教，歡迎一起交流學習。

首先做下自我介紹，我叫蔣磊，現在是騰訊云TRTC客戶端的產品架構師。加入騰訊云之前在網易和阿里云，主要從事直播、點播、CDN的技術。加入騰訊云之后主要做的是關于音視頻處理這一塊的客戶端SDK。

今天分享內容主要包括三點。第一個點是關于疫情影響下在線教育市場的變化情況，我們稱做井噴，第二點是我們這個項目在此過程中踩坑、填坑的幾個案例，以及實踐經驗分享，最后是我們在在線教育新模式上面的一些嘗試與探索。

1.在線教育的變化

首先，簡單介紹一下我們TRTC這個項目。

TRTC（Tencent Realtime Communication）全稱是騰訊實時音視頻，是在騰訊云上以SDK和REST API的方式提供售賣的云服務。我們主打兩個場景，一個是多人實時互動，像視頻會議、小班課、大班課等，另一種是低延時的直播，像娛樂場景中的語聊房、秀場直播等。這兩類場景對延時的要求都比較低。

對于在線教育場景，大家今年的感受都比較明顯。上圖數據來自CNNIC和前瞻研究院的公開數據。原本按照預期，在去年的基礎上，普遍認為今年在線教育行業(yè)的用戶量應該在接近3個億左右的規(guī)模。今年因為疫情的影響，大量的線下場景搬到了線上，疫情期間中國在線網民參與到在線教育的用戶數量已經接近于4.3億。這個數據還僅是截至3月份，應該在4、5月時才算到一個最高峰。早在16、17年就已經出現過一次在線教育的融資熱潮，之后平靜了一兩年，再到今年又一次掀起新的熱潮，這一次主要原因在于用戶包括學生、家長、各個教育者以及管局都意識到了在線教育的必要性，尤其對線下學校而言，所以說我們將此定義為在線教育的新風口。

另外一個反映在線教育新風口的點是來自于我們實際的線上數據。大家可以從上圖看出TRTC線上規(guī)模的增長，我們統(tǒng)計規(guī)模的方式是按照上行分鐘數。因為TRTC在騰訊內部支持了非常多的業(yè)務，包括騰訊會議，騰訊課堂、企業(yè)微信、微信都是TRTC在支撐。我們拋開內部用量，單看外部的因素，在峰值的時候，當天的上行超過了30億分鐘，相比之前正常情況下的規(guī)模翻了好幾倍，而且這中間大部分的增量是來自于在線教育。所以從業(yè)務規(guī)模走勢上我們也能感受到，今年在線教育這個風口來得非常猛烈。

2.實時音視頻踩坑與填坑的二三事

從技術的角度來看，當你的線上規(guī)模猛增的時候，很多以前可能沒有意識到的小的細節(jié)點就會在過程中間不斷的暴露出來。第二部分我將重點介紹在這過程中我們遇到的一些實際問題以及解決辦法。

2.1 基礎能力優(yōu)化

首先是關于基礎能力的優(yōu)化。在疫情期間，我們遇到有些客戶反饋，他們的一些用戶用的是iPad mini，性能不是很夠，提出是否可以支持320x240分辨率的編解碼，而且是要12個人同時在iPad mini上面去做編解碼的工作。這就比較麻煩，由于iPad mini是2013年發(fā)布的，距今已經7年，它的性能不是那么強，同時做12路編解碼的時候，性能上只能說是勉強能用。事實上這個問題在教育環(huán)境中是非常普遍的，因為在接觸過很多客戶之后，我們發(fā)現孩子在線課堂上課的設備大多是家長以前用過、閑置下來的設備，這些設備一般都是好幾年前的，所以對于應用程序的性能的要求會更高。按照常理來說，這個問題也是比較好解決的，我們可以用硬編硬解來處理。但實際上并不是這么簡單，這里面有一點歷史給大家介紹一下。

在H.264的標準編解碼的參考序列里用的是被我們叫GoP的標準參考關系。在標準的GoP的幀參考關系下，其每一個序列的后一幀是嚴格地依賴于前一幀的。就比如說網絡抖動了一下，可能不是所有的數據全丟了，只是丟了中間某一幀數據，但是丟了這一幀之后，參考關系也會馬上丟失，所以哪怕后面的數據全部都過來了，播放端也解碼不出來，這就導致用戶看到的畫面卡了一下。所以之前為了解決這類問題，我們將編解碼器的參考方式改為RPS的方式。RPS方式相比于標準GoP的不同之處就在于不要求每一幀嚴格地依賴于前一幀，它是可以挑選前面的某幀作為依賴。這樣當遇到同樣的丟包的情況，比如說圖中丟了第三幀，只要能夠控制好參考關系，不會影響后面的幀繼續(xù)解碼，也就是說從用戶的感官上是感覺不到這個視頻卡頓的。

但是因為這種方式并不是標準的，所以我們只能用軟編軟解的方式來做，一般情況在普通的手機和平板上都還好，而且?guī)砀玫娜蹙W抗性，但一旦遇到了像iPad mini同時支持12個人的這種情況，軟編軟解疊加起來的性能消耗就非常明顯，所以我們要做的就是要嘗試優(yōu)化這種通話場景的效果。RPS的引入幫助降低了用戶的卡頓率，是具有實際使用效益的，不過為了保證更好的流暢性、控制好低性能設備的消耗，我們就必須要把RPS關掉，切換回原本的GoP的方式，這樣才能調用硬編硬解，同時我們還要同步做好參數控制以及網絡的調優(yōu)。這里也給我們自己上了一課，我們之前認為大部分的用戶會追求流暢性，所以通過各種技術手段去保障在弱網下盡可能地流暢，但同時也引入了更多的性能消耗，尤其是在低端設備上遇到這種多人的場景，就必須要嘗試用更經典的方式換回到以前的硬編硬解的思路，優(yōu)化更合適的編解碼參數控制、更合適的網絡參數上面，讓我們意識到經典的東西還是很重要的，要把基礎打牢。

第二個是另一個場景。疫情期間，一些教輔機構、教育機構希望把線下的場景能夠在線上還原，比如1個老師跟30個學生這樣非常典型的線下課堂。這里會碰到一個問題就是當所有人的麥都會打開，非常典型的場景是上課的時候同學們齊聲喊老師好，這在線下課堂是很常見的，但搬到線上的時候就非常麻煩。因為在客戶端去拉取上行數據進行本地播放的時候，如果只是幾路音頻做混音還好，但如果是三十路很有可能混音出來的聲音大家都聽不清了，無法分辨老師和同學說的話。尤其這種課堂一般是針對中小學，小學生在上課的時候其實不太能夠安靜得下來，針對這種場景我們之前沒有重點關注到。這樣的場景主要有兩個點。

第一個點是做音頻播放選路。因為音頻最終播放的時候只有一路聲音，是經過混音的。在播放前我們必須要對這么多路的音頻去做選路，選擇中間權重最高的幾路進行混音，最終播放出來，這樣就能從技術、聽感以及用戶體驗上盡可能保證音視頻體驗，比如上課時老師權重是最高的。這種方式的技術實現其實是比較復雜的，我們設計了一套音頻選路的加權選路算法——選擇性去從幾十路音頻中間抽幾路播放出來。

除了做選路以外，另一點是回聲消除。因為同時說話是一個非常典型的場景，我們叫做雙講場景——我在說話的時候，遠端也在說話，遠端的聲音就會從我的本地播出來，本地我自己的聲音也要采集，這樣兩邊同時說話的時候就會導致對方的聲音里面可能會帶上自己的聲音，對方會聽到自己的聲音，產生回聲。這種情況是音頻處理中一個典型的”紅藍墨水分離”問題，我們要做的是從紅墨水跟藍墨水的混合中把各自抽離出來，這在業(yè)界是比較典型的難題。騰訊其實在10多年前就開始做音視頻技術相關的研究，并在16年組建了音視頻實驗室，后來改名叫多媒體實驗室，它打造了一個TRAE引擎（Tencent of the Realtime Audio Engine）——騰訊實時音頻引擎，這個音頻引擎主要做3A處理和音效，在行業(yè)內都處理于領先水平，對于雙講的處理表現不俗。

2.2 效果與質量檢測

除了基礎能力以外，大家平時做業(yè)務的時候經常會遇到客服接到一些反饋，總結起來有兩大部分是要特別關注的。第一個是屬于不可用類的問題，比如無聲、黑屏等完全不可用的情況，這種我們叫客損。第二種是體驗比較差的情況，比如模糊、卡頓，以及包括雜音、回聲等在平時上課過程中經常可能接到的反饋。因為客戶端的設備非常多，我們無法預測到用戶在當下堂課使用什么設備，所以歸根起來就是是否能夠更好地把控音視頻質量以及效果。

針對這個問題，我們在產品的全鏈路中埋點，引入了一套大數據的分析系統(tǒng)，盡可能早的掌握音視頻質量和效果的潛在問題。舉個例子，無聲現象的典型來源有幾個：首先是設備問題，比如麥克風采集不到聲音或者揚聲器壞了，這是都屬于設備故障類；第二是比較常見的網絡問題，比如家庭的WiFi可能接入太多設備后，由于路由器本身性能不好，負載過高，從而出現了隨機性的丟包或者隨機性的高抖動；第三個是打斷，比如臨時的電話接入、誤開第三方App或者進程搶占，都可能會導致課程中斷；最后一點是數據處理，比如雙講的剪切、采集播放的音量太小、沒有做增益調節(jié)等等。

我們針對每一個環(huán)節(jié)都加了相應的埋點上報，并且在這個環(huán)節(jié)也提前預置一套解決流程。比如當檢測到設備故障，就直接拋出一個回調，告訴用戶設備故障；再比如當檢測到音頻持續(xù)為0超過幾秒，就會直接警告設備持續(xù)無采集、持續(xù)音量為0。

我們根據全鏈路埋點監(jiān)控，把所有數據上報，搭建了一套AI模型，也就是云端決策系統(tǒng)，這個系統(tǒng)使用了騰訊自研的質量評估算法，既包括有參考的、也包括無參考的，同時在云端做持續(xù)的優(yōu)化迭代。我們把整個鏈路中間包括模塊處理失敗的反饋上報、網絡狀態(tài)、QoE的算法策略等全鏈路的追蹤都做了埋點，這樣我們就可以通過這一套系統(tǒng)精確的找出哪一個模塊出了問題，以及下一步應該如何改進。

除了全鏈路埋點監(jiān)控和云端決策系統(tǒng)，我們針對客戶面在TRTC控制臺上開放一個Dashboard（監(jiān)控儀表盤），這個監(jiān)控儀表盤我們盡可能提供精準簡要的數據，并且向用戶可視化地開放出來。目前第一期主要做的是通話詳情，提供兩周之內端到端全鏈路的通話詳情，通過這個儀表盤就能有效獲知課堂的整體情況，后續(xù)我們還將繼續(xù)推出更多的能力。

此外我們還做了一套自研評估體系，以此作為內部的預警監(jiān)控。以Demo為例，我們會從幾十個維度做了一整套數據的分析，其中包括音視頻卡頓率、緩沖時長、連接成功率等，通過自研的質量評估算法評估音頻以及視頻的質量，幫助我們更好地知道某一個客戶線上的情況到底是怎么樣？相比昨天質量是否有下降？下降的原因在哪里？結合前面提到的全鏈路跟蹤，我們就可以在很大程度上分析出來導致質量下降的原因所在。

2.3 組合類場景下的音頻優(yōu)化

第三塊是關于組合場景，典型的就是精讀課——在老師授課過程中會分享一些課件或者視頻，比如在語文學科中就有古詩詞誦讀的部分，老師會先播放一個視頻，然后再對古詩詞做講解，類似的場景還有很多。這其中就會出現一些問題，比如音量大小不一致，老師說話的同時視頻也在播放，但視頻的聲音可能就聽不清楚了；還有視頻跳音，視頻播放過程中突然發(fā)現視頻的聲音卡了一下又跳了；此外還有本地出現回聲、音頻被打斷等等。

在這種場景下，它主要的問題在于音頻。操作系統(tǒng)中間對于音量通道分級的處理不同，以iOS為例，它的音頻管理做得非常復雜，會針對不同的音頻通道做不同的優(yōu)先級管理，而且每個音頻通道相互之間處于分離的狀態(tài)，舉例來說就是電話和平時播放騰訊視頻走的音量通道是不一樣的，操作系統(tǒng)會認為這是兩個不同的音量，就單獨的去處理，然后最終把它從系統(tǒng)的輸出送出來，但就是因為音量通道不同，所以在操作系統(tǒng)層面就會做優(yōu)先級，比如電話的優(yōu)先級肯定是最高的，其次是鬧鐘，然后是媒體音量。

媒體音量就是我們平時觀看視頻或直播的，所以在這種場景下你的播放器一般走的就是媒體音量。但是做RTC的話，我們默認會選擇用通話音量來做。但是這兩者用了不同的音量通道之后，因為通話音量的優(yōu)先級更高，就會壓制媒體音量通道。而且在做3A處理的時候，比如用硬3A的話，系統(tǒng)會在在輸出之前去做3A的對比，然后可以處理好回聲；但是用軟3A的話，一個APP中RTC進程沒有辦法拿到另一個進程的音頻數據，這樣就沒有辦法把它的回聲消掉，從而導致了前面提到的音量不一致以及音量回聲沒有消除干凈等現象。

那最好的解決辦法是什么呢？我們把這兩個音量通道做了合并，雖然原理很簡單，但實際執(zhí)行起來是非常復雜的，原因首先來自編解碼，第二是源于播放器。播放器有非常復雜的業(yè)務邏輯，大部分RTC廠商都是先做RTC，然后在它的上面做一個非常簡單的播放器，只能用來播放基本的視頻、音頻內容。但是我們已經有一套非常完整的播放器，跟RTC要完全融合的話，中間會有比較大的改造量，兩者的融合需要把整個播放器底層的音頻完整替換掉，并且保證它能夠跟RTC用起來。

解決這個場景要做到兩點，一款高效好用的播放器以及一套十分穩(wěn)定的RTC客戶端。我們在17年的時候就已經做了一套非常完整、高效好用的TXVodPlayer，這個播放器現在非常多的用戶都在用，而另一方面TRTC今年支撐了非常多的內部業(yè)務以及外部業(yè)務。那么當這兩者很好地結合起來，我們才認為真正的解決了精讀課這一場景。

3.TRTC一些新的嘗試

以上是我們疫情期間在教育行業(yè)實踐中踩過的坑以及優(yōu)化方案。除了底層技術的優(yōu)化，我們也和客戶一起探索了新的場景，今天主要介紹兩個方向，一個是AI老師課堂，另一個是超級小班課。

3.1 AI老師課堂

我們第一次接到這個需求的時候，和客戶討論了很長時間，從技術產品的角度出發(fā)其實并不困難，重點在于它是不是一個偽需求。經過和多家客戶討論，我們都認為它是真正存在痛點的需求。比如一些教輔機構多年運營積累了非常多精華的課程內容，他們希望能夠把這些內容合理地利用起來，提高使用效率；同時對學生而言，一些新老師講授的內容并不一定有以前經典的講得那么好，學生也希望能夠接受更好的教學資源，所以在這一點上AI課堂能夠發(fā)揮很好的作用。

AI課堂技術實現最主要的就是兩個方面。首先是AI算法識別，我們給視頻打標簽，識別學生的語音反饋，然后推送相應的內容；另一方面是要有穩(wěn)定的RTC，這種情況下肯定無法在客戶端去做推送，而是要在服務端把推送服務集成進去，然后通過AI識別之后，要有交互的過程，所以我們做了一套Linux SDK。這一套Linux SDK的主要作用是輸入輸出。通過Linux SDK這種方式來解決推送以及拉取視頻、音頻的問題。這樣就實現了用戶在上課的時候能夠把語音反饋實時識別，然后到AI課堂服務識別后挑選對應標簽的視頻推送給用戶。從用戶體驗角度，只要視頻剪輯比較好的話，用戶是感受不到中間跳轉的問題。而且因為是通過RTC的方式來做的，所以在平滑度、自然度上做得是非常好的。

3.2 超級小班課

第二個場景創(chuàng)新是關于超級小班課。在教育行業(yè)一方面是內容特別重要，另一方面是老師特別重要。培養(yǎng)一個好的老師需要花費大量的人力物力財力，因此就出現了一個好老師同時給多個學生上課的需求，由此提出了超級小班課的概念——一個老師會同步給很多組學生上課，每個組有3-4名學生，在這過程中每一個學生都能到得答疑的機會，還能夠自由地跟老師互動。

這個場景的主要問題在于傳統(tǒng)RTC是基于房間的，所以一個老師往往只能在一個房間，這種情況下需要將老師的流擴散出去，房間只是作為一個標記。那么通過對房間邏輯的優(yōu)化，我們可以讓一個用戶同時存在于多個邏輯房間，從而解決這個問題。

最后感謝信任我們的客戶，雖然TRTC已經在騰訊內部服務了很多年，但正式對外是在2019年，企業(yè)服務相比內部服務有很多的東西是之前沒有預想到的，所以非常感謝客戶能夠在這個過程中間與我們一起把技術產品踏實落地，也歡迎大家給我們多提出一些寶貴的意見，讓我們可以更好地去改進，謝謝大家。

灣區(qū)最原汁原味的技術，全球最前沿的應用實踐

無需漂洋過海，我們在線上等您！

LiveVideoStackCon 2020?美國站

2020年12月11日-12月13日

點擊【閱讀原文】了解更多詳細信息

總結

以上是生活随笔為你收集整理的实时音视频助力在线教育风口的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。