一、互聯網通信服務的發展

縱觀整個互聯網通信發展史，最開始是傳統通信，主要借助郵件、短信、電話、傳真等方式進行通信。到瞭移動互聯網時代，利用IM技術我們在手機上做到瞭更豐富的通信能力，誕生瞭QQ、微信等一堆工具。再往後面發展就到瞭通信3.0時代，也即產業互聯網時代。此階段要打通的不僅僅是人跟人之間的通信，而是人跟物，人跟服務，服務跟人之間的全部聯結，達到萬物互聯的狀態。而基於萬物互聯的通信能力，就需要通過IM+RTC的能力來實現。

比較常見的場景包括在線會議、視頻客服、在線教育等，另外還有一些娛樂場景，比如桌遊直播、在線K歌、在線語音聊天室、音頻FM電臺、視頻直播等，這些場景都是大傢平時可能接觸比較多的跟音視頻通信相關的場景。除此以外，我們還實現瞭很多其他的能力和場景。

二、騰訊實時音視頻TRTC

1. TRTC能力介紹

騰訊實時音視頻TRTC是在騰訊雲官網上對外售賣的面向開發者的PaaS服務，主要是提供音視頻的通信能力。同時我們提供覆蓋全平臺的客戶端SDK，不管是手機、桌面或者是網頁、小程序，都擁有對應的解決方案。

今年由於疫情原因，在線教育和遠程辦公得到瞭迅猛發展，我們的服務達到瞭日均30億分鐘/天的規模，是全球目前運營規模最大的RTC服務之一。

主要提供以下兩種場景，第一種場景是多人實時互動，典型的代表就是騰訊會議。騰訊會議是基於TRTC做的，我們針對多人互動進行瞭深度優化，現在可以做到全球端到端延時在300毫秒以內。丟包率達40%的時候也可以正常進行視頻通話（70%丟包率下仍能保持通話能力），單房間可以做到300人同時在線，最多支持30個人同時說話。

在線教育運用也比較多，比如好未來教育、高思教育等，在疫情期間他們的線下業務完全沒辦法開展，所以隻能把線下課堂搬往線上，在這個過程中就需要有非常可靠的音視頻能力來保障。

另一個場景是超低延時直播。我們平常看到的很多直播，它們的延時通常是在3-5秒，尤其是用手機H5來觀看的話，延時可能會達到幾十秒，我們通過對TRTC的技術架構做優化，把全平臺的延時做到一秒以內，並支持大規模的並發。

這個場景目前在騰訊內部的多個產品都可以體驗到，比如騰訊課堂、企業微信，微信群直播功能，其中就運用到瞭TRTC的低延時直播能力，最近火熱的微信視頻號直播，也都是使用TRTC來做的。

2. 如何做到實時？

在互聯網想要做到端到端延時在300~1000毫秒以下的實時體驗，是有很多的技術難題需要攻克的。正常直播的延時例如虎牙、鬥魚、B站那樣，通常延時在三到五秒以上，實時互動能力比較欠缺。另一個典型場景如微信通話，因為走的是UDP，所以延時非常低，雙向延時能控制在500毫秒以內，能夠帶給通話雙方良好的互動反饋體驗。

為什麼大傢覺得面對面說話的感受，會比通過互聯網打電話的感受更好呢？原因很簡單，因為當面對面的時候，大傢的交流是即時的，說出一句話那邊可以馬上得到反應。而如果切換到網絡上，因為各種原因延時總會存在，如果延時大於500毫秒左右，就能明顯感覺到對方的反饋會慢上一些，從而帶來不好的實時體驗。

為瞭解決這樣的問題，我們首先要瞭解一點：在實際的互聯網場景裡，網絡肯定是有損的。理想的情況是網絡發多少包過去對方都能收到，不會丟一個包，帶寬無限大，延時無限低。而現實的情況是或多或少總會有丟包，網絡延時也不確定，有時快有時慢，網絡帶寬也不確定，我這邊是100Mbps的高帶寬，而對方卻可能隻有300kbps。

這種情況下如果用TCP來做會面臨很多的問題，TCP傳輸策略會導致在傳輸的過程當中，如果遇到抖動傳輸就會變得很慢，導致發包速度降低，數據發送變慢，延時就會拉大。

另外TCP的緩沖機制，在拿到數據包之後不是馬上發出去，而是設置一個緩沖，因為網絡抖動，有瞭緩沖就可以更好的抵抗抖動，但也因為有瞭緩沖，意味著所有的數據要等到緩沖滿瞭後才能發出去，這個過程也會產生延時。

而且在播放器端，通常為瞭抵抗來自網絡的抖動，視頻幀在交給解碼器解碼之前，我們會設置一個區域叫Jitter Buffer。Jitter Buffer的作用類似於一個小水庫，當我們收到瞭一些數據，會放在裡面緩沖一下，比如拿到瞭對方的一幀畫面，不會馬上渲染出來，可能等到兩幀之後再去渲染前面一幀，這樣做會加強觀感的流暢性，但也因為等瞭一兩幀，增加瞭一些延時。

為瞭減少延時，在丟包的時候需要盡量減少重傳，重傳一次就意味著要再發一次包，延時也會增大。TCP采用的是ACK機制，比如我發瞭5個包過去，其中丟失瞭第三個包，那麼對方會告訴我：他收到瞭第一個和第二個，請接著把三、四、五發過來。用這樣的方式可以保證每次發包對方都能收到，保證瞭可靠性，但是缺點就是需要不停地做確認，往返時間變得很大。

5ecac0bbd00e9e3a77b49eac71284232

而TRTC使用的是UDP傳輸，采用的方式是NACK，比如我發5個包過去，其中丟瞭第3個，對方就會告訴我哪個丟瞭，後面發包的時候，再把第3個發過去，通過這樣的方式我們把延時控制在幾百毫秒以內。

我們還通過FEC技術來優化網絡抗性，比如本來要發10個包過去，為瞭防止中間有丟包，發的時候可能發11或12個包過去，多出來的這幾個包就是做冗餘數據校驗的。對方收到這些包之後，如果發現中間有丟包，可以通過校驗數據把丟失的數據恢復出來，避免瞭因網絡丟包而重傳的次數，從而降低延時。但是FEC是采用多發包的方式，所以相當於是占用更多的帶寬來換取延時的降低。

不管使用的是FEC，還是ARQ的策略，如果隻是單純使用一種的話，達到的效果也是有限的，我們通常還會結合QoS實現更快速準確的帶寬預測，及時地調整編碼速率以匹配帶寬變化，降低傳輸耗時。QoS越準確，就可以越精確地調整發包的數量，包括要不要補發，要不要發更多的冗餘包等，綜合運用QoS、FEC和ARQ，一般能抵擋一定的網絡丟包。

為瞭抵抗網絡抖動引起的視頻損傷，我們修改瞭編解碼器。在標準的H264編碼裡面，每一個畫面都會有一個I幀作為開始，後面的幀依靠前面一幀作為參考，在解碼的時候先拿到I幀，再依次把後面的幀一幀幀的解碼出來，還原視頻畫面。但是這會帶來一個問題，因為是嚴格依賴於前一幀，當發生網絡丟包的時候，即使隻丟瞭一幀，在解碼的時候由於缺失瞭那一幀的數據，失去瞭參照關系就解不出來，對於用戶來說就是卡在瞭那邊。

對此，我們修改瞭參考關系，不是嚴格依賴於前一幀，而是可以選擇性的去依賴前面某一幀。這樣做帶來瞭什麼好處呢？隻要控制好瞭依賴的順序，就能保證在網絡出現丟包的時候，即使缺失瞭一兩幀的數據，也可以完完整整的把畫面顯示出來，讓用戶看上去不卡頓。

音頻的敏感程度比視頻更高，視頻即使丟瞭一幀兩幀，延遲一兩幀人也可以腦補回來，而音頻丟包哪怕很少，人也會明顯感覺卡頓。音頻丟包的補償采用的方式是PLC，我們對采集到的音頻以20毫秒作為一幀，在編解碼器裡對音頻的幀做一些狀態保存，叫做PLC unit，當我們發現這個PLC unit裡有幀丟失的時候，就會通過其它關聯的PLC unit來計算出這裡丟掉的幀的聲音數據是怎樣的。

為什麼可以這樣做呢？人說話的時候，他的語音是存在一定的關聯性，前面說的一句話跟後面說的一句話，在音頻的音調和頻率上有一定的關聯性，所以可以通過前後的算法依賴去重建丟失幀的聲音信息。

原理雖然簡單，但是實際上算法實現的時候，需要考慮的因素是非常多的，通過PLC技術，可以在70%的丟包情況下還能保持語音的通暢。

3. 深度優化

除瞭上述的技術應用，我們還做瞭一些深入的優化，第一個就是關於音畫同步。因為網絡會有抖動，收到音頻或者視頻的速度有快有慢，在得到音頻數據之後，我們會先做一次抖動評估，評估出當前抖動的劇烈程度，由此評估出視頻比音頻究竟是來快瞭還是來慢瞭。通過這個再進行變速調節，變速調節是用來調節音頻，把音頻的速度撥快或撥慢一點，最終找到平衡點。音頻按照平衡點的這個速度來播放，視頻的幀就能和音頻對齊，從而保證每一個接收端看到的畫面和聽到的聲音可以同步播放出來的。

另外還要註意“回聲”現象，大傢如果平時註意一下手機，就會發現揚聲器和麥克風一般安裝在手機底部左右兩邊，這樣就會導致：對方聲音播放出來的時候，會被自己本地的麥克風再采集一遍，如果不做任何處理對方就會聽到這邊采集到的他說出的話，也就是自己的回聲。

因此在這個過程中我們運用騰訊自研的領先行業的實時音頻引擎—TRAE（Tencent Real-time Audio Engine）的能力來做一些3A處理，比如回聲處理，也叫做AEC。將拿到的對方聲音跟本地采集到的聲音做比對，在本地采集到的聲音裡把對方要播的聲音反向消除掉，這樣對方就不會聽到自己的回聲瞭。AEC還有更復雜的場景——雙講場景。當兩邊一起說話的時候，雙方都聽不清楚對方在說什麼，這種情況就叫雙講。在雙講場景下，這邊說話的聲音從那邊播出來，那邊再把這邊聲音采集一遍傳回來，這邊又會采集一遍再傳回去......兩邊聲音來回采集，最後雙方都聽不清楚對方說什麼。

行業把這個問題形象的稱之為“紅藍墨水分離”，紅藍墨水混合在一起，如何把各自的墨水再單獨抽取出來？雙講問題是業界公認的難題，而騰訊在通信領域鉆研多年，通過自己的算法解決瞭這一難題，TRAE既能保護近端不受損傷，還能保證回聲消除幹凈，讓雙講場景下的人聲清亮通透。

此外我們還做瞭一套雲端決策系統。我們整個音視頻的體驗系統叫做QoE，除瞭做FEC、ARQ、QoS以外，我們還需要評估用戶的個人感受。因為如果完全從技術上來描述，也許一次通話已經沒有丟包情況，但是視頻播放的實際情況，用戶看到的、聽到的卻並不一定能帶給他自然真實的感受，所以還需要一套大數據系統，來監測線上各個環境下用戶的使用體驗。

我們需要打造一套提分系統，來評價線上的直播和通話質量，這樣的一套東西我們稱之為雲端決策系統。雲端決策系統通過客戶端上報各項質量指標，動態地去調節每一端的參數，它能夠做到哪怕大傢都處在同一個房間裡面，每一個人也都可以有一套不同的參數，也就是說能保證每一個端都有自己的獨立參數，保證端上最好的效果。

cce20399575fc7b2ab092fc8758f1eda

4. 更多能力

我們還做瞭一些其它的能力，比如跟微信小程序團隊合作，為微信、QQ、企業微信小程序提供底層音視頻能力的SDK，並在小程序上對外開放。對外封裝主要分為兩個標簽，一個叫<live-pusher>，一個叫<live-player>。我們結合瞭騰訊雲的後臺，做瞭大量的加速和優化，能夠保證用戶溝通擁有和原生APP一樣的使用體驗，延時一樣，聲音的聽感也一樣。

47afc7d87415a78cc4c9157fb436d0a9

還有現在無論是做直播還是普通的會議和通話，美顏功能運用得很多，於是我們基於人臉算法能力，加入瞭人臉的美顏、動效、背景替換、高級美顏等特效。另外還跟騰訊天籟實驗室合作，添加瞭包括變聲、混響等許多音頻特效。

我們還提供一個運維層面的監控儀表盤。因為網絡抖動和設備問題，平時通話過程中難免會發生不順暢的時候，比如有的用戶麥克風壞瞭，有的在高鐵上過隧道網絡斷開，這些情況下我們就需要瞭解到用戶的網絡情況或者設備情況到底是怎麼樣的，因此我們做瞭一個全鏈路的儀表盤，可以追蹤到15天以內用戶從端到端的整體鏈路情況，能夠看到這個用戶到底因為什麼原因遇到瞭問題。

通過改造RTC技術，我們實現瞭單個房間容納十萬人的低延時直播。傳統RTC直播一個房間最多容納幾百人，而且投入的成本也比較高，需要采購很多終端，才能搭起幾百人的會議。而我們通過改造技術棧，把RTC的播放能力從原本的幾百方擴大到10萬人級別，所有的用戶都在一個房間裡面，而且每一個人說的話對方都能馬上清晰聽到。

如果還有更大規模的需求，可以旁路轉推到CDN再去進行更大規模的分發。如下圖所示，我們的基礎指標列在上面，包括支持720P、1080P高清畫質，支持48kHz立體聲高音質語音等等，這些都是我們經過許多年的積累打造出來的音視頻能力。

5.客戶案例

TRTC現已上線兩年多時間，我們也為各個行業一千多傢客戶提供瞭各種各樣的解決方案和技術支持，比如跟金融行業合作，在金融的虛擬營業廳裡聯合央行的科技司起草遠程手機銀行音視頻的標準，跟騰訊雲物聯網團隊合作，在IoT物聯網雲上直接把實時音視頻的能力嵌入進去，用戶在IoT場景裡需要使用到實時音視頻能力的時候，可以直接在騰訊物聯網開發平臺loT Explore的控制臺上選擇使用。

我們為騰訊內部多個BG 80%的業務場景提供瞭支持，也為各個行業，包括政府民生、社交娛樂、在線教育等等提供能力支持。比如跟華晨寶馬合作上線瞭一個小程序，用戶通過小程序可以在線看車，聽導購實時介紹每一輛車的特點。另外還有跟貝殼合作上線瞭VR看房功能，讓用戶可以遠程通過VR的方式瞭解每一個樣板房的場景，並且在這個過程當中能夠跟導購員和經紀人實時溝通，瞭解房子的狀態。

下圖所示的是我們寫的一個 Demo，如果大傢想體驗 TRTC 的相關能力，可以掃碼下面二維碼體驗，想瞭解更多信息也可以到騰訊雲官網上搜索 TRTC，查閱更多相關介紹。

http://itunes.apple.com/cn/app/id1400663224?mt=8<br>http://mp.weixin.qq.com/a/~42CfpvYZh_987JvBHjJD9A~~<br> (二維碼自動識別)