隨著低延時流媒體技術的不斷進步，在線教育行業持續升溫。本文來自七牛云在線教育行業解決方案專家 徐晶在LiveVideoStackCon2018大會中的演講。在演講中他闡述了基于WebRTC架構的低延時直播技術突破以及其在教育行業中的實踐與思考。本文由LiveVideoStack整理而成。

文 / 徐晶

整理 / LiveVideoStack

大家好，我是來自七牛云的徐晶，非常榮幸可以跟大家分享我所做的一些項目和實踐，本次我要分享的主要內容包括以下幾個方面：

1， 視音頻技術的演進；

2， WebRTC 課堂實踐；

3， WebRTC 在教育行業的思考；

一、視音頻技術的演進

首先，我們一起來看上面這張圖，這張圖是由國際電信聯盟電信標準化部門統計所得，圖中的橫軸坐標是毫秒，代表著時延，縱軸坐標是用戶的體驗度。由上圖，我們不難發現，時延達到150毫秒的時候，用戶的體驗度開始下降，當達到400毫秒的時候，用戶的感受是無法容忍。由此，ITU-T G.114國際標準規定，延時超過150毫秒表示已經開始影響用戶體驗，并且用戶可以容忍的最高延時是400毫秒。舉個例子，當發生臺風天氣時，電視臺的主持人通常會連線現場的記者，當連線返回現場報道時，基本是過了兩秒左右的時間，現場記者才收到主持人的話，聽眾的體驗感相當不好。類似于上面的情況基本上是無法實現實時互動的，想要進行實時互動的關鍵點就在于低延時。我以前也曾經做過八年直播相關的研發，從最初的底層協議到RTMP協議再到現在的WebRTC，用戶需求為何會逐漸從點播域向直播域靠攏，直播流媒體實時音視頻為何會越來越關注互動，也正是因為有了低延時，互動才得以慢慢發展出來。

不知道大家是否清楚，為什么流媒體在之前都沒有發展起來這種很好的互動性呢？有很多人認為RTMP協議很不錯，并且現在外面大部分采用的都是RTMP協議。既然如此，為什么大家都去研究WebRTC呢？首先，RTMP是基于TCP協議的，TCP是一個安全可靠的協議，它包含了很多機制，如數據的安全保障、三次握手、重傳機制等，但是這恰恰會影響到它的傳輸時間。舉個例子，我現在手上有一份數據要發送給另外一個人，發送過去之后由于網絡抖動導致丟包。他沒有收到包則會返回一個消息來告訴我他沒收到我的包，這樣就會產生很大的延遲。那么，能不能直接用UDP呢？三年前的廣電系統，比如北京衛視等采用的是TS流，TS流就是基于UDP的，它的傳輸非常有效。TS傳輸具有高可靠度，流媒體安全且質量好，但是基于UDP都是基于內網的，對網絡的要求非常高。北京衛視也只有內部的網絡全部用的是TS流，采用UDP的協議來傳送，一旦離開公司，就不可行了。因為UDP是不安全的，它沒有重傳機制，沒有各種保障的能力。從上圖中可以看出，UDP相對來說延時是最低的，但整體質量很低，對網絡的依賴程度也非常高，所以我認為這是一個成本的問題。在這里推出一個概念，叫做RUDP（Reliable UDP）。RUDP指的是將TCP和UDP各種優勢結合在一起，包含的功能有：

1）冗余編碼和前向糾錯；

2）場景化的重傳策略；

3）帶寬自適應調整；

4）更優的擁塞控制算法；

5）多點 relay…

簡單解釋一下什么叫做場景化的重傳，UDP因為沒有重傳策略，對于我們來說絕對不安全，場景化重傳就是說，如果是I幀這種關鍵幀丟失，那就重傳一個I幀，如果是一個不是特別重要的幀丟失，則不重傳，或者說有一些可以做同步的信令標準沒有到達，我也不重傳，這樣就可以極大的優化傳輸效率。

接下來介紹的是WebRTC的核心，大家也可以在Chrome，Google或WebRTC的官網上找到它的解釋。概括一下，WebRTC 內核提供的技術能力包括：第一，低延時的音視頻采集編碼和解碼。編碼和解碼是音視頻中最重要的部分，是提供低延時的保證。第二，降低門檻，有瀏覽器的地方就可以使用WebRTC；這點我覺得是Google做得非常好的地方，目前微軟、蘋果、Google等都支持WebRTC，除此之外，大家現在手上用的很多硬件設備，都已經支持。最終會達到只要存在瀏覽器的地方都能使用。第三，優異的RUDP傳輸協議；WebRTC原本就是基于UDP的，在UDP上進行優化，可以更有效的使其傳輸的數據安全、可靠。第四，端到端的協商/建聯框架；在七八年前，端到端上的直播幾乎不可能實現，為什么那時大家看到都是廣電做的直播，而不是互聯網在做直播？原因是端上的系統度不夠。

此外，WebRTC還提供一系列的業務能力：第一，低延時音視頻垂直領域的發展； 什么是垂直領域？比如今天分享的主題——教育，就是一個非常垂直的領域，當前在線教育的火爆也正是由于音視頻技術的發展，可以真正的實現溝通零距離。因此WebRTC對于垂直的領域非常有效，比如說教育、醫療行業等。第二，就是剛剛提到教育和醫療實時音視頻。第三，互動音視頻，遠程廣電系統；我之前在阿里巴巴為阿里云做了一個五地互傳，當時阿里云在紐約，新加坡，肯尼亞，杭州等都有很多分部，會發現你要把他們放在一起溝通是一件很難的事，當時我們想到的第一個策略就是用衛星，但衛星的成本真的是高的離譜，而WebRTC就可以完全顛覆它，衛星傳輸的質量不如WebRTC是因為WebRTC采用的技術和算法完全超越了硬件所能帶來的最低延時。第四，海外視頻；WebRTC還有一個最大的業務能力是進行海外跨國傳輸，例如在之前將戛納電影節上的一些活動的內容從戛納傳回來是一件基本不可能的事情，但是現在可以通過WebRTC實現，當然還要結合一些網絡和語音的相關優化。

二、WebRTC課堂實踐

接下來，從垂直領域來為大家介紹一下WebRTC在教育行業的課堂實踐中的一些能力，包括電子白板、高質量通訊、IM和協作能力。

2.1 在線白板

電子白板是用于解決多人互動場景下，用戶理解和分析的黑板能力。在教育行業中，無論是視頻還是音頻，都離不開這個白板。在學校里，對比現在和過去的課堂我們會發現變化是非常大的，但是只有一樣東西沒變，就是黑板，所以足以證明黑板有多么的重要。當我在一塊黑板上面寫字，一般人的做法是將它變成一個視頻然后傳播出去，讓大家看到。但是這樣有一個很大的問題，視頻資源最少需要300kbps的帶寬，這會占用用戶很多的帶寬，對于資源消耗是非常高的。我們做了一件事情，就是讓黑板變成一種描述性的語言。用描述性語言來替代白板，用它來描述白板到底畫了一些什么，而它所占的帶寬資源最高是9kbps，也就意味著，它的帶寬消耗是用傳統方式傳輸最低質量視頻這種方式的1/30。這是一個非常偉大的突破，可以為客戶節約大量的成本和資源消耗。視頻化白板的體驗問題包括無法放大縮小、不具備交互能力。但如果它是一個描述性語言，就可以隨意放大縮小，并保持清晰。另外，對于視頻，我無法在上面做第二次操作，但描述性語言可以。在數據擴充性方面，視頻化白板是很差的，由于視頻內容是非結構化的，導致很難被存儲。另外，AI是無法識別視頻索引的。舉例說明，我畫了一只貓，現在AI的能力還不足以識別它是一只貓。因為我畫的并不是特別有效，因此識別不了，但如果是描述性語言來表示，就能立刻識別出是只貓。最后是視頻化白板的數據識別轉換低。舉個例子，有些AI公司會將一些視頻中的數學符號識別成了數字，這是因為它無法識別。但對于描述性語言就可以輕松識別，因為它是一個矢量數據，它可以體量。這些說明了使用描述性語言改善了白板是有效的，在這里總結了一下，使用描述性語言白板帶來的好處：

1) ?對白板改變進行沖突管理

2) ?描述性語言降低整個白板視頻帶寬

3) ?降低 CDN 使用成本

4) ?回放和錄制存儲要求極低，幾乎可以忽略

5) ?矢量信息可無限放大細節

6) ?多端同步，相互備份

2.2 高質量通訊

Mesh、MCU和SFU是WebRTC的三種模式，目前可以說大部分使用WebRTC的廠商都選擇了SFU模式，因為它是最高效的。MCU一般應用于廣電領域，MCU就是不同端的推流，都發送到一個中央處理器上進行混流處理，處理完成后再分發給每個客戶端。SFU指的是每個客戶端都推流到服務器，由服務器轉發所有的數據到各個客戶端。如果廣電要用到畫中畫的功能，MCU是沒辦法實現的。通俗的講就是MCU將東西都固定好了，不能進行某一個區域的放大，它在服務端就已經進行了拼合。但是對于SFU，在收到服務器返回的數據流后可以再隨意進行拼合。Mesh是一個最基本的，相對高質量的模式，但由于它消耗的資源及帶寬功耗都比較高，所以不會經常用到。

高質量的通訊包括畫質、流暢度和協同，畫質包括了編碼方式、碼率和編碼效率，流暢度包括了中間層構建、Plus插件和帶寬優化方案，協同包括配套播放器和沖突管理。那在這里有幾個問題想和大家分享一下：

1) ?1.8Mbps 的 720P 清晰度高還是 3Mbps 的 1080P 清晰度高？

2) ?H264 Profile Level 決定了哪些要素？用戶體驗是什么？

3) ?為什么有些場景下只能用 Profile level 3.1 ?

4) ?究竟我們應該使用哪些最優方案去做畫面的匹配？

對于第一個問題，我問了很多人，最后發現一個很神奇的事情，還是有很多人會選擇3M碼率的1080P的清晰度高。我想跟大家說，Adobe官方有一個推薦，剛開始推RTMP協議的時候，對編解碼也給出了一個標準的推薦值，720P推薦的是1.8Mbps，1080P推薦的是5.5Mbps，只有這樣才能滿足相應畫質的傳輸。那么這個問題的答案也就自然而然了，用3Mbps去傳輸1080P是不滿足對應畫質的，看起來的效果不如1.8Mbps 的 720P 清晰度高。對于第二個問題，H264 Profile有3.0、3.1、4.0、4.1等不同level，這些算法依次是復雜程度越高，圖像的精度也越好，這也決定了畫質和效率，而用戶體驗指的是流暢度。對于第三個問題，為什么有些場景下只能用H264 Profile Level 3.1，而它的畫質沒有那么清晰？舉例說明，有一天小天才的負責人跟我說，他要做一件事情，就是讓孩子的父母可以用著手表進行有效的溝通。那這當中有個問題，我們當時給它設計的是畫質優先，將profile level調到了4.1，結果發現，手表8分鐘就燙得戴不了，功耗實在是有點高。后來，我們想到把這種嵌入式設備的profile level降到3.1，所以這就回答了為什么是有些地方情愿不需要畫質，而需要它的profile level更高效，這跟功耗有關。 對于最后一個問題，就畫面匹配這件事情來說，到底是提供一個高profile level的算法，還是低功耗的性能？這是兩件事情，需要有一些權衡，確定其中一個有最大化利益。

2.3 IM/AI

在這里我想給大家講一些案例，就是AI在視頻里的一些應用。噠噠英語的老板，給了我一個案例，他說有一個小孩上他們的課，噠噠都是一對一模式上課，結果那個小孩上來跟老師說， “老師啊，那個我不想上課，是我爸讓來的，你該干嘛干嘛去吧，我打游戲去了”。最后，這個課堂只是攝像頭開著，但是兩邊都沒有人，成了一個無效的課堂。后來，我設計了一樣東西，就是AI在視頻里面的應用。這個東西就是用一個機制去計算攝像頭的兩端，如果超過一分鐘沒有識別到人臉，那么它觸發一個報警給到教務，告訴他說，這是一個無效的課堂，你應該管管。第二個案例，為了防止高校中的翹課現象，我在課堂上裝一個攝像頭，然后對視音頻進行AI的識別，事先知道每個人是誰，然后不間斷去識別。若某位同學進來后，10分鐘之后他從后門溜走導致識別不到他，立刻出現一個報警，表示沒有檢測到某位同學。還有一個應用是我在跟浙江傳媒大學一起溝通的時候發現的，中國的教育到現在還沒有一個龐大的數據庫，沒有對某一個學生從0到1的分解。舉個例子，現在的探頭在視頻里的應用可以偵測很多行為，我發現上語文課時，有個小姑娘永遠坐在第一排，并且偵測她舉手次數超過30次，然后又發現她上數學課時，永遠在最后一排睡覺。它觸發的是系統自動進行一個大數據分析來告訴說這個女孩是適合文科，而不適合理科的，然后把這個信息交給教務，在這個女孩身上她打了一個標簽，大數據識別出來她適合文科，這就是社會價值、教育的價值。還有就是在教育領域也已經做了的，利用AI來做課堂筆記，在講課的同時，將老師和學生的語音進行語音識別直接轉成了文字，也就意味著，當這個課堂結束，課堂的所有筆記以及老師說的每一句話，已經全部變成一個文檔留存下來。

三、WebRTC 在教育行業的思考

最后，說說我們在教育行業里面的思考。第一，傳統教育是解決更多場景化的共性需求。舉一個簡單的例子，場景化教育就是當我有一天站在某個傳統高校的講堂進行演講的時候，該如何幫助提升效率。第二，垂直教育，利用WebRTC能力，構建創新型協作思維，讓程序員也可以做教育。第三，PUDC的開放，我認為現在中國教育還是有很多機構參與的，但未來會是一個PUDC的時代，每個人都是老師，每個人都是學生。最后，智能改變，就是去實現各種AI的教育。

精品文章推薦

技術干貨：

• 誰是最好的WebRTC SFU？

• WebRTC的擁塞控制和帶寬策略
  

• 使用級聯SFU改善媒體質量和規模
  

• 基于HLS格式的低延時互動直播技術

• 機器學習幫助WebRTC視頻質量評價

• 用WebRTC在Firefox上實現YouTube直播

• UDP成為低延時流媒體關鍵 選SRT還是QUIC？

• 下一代低延時直播CDN：HLS、RTMP 與UDP +WebRTC

總結

以上是生活随笔為你收集整理的WebRTC直播课堂实践：实时互动是核心的全部內容，希望文章能夠幫你解決所遇到的問題。

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