歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
轉載，本文作者，rexchang（常青），騰訊視訊雲終端技術總監，2008 年畢業加入騰訊，一直從事客戶端研發相關工作，先後參與過 PC QQ、手機QQ、QQ物聯 等產品專案，目前在騰訊視訊雲團隊負責音視訊終端解決方案的優化和落地工作，幫助客戶在可控的研發成本投入之下，獲得業內一流的音視訊解決方案，目前我們的產品線包括：互動直播、點播、短視訊、實時視訊通話，影象處理，AI 等等。
為方便大家消化，請參考本篇文章的思維導圖
音視訊小程式誕生在2017年4月一輛從深圳開往廣州的C7172列車上……
一次偶然的合作
2016年微信開始啟動小程式內測之前，騰訊內部的各個團隊就已經開始接到訊息。我們每個人都能預感到小程式將會對移動應用場景產生很大的改變。但在當時，我也是剛加入騰訊視訊雲團隊不久，對於這樣的資訊更多的是關注，而並無太多細緻的思考。
2017年伊始，隨著大量客戶的諮詢，我以及我所在的騰訊視訊雲團隊都開始意識到這裡的需求特別的旺盛。但由於精力有限，以“小團隊大成績”著稱的微信工程師團隊很難有精力覆蓋所有的應用場景，在音視訊這裡，小程式僅提供了一些基礎的採集和播放能力，比如大家最為熟知的
而就在此時，騰訊視訊雲的 SDK 產品在經過了一年多的打磨優化之後，已經像是二戰初期的零式戰機，隨時準備“砍瓜切菜”。這裡和合作機會雖然不定，但我們團隊依然坐上了從深圳總部開往廣州 T.I.T 的班車。
經過多次的溝通，以及 jianx 的努力幫助下，這個合作雖然偶然且充滿了各種不確定，但最終達成。
技術的挑戰
在音視訊應用場景下，兩個團隊能夠達成合作自然是個好事情。但是微信的市場地位也決定了這是一個不容兒戲的戰場，所以我們所面臨的挑戰也異常嚴峻：
（1）介面必須簡單易用，最好一兩個標籤就能解決問題
（2）滿足多種應用場景，既要支援直播又要能夠支援實時視訊通話
（3）功能必須可擴充套件，開發者可以根據自身的需要構建出各種個性化應用場景
（4）可維護性好，開發者能夠自助排查一些技術問題，而不需要本身是個音視訊專家
（5）安裝包體積增量足夠小，不然微信的安裝包體積控住不住
除了高標準的要求以外，時間也是一個非常不利的因素。整個專案留給我們可以證明自身能力的時間只有兩週，在短短兩週的時間裡，我們需要在一個 G2C 專案落地且成功通過產品演示和方案驗收。
化繁為簡
面對這些挑戰，我想到了蘇聯卡拉什尼科夫所設計的名槍 AK-47 。
之所以這麼成功，源於其所貫徹的簡單實用的設計理念：迴轉式閉鎖確保了安全性，杜絕了隨機事故的可能性；結構簡單易拆卸，因此要生產它並不需要特別精密的加工技術，也不需要投資巨大的生產裝置，甚至一個普通小作坊就能開工生產。
沒錯，化繁為簡，追求簡單可靠，這就是我們需要達成的目標。
攻克技術難關
達成這些並不容易，我們團隊一步一步的攻克技術難關
上行和下行
首先，我們要對騰訊視訊雲現有的音視訊體系進行拆解和抽象，也就是把整個體系打散成一個個積木，其中最重要的兩塊就是：音視訊上行（push）和音視訊下行（play）。
-音視訊上行（PUSH）
就是把自己手機上的聲音和畫面實時的上傳到雲端。我們將這部分能力用視訊雲 SDK 進行實現，並封裝成一個叫做 的標籤。
SDK 內部實現機制如上圖所示：首先，我們要對攝像頭的畫面進行捕獲，對麥克風的聲音進行採集。但是，原生採集和捕獲的畫面和聲音是需要進行預處理的，直接採集的畫面可能有很多噪點，所以我們要進行影象降噪；比如， 原生採集的人像裡，皮膚可能並不符合人們的預期，所以我們需要進行磨皮和美顏；直接採集的聲音可能也有很多的環境噪音，所以我們需要進行前景和後景音的分離然後進行底噪抑制。
經過預處理之後的畫面和聲音相比於原始採集的一般會有較大改善，因為所有的預處理都是以“討好”人類的視聽體驗為目的，所以這一看似不起眼的部分會吸引很多公司在其上做不少的技術投入。舉個身邊的例子，以 LCD 平板電視為例，SONY 的 LCD 產品線都沒有自家的液晶皮膚（以臺灣和大陸液晶皮膚為主），卻能在總體效果上一直領先其它公司，其背後的祕密就是在影象處理（基於影象資料庫做超解析度顯示）和背光技術（所有動物的眼睛都是對亮度最為敏感）上的不間斷的積累和投入。
畫面和聲音都經過“粉飾”之後，就可以送給編碼器進行編碼壓縮了。編碼器的工作是將一張張的畫面和一段段的聲音壓縮成 0101001... 的二進位制資料，而壓縮後的體積要遠小於壓縮前。最後要做的工作就是將編碼後的資料通過網路模組傳送出去。在線上直播場景中，一般採用的網路協議都是基於TCP的，而在實時通話場景中，所採用的網路協議則是 UDP 為主。
-音視訊下行（PLAY）
也叫播放，就是從雲端把編碼後的音視訊資料實時下載下來並實時的播放，這樣一來，您就能看到遠端的畫面，聽到遠端的聲音。同樣的，我們將這部分能力用視訊雲 SDK 進行實現，並封裝成一個叫做 的標籤。
SDK 內部實現機制如上圖所示：來自雲端的資料會直接送給網路模組，但網路不是完美的，總會有時快時慢的波動，甚至會有可能發生阻塞和閃斷。如果伺服器來一段資料， SDK 就播一段資料，那麼網路稍微一波動，畫面和聲音就會表現出卡頓。我們採用抖動緩衝（VideoJitterBuffer）技術解決這個問題，就像是為網路過來的資料準備一個小的蓄水池，音視訊資料先在這裡暫存一小會兒再送去播放，這樣就可以在網路不穩定時有一定的“應急”資料可以使用。
資料經過緩衝以後，就可以送給解碼器進行解碼，解碼就是把壓縮後的音視訊資料還原成影象和聲音，然後進行渲染和播放。我們採用了 openGL 進行畫面的渲染，使用 iOS 和 Android 的系統介面來播放聲音。
訊號放大器
有了這兩個簡單的標籤，我們就可以進行初步的組合，構建出第一個最簡單的應用場景：線上直播。
線上直播是一個非常經典的單向音視訊場景，您只需要簡單的將兩個標籤組合在一起即可， 負責將本地畫面和聲音實時上傳到騰訊雲， 則負責從雲端實時拉取音視訊流。
如果是簡單的一路上行 + 一路下行，那麼我們隨便搭建一箇中轉伺服器就可以解決問題了，但這樣只能在很小的範圍內實現高質量的直播服務，真正要做到高併發和流暢無卡頓，就需要一個強大的視訊雲。
視訊雲在這裡的作用就像一個訊號放大器，它負責將來自 的一路音視訊進行放大，擴散到全國各地，讓每一個 都能在離自己比較近的雲伺服器上拉取到實時且流暢的音視訊流。由於原理簡單、穩定可靠且支援幾百萬同時線上的高併發觀看，所以從線上教育到體育賽事，從遊戲直播到花椒映客，都是基於這種技術實現的。
但線上直播方案只能應用於解決單向音視訊問題，因為它有個明顯的問題，就是延時一般都是在 2秒 - 5秒左右，這是使用 標籤配合騰訊雲視訊雲可以達到的效果。如果是
把延遲降低
在安防監控的場景裡，家用 IP 攝像頭一般都帶有云臺旋轉的功能，也就是攝像頭的指向會跟隨遠端的遙控進行轉動，如果畫面延時比較大，那麼觀看端按下操控按鈕到看到畫面運動所需要等待的時間就會比較長，這樣使用者體驗就會特別不好。
再比如 2017 非常流行的線上夾娃娃場景，如果遠端玩家視訊畫面的延時非常高，那麼遠端操控娃娃機就變得不太可能，沒有誰能真正抓到娃娃。
既然要達到這麼低的要求，普通的線上直播技術就不再適用了，我們需要新引入兩個新的科技點：延時控制 和 UDP加速。
- 延時控制
網路不是完美的，網路是波動的。在有波動的網路下，伺服器上的音視訊資料並不是穩穩的來到您的手機上，而是忽快忽慢。慢的時候您可能會看到卡頓，快的時候就會產生堆積，而堆積的後果就是延時的增加。所以，我們需要採用延遲控制技術，它的原理很簡單，當網路慢的時候就播的慢一點，當網路快的時候就播得快一點，這樣就起到一定的緩衝作用。當然，真正實現時就會發現，聲音是個很不聽話的“孩子”，要處理好聲音的效果是一個非常高難度的技術活。
- UDP加速
既然網路不那麼完美，總是時快時慢，那我們是不是可以改善一下呢？在經典的單向音視訊方案中，一般採用的都是 TCP 協議，因為它簡單可靠且相容性極好。然而 TCP 的擁塞控制特別注重公平，天然就有時快時慢的壞毛病，所以我們需要用 UDP 協議替代之，相比於設計目標定位於可靠傳輸的 TCP 協議，UDP 可以做得更穩且更快。
我們將 延時控制和 UDP 加速技術加入到 標籤裡，可以將端到端的延時控制在 500ms 左右。這對於操作延時要求比較苛刻的場景，就可以滿足需求了。
單向變雙向
有了單向低延時技術，那麼雙向視訊通話自然也就比較簡單了，只需要通話的雙方 A 和 B 各自拉通一路低延時鏈路就可以了。
比如在車險定損的場景裡，遇險的車主通過小程式呼叫保險公司，這個時候保險公司內部的定損客服只要通過一路低延時的鏈路就可以看到車子的出險情況。但是僅僅這樣還不夠，視訊內容跟圖片一樣，都容易被實現偽造和作假。所以定損員就需要有一路視訊同樣到達車主那裡，這樣兩路音視訊同時連通，就構成了一個典型的視訊通話場景。由於車主和定損員可以通過視訊進行交流，因此造假騙保的風險就被極大地降低了。
雖然這樣說是沒錯，但實現上可不是那麼簡單的。恰恰相反，它非常困難，因為我們還需要引入額外的很多科技點：
- 噪聲消除
噪聲抑制的目的是將使用者所處環境裡的背景噪音去除掉，好的噪聲抑制是迴音消除的前提，否則聲學模組無法從採集的聲音辨別出哪些是回聲，哪些是應該被保留的聲音。
- 迴音抑制
在雙向視訊通話中，使用者自己手機的麥克風會把喇叭裡播放的聲音再次記錄下來，如果不將其抹除掉，這些聲音會被反送給對端的使用者，從而形成回聲。
- Qos流控
網路不可能一直都很完美，尤其是中國大陸地區的上行網速一直都有政策限制。Qos流控的作用就是預測使用者當前的上行網速，並估算出一個適當的數值反饋給編碼器，這樣一來，編碼器要送出的音視訊資料就不會超過當前網路的傳輸能力，從而減少卡頓的發生。
- 丟包恢復
再好的網路也難免會有丟包的情況，尤其是 WiFi 和 4G 等無線網路，由於傳輸介質本身就不是可以獨享的，所以一旦受到干擾，或者高速運動都會產生大量的丟包，這時就需要引入一些丟包恢復技術，將失去的資料儘量補救回來。
以上四個科技點，我們也加入到了 和 標籤中，並給他們賦予了一個新的模式 RTC（ Real Time Chatting 的 首字母縮寫，有點 Chenglish 的味道），這才真正把實時音視訊通話搞定。
你看，要保持功能到位，又不能跳出標籤這種簡單易用的設計風格，這不容易吧。實際上這裡的四個科技點實在是太難了，需要很多年的技術積累和沉澱，以至於我們也不是現用現做的。正所謂站在巨人的肩膀上才能看得更遠，這裡的技術能力是由騰訊音視訊實驗室的“天籟”引擎所實現的。
雙向變多人
既然雙人視訊通話已經搞定了，是不是多人也就照葫蘆畫瓢就可以了？您看，我們只需要將 A 和 B 之間的 url 置換，變成 A、B、C 甚至更多人之間的 url 置換，不就可以了嗎？
思路依然正確，但是真正要將功能做到好用且成熟，僅依靠簡單的 url 交換是非常粗糙的，我們需要繼續引入額外的兩個科技點：
- 房間管理
以上圖所示的 A B C 之間的多人視訊場景為例，要讓每一個人都很清楚其它人的狀態（比如播放url，以及當前是否有上行等等），這個事情可是非常困難的，搞不好就容易出現各方資訊不對齊。對於更復雜一點的情況，比如當有第四個人 D 進來的時候，或者第五個人 E 進來又出去的時候，這種資訊同步幾乎就是一場噩夢。
最好的辦法就是把參會人的狀態和資訊都收攏在伺服器端，構造一個 房間 的概念，這樣就可以確保參會人都能從服務端獲得同樣的資訊，而不需要各自去維護。
- 通知系統
當有新的參與者進入房間，或者有人離開時，就需要對房間裡的人進行資訊廣播，這就需要一個不錯的 IM 系統負責收發訊息。比如當 D 進入時，就可以向房間內的其它成員廣播這個 “I'm coming” 的事件，這樣 A B C 就可以在自己的 UI 上展示 D 的視訊畫面了。
加入房間管理和 通知系統以後，我們就可以將 和 和微信小程式的 websocket 等基礎能力組合在一起，構建各種功能強大、邏輯複雜的小程式應用。
一路走來
一路走來，大家可以看到我們在小程式音視訊的技術體系上所做的種種努力可以用如下的技術圖譜勾勒出來：
- 首先是化繁為簡，將所有的音視訊解決方案拆解成兩個基礎行為：上行和下行，並通過兩個標籤 和 的簡單組合，實現最基本的線上直播功能。
- 之後是通過加速線路和延時控制，將一路音視訊的時延縮短到 500ms 以內；
- 再之後，我們通過引入噪聲抑制和回聲消除等聲學處理模組，讓一路變兩路成為了可能，這也就構成一個最簡單的視訊通話能力。
- 最後，我們又通過加入房間服務和狀態同步通知，將雙路音視訊變成了多路音視訊，從而將應用範圍進一步擴大。
問答
相關閱讀
此文已由作者授權騰訊雲+社群釋出，完整原文請點選
搜尋關注公眾號「雲加社群」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在雲加社群！